Where Are You Coming From Today?
Follow us on:
Por Daniel Seveso
En Exchange 2000 y 2003 las colas (queues) representan los distintos estados de los mensajes en el servidor al pasar por el motor de transporte. La acumulación de mensajes en en las colas de Exchange, es un síntoma que preocupa a los administradores, aunque no necesariamente representa un problema.
El artículo KB823489 describe las distintas colas de Exchange, sus funciones y cuáles pueden ser las causas de acumulación de mensajes en cada una de ellas.
Cuando nuestro servidor presenta problemas de desempeño, uno de los síntomas más comunes es la acumulación de mensajes en varias de estas colas simultáneamente. En este artículo trataremos este síntoma y su causa más común: El desempeño del subsistema de discos.
La cola de entrega local "Local Delivery", muestra los mensajes que serán entregados a buzones localizados en bases de datos del propio servidor. Cuando hay acumulación de mensajes en "Local Delivery" y simultáneamente en otras colas como "Messages awaiting directory lookup" "Messages pending submission" y/o "Messages waiting to be routed", podemos estar en presencia de un problema de desempeño o "performance" en el servidor.
Como diagnosticar si nuestro servidor tiene un problema de performance?
La forma más directa y simple es utilizar la herramienta "Performance" (perfmon.exe). La causa más común de los problemas de performance en un servidor de Exchange moderno, suele ser el subsistema de discos. Pero antes de seguir adelante, simplemente podemos descartar los otros dos componentes fundamentales CPU y Memoria como posibles causas, ya que es bastante más sencillo.
Un valor promedio menor a 75% para “% Processor Time” y un valor mayor a 10Mb para “Available MBytes” pueden considerarse dentro de lo normal. Si esta afirmación te parece muy simplista, podrás encontrar información completa en la guía de performance y escalabilidad de Exchange 2003.
Subsistema de discos:
Empecemos desde lo general a lo particular. Veamos cuanto es el tiempo de respuesta de los discos cuando el servidor está encolando mensajes. Los contadores Avg. Disk sec/Read y Avg. Disk sec/Write representan los segundos tarda el subsistema de disco en completar un requerimiento de lectura o escritura respectivamente. Listando estos dos contadores para todos las unidades lógicas (LogicalDisk) del sistema podemos ver rápidamente si alguno de ellos está sobrepasando los 20ms. En el ejemplo de abajo, vemos que el tiempo promedio de escritura en la unidad lógica G: son 44ms (0.044 segundos como lo indica el contador) que puede considerarse inaceptable para la mayoría de los componentes de Exchange.
Nota: Es importante distinguir entre los contadores discos lógicos (LogicalDisk) y discos físicos (PhysicalDisk). Cuando consideramos performance por componente lo apropiado es medirla en LogicalDisk, porque veremos claramente que componentes afecta. Una vez que tenemos esta vista, debemos inspeccionar los contadores de PhysicalDisk. El tiempo de respuesta siempre afecta a PhysicalDisks, por lo tanto necesitamos saber la relación o correspondencia de discos físicos a discos lógicos en el servidor. Esta relación puede ser menor (ejemplo: un disco físico dividido en varias particiones – peor caso desde el punto de vista de desempeño), igual (cada disco lógico representa un disco físico) o menor (un arreglo de discos físicos representando una unidad lógica).
En el ejemplo de abajo, vemos que las unidades lógicas C:, D: y E: corresponden a un único disco físico, por lo que el tiempo de respuesta en esas tres unidades será el mismo y cambiar componentes entre estas unidades para mejorar su performance no tendrá sentido alguno.
Una vez que damos el vistazo general de performance en el subsistema de discos, podemos seguir indagando para confirmar si realmente estos valores son la causa de los síntomas que vemos en el servidor.
Debemos conocer dónde están localizados los distintos componentes de Exchange que utilizan el subsistema de disco:
Dependiendo de la configuración de tu servidor de Exchange, estos componentes pueden estar localizados cada uno en su propio disco (mejor de los casos), hasta todos en el mismo disco (peor caso). Si todos los componentes de Exchange están en un único disco (por ejemplo, el servidor tiene solo un disco o arreglo físico), un valor promedio mayor a 20ms. para lectura o escritura en ese disco puede considerarse límite. Peores valores degradarán el desempeño del servidor causando encolamiento y demora en la respuesta a clientes cuando estos valores son sostenidos en el tiempo.
Mejores prácticas
Si la situación particular de tu servidor no es tan obvia, revisemos las mejores prácticas para la configuración de discos en Exchange y los valores de tiempo de acceso recomendados para cada componente. Si tienes más de un componente en un mismo disco físico, éste debería cumplir el requerimiento más exigente.
Componente
Mejor práctica
PhysicalDisk\Average Disk sec/Read
PhysicalDisk\Average Disk sec/Write
Archivo de paginación (page file)
Para un desempeño óptimo, la recomendación es configurar el archivo de paginación en discos independientes. RAID 1 es una buena opción para esta partición.
Avg: <10ms at all times
Colas de SMTP y MTA
Si la performance del servicio de smtp es importante para el rol de tu servidor, el disco para la cola de smtp debe tener la menor latencia de escritura posible. Se recomienda la utilización de RAID 0+1 o RAID 10. Si anticipamos mucha actividad de MTA además de SMTP debemos considerar particiones separadas para SMTP y MTA, y nunca configurar estos componentes junto a las bases de datos o logs de transacciones.
Avg: <10ms
Max: <50ms
Indices de Microsoft Search
Si usas la funcionalidad de Indexación de contenido (Content Index) considera localizar los índices en un disco independiente o en un disco con otro componente de acceso randómico como las bases de datos por ej. Evita configurarlo en el disco de logs o archivo de paginación.
Avg: <20ms
Directorio de Logs transaccionales (*.log)
Todas las transacciones son escritas primero en los logs de transacciones en forma secuencial. Por este motivo el disco utilizado para logs de transacciones debe tener la menor latencia de escritura posible. Si contamos con almacenamiento respaldado por baterías, es recomendado habilitar el cache para escritura (Write back caching) y optimizarlo para escritura frente a lectura si disponemos de esta opción. Se recomienda utilizar RAID 0+1 o RAID 10 en estas particiones
Avg: <5ms
Directorio de las bases de datos (*.stm, *.edb)
Los archivos de base de datos de un Storage Group deberían estár en un volumen dedicado. Este volumen debe tener alta velocidad de acceso randómico.
Adicionalmente a las razones de performance, la recuperabilidad de datos también aumenta si separamos las bases de datos de los logs de transacciones. (ver "Excange 2003 Disaster Recovery Operations Guide" en el sitio de Technet)
Si los valores de tiempos de acceso se encuentran dentro de estas recomendaciones, podremos descartar el subsistema de discos como causa del problema.
Ejemplo óptimo de configuración de discos en Exchange:
Disco
C:\
Partición de sistema, sistema operativo y archivos de instalación de Exchange RAID-1 (Discos locales, no SAN)
D:\
Archivo de paginación - RAID-1 (Discos locales, no SAN)
E:\
Colas de SMTP y MTA - RAID -0+1 or 10 (SAN)
F:\
Archivos de log de transacciones - RAID-1 (SAN)
G:\
Archivos de bases de datos *.edb y *.stm - RAID-0+1 o 10 (SAN)
Esta es una aproximación simplificada al problema. Aunque los conceptos de cache, relación entre ejes (spindles) y performance, y tipos de arreglo se mantienen vigentes, hay muchas otras variables consecuencia del avance en la tecnología de almacenamiento. La virtualización del almacenamiento hace que no sea tan fácil determinar exactamente qué tipo de arreglos estamos usando, dado que el servidor ve una unidad definida en una "caja negra". En casos más complejos, el almacenamiento puede estar compartido entre varios servidores, por lo que un arreglo físico puede terminar sirviendo dos perfiles distintos de acceso en distintos servidores. Por ejemplo una base de datos SQL en el servidor A puede estar localizada en el mismo arreglo físico que los logs de transacciones de Exchange de un servidor B, la base de datos se beneficia de un acceso aleatorio y los logs de un acceso secuencial. Por ende, uno de los dos se verá perjudicado en momentos de stress. Es recomendable contar con apoyo profesional de un técnico calificado en soluciones de almacenamiento al planificar, adquirir y configurar nuestra solución.
Referencias:
Optimizing Storage for Exchange Server 2003
Ruling Out Disk-Bound Problems
Troubleshooting Microsoft Exchange Server Performance
Cool.
Nice!
Cool!