Programe / ponga en cola grandes correos electrónicos en Exchange 2010, difiera hasta que la latencia disminuya


14

Mi reto

Tenemos servidores de Exchange en varios sitios, pero también a bordo de barcos. Los barcos están conectados a nuestra red a través de enlaces satelitales cuando están en el mar, pero cambian a puentes WiFi cuando están en el puerto.

Debido a la alta latencia (más de 500 ms) y los abandonos no infrecuentes (p. Ej., Cuando los barcos están girando), es probable que el intento de enviar correos electrónicos por encima de unos pocos megabytes en el mar falle y se vuelva a intentar hasta el límite ha sido conseguido. El resultado: el correo electrónico no se entrega y cada intento consume un valioso ancho de banda en el enlace satelital.

Una "solución" es limitar el tamaño máximo de correo electrónico para decir 5 MB, pero eso es difícil de usar y una restricción innecesaria mientras está en el puerto.

Idea aproximada

Lo que preferiría hacer es poner en cola todos los correos electrónicos más grandes que un límite establecido para su posterior entrega cuando está en el mar, mientras se envían todos los correos electrónicos pequeños de inmediato. Entonces estaba pensando en hacer ping al servidor de transporte del concentrador en nuestro centro de datos regularmente, cuando la latencia cae por debajo de ~ 400 ms, comenzaría a procesar la gran cola de correos electrónicos. Cuando la latencia aumenta más de 400 ms, enchufaría el agujero y dejaría que los correos electrónicos se vuelvan a poner en cola.

Ahora, no me he ensuciado mucho las manos con Exchange desde la versión 2003. En aquel entonces, podía programar correos electrónicos grandes para una entrega posterior, por lo que mi idea era hacer algo similar en Exchange 2010, luego escribir una forma de cambiar la entrega programación para correos electrónicos grandes entre 'siempre' y 'nunca'.

Obstáculo

No debería ser demasiado complicado crear un script como ese, pero luego leí que la función en la que confiaba se eliminó con Exchange 2007:

Esta era una característica presente en Exchange 2003, pero se ha eliminado para Exchange 2007. Se configuró en un conector SMTP con el "uso de tiempos de entrega diferentes para mensajes de gran tamaño".

TechCenter: ¿Es posible programar la entrega de correo electrónico según el tamaño en Exchange?

Preguntas

¿Es verdad? - ¿Esta característica ya no está presente en Exchange 2010, o simplemente se ha transformado en algo similar, que puedo usar para lograr mi objetivo? ¿Entonces qué?

¿Hay otra forma de diferir la entrega de correos electrónicos grandes en ciertos servidores de Exchange? Podría basarse en un cronograma o tal vez incluso requerir una acción específica: estoy bastante seguro de que habrá alguna forma de activar la entrega a través del script, solo necesito grandes correos electrónicos en una cola separada en los barcos.

¡Tus pensamientos sobre esto serán muy apreciados! :-)

Editar # 1: idea aproximada refinada

Me topé con dos CmdLets de PowerShell que creo que me pueden acercar bastante a mi objetivo:

Jugué un rato con Get-Message por un tiempo, para ver qué tipo de mensajes tratarían los comandos anteriores.

Lo más importante, estos comandos aceptan un filtro de tamaño de mensaje. Este comando enumerará los mensajes en cola, en el servidor actual, de más de 5 MB (5,242,880 bytes):

get-message -Filter {Size -gt 5242880}

Parece que Get-Messagesolo devuelve mensajes de varias colas de entrega remota. Pero, ¿los mensajes que fluyen dentro del servidor, aunque brevemente, aparecen en una cola con la que Get / Suspend / Resume-Message se meterá?

Si no, la solución podría ser tan simple como un script programado cada pocos minutos, en la línea de (en pseudocódigo):

if ping_rtt > 400 Then
    Suspend-Message -Filter {Size -gt 5242880}
Else
    Resume-Message
EndIf

Preocupaciones / preguntas de seguimiento:

Principalmente irrelevante ahora - ver edición # 2.

Será Get-Messagenunca los mensajes para entrega intra-servidor - sólo los mensajes de colas de entrega remota volver? Si no, ¿el nombre de identidad de las colas de entrega remota sigue un cierto patrón que puedo usar para filtrar?

¿Podría / debería hacerse esto a través de un agente de transporte personalizado (como lo sugiere @longneck) o un sumidero de eventos (si este concepto todavía existe en Exchange 2010)?

Digamos que ejecuto el script cada 5 minutos, lo que aún significa que se envían mensajes grandes, potencialmente puede causar problemas por hasta 5 minutos, antes de ser suspendido. Aún estaríamos mejor de lo que estamos ahora, pero no es óptimo. Podría aumentar la frecuencia a cada minuto, pero no sería la solución más elegante.

Incluso si solo verifico el tiempo de ida y vuelta cada 5 minutos (para ahorrar tráfico satelital), qué mecanismo de intercambio necesitaría configurar, para verificar el último RTT registrado, cada vez que se envía un mensaje que se envía a una entrega remota hacer cola y luego tomar una acción apropiada?

Editar # 2: Soluciones propuestas

Permítanme resumir las soluciones propuestas, y sus ventajas y desventajas tal como las veo:

Agente de transporte personalizado

Concepto

  • Controle periódicamente la latencia, clasifíquela como alta o baja (umbral: ¿400 ms?)
  • A través de un Agente de transporte personalizado, suspenda / reanude todos los correos electrónicos que superen un umbral establecido, cuando cambie la clasificación de latencia
  • A través del TA personalizado, ponga inmediatamente los mensajes grandes enviados posteriormente en modo "suspender", si la latencia es alta

Fortalezas

  • Los correos electrónicos grandes nunca se intentan entregar cuando la latencia es alta

Debilidades

  • No hay habilidades de desarrollo para hacer esto internamente (nota para mí mismo: el código fuente debe pertenecer a mi empresa como parte del contrato con el desarrollador externo)
  • El software de terceros que se vincula con Exchange puede causar problemas al parchar o actualizar
  • Se necesita algún tipo de acuerdo de soporte, en caso de que algo salga mal (ver arriba)

Mensajes grandes moderados

Concepto

  • Controle periódicamente la latencia, clasifíquela como alta o baja (umbral: ¿400 ms?)
  • Según la clasificación de latencia, configure las Reglas de transporte de Exchange mediante secuencias de comandos, para permitir que todos los mensajes fluyan o reenviar mensajes grandes al moderador
  • Aprobar mensajes en la cola del moderador cuando el barco está en el puerto, posiblemente por un humano

Fortalezas

  • Los correos electrónicos grandes nunca se intentan entregar cuando la latencia es alta
  • Los mensajes se suspenden utilizando las reglas de transporte de Exchange nativas nativas

Debilidades

  • Por lo que parece, los mensajes no pueden aprobarse programáticamente cuando la latencia es baja, por lo tanto, se requiere intervención humana cada vez que el barco está en el puerto
  • Posiblemente problemas de privacidad, si la moderación no se maneja mediante programación

Preguntas

  • ¿Se pueden aprobar los mensajes mediante programación desde el buzón del moderador? ¿Cómo?

Comandos programados de PowerShell

Concepto

  • Controle periódicamente la latencia, clasifíquela como alta o baja (umbral: ¿400 ms?)
  • Siempre que la latencia sea alta, con frecuencia (¿cada minuto?) Suspende cualquier mensaje grande ( Suspend-Message -Filter {Size -gt 5242880})
  • Cuando la latencia baje a baja, reanude todos los mensajes ( Resume-Message)

Fortalezas

  • Muy simple de implementar

Debilidades

  • No es la solución más elegante.
  • La entrega de cada nuevo mensaje grande se puede intentar durante el intervalo entre Suspend-Messagecomandos, posiblemente aún desperdiciando algo de ancho de banda y creando congestiones (aunque muy brevemente en comparación con no hacer nada)

Preguntas

  • ¿Alguna idea sobre cómo evitar los intentos de entregar mensajes grandes, entre Suspend-Messagecomandos?
  • Será Get-Messagenunca los mensajes para entrega intra-servidor - sólo los mensajes de colas de entrega remota volver? Si no, ¿el nombre de identidad de las colas de entrega remota sigue un cierto patrón que puedo usar para filtrar?

Editar # 3: El camino a seguir

Después de presentar las soluciones propuestas en mi equipo (incluido el proxy SMTP, que no pude incluir en la edición n. ° 2), y según mi propia intuición, decidimos optar por un Agente de transporte de Exchange personalizado.

Estoy en contacto con un par de empresas de consultoría, que me responderán cómo atacará el problema y cuánto costará.

Si tiene alguna experiencia con las tareas de programación de outsourcing, no dude en dejar comentarios a mi pregunta relacionada sobre Stack Overflow , porque no lo hago.


3
+1 para una de las mejores preguntas que he visto últimamente.
John Gardeniers

¿Qué roles tienen los servidores de Exchange en los barcos?
Agosto

Los servidores de Exchange en los barcos tienen los roles de Transporte de concentradores, Buzón y Acceso de cliente.
abstrask

1
¿Está ejecutando algún tipo de QoS o optimizador WAN en los enlaces satelitales?
cuello largo

Hmm con la función de buzón, también podría hacer que el enlace se sature cuando se envíe un correo externo a un buzón de alguien en el servidor de Exchange del barco ...
agosto

Respuestas:


2

Para resolver el problema de la manera que lo solicitó, puede escribir su propio Agente de transporte utilizando el SDK del Agente de transporte de Microsoft Exchange . Los agentes de transporte se basan en eventos, por lo que Exchange llamará a una función en su biblioteca cuando se reciba un mensaje. Su biblioteca puede hacer algo como retener el mensaje. Si no tiene las habilidades internas para hacer esto, estoy seguro de que podría contratar a un desarrollador para que lo escriba por usted.

Pero no creo que esta sea una gran solución. Como alternativa para que investigue, es posible que desee buscar algo como un proxy SMTP para enlaces de baja calidad. Como ha descubierto, SMTP es un protocolo horrible para enlaces de baja calidad porque una conexión interrumpida hace que la transmisión del mensaje se reinicie desde el principio en lugar de reanudarse desde donde se quedó. Si va a contratar a un desarrollador para algo, consideraría escribir un programa de servidor que acepte conexiones SMTP entrantes y envíe el mensaje a una instancia remota de este mismo programa en el otro extremo de la conexión satelital de manera reanudable ( posiblemente segregar los mensajes grandes de los mensajes pequeños a través del puerto TCP para permitir el tratamiento de QoS por su acelerador WAN). La instancia remota podría, luego de recibir el mensaje completo,


¡Gracias por tu contribución! Debo decir que es mucho menos original de lo que esperaba. Soy un gran admirador del principio KISS. Si bien no sé mucho sobre cómo escribir agentes de transporte, es algo convincente para mí mantener el manejo dentro de Exchange. En Exchange 2010, parece que las colas se crean y destruyen a pedido. Tal vez el agente podría forzar correos grandes en una cola separada y un script puede cambiar entre 'suspender' y 'reanudar'. ¿Alguna idea es que ese es el tipo de cosas que puedes hacer con los TA en Exchange 2010?
abstrask

En cuanto a la sugerencia SMTP proxy / smarthost, también suena como una solución correcta, si puedo encontrar una solución estándar, preferiblemente mantenida activamente. Parece ser una tarea de programación más compleja y más grande que un agente de transporte de Exchange, que modifica el flujo dentro de Exchange (¿podría estar equivocado?). Según mi experiencia, las soluciones complejas y personalizadas, como imagino que sería un proxy SMTP, tienden a ser costosas de soportar a largo plazo.
abstrask

re: separar las colas, no estoy lo suficientemente familiarizado con los aspectos internos de Exchange para saber si las colas funcionan así, o si esa es la mejor manera. Sé que un TA puede retener mensajes individuales para procesarlos según mi experiencia con Litera Metadact-e, que hace exactamente eso: retener un mensaje hasta que termine de procesarse (lo que puede llevar muchos minutos). No sé si es posible mantenerlos indefinidamente.
cuello largo

mi punto general de mi respuesta es que probablemente deberías consultar a un desarrollador ya que no hay una solución lista para usar. sin embargo, este es un problema bastante simple y la contratación de un desarrollador para resolver este problema por usted probablemente no tenga un costo prohibitivo.
cuello largo

La existencia del Suspend-Message PowerShell CmdLet se ha convencido de que el estado de entrega de los mensajes también se puede modificar mediante programación. Me gusta la idea de un agente de transporte personalizado, que simplemente modifique el estado de entrega del mensaje, a través de un proxy SMTP separado, ya que aún podremos mantener todo el seguimiento de mensajes, la delegación de derechos de administrador, etc., en Exchange. ¡Gracias por tu contribución!
abstrask

3

Moderación de mensajes

Una solución probablemente no ideal es usar una regla de transporte para reenviar mensajes de un tamaño determinado al administrador del remitente o al buzón designado (en el servidor de Exchange del barco) para moderación. De esta manera, si están en el mar, los mensajes grandes se pueden poner en cola en otro buzón. Cuando el barco llega a puerto, el gerente o moderador designado puede aprobar su entrega.

Los inconvenientes son:

  • esta regla siempre está activa a menos que la desactive manualmente (pero podría hacerse mediante un script) para que incluso en el puerto los mensajes grandes redirijan al buzón del moderador
  • todos los mensajes grandes necesitarían una revisión manual por parte de alguien antes de enviarlos, pero puede agregar excepciones en la regla para cosas específicas
  • otra persona estaría leyendo el correo saliente, lo que puede no ser ideal debido a problemas de privacidad, pero esto depende de su organización

Una ventaja es que un humano tomaría decisiones sobre si un mensaje debería enviarse o no, como si un usuario intentara enviar un montón de basura no relacionada con el trabajo que simplemente empantanaría la conexión sin ningún motivo. Podrían corregirse mediante controles administrativos como señalar una política y golpearlos en la muñeca para que no lo vuelvan a hacer.

Reglas de transporte de Exchange 2010

Script personalizado

RE: Un script personalizado para administrar correos electrónicos grandes. Podría ver algo como lo siguiente que habilitaría / deshabilitaría su conector de envío en el servidor de Exchange. Una desventaja es que todo el correo se mantiene en cola en lugar de solo mensajes grandes, pero algo de lógica en estas líneas debería funcionar:

  1. Verifique la latencia. Si es bajo, habilite el conector de envío, suspenda los mensajes grandes y espere 5 minutos (u otro período de tiempo arbitrario). Si es alto, deshabilite el conector de envío.
  2. Espera 5 minutos.
  3. Después de 5 minutos, verifique si hay mensajes grandes y suspenda. Vuelva a habilitar el conector de envío tan pequeño, los mensajes en cola se liberan hasta que la cola esté vacía (incluso puede recorrer un mensaje a la vez para no obstruir el enlace de cola / WAN después de volver a habilitar el conector de envío)
  4. Deshabilite el conector de envío y pase al # 1

Esta lógica no está completamente pulida para que tenga 100% de sentido, pero se le ocurre la idea: poner en cola todo el correo, verificar la latencia, suspender mensajes grandes si es alto, quitar el correo de la cola, poner en cola todo el correo, etc. Otra desventaja de la ejecución Un guión como este es si alguna vez se bloquea o se detiene, ¿cómo sabría reiniciarlo sin personal de TI a bordo de los barcos? Podría detener todo el correo saliente indefinidamente (si se detiene después de deshabilitar el conector de envío) o podría perder el control de mensajes grandes si deja el conector de envío habilitado y el script ya no se ejecuta.

Proxy SMTP

Aunque haya indicado que está en contra de cualquier manejo de mensajes fuera de Exchange, después de pensar en esto un poco más, he decidido que estoy con @longneck en el uso de algún tipo de solución de proxy SMTP. Incluso IIS SMTP tiene un mecanismo de entrega diferida que parecería que Exchange 2010 no tiene. Puede redirigir mensajes grandes al servidor SMTP de IIS que podría almacenarlos en el disco, y, primero para verificar la latencia, hacer que el servidor SMTP de IIS los envíe a través de un script cuando la latencia sea baja. El peor de los casos si su mecanismo de programación se atasca o detiene es que los mensajes grandes se atascan en el disco, pero los mensajes pequeños se siguen enviando. Probablemente hay mejores soluciones que IIS SMTP, y nunca lo he usado yo mismo, pero es solo un ejemplo.

Configurar el correo electrónico SMTP en IIS 7


¡Gracias por tu contribución! Si bien no se especificó directamente, es un requisito para mí que los correos electrónicos diferidos finalmente lleguen a su destino sin modificaciones. ¿Es ese el caso, cuando los reenvía por primera vez a un buzón de moderador, o dejará signos ocultos o visibles? En cuanto al proceso manual de aprobación, ¿creo que esto se puede escribir de alguna manera?
abstrask

Buena pregunta, y como nunca he implementado esto, creé una regla de prueba rápida en nuestra organización de Exchange y envié un correo electrónico de prueba. El moderador recibió el mensaje con la opción 'Aprobar' o 'Rechazar'. Una vez que aprobé el mensaje, fue liberado y enviado al destino sin modificaciones, sin signos del buzón del moderador en ninguna parte del encabezado del mensaje o del cuerpo del correo electrónico. Sin embargo, parece que no puedo encontrar nada sobre la secuencia de comandos del proceso de aprobación, por lo que es posible que deba designar a un humano para esta tarea.
Agosto

Muchas gracias por la idea. Creo que la regla se puede modificar fácilmente mediante secuencias de comandos, pero la parte de intervención humana es un gran inconveniente para nosotros, ya que no tenemos personal de TI dedicado a bordo. ¿Alguien sabe si los mensajes se pueden aprobar programáticamente y cómo?
abstrask

2

Intente echar un vistazo a las nuevas características de "Aceleración de mensajes" introducidas con Exchange 2010 SP1. Podría ser muy útil para su caso de uso.

http://technet.microsoft.com/en-us/library/bb232205(v=exchg.141).aspx


1
No estoy tan seguro de que la limitación de mensajes ayude en este escenario en particular. Al leer el artículo, parece más orientado a evitar que un servidor de transporte o perimetral se vea abrumado con una tonelada de mensajes, por lo que se aplica el costo para proporcionar un nivel de entrega de mensajes de tipo QoS. En este caso, aunque un solo usuario que envíe un mensaje de 10 MB podría saturar todo el enlace WAN, haciendo que otros servicios no estén disponibles. Un mecanismo de entrega diferida sería más apropiado, creo.
Agosto

1
Lo sentimos, pero mientras lo leo, "Limitación de mensajes" solo favorecerá el envío de mensajes más pequeños (de forma predeterminada, la proporción de mensajes normales a bajos es de 20: 1 ), no impide enviar mensajes más grandes. ¿Tiene una sugerencia más específica sobre cómo lograr mi objetivo? Gracias.
abstrask
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.