IaaS con SQL Server: ajuste de los umbrales de red del clúster de conmutación por error

En este artículo se presentan soluciones para ajustar el umbral de las redes de clúster de conmutación por error.

Síntoma

Al ejecutar Windows clúster de conmutación por error en IaaS con un grupo de disponibilidad SQL Server Always On, se recomienda cambiar la configuración del clúster a un estado de supervisión más relajada. La configuración del clúster de fábrica es restrictiva y podría provocar interrupciones innecesarios. La configuración predeterminada está diseñada para redes locales muy ajustadas y no tiene en cuenta la posibilidad de latencia inducida causada por un entorno multiinquilino como Windows Azure (IaaS).

Windows clústeres de conmutación por error de servidor supervisa constantemente las conexiones de red y el estado de los nodos de un clúster Windows servidor. Si un nodo no es accesible a través de la red, se toma la acción de recuperación para recuperar y poner las aplicaciones y servicios en línea en otro nodo del clúster. La latencia en la comunicación entre los nodos del clúster puede provocar el siguiente error:

Error 1135 (registro de eventos del sistema)

El nodo de clúster Node1 se quitó de la pertenencia activa al clúster de conmutación por error. La Servicio de clúster en este nodo puede que se haya detenido. Esto también puede deberse a que el nodo ha perdido la comunicación con otros nodos activos en el clúster de conmutación por error. Ejecute el Asistente para validar una configuración para comprobar la configuración de red. Si la condición persiste, compruebe si hay errores de hardware o software relacionados con los adaptadores de red de este nodo. Compruebe también si hay errores en cualquier otro componente de red al que esté conectado el nodo, como concentradores, conmutadores o puentes.

Ejemplo de Cluster.log:

0000ab34.00004e64::2014/06/10-07:54:34.099 DBG   [NETFTAPI] Signaled NetftRemoteUnreachable event, local address 10.xx.x.xxx:3343 remote address 10.x.xx.xx:3343
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] got event: Remote endpoint 10.xx.xx.xxx:~3343~ unreachable from 10.xx.x.xx:~3343~
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Marking Route from 10.xxx.xxx.xxxx:~3343~ to 10.xxx.xx.xxxx:~3343~ as down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] Checking to see if all routes for route (virtual) local fexx::xxx:5dxx:xxxx:3xxx:~0~ to remote xxx::cxxx:xxxd:xxx:dxxx:~0~ are down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] All routes for route (virtual) local fxxx::xxxx:5xxx:xxxx:3xxx:~0~ to remote fexx::xxxx:xxxx:xxxx:xxxx:~0~ are down
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [CORE] Node 8: executing node 12 failed handlers on a dedicated thread
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: Cleaning up connections for n12.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [Nodename] Clearing 0 unsent and 15 unacknowledged messages.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: n12 node object is closing its connections
0000ab34.00008b68::2014/06/10-07:54:34.099 INFO  [DCM] HandleNetftRemoteRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 1: Old: 05.936, Message: Response, Route sequence: 150415, Received sequence: 150415, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:28.000, Ticks since last sending: 4
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: closing n12 node object channels
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 2: Old: 06.434, Message: Request, Route sequence: 150414, Received sequence: 150402, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.665, Ticks since last sending: 36
0000ab34.0000a8ac::2014/06/10-07:54:34.099 INFO  [DCM] HandleRequest: dcm/netftRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 3: Old: 06.934, Message: Response, Route sequence: 150414, Received sequence: 150414, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.165, Ticks since last sending: 4
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 4: Old: 07.434, Message: Request, Route sequence: 150413, Received sequence: 150401, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:26.664, Ticks since last sending: 36
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realLocal>10.xxx.xx.xxx:~3343~</realLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realRemote>10.xxx.xx.xxx:~3343~</realRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualLocal>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualRemote>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Delay>1000</Delay>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Threshold>5</Threshold>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Priority>140481</Priority>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Attributes>2147483649</Attributes>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO  </struct mscs::FaultTolerantRoute>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO   removed
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: Lost quorum (3 4 5 6 7 8)
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: goingAway: 0, core.IsServiceShutdown: 0
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   lost quorum (status = 5925)

Causa

Hay dos opciones que se usan para configurar el estado de conectividad del clúster.

Retraso Esto define la frecuencia con la que se envían latidos de clúster entre nodos. El retraso es el número de segundos antes de que se envíe el siguiente latido. Dentro del mismo clúster, puede haber diferentes retrasos entre los nodos de la misma subred y entre los nodos, que se encuentran en subredes diferentes.

Umbral Esto define el número de latidos que se pierden antes de que el clúster tome medidas de recuperación. El umbral es un número de latidos. Dentro del mismo clúster, puede haber umbrales diferentes entre los nodos de la misma subred y entre los nodos que se encuentran en subredes diferentes.

De forma Windows Server 2016 establece SameSubnetThreshold en 10 y SameSubnetDelay en 1000 ms. Por ejemplo, si se produce un error en la supervisión de conectividad durante 10 segundos, se alcanza el umbral de conmutación por error, lo que hace que ese nodo se quite de la pertenencia al clúster. Esto da como resultado que los recursos se mueven a otro nodo disponible en el clúster. Se notifican errores de clúster, incluido el error de clúster 1135 (anterior).

Solución

Para resolver este problema, relaje las opciones de configuración de red del clúster. Consulte Latido y umbral.

Referencias

Para obtener más información sobre cómo optimizar Windows configuración de red del clúster, vea Tuning Failover Cluster Network Thresholds.

Para obtener información sobre el uso de cluster.exe para ajustar Windows configuración de red del clúster de clústeres, vea How to Configure Cluster Networks for a Failover Cluster.