Share via

Revisión de Windows recomendada para grupos de disponibilidad de bases de datos que ejecutan Windows Server 2008 R2

  • Article

Artículo original publicado el domingo, 20 de noviembre de 2011

A principios de agosto de este año, el equipo de Windows SE publicó el siguiente artículo de Knowledge Base (KB) que acompañó la revisión de software con respecto a un problema en clústeres de conmutación por error de Windows Server 2008 R2:

KB2550886 - Un error de comunicación transitorio hace que un clúster de conmutación por error de Windows Server 2008 R2 dejar de funcionar

Se recomienda encarecidamente usar esta revisión para todos los grupos de disponibilidad de base de datos que se extienden en varios centros de datos. Para los grupos que no se extienden en varios centros de datos, también es conveniente tener esta revisión. En este artículo se describe una condición de carrera y un problema de interbloqueo de base de datos de clúster que pueden ocurrir cuando un clúster de conmutación por error de Windows encuentra un error de comunicación transitorio. Existe la condición de carrera dentro de la lógica de reconexión de los nodos de clúster que se manifiesta cuando el clúster tiene errores de comunicación. Cuando esto sucede, hace que la base de datos de clúster deje de funcionar, lo que da como resultado una pérdida de quórum en el clúster de conmutación por error.

Tal como se describe en TechNet, un Grupo de disponibilidad de base de datos (DAG) depende de funcionalidad de clúster específica, incluida la base de datos de clúster. Para que un DAG pueda funcionar y proporcionar una alta disponibilidad, el clúster y la base de datos de clúster deben estar funcionando correctamente.

Microsoft encontró casos en los que se da un error de red transitorio (un error de comunicaciones de red que dura 60 segundos aproximadamente) y, en consecuencia, se interbloquea el clúster entero y se desmontan todas las bases de datos dentro del DAG. Como no es muy fácil determinar qué nodo de clúster está interbloqueado realmente, si un clúster de conmutación por error se interbloquea como consecuencia de la carrera de lógica de reconexión, el único modo de proceder disponible es reiniciar todos los miembros dentro del clúster entero para resolver la condición de interbloqueo.

El problema generalmente se manifiesta de forma de pérdida de quórum de clúster debido a un error de comunicación asimétrica (cuando dos nodos no pueden comunicarse entre sí pero aún pueden comunicarse con otros nodos). Si hay demoras entre otros nodos en la recepción de mensajes de reagrupación de clúster desde el Administrador de actualizaciones globales (GUM) de clúster, es posible que los mensajes de reagrupación se terminen recibiendo en un orden imprevisto. Cuando eso sucede, el clúster pierde quórum en vez de invocar el comportamiento imprevisto, que es quitar del clúster uno de los nodos que experimentó el error de comunicación inicial.

Generalmente, este error se manifiesta cuando existe latencia asimétrica (por ejemplo, donde la mitad de los miembros del DAG tienen una latencia de 1 ms, mientras que la otra mitad de los miembros del DAG tiene una latencia de 30 ms) para dos nodos de clúster que encuentran una conexión dañada entre el par. Si el primer nodo detecta una pérdida de conexión con suficiente anticipación al segundo nodo, puede darse una condición de carrera:

  • El primer nodo iniciará una reconexión del flujo entre los dos nodos. Esto hará que el segundo nodo agregue el nuevo flujo a sus datos.
  • Agregar el nuevo flujo destruye el viejo flujo y establece su controlador de error para que se ignore. En el caso de error, el viejo flujo es el que tuvo un error que todavía no se detectó.
  • Cuando se detecta la interrupción de conexión en el segundo nodo, este inicia una secuencia de reconexión propia. Si la interrupción de conexión se detecta en la ventana de competencia adecuada, el controlador de error del flujo con error se establece para que se ignore, y el proceso de reconexión no inicia una reconexión. Sin embargo, emite una pausa para la cola de envío, que detiene el envío de mensajes entre los nodos. Cuando se detienen los mensajes, esto impide que el GUM funcione correctamente y fuerza un reinicio de clúster.

Si efectivamente ocurre este problema, las consecuencias son muy malas para los DAG. En consecuencia, se recomienda implementar esta revisión en todos sus servidores de buzón que son miembros de un DAG, especialmente si el DAG se extiende en centros de datos. Esta revisión también puede representar un beneficio para los entornos que ejecutan entornos de Replicación continua de clúster y Clústeres de copia única de Exchange 2007.

Además de solucionar el problema que se describe más arriba, KB2550886 también incluye otras revisiones importantes de Windows Server 2008 R2 que también se recomiendan para los DAG:

Esta entrada de blog es una traducción. Puede consultar el artículo original en Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2