Solución de problemas de clúster con el identificador de evento 1135

Este artículo le ayuda a diagnosticar y resolver el identificador de evento 1135, que se puede registrar durante el inicio del servicio cluster en el entorno de clústeres de conmutación por error.

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versiones 21H2 y 20H2

Pruebe nuestro agente virtual : puede ayudarle a identificar y corregir rápidamente problemas comunes de replicación de Active Directory.

Página de inicio

El identificador de evento 1135 indica que se quitaron uno o varios nodos de clúster de la pertenencia activa al clúster de conmutación por error. Puede ir acompañado de los siguientes síntomas:

• Conmutación por error de clúster\nodes que se quitan de la pertenencia al clúster de conmutación por error activa:

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

• Identificador de evento 1069:

  Identificador de evento 1069: disponibilidad del servicio en clúster o de la aplicación

• Identificador de evento 1177 para la pérdida de cuórum:

  Identificador de evento 1177: cuórum y conectividad necesarios para el cuórum

• Identificador de evento 1006 para el servicio de clúster detenido:

  Identificador de evento 1006: inicio del servicio de clúster

Se recomienda una validación y las pruebas de red como uno de los pasos iniciales de solución de problemas para asegurarse de que no hay problemas de configuración que puedan ser una causa de problemas.

Compruebe si ha instalado las correcciones de acceso frecuente recomendadas.

El servicio cluster es el componente de software esencial que controla todos los aspectos de la operación del clúster de conmutación por error y administra la base de datos de configuración del clúster. Si ve el identificador de evento 1135, se recomienda instalar las correcciones mencionadas en los artículos siguientes y reiniciar todos los nodos del clúster y, a continuación, observar si el problema se repite.

• Revisiones y actualizaciones recomendadas para Windows Server 2012 clústeres de conmutación por error basados en R2
• Revisiones y actualizaciones recomendadas para clústeres de conmutación por error basados en Windows Server 2012
• Revisiones y actualizaciones recomendadas para clústeres de conmutación por error de Windows Server 2008 R2 SP1

Compruebe si el servicio de clúster que se ejecuta en todos los nodos

Siga el siguiente comando según el sistema operativo Windows para validar que el servicio de clúster se está ejecutando continuamente y disponible.

Para el clúster de Windows Server 2008 R2

Desde un símbolo del sistema con privilegios elevados, ejecute cluster.exe node /stat.

Para Windows Server 2012 y Windows Server 2012 clúster de R2

Ejecute el siguiente cmdlet de PowerShell: Get-ClusterResource

¿El servicio de clúster se ejecuta continuamente y está disponible en todos los nodos?

Varios escenarios de id. de evento 1135

Queremos que eche un vistazo más de cerca a los registros de eventos del sistema en todos los nodos del clúster. Revise el identificador de evento 1135 que ve en los nodos y copie todas las instancias de este evento. Esto le permitirá verlos y revisarlos.

Event ID 1135
Cluster node ' **NODE A** ' was removed from the active failover cluster membership. The Cluster service on this node may have stopped. 
This could also be due to the node having lost communication with other active nodes in the failover cluster. 
Run the Validate a Configuration wizard to check your network configuration. 
If the condition persists, check for hardware or software errors related to the network adapters on this node. 
Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

Hay tres escenarios típicos:

Escenario A

Está examinando todos los eventos y todos los nodos del clúster indican que NODE A había perdido la comunicación.

Podría ser posible que, al ver los registros del sistema en NODE A, tenga eventos para todos los nodos restantes del clúster.

Solución

Esto sugiere bastante que en el momento del problema, ya sea debido a la congestión de red o de lo contrario, se perdió la comunicación con el NODO A.

Debe revisar y validar los problemas de comunicación y configuración de red. No olvide buscar problemas relacionados con el nodo A.

Escenario B

Está examinando los eventos en los nodos y supongamos que el clúster está disperso entre dos sitios. NODE A, NODE B y NODE C en el sitio 1 y NODE D & NODE E en el sitio 2.

En los nodos A, B y C, verá que los eventos que se registran son para la conectividad con los nodos D & E. De forma similar, cuando se ven los eventos en los nodos D & E, los eventos sugieren que hemos perdido la comunicación con A, B y C.

Solución

Si ve una actividad similar, es indicativo de que se produjo un error de comunicación, a través del vínculo que conecta estos sitios. Se recomienda revisar la conexión entre los sitios; si se trata de una conexión WAN, se recomienda comprobar con el ISP la conectividad.

Escenario C

Está examinando los eventos en los nodos y verá que los nombres de los nodos no se contabilizan con ningún patrón determinado. Supongamos que el clúster está disperso en dos sitios. NODE A, NODE B y NODE C en el sitio 1 y NODE D & NODE E en el sitio 2.

• En el nodo A: verá eventos para los nodos B, D, E.
• En el nodo B: verá eventos para los nodos C, D, E.
• En el nodo C: verá eventos para los nodos A, B, E.
• En el nodo D: verá eventos para los nodos A, C, E.
• En el nodo E: verá eventos para los nodos B, C, D.
• O cualquier otra combinación.

Solución

Estos eventos son posibles cuando los canales de red entre los nodos se ahogan y los mensajes de comunicación del clúster no llegan a tiempo, lo que hace que el clúster sienta que la comunicación entre los nodos se pierde, lo que provoca la eliminación de los nodos de la pertenencia al clúster.

Revisión de redes de clúster

Se recomienda revisar las redes de clúster comprobando las tres opciones siguientes, una por una, para continuar con esta guía de solución de problemas.

Comprobación de la exclusión del antivirus

Excluya las siguientes ubicaciones del sistema de archivos del examen de virus en un servidor que ejecuta Cluster Services:

• Ruta de acceso del testigo de FileShare
• La carpeta %Systemroot%\Cluster

Configure el componente de examen en tiempo real dentro del software antivirus para excluir los siguientes directorios y archivos:

• Directorio de configuración de máquina virtual predeterminado (C:\ProgramData\Microsoft\Windows\Hyper-V)

• Directorios de configuración de máquinas virtuales personalizados

• Directorio predeterminado de la unidad de disco duro virtual (C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks)

• Directorios de unidades de disco duro virtuales personalizadas

• Directorios de datos de replicación personalizados, si usa réplica de Hyper-V

• Directorios de instantáneas

• mms.exe

  Nota:

  Es posible que este archivo tenga que configurarse como una exclusión de proceso dentro del software antivirus.

• Vmwp.exe

  Nota:

  Es posible que este archivo tenga que configurarse como una exclusión de proceso dentro del software antivirus.

Además, al usar Live Migration junto con volúmenes compartidos de clúster, excluya la ruta de acceso CSV C:\Clusterstorage y todos sus subdirectorios. Si está solucionando problemas de conmutación por error o problemas generales con los servicios de clúster y el software antivirus está instalado, desinstale temporalmente el software antivirus o compruebe con el fabricante del software para determinar si el software antivirus funciona con los servicios de clúster. Simplemente deshabilitar el software antivirus es insuficiente en la mayoría de los casos. Incluso si deshabilita el software antivirus, el controlador de filtro se sigue cargando al reiniciar el equipo.

Comprobación de la configuración del puerto de red en el firewall

El servicio de Cluster Server controla las operaciones del clúster de servidores y administra la base de datos de clúster. Un clúster es una agrupación de equipos independientes que actúan como un solo equipo. Administradores, programadores y usuarios consideran el clúster como un solo sistema. El software distribuye los datos entre los nodos del clúster. Si un nodo da error, otros nodos proporcionan los servicios y datos que hasta ese momento había proporcionado el nodo que falta. Cuando se agrega o repara un nodo, el software del clúster migra algunos datos a ese nodo.

Nombre del servicio del sistema: ClusSvc

Aplicación	Protocolo	Puertos
Servicio de clúster	UDP	3343
Servicio de clúster	TCP	3343 (este puerto es obligatorio durante una operación de combinación de nodos)
RPC	TCP	135
Administración de clúster	UDP	137
Kerberos	UDP/TCP	464*
SMB	TCP	445
Puertos UDP elevados asignados aleatoriamente**	UDP	Número de puerto aleatorio entre 1024 y 65535 Número de puerto aleatorio entre 49152 y 65535***

Nota:

Además, para una validación correcta en clústeres de conmutación por error de Windows en Windows Server 2008 y versiones posteriores, permita el tráfico entrante y saliente para ICMP4, ICMP6.

• Para obtener más información, consulte Creación de un clúster de conmutación por error de Windows Server 2012 se produce un error 0xc000005e.
• Para obtener más información sobre cómo personalizar estos puertos, vea la sección "Referencias" en Información general del servicio y requisitos de puertos de red para Windows.

Este es el intervalo de Windows Server 2012, Windows 8, Windows Server 2008 R2, Windows 7, Windows Server 2008 y Windows Vista.

Además, ejecute el siguiente comando para comprobar la configuración del puerto de red en el firewall. Por ejemplo: este comando ayuda a determinar el puerto 3343 available\open usado para el clúster de conmutación por error:

netsh advfirewall firewall show rule name="Failover Clusters (UDP-In)" verbose

Ejecute el informe de validación del clúster para ver si hay errores o advertencias.

La herramienta de validación de clústeres ejecuta un conjunto de pruebas para comprobar que el hardware y la configuración son compatibles con los clústeres de conmutación por error.

Siga estas instrucciones:

1. Ejecute el informe de validación del clúster para ver si hay errores o advertencias. Para obtener más información, consulte Descripción de las pruebas de validación de clúster: red

   

2. Compruebe si hay advertencias y errores para redes. Para obtener más información, consulte Descripción de las pruebas de validación de clúster: red.

   

   

Comprobar el orden de enlace de red de lista

En esta prueba se muestra el orden en que las redes se enlazan a los adaptadores de cada nodo.

La pestaña Adaptadores y enlaces enumera las conexiones en el orden en que los servicios de red acceden a las conexiones. El orden de estas conexiones refleja el orden en el que las llamadas/paquetes TCP/IP genéricos se envían a la conexión.

Siga los pasos siguientes para cambiar el orden de enlace de los adaptadores de red:

1. Seleccione Inicio, Ejecutar, escriba ncpa.cply, a continuación, seleccione Aceptar. Puede ver las conexiones disponibles en la sección LAN y High-Speed Internet de la ventana Red Connections.
2. En el menú Opciones avanzadas , seleccione Configuración avanzada y, a continuación, seleccione la pestaña Adaptadores y enlaces .
3. En el área Connections, seleccione la conexión que desea mover más arriba en la lista. Use los botones de flecha para mover la conexión. Como regla general, la tarjeta que habla con la red (conectividad de dominio, enrutamiento a otras redes, etc.) debe ser la primera tarjeta enlazada (parte superior de la lista).

Los nodos de clúster son sistemas de varios hogares. La prioridad de red afecta al cliente DNS para la conectividad de red saliente. Los adaptadores de red usados para la comunicación de cliente deben estar en la parte superior en el orden de enlace. Las redes no enrutadas se pueden colocar con menor prioridad. En Windows Server 2012 y Windows Server 2012 R2, el adaptador del controlador de red de clúster (NETFT.SYS) se coloca automáticamente en la parte inferior de la lista de pedidos de enlace.

Comprobar la validación de la comunicación de red

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.

Esta prueba valida que los servidores probados puedan comunicarse con una latencia aceptable en todas las redes.

Por ejemplo: en Validar comunicación de red, puede ver los mensajes siguientes para problemas de latencia de red:

Succeeded in pinging network interface node003.contoso.com IP Address 192.168.0.2 from network interface node004.contoso.com IP Address 192.168.0.3 with maximum delay 500 after 1 attempt(s).
Either address 10.0.0.96 is not reachable from 192.168.0.2 or **the ping latency is greater than the maximum allowed 2000 ms** 
This may be expected, since network interfaces node003.contoso.com - Heartbeat Network and node004.contoso.com - Production Network are on different cluster networks
Either address 192.168.0.2 is not reachable from 10.0.0.96 or **the ping latency is greater than the maximum allowed 2000 ms** 
This may be expected, since network interfaces node004.contoso.com - Production Network and node003.contoso.com - Heartbeat Network for MSCS are on different cluster networks

En el caso del clúster de varios sitios, puede aumentar los valores de tiempo de espera. Para obtener más información, consulte Configuración de latidos y dns en un clúster de conmutación por error de varios sitios.

Compruebe con ISP si hay problemas de conectividad WAN.

Compruebe si encuentra alguno de los siguientes problemas.

Paquetes de red perdidos entre nodos

1. Comprobación de la pérdida de paquetes mediante el rendimiento

   Si el paquete se pierde en la conexión en algún lugar entre los nodos, se producirá un error en los latidos. Podemos averiguar fácilmente si se trata de un problema mediante el uso de Monitor de rendimiento para ver el contador "Interfaz de red\Paquetes recibidos descartados". Una vez que haya agregado este contador, examine los números Promedio, Mínimo y Máximo y, si son valores superiores a cero, el búfer de recepción debe ajustarse para el adaptador.

   

   Si experimenta la pérdida de paquetes de red en la plataforma de virtualización de VMware, consulte la sección "Clúster instalado en la plataforma de virtualización de VMware".

2. Actualización de los controladores de NIC

   Este problema puede producirse debido a controladores nic obsoletos\Componentes de integración (IC)\VmTools o adaptadores de NIC defectuosos. Si se pierden paquetes de red entre nodos en máquinas físicas, haga que el controlador del adaptador de red se actualice. 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.

Clúster instalado en la plataforma de virtualización de VMware

Compruebe los problemas del adaptador de VMware en el caso del entorno de VMware.

Este problema puede producirse si los paquetes se quitan durante las ráfagas de tráfico elevadas. Asegúrese de que no se produzca ningún filtrado de tráfico (por ejemplo, con un filtro de correo). Después de eliminar esta posibilidad, aumente gradualmente el número de búferes en el sistema operativo invitado y compruebe.

Para reducir las caídas de tráfico de ráfaga, siga estos pasos:

1. Seleccione Inicio, seleccione Ejecutar, escriba devmgmt.msc y presione Entrar.
2. Expanda Adaptadores de red, haga clic con el botón derecho en vmxnet3 y seleccione Propiedades.
3. Seleccione la pestaña Opciones avanzadas.
4. Seleccione Búferes de rx pequeños y aumente el valor. El valor predeterminado es 512 y el máximo es 8192.
5. Seleccione Rx Ring #1 Size (Tamaño del anillo rx n.º 1 ) y aumente el valor. El valor predeterminado es 1024 y el máximo es 4096.

Consulte los artículos siguientes para comprobar los problemas del adaptador de VMware en el caso del entorno de VMware:

• Nodos que se quitan de la pertenencia a clústeres de conmutación por error en VMware ESX.
• Pérdida de paquetes grandes en el nivel de sistema operativo invitado en el VMXNET3 vNIC en ESXi

Observe cualquier congestión de red

La congestión de red también puede causar problemas de conectividad de red.

Compruebe que la red está configurada según las recomendaciones de MS y proveedor, consulte Configuración de redes de clústeres de conmutación por error de Windows.

Comprobación de la configuración de red

Si todavía no funciona, compruebe si ha visto una red con particiones en la GUI del clúster o si tiene habilitada la formación de equipos nic en la NIC de latido.

Si ve la red con particiones en la GUI del clúster, consulte Redes de clúster con particiones para solucionar el problema.

Si tiene habilitada la formación de equipos nic en la NIC de latido, compruebe la funcionalidad de software de formación de equipos según la recomendación del proveedor de formación de equipos.

Actualización de los controladores de NIC

Este problema puede producirse debido a controladores NIC obsoletos o adaptadores de NIC defectuosos.

Si se pierden paquetes de red entre nodos en máquinas físicas, haga que el controlador del adaptador de red se actualice. 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.

Comprobación de la configuración de red

Si todavía no funciona, compruebe si ha visto una red con particiones en la GUI del clúster o si tiene habilitada la formación de equipos nic en la NIC de latido.