Back pressure monitoriza características del motor de transporte de Exchange Server 2007 con el objetivo de evitar una sobrecarga del equipo ocasionados por un mal dimensionamiento o picos puntuales de tráfico de correo. Back pressure está activo por defecto en todos los servidores Exchange 2007 con el rol HUB Transport o EDGE Transport instalado.

Concretamente son cinco áreas las que se monitorizan:

• Espacio libre en el disco donde se almacena la base de datos de la cola de mensajes
• Espacio libre en el disco donde se almacenan los registros de transacciones de la cola de mensajes
• Número de transacciones en cola no completadas que existen en memoria
• Cantidad de memoria utilizada por el proceso EdgeTransport.exe
• Cantidad de memoria utilizada por el resto de los procesos

Para cada uno de estos recursos de sistema, se aplican tres niveles de utilización:

• Normal   El recurso no se está utilizando en exceso. El servidor acepta conexiones y mensajes nuevos.
  
• Medio   El recurso se está sobreutilizando ligeramente. Se aplica back pressure al servidor con limitaciones. Puede recibir correo de remitentes autenticados del dominio. En cambio, el servidor rechaza conexiones y mensajes nuevos de otras fuentes.
  
• Alto   El recurso se está utilizando en exceso. Se aplica back pressure completamente. Se detiene el flujo de mensajes y el servidor rechaza todas las conexiones y mensajes nuevos.

Pues bien, esta configuración que aparentemente podría aplicarse en la mayoría de los escenarios, es posible que no sea del todo adecuada para aquellos escenarios en donde haya un alto nivel de tráfico de correo, ya sea por el alto número de usuarios simultáneos o por otras causas como el tipo de mensajes que se envían, por ejemplo mensajes muy grandes.

Lo primero que debemos tener en cuenta es que hay que realizar un adecuado dimensionamiento de la infraestructura y balancear la carga entre varios equipos con el fín de evitar esta sobrecarga. Es probable que necesitemos revisar aspectos como cantidad de memoria física disponible en cada servidor, para ajustar la capacidad de la máquina al tráfico de correo de la organización. Recordemos que Exchange Server 2007 requiere al menos 2 GB de RAM para cualquiera de sus roles.

Pero, ¿qué sucede si a pesar de haber dimensionado adecuadamente y tener la capacidad física de la máquina según las recomendaciones del producto, nos encontramos que hay momentos en que nuestro servidor Hub o Edge dejan de aceptar nuevos mensajes? Entonces es hora de ir a revisar la configuración de Back Pressure, y esto lo podemos realizar a partir de unos umbrales guardados en un archivo de configuración en formato XML fácilmente editable.

El archivo lo podemos encontrar de forma predeterminada en C:\Archivos de programa\Microsoft\Exchange Server\Bin\EdgeTransport.exe.config.

Lo primero que debemos considerar es si mantenemos la monitorización (altamente recomendado) o por el contrario la deshabilitamos.

• EnableResourceMonitoring  Este parámetro habilita o deshabilita la presión de reserva. El valor predeterminado es TRUE.
• ResourceMonitoringInterval  Este parámetro controla la frecuencia con la que se comprueban los niveles de utilización de los recursos del sistema en hh:mm:ss. El valor predeterminado es 00:00:02. Se puede configurar desde 00:00:01 hasta 00:00:30.

Otros valores configurables son, por ejemplo el espacio libre en el disco donde se almacena la base de datos de la cola de mensajes.

El cálculo de estos umbrales es un tanto curioso porque no se utilizan valores fijos, sino dinámicos, basados en una fórmula y a partir de la cual los tres umbrales (alto, medio y bajo) dependen. La formula es: 100*(tamaño de unidad de disco duro - 4 GB) / tamaño de unidad de disco duro, es decir que si tenemos un disco duro de 200 GB, los umbrales quedarían así: Alto: 98% 100*(200-4)/200, Medio: 96%, Bajo: 94%

Todos los valores se calculan en porcentaje, y lo que realmente consigue la fórmula es garantizar que siempre habrá al menos 4GB de espacio libre para la cola de mensajes. También es posible configurar estos umbrales con valores reales que pueden ir de 0 a 300.

• PercentageDatabaseDiskSpaceUsedHighThreshold  El valor predeterminado es 0, lo que indica que se utilizará la fórmula predeterminada.
• PercentageDatabaseDiskSpaceUsedMediumThreshold  El valor predeterminado es 0, lo que indica que valor real es un 2% inferior al valor de PercentageDatabaseDiskSpaceUsedMediumThreshold.
• PercentageDatabaseDiskSpaceUsedNormalThreshold  El valor predeterminado es 0, lo que indica que el valor real es un 2% inferior al valor de PercentageDatabaseDiskSpaceUsedMediumThreshold.

Pero es poco frecuente llegemos a colapsar el servidor de transporte por falta de espacio en disco, a no ser que, por una mala administración se llene el disco debido a otros servicios o actividades. Lo que si puede suceder más frecuentemente es que el servidor deje de aceptar mensajes porque el número de transacciones en memoria sin confirmar se haya elevado por encima del umbral establecido. De hecho yo ya he tenido que enfrentarme a esta situación algunos dias después de haber finalizado un proyecto de implantación.

En este caso, los valores que podemos revisar son:

• VersionBucketsHighThreshold Valor predeterminado 100
• VersionBucketsMediumThreshold Valor predeterminado 60
• VersionBucketsNormalThreshold Valor predeterminado 40
    

Estos valores se pueden configurar desde 1 a 8000, siempre teniendo en cuenta que el umbral medio debe ser menor al alto y el bajo menor al medio. Si el número de transacciones en memoria sin confirmar supera el umbral medio, el servidor dejará de aceptar nuevos mensajes que provengan de fuentes externas sin auntenticar, por ejemplo, otros servidores SMTP. Si se supera el umbral alto, entonces dejará de aceptar cualquier mensaje nuevo, provenga de donde provenga, hasta que el número de transacciones se normalice.

Habitualmente esto suecede en breves segundos, y puede estar ocasionado por oleadas de correo no deseado (SPAM), picos de tráfico de correo de los propios usuarios u otros motivos. Si fuera necesario, se pueden incrementar los tres umbrales, teniendo siempre en cuenta que si no contamos con la capacidad de hardware necesaria, podríamos estar causando una sobrecarga real en el equipo.

Me he encontrado en alguna ocasión que después de haber finalizado un proyecto de implantación de Exchange Server 2007, el servidor perimetral (Edge Transport) o el servidor Central (Hub Transport) comienzan a experimentar extrañas interrupciones en el servicio de recepción y envío de correo.

Pues bien, no hay que alarmarse, ya que probablemente estemos experimentando una nueva característica de protección que incorpora Exchange Server 2007 en sus servicios de transporte llamada Back Pressure. El Back Pressure es una funcionalidad de monitorización constante de diversos umbrales de rendimiento que al llegar a ciertos límites, hace que Exchange bloquee cualquier tipo de envío o incluso recepción de mensaje de correo.

A primera vista esto pudiera parecer contraproducente, pero lo cierto es que es un nuevo mecanismo de protección ante por ejemplo, intentos de ataques por denegación de servicio (DoS) o saturación del servidor por una mala configuración o falta de recursos. Exchange Server 2007, asume que antes de llegar a un punto crítico de colapso, es perferible dejar de aceptar mensajes hasta que la situación vuelva a la normalidad, habitualmente en breves segundos.

Sin embargo, debemos tener en cuenta que no todas las organizaciones tienen el mismo nivel de tráfico de correo, por lo tanto, una deficiente configuración de Hardware podría hacer que este proceso de bloqueo se repita más frecuentemente, sobre todo en los momentos de más carga de trabajo.

Microsoft recomienda hacer una revisión de las causas que provocan la saturación y no  modificar los valores por defecto, aunque alternativamente, se pueden configurar dichos valores de umbrales de Back Pressure para ajustarlos adecuadamente a organizaciones con un alto volumen de tráfico.

En la siguiente entrega comentaré cómo configurar estos valores y que es exáctamente lo que monitoriza Exchange Server 2007.

Para saber como se está comportando nuestro servidor perimetral (Edge transport) con respecto a los niveles SCL (Spam Confidence Level) en un periodo determinado, podemos extraer un pequeño informe con el siguiente cmdlet:

• Get-AgentLog -StartDate "dd/mm/aaaa hh:mm:ss" -EndDate "dd/mm/aaaa hh:mm:ss" | ft timestamp,IPaddress,P1FromAddress,recipients,action,reason,
  reasondata | out-String -Width 180 > C:\listaSCL.txt

Para poder recuperar el proceso de replicación entre los nodos, debemos hacer lo siguiente:

• Suspendemos la réplica manualmente desde elñ Shell de Administración de Exchange con suspend-storageGroupCopy -identity "<NOMBRE DEL ALMACEN>"
• Eliminamos manualmente los archivos .log del almacén con problemas en el nodo pasivo
• Reiniciamos la réplica indicando que se debe crear una nueva copia de la base de datos con update-StorageGroupCopy -identity "<SERVIDOR\NOMBRE DEL ALMACEN>" -deleteExistingFiles

Con estos pasos debemos poder ver de nuevo la réplica iniciandose, algo parecido a esto:

Adicionalmente podemos comprobar que efectivamente la replicación se está reiniciando, observando el proceso de creación de la carpeta temp-seeding y posteriormente la replicación física de los archivos .log del nodo activo hacia el nodo pasivo del cluster.

Otra comprobación que se puede realizar para garantizar que todo el proceso se está ejecutando correctamente es ver cómo la cola de transacciones pendientes de transferir entre los nodos se reduce a medida que se confirman dichas transacciones en el nodo pasivo. Esto se puede observar con el cmdlet get-StorageGroupCopyStatus

Recientemente fui nombrado MVP de Exchange Server, por lo tanto que mejor que comenzar este blog con un articulo dedicado a este excepcional producto. Seguro muchos de vosotros ya lo conoceis, y seguro lo teneis implantado en vuestras organizaciones. Exchange Server 2007 ha incluido muchas características nuevas y mejoras en diversos ámbitos, las cuales iré comentado proximamente.

Me quiero centrar en la replicación continua de cluster o CCR. Esta funcionalidad de replicación de archivos de transacciones entre nodos permite disponer de un entorno de alta disponibilidad en donde los nodos del cluster estén geográficamente dispersos, minimizando así el posible impacto de una pérdida severa de uno de los centros de datos o ubicaciones físicas.

Sin embargo, no hace falta plantear escenarios catastróficos para caer en riesgos que puedan alterar el correcto funcionamiento de CCR, por ejemplo: ¿que sucede cuando nos quedamos sin espacio en disco en el nodo pasivo?

Lo primero que observaremos es que Exchange tratará de interrumpir la replicación en tantos grupos de almacenamiento como sea necesario, con el objetivo de no seguir consumiendo el poco espacio que pudiera quedar. Esto lo podemos comprobar en el visor de eventos del nodo pasivo

El evento 428 de ESE indica que se ha rechazado cualquier actualización de la base de datos debido a la falta de espacio en disco. Evidentemente, esto se produce antes de que se quede el equipo completamente sin espacio.

Pues bien, ¿que pasos debemos seguir para poder solucionar este problema? Lo primero será tratar de liberar espacio, eliminando archivos innecesarios y tratar de reiniciar la réplica para posteriormente hacer una copia de seguridad completa que libere los archivos .log de nuestro disco lleno.

Hay que decir que si esta situación se produce, la creación de copias de seguridad completas no hace que se eliminen los .log ni del nodo activo, ni del pasivo. Esto es debido a que Exchange debe comprobar que la transacciones se han aplicado correctamente en la copia de la base de datos antes de poder eliminarlos.