Exchange Server 2010 y tiempos de espera de disco de Windows

Artículo original publicado el jueves, 17 de noviembre de 2011

Unos pocos meses atrás, Bruce Langworthy escribió un excelente artículo sobre algunas nuevas recomendaciones para establecer el valor de tiempo de espera de disco de Windows: https://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx.

Esta entrada me hizo pensar sobre Exchange y cómo lidiamos con los problemas de E/S. Si no leyó el artículo de Bruce, se explica que el tiempo de espera de disco predeterminado de 60 segundos significa que Windows no informará la interrupción de funcionamiento de E/S por 60 segundos y no reintentará la E/S por 8 minutos. 8 minutos es demasiado para esperar antes de reintentar una interrupción de funcionamiento de E/S. Por lo tanto, Microsoft está publicando nuevas instrucciones que recomiendan cambiar la opción de tiempo de espera de disco de Windows a un valor que esté en línea con su arquitectura de almacenamiento.

La pregunta que tenía en mente para Exchange era simple, ¿cómo afecta este comportamiento de tiempo de espera de disco a las implementaciones de DAG de Exchange? ; más específicamente ¿debo reducir el tiempo de espera de disco de Windows en mis servidores Exchange de acuerdo con las nuevas recomendaciones o no debo modificar nada?

Para responder a esta pregunta, me acerqué a algunos de nuestros programadores de ESE para conocer sus opiniones… Esto es lo que surgió del debate…

• El valor de tiempo de espera de disco de Windows está pensado principalmente para registro de eventos y el reintento de E/S.
• Antes de Exchange Server 2010, Exchange no hacía nada con respecto a una E/S lenta, excepto informar estos casos en el registro de eventos.
• Exchange Server 2010 RTM introdujo la revisión de página preferente (sobrescritura de página en limpio) para aquellas páginas afectadas por E/S lenta.
• Exchange Server 2010 SP1 es la primera versión de Exchange que incluye inteligencia para lidiar con E/S que deja de funcionar y provocará activamente un error en el servidor (comprobación de errores) si la E/S que dejó de funcionar está afectando a las bases de datos activas en un nodo de DAG.

Decidí que antes de poder determinar qué hacer con nuestra configuración de tiempo de espera de disco, primero debemos comprender qué inteligencia introdujo Exchange Server 2010 SP1 y cómo podría interactuar con tiempos de espera de disco.

Recuperación de Motor de almacenamiento extensible de Exchange Server 2010 SP1 en E/S que dejó de funcionar

Exchange Server 2010 SP1 trajo consigo algunas excelentes mejoras en la forma de lidiar con E/S que dejó de funcionar. Estas mejoras se analizan en detalle en el siguiente artículo de TechNet https://technet.microsoft.com/en-us/library/ff625233.aspx:

“Exchange 2010 SP1 incluye lógica de recuperación nueva que aprovecha el comportamiento de comprobación de errores de Windows integrado cuando se dan ciertas condiciones, específicamente, cuando E/S deja de funcionar. En SP1, el Motor de almacenamiento extensible (ESE) se actualizó para detectar E/S que dejó de funcionar y realizar acción correctiva para recuperar automáticamente el servidor. ESE mantiene un subproceso guardián de E/S que detecta cuando hay una E/S que está pendiente durante un período de tiempo específico. De forma predeterminada, si una E/S para una base de datos está pendiente durante más de un minuto, ESE registrará un evento. Si una base de datos tiene una E/S pendiente durante más de 4 minutos, registrará un evento de error específico, si es posible hacerlo. El evento de ESE 507, 508, 509 o 510 puede o no registrarse, según la naturaleza de la E/S que dejó de funcionar. Si la naturaleza del problema es tal que el volumen de SO se ve afectada o la capacidad de escribir en el registro de eventos se ve afectada, no se registrarán los eventos. Si se registran los eventos, el servicio de replicación de Microsoft Exchange (MSExchangeRepl.exe) detectará esa condición y provocará intencionalmente una comprobación de errores de Windows mediante la terminación del proceso wininit.exe”.

Entonces, ¿qué significa eso? Bien, después de debatir un poco (y buscar código ESE), se creó la siguiente tabla para hacer que sea más fácil entender el comportamiento (incluí versiones anteriores de Exchange como referencia).

Nota: realmente deseo agradecer inmensamente en este punto a Alexandre Costa y Brett Shirley, programadores de ESE dentro del equipo de Exchange. Sin ellos, esta información no hubiera sido posible. ¡Gracias!

Nota: E/S en desarrollo describe una operación de E/S lenta que todavía no se completó correctamente. La E/S completada representa una E/S lenta que se completó, pero que tardó más de 30 segundos. Es importante tener en cuenta aquí que antes de Exchange Server 2010 no existía el concepto de detectar E/S en desarrollo, solo informábamos una vez que la E/S se había completado.

No me gusta este nuevo comportamiento, ¿qué puedo hacer al respecto?

Al igual que con la mayoría de cosas, le recomendaría que no cambie el nuevo comportamiento a menos que tenga un motivo bien definido y convincente para hacerlo... Sin embargo, si efectivamente necesita modificar el nuevo comportamiento de la recuperación de motor de almacenamiento extensible en E/S que dejó de funcionar, existen algunas claves del registro y algunos atributos de Active Directory que le permiten hacerlo y que están documentados aquí.

Conclusión

Si regresamos al motivo por el que empecé a escribir este artículo, era evaluar si debíamos reducir el TimeOutVale de disco de Windows en los nodos de servidor de DAG de Exchange tal como se recomienda aquí.

Después de hablar con Matt Gossage en el equipo de Exchange (Matt sabe todo sobre Exchange y E/S), explicó que una de las cosas que el tiempo de espera de disco hace es proteger al host de las tormentas de restablecimiento de bus. Uno de los efectos secundarios interesantes cuando una E/S llega al TimeOutVale de disco de Windows es que el controlador disk.sys emite un restablecimiento de bus; este restablecimiento afecta a todos los LUN del servidor, no solo el LUN que no responde.

El caso más común donde se observó este comportamiento es con el almacenamiento JBOD y Exchange 2010. Donde una solución RAID se implementó, la controladora de disco puede trabajar con las lecturas de bloques dañados al leer los datos de otro disco o volver a calcular los datos a partir de la paridad; esto demora la E/S, pero no significativamente. Con JBOD, existe solo una copia del bloque de datos y, por lo tanto, existe la posibilidad de que un bloque dañado haga que la E/S deje de funcionar mientras esperamos que el disco intente leer los datos. Lo importante aquí es que con una implementación JBOD no debemos reducir el TimeOutValue de disco y, de hecho, es posible que debamos aumentarlo para reducir los efectos de una tormenta de restablecimiento de bus si uno de los ejes del disco JBOD comience a fallar.

En la siguiente tabla se incluyen las instrucciones recomendadas para establecer el HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue para servidores que ejecutan el rol de buzón de Server 2010.

Neil Johnson
Consultor senior, UK MCS

Esta entrada de blog es una traducción. Puede consultar el artículo original en Windows Disk Timeouts and Exchange Server 2010