Partage via

IaaS avec SQL Server - Paramétrage des seuils réseau du cluster de basculement

  • Article

Cet article présente des solutions pour ajuster le seuil des réseaux de cluster de basculement.

Symptôme

Lorsque vous exécutez des nœuds de cluster de basculement Windows dans IaaS avec un groupe de disponibilité Always On SQL Server, la modification du paramètre de cluster par un état de surveillance plus détendu est recommandée. Les paramètres de cluster prêt à l’emploi sont restrictifs et peuvent entraîner des pannes inutiles. Les paramètres par défaut sont conçus pour des réseaux locaux hautement optimisés et ne tiennent pas compte de la possibilité d’une latence provoquée par un environnement multilocataire tel que Microsoft Azure (IaaS).

Le cluster de basculement Windows Server analyse en permanence l’intégrité des nœuds dans un cluster Windows. Si un nœud n’est pas accessible sur le réseau, une action de récupération est effectuée pour récupérer des applications et services et les mettre en ligne sur un autre nœud du cluster. La latence de communication entre les nœuds de cluster peut entraîner l’erreur suivante :

Erreur 1135 (journal des événements système)

Le nœud de cluster 1 a été supprimé de l’appartenance au cluster de basculement actif. Le service de cluster sur ce nœud peut avoir été arrêté. Une autre raison peut être que le nœud a perdu la communication avec d’autres nœuds actifs dans le cluster de basculement. Exécutez l’Assistant Valider une configuration pour vérifier votre configuration réseau. Si la condition persiste, recherchez les erreurs matérielles ou logicielles liées aux cartes réseau sur ce nœud. Recherchez également des défaillances dans d’autres composants réseau auxquels le nœud est connecté, comme les hubs, les commutateurs ou les ponts.

exemple 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)

Cause

Deux paramètres sont utilisés pour configurer l’intégrité de la connectivité du cluster.

Délai : définit la fréquence à laquelle les pulsations de cluster sont envoyées entre les nœuds. Le délai correspond au nombre de secondes avant l’envoi de la pulsation suivante. Dans le même cluster, il peut y avoir différents paramètres de délai configurés entre les nœuds du même sous-réseau, et entre les nœuds de sous-réseaux différents.

Seuil : définit le nombre de pulsations qui sont manquées avant l’action de récupération du cluster. Le seuil est un nombre de pulsations. Dans le même cluster, il peut y avoir diffénts seuils configurés entre les nœuds du même sous-réseau, et entre les nœuds de sous-réseaux différents.

Par défaut, Windows Server définit SameSubnetThreshold sur 10 et SameSubnetDelay sur 1 000 ms. Par exemple, si la surveillance de la connectivité échoue pendant 10 secondes, le seuil de basculement est atteint, ce qui entraîne la suppression du nœud inaccessible de l’appartenance au cluster. Cela entraîne le déplacement des ressources vers un autre nœud disponible sur le cluster. Les erreurs de cluster sont signalées, notamment l’erreur de cluster 1135 (ci-dessus).

Résolution

Pour résoudre ce problème, relâchez les paramètres de configuration réseau du cluster. Consultez Pulsations et seuil.

Références

Pour plus d’informations sur l’ajustement des paramètres de configuration réseau du cluster Windows, consultez Ajustement des seuils réseau du cluster de basculement.

Pour plus d’informations sur l’utilisation de cluster.exe pour paramétrer les paramètres de configuration réseau du cluster Windows, consultez Comment configurer des réseaux de cluster pour un cluster de basculement.