2 votes

Comment supprimer les itinéraires périmés lors du redémarrage du cluster Windows ?

CONTEXTE

J'ai un cluster Windows (2016) avec quatre nœuds (3 NICs chacun). Lorsque j'essaie de redémarrer l'un des serveurs hôtes du cluster, tout le cluster tombe en panne et les autres nœuds tombent en panne de manière aléatoire.

Lorsque j'ai déposé un dossier auprès de Microsoft, ils m'ont dit que c'était à cause des routes périmées dans la table NETFT qui n'est pas effacée lors du redémarrage et ils m'ont donné une solution pour redémarrer tous les nœuds afin d'activer le cluster.

J'ai l'impression que cela va prendre beaucoup de temps avant que je redémarre mes serveurs physiques et que je mette en place mon cluster. J'ai un accord de niveau de service qui pourrait être rompu.

Existe-t-il une solution de rechange utile ?

RÉPONSE DE MICROSOFT

De cluster.log le problème semble lié aux routes périmées sur NetFT.sys .

Analyse du journal

(Les erreurs ci-dessous ont continué à se produire sur les 4 nœuds du cluster, en prenant l'une de ces occurrences comme exemple :)

HOST1

2018/09/24-18:25:01.067 INFO  [FTI][Initiator] This node (1) is initiator
2018/09/24-18:25:01.067 WARN  [FTI][Initiator] `Ignoring duplicate connection: usable route already exists`
2018/09/24-18:25:01.067 INFO  [CHANNEL 192.1.0.172:~3343~] graceful close, status (of previous failure, may not indicate problem) (0)
2018/09/24-18:25:01.068 WARN  cxl::ConnectWorker::operator (): GracefulClose(1226)' because of 'channel to remote endpoint 192.1.0.172:~3343~ is closed'

HOST2

2018/09/24-18:25:01.095 INFO  [FTI][Initiator] This node (2) is initiator
2018/09/24-18:25:01.095 WARN  [FTI][Initiator] `Ignoring duplicate connection: usable route already exists`
2018/09/24-18:25:01.095 INFO  [CHANNEL 192.1.0.172:~3343~] graceful close, status (of previous failure, may not indicate problem) (0)
2018/09/24-18:25:01.096 WARN  cxl::ConnectWorker::operator (): GracefulClose(1226)' because of 'channel to remote endpoint 192.1.0.172:~3343~ is closed'

HOST3

2018/09/24-18:25:01.057 INFO  [FTI][Follower] This node (4) is not the initiator
2018/09/24-18:25:01.057 DBG   [FTI] Stream already exists to node 1: false
2018/09/24-18:25:01.057 DBG   [CHANNEL 192.1.0.170:~62824~] Close().
2018/09/24-18:25:01.057 INFO  [CHANNEL 192.1.0.170:~62824~] graceful close, status (of previous failure, may not indicate problem) (0)
2018/09/24-18:25:01.057 INFO  [CORE] Node 4: Clearing cookie [GUID]
2018/09/24-18:25:01.057 DBG   [CHANNEL 192.1.0.170:~62824~] Not closing handle because it is invalid.
2018/09/24-18:25:01.058 WARN  mscs::ListenerWorker::operator (): GracefulClose(1226)' because of 'channel to remote endpoint 192.1.0.170:~62824~ is closed'

HOST4

2018/09/24-18:25:01.087 INFO  [FTI][Initiator] This node (3) is initiator
2018/09/24-18:25:01.087 WARN  [FTI][Initiator] `Ignoring duplicate connection: usable route already exists`
2018/09/24-18:25:01.087 INFO  [CHANNEL 192.1.0.172:~3343~] graceful close, status (of previous failure, may not indicate problem) (0)
2018/09/24-18:25:01.088 WARN  cxl::ConnectWorker::operator (): GracefulClose(1226)' because of 'channel to remote endpoint 192.1.0.172:~3343~ is closed'

Ces routes périmées sont la cause de l'impossibilité pour les nœuds de rejoindre le cluster et c'est la raison pour laquelle le nœud n'a pas été en mesure de rejoindre le cluster.

Pour NetFT, en tant que réseau en grappe, si un membre inattendu est supprimé, la table de routage NetFT n'est pas effacée. La connexion est maintenue.

Lorsque le nœud initiateur a essayé de créer une nouvelle connexion, comme la table de routage contenait toujours l'ancienne, les nœuds n'ont finalement pas réussi à se reconnecter à la grappe. NETFT est un pilote de niveau noyau et c'est pourquoi nous devons redémarrer les nœuds pour rafraîchir la table NETFT.

Plan d'action

Essayez de redémarrer tous les nœuds du cluster en même temps pour supprimer les routes périmées.

0voto

JotaBe Points 119

Je viens d'en faire l'expérience ce week-end sur un cluster SQL AlwaysOn à deux nœuds. J'ai dû redémarrer le nœud principal pour le récupérer. Cela s'est produit après quelques changements sur le réseau et la mise à jour Windows Update Parcheando le même jour.

J'ai lancé pssdiag pour extraire le journal du cluster et j'ai vu exactement les mêmes entrées. Je l'ai relancé après le redémarrage et elles avaient disparu.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X