IaaS con SQL Server: optimización de 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 de 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 SQL Server Always On, se recomienda cambiar la configuración del clúster a un estado de supervisión más relajado. La configuración del clúster de fábrica es restrictiva y podría provocar interrupciones innecesarias. La configuración predeterminada está diseñada para redes locales muy optimizadas y no tiene en cuenta la posibilidad de latencia inducida causada por un entorno multiinquilino como Microsoft Azure (IaaS).

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

Error 1135 (registro de eventos del sistema)

El nodo de clúster 1 se quitó de la pertenencia al clúster de conmutación por error activa. Es posible que el servicio cluster de este nodo se haya detenido. Esto también podría deberse a que el nodo ha perdido la comunicación con otros nodos activos del 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 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 una acción 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 predeterminada, 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 no se pueda acceder a ese nodo de la pertenencia al clúster. Esto da lugar a que los recursos se muevan a otro nodo disponible en el clúster. Se notificarán errores de clúster, incluido el error de clúster 1135 (anterior).

Solución

Para resolver este problema, relaje los valores 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 umbrales de red de clústeres de conmutación por error.

Para obtener información sobre el uso decluster.exe para ajustar los valores 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.