Tener un problema con los nodos que se quitan de la pertenencia a clústeres de conmutación por error activa

En este artículo se presenta cómo resolver los problemas en los que los nodos se quitan de la pertenencia al clúster de conmutación por error activa aleatoriamente.

Síntomas

Cuando se produce el problema, verá eventos como este evento registrado en el registro de eventos del sistema:

Este evento se registra en todos los nodos del clúster, excepto en el nodo que se quitó. El motivo de este evento se debe a que uno de los nodos del clúster marcó ese nodo como inactivo. A continuación, notifica a todos los demás nodos del evento. Cuando se notifica a los nodos, interrumpen y interrumpen sus conexiones de latido con el nodo inactivo.

¿Qué hizo que el nodo se marcase como inactivo?

Todos los nodos de un clúster de conmutación por error de Windows 2008 o 2008 R2 se comunican entre sí a través de las redes establecidas para permitir la comunicación de red del clúster en esta red. Los nodos envían paquetes de latido a través de estas redes a todos los demás nodos. Se supone que los otros nodos reciben estos paquetes y, a continuación, se devuelve una respuesta. Cada nodo del clúster tiene sus propios latidos que va a supervisar para asegurarse de que la red está en marcha y de que los demás nodos están activos. El ejemplo siguiente debe ayudar a aclarar este comportamiento:

Si no se devuelve ninguno de estos paquetes, el latido específico se considera erróneo. Por ejemplo, W2K8-R2-NODE2 envía una solicitud y recibe una respuesta de W2K8-R2-NODE1 a un paquete de latido para que determine la red y el nodo esté activo. Si W2K8-R2-NODE1 envía una solicitud a W2K8-R2-NODE2 y W2K8-R2-NODE1 no obtiene la respuesta, se considera un latido perdido y W2K8-R2-NODE1 realiza un seguimiento de él. Esta respuesta perdida puede hacer que W2K8-R2-NODE1 muestre la red como inactiva hasta que se reciba otra solicitud de latido.

De forma predeterminada, los nodos de clúster tienen un límite de cinco errores en 5 segundos antes de que se marque la conexión. Por lo tanto, si W2K8-R2-NODE1 no recibe la respuesta cinco veces en el período de tiempo, considera que la ruta determinada a W2K8-R2-NODE2 está inactiva. Si se sigue considerando que otras rutas están activas, W2K8-R2-NODE2 permanecerá como miembro activo.

Si todas las rutas están marcadas para W2K8-R2-NODE2, se quita de la pertenencia al clúster de conmutación por error activa y se registra el evento 1135 que se ve en la primera sección. En W2K8-R2-NODE2, el servicio de clúster se finaliza y, a continuación, se reinicia para que pueda intentar volver a unirse al clúster.

Para obtener más información sobre cómo se controlan rutas específicas con tres o más nodos, consulte el blog "Partitioned" Cluster Networks (Redes de clúster con particiones ) escrito por Jeff Hughes.

Ahora que sabemos cómo funciona el proceso de latido, ¿cuáles son algunas de las causas conocidas para que se produzca un error en el proceso?

1. Errores reales de hardware de red. Si el paquete se pierde en la conexión en algún lugar entre los nodos, los latidos fallan. Un seguimiento de red de ambos nodos implicados lo revelará.

2. El perfil de las conexiones de red podría estar rebotando de Dominio a Público y volver a Dominio de nuevo. Durante la transición de estos cambios, se puede bloquear la E/S de red. Para comprobar si este es el caso, consulte el registro operativo del perfil de red. Para encontrar este registro, abra el Visor de eventos y vaya a Registros de aplicaciones y servicios\Microsoft\Windows\NetworkProfile\Operational. Examine los eventos de este registro en el nodo que se mencionó en el identificador de evento 1135 y vea si el perfil estaba cambiando en este momento. Si es así, consulta El perfil de ubicación de red cambia de "Dominio" a "Público" en Windows 7 o en Windows Server 2008 R2.

3. Tiene IPv6 habilitado en los servidores, pero tiene las dos reglas siguientes deshabilitadas para Entrante y Saliente en el Firewall de Windows:

   • Redes principales: anuncio de detección de vecinos
   • Redes principales: solicitud de detección de vecinos

4. El software antivirus también podría interferir con este proceso. Si sospecha esto, pruebe deshabilitando o desinstalando el software. Haga esto por su cuenta y riesgo porque en este momento está desprotegido de virus.

5. La latencia en la red también podría hacer que esto suceda. Es posible que los paquetes no se pierdan entre los nodos, pero es posible que no lleguen a los nodos lo suficientemente rápido antes de que expire el período de tiempo de espera.

6. IPv6 es el protocolo predeterminado que la agrupación en clústeres de conmutación por error usará para sus latidos. El latido en sí es un paquete de red de unidifusión UDP que se comunica a través del puerto 3343. Si hay conmutadores, firewalls o enrutadores que no están configurados correctamente para permitir este tráfico, puede experimentar problemas como este.

7. Las actualizaciones de directivas de seguridad de IPsec también pueden causar este problema. El problema específico es que, durante una actualización de la directiva de grupo de IPSec, todas las asociaciones de seguridad de IPsec (SA) se desmantela mediante firewall de Windows con seguridad avanzada (WFAS). Mientras esto sucede, toda la conectividad de red está bloqueada. Al renegociar las asociaciones de seguridad si hay retrasos en la realización de la autenticación con Active Directory, estos retrasos (donde se bloquea toda la comunicación de red) también impedirán que los latidos del clúster pasen y harán que la supervisión del estado del clúster detecte nodos como inactivos si no responden dentro del umbral de 5 segundos.

8. Controladores de tarjetas de red antiguos o obsoletos o firmware. A veces, una configuración incorrecta simple de la tarjeta de red o del conmutador también puede causar pérdida de latidos.

9. Las tarjetas de red modernas y las tarjetas de red virtual podrían estar experimentando pérdida de paquetes. Para realizar un seguimiento de esto, abra Monitor de rendimiento y agregue el contador "Interfaz de red\Paquetes recibidos descartados". Este contador es acumulativo y solo aumenta hasta que se reinicia el servidor. Ver un gran número de paquetes descartados aquí podría ser una señal de que los búferes de recepción en la tarjeta de red están establecidos demasiado bajo o que el servidor está funcionando lentamente y no puede controlar el tráfico entrante. Cada fabricante de tarjetas de red elige si se expone esta configuración en las propiedades de la tarjeta de red, por lo que debe consultar el sitio web del fabricante para aprender a aumentar estos valores y se deben usar los valores recomendados. Si se ejecuta en VMware, en el blog siguiente se habla de esto con un poco más de detalle, incluido cómo saber si se trata del problema, así como el artículo de VMware sobre la configuración que se va a cambiar.

   Nodos que se quitan de la pertenencia a clústeres de conmutación por error en VMware ESX

Estas son las razones más comunes por las que se registran estos eventos, pero también podría haber otras razones. El punto de este blog era darle algo de información sobre el proceso y también dar ideas de lo que se debe buscar. Algunos elevarán los siguientes valores a sus valores máximos para intentar que este problema se detenga.

Parámetro	Valor predeterminado	Rango
SameSubnetDelay	1000 milisegundos	250-2000 milisegundos
CrossSubnetDelay	1000 milisegundos	250-4000 milisegundos
SameSubnetThreshold	5	3-10
CrossSubnetThreshold	5	3-10

Aumentar estos valores hasta su máximo podría hacer que el evento y la eliminación del nodo desaparezcan, simplemente enmascara el problema. No soluciona nada. Lo mejor es averiguar la causa principal de los errores de latido y solucionarlo. La única necesidad real de aumentar estos valores es en un escenario de varios sitios en el que los nodos residen en ubicaciones diferentes y no se puede superar la latencia de red.