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

  • Artículo

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

Síntoma

Al ejecutar nodos de clúster de conmutación por error de Windows en IaaS con un grupo de disponibilidad AlwaysOn de SQL Server, se recomienda cambiar la configuración del clúster a un estado de supervisión más relajado. La configuración del clúster está lista para usar y podría provocar interrupciones innecesarias. La configuración predeterminada está diseñada para redes locales altamente optimizadas y no tiene en cuenta la posibilidad de latencia inducida causada por un entorno multiinquilino como Microsoft Azure (IaaS).

La característica de clústeres de conmutación por error de Windows Server supervisa constantemente las conexiones de red y el estado de los nodos en un clúster de Windows. 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)

Nodo de clúster Nodo 1 se quitó de la pertenencia activa al clúster de conmutación por error. Es posible que el servicio de clúster de este nodo 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.

Cluster.log ejemplo:

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 : define la frecuencia con la que se envían los latidos del clúster entre los 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 definidos entre los nodos de la misma subred, y entre los nodos que se encuentran en subredes diferentes.

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

De forma predeterminada, Windows Server 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 da lugar a que ese nodo se quite de la pertenencia al clúster. Esto hace que los recursos se muevan a otro nodo disponible en el clúster. Se notificarán errores de clúster, incluido el error 1135 (anterior) del clúster.

Resolució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 ajustar las opciones de configuración de red del clúster de Windows, consulte Ajuste de los umbrales de red del clúster de conmutación por error.

Para obtener información sobre el uso de cluster.exe para ajustar las opciones de configuración de red del clúster de Windows, consulte Configuración de redes de clúster para un clúster de conmutación por error.