Mise à jour VxRail 4.5 vers 4.7. Que s’est-il vraiment passé ?

Et oui, j’ai été un peu trop optimiste sur ce coup là. Mon dernier billet de compte-rendu que vous pouvez lire ici-même semblait en témoigner, le chantier de mise à jour récente de notre principal cluster VxRail ne s’est, au final et après plusieurs semaines, pas si bien passé que cela. Plutôt que mettre à jour l’article original et comme j’ai pas mal de choses à vous raconter, j’ai préféré en créer un nouveau. Le voici.

EDIT: j’ai rajouté une section “edit” spécifique en fin d’article pour la recherche de root cause. Très intéressant à suivre. Revenez-y régulièrement si vous voulez des nouvelles ^^

Quoi ? C’est ENCORE un problème réseau ?

Tout a commencé le 8 Avril dernier. Comme déjà évoqué, nous sommes parti de la version VxRail 4.5.225 pour nous diriger tout droit vers la dernière update en date 4.7.111. Je ne vais pas rentrer dans le détail du début de semaine en question, que j’ai déjà décrit et qui s’est, lui, globalement très bien passé. Commençons donc par la fin, le “dernier jour” de la migration, Mercredi 10 Avril.

Ce mercredi, donc, le dernier serveur “esx09” (oui les migrations ne se passent pas dans l’ordre des numéros d’index des ESXi, rapport à l’ordre de leur numéro de série) démarre sa mise à jour. Au bout d’une heure et demi environ, la machine ressort de maintenance et tout semble terminé. Sauf que dans la pratique elle ne semble pas avoir correctement synchronisé son dvSwitch avec le vCenter. Après investigation et quelques tests, impossible de remettre la machine en état, elle refuse de ré-intégrer le dvSwitch du cluster et certains portgroups sont dans un état incohérent. Sans trop rechercher la root cause et pour aller vite, décision est prise avec le support Dell EMC de ré-imager la machine et la ré-intégrer ensuite au cluster.

Je vous passe les détails (que je ne connais pas trop moi-même d’ailleurs), mais cette réinstallation n’a pas été de tout repos pour l’ingénieur Dell EMC sur place (big up à Pierre-Eric) qui a pas mal galéré avant d’obtenir un serveur compatible avec notre dernière build. Mais bon, bref, au final, il se passe une semaine complète (période où j’étais en congés en plus… finalement, c’est bien tombé ^^) et nous nous retrouvons le Mardi 23 Avril (déjà 15 jours après le lancement de la mise à jour) pour ré-intégrer ensemble le serveur fraîchement ré-installé.

L’opération semble bien se passer et cette fois-ci le dvSwitch est bien synchro, sauf qu’une fois sorti de maintenance, l’ESXi ne réplique aucune données VSAN et refuse encore de prendre des VMs. Par ailleurs, des vMotions forcés tombent en échec systématiques et même des déplacement à froid de petites machines et tentatives de Power On échouent aussi. Houston ?

Nous escaladons à Dell EMC et parallèlement, sentant que la situation commence à se compliquer, je tente aussi une approche directe en ouvrant un call chez VMware avec l’aide de David, notre bienveillant VTAM. Parallèlement à cela, je commence de mon coté à creuser aussi (vous me connaissez, pas mon style de laisser un problème en plan ^^). Nous avions déjà évoqué avec David plusieurs pistes :
– un souci avec vCenter que l’on avait migré en 6.7 peu de temps avant,
– un souci avec l’image VxRail packagée utilisée
– ou des soucis réseau …
Après quelques tests basiques et la vérification de la configuration du serveur, rien ne semble me sauter aux yeux. J’ai donc essayé de rentrer un peu plus dans le diagnostic en testant la connectivité des interfaces vmkernel (mgmt, vmotion, vsan) via vmkping.

Je me rends compte assez vite que l’ESXi ping bien ses copains de cluster, que ce soit sur les interfaces de management, vmotion et vsan … SAUF le witness ! Précision importante : le witness de notre cluster se trouve sur un troisième site et est accessible via du niveau 3 et à travers 2 routeurs, alors que les autres serveurs sont dans le même subnet au sein de nos deux datacenters.

L’IP de management du witness était pingable, mais l’ip “VSAN” ne l’était pas depuis la vmkernel VSAN du serveur. En gros, “on a un souci de gateway, très vraisemblablement”. Bingo. En regardant dans la configuration réseau du vmkernel VSAN, je constate que la gateway est celle “par défaut” de l’ESXi (donc du management).

… après avoir modifié les paramètres pour indiquer à la vmkernel VSAN la bonne gateway, ça marche beaucoup mieux … OU PAS ! J’avais toujours des soucis de vMotion. Pour le coup, mon sang n’a fait qu’un tour et j’ai vérifié la configuration réseau VSAN de chaque serveur. Bien m’en a pris : en effet, ce sont quasiment tous les serveurs du cluster (à l’exception d’un seul… mystère) dont la gateway des vmkernel VSAN avait sauté ! Gloups. Cela signifie donc que l’on tournait sans witness depuis … un moment, au moins depuis le démarrage de la migration, sans pour autant avoir des alertes visibles coté vCenter. En fait, étant donné qu’il restait un serveur encore bien connecté, je me demande si le vCenter, recevant des informations contradictoires des machines et n’a pas un peu perdu les pédales lui-même vis à vis des alertes/status VSAN.

Quelques clics plus tard, les 20 machines retrouvaient leur gateway et tout rentrait dans l’ordre : vMotion, démarrage de VMs etc. Vous allez me dire “comment se fait-il qu’on ne s’en soit pas rendu compte plus tôt, hors alertes vCenter ?”. Certes, notre production vit beaucoup et l’arrêt redémarrage de VM ainsi que les vMotion sont courant chez nous. Sauf que nous étions en pleine période de migration du cluster doublée d’une période de congés. En gros : plus personne n’avait le droit de toucher à quoi que ce soit… CQFD. Accessoirement, cela nous a appris aussi que si le witness du cluster VSAN n’est pas joignable/en maintenance, la création de VM, leur démarrage ou leur déplacement n’est pas possible.

Aujourd’hui, je n’ai toujours pas de réponse ni d’explication au fait que la default gateway des vmkernel ait sauté : est-ce un souci spécifique VxRail dans le scripting ou est-ce un bug de migration ESXi… le mystère reste entier. J’attends le retour de Dell EMC à ce sujet.

Ouf, notre cluster était enfin au complet et à nouveau parfaitement fonctionnel. Il restait juste à mettre à jour notre Witness. Une formalité bien sûr …

Le witness fait son tatillon

Première chose étrange qui aurait du nous mettre la puce à l’oreille, impossible de mettre à jour le Witness via Update Manager (sans message explicite pour autant). Pourtant, cela fait partie des “options possibles” proposé par VMware. La machine était systématiquement affichée comme “Incompatible” au lieu d’un “Non compliant” plein d’espoir. Qu’à cela ne tienne, on va faire cela à l’ancienne en mettant à jour via du esxcli software bien roots. L’installation via le “offline vib” se passe bien et il est temps de redémarrer la VM. Et … bien non, lors de l’initialisation de l’ESXi, on obtient une erreur fatale “Incompatible CPU”. La plateforme d’hébergement de la VM est pourvue de bon vieux CPU Intel Xeon X5690 “Westmere”, alors que le service minimum d’un Witness VSAN 6.7 est désormais du “Sandy Bridge” de type Xeon E5-xxxx. Heu oui, mais alors non, comment va-t-on faire !?

C’était sans compter sur nos Zorros de la production et la disponibilité miracle d’un serveur de test avec des CPUs “Sandy Bridge”. Qu’à cela ne tienne, quelques jours et un déménagement physique plus tard, le witness pouvait être hébergé sur un CPU compatible et migré directement via “Update Manager” en ESXi 6.7.

Le bilan

Bon… que faut-il retenir de cette deuxième épopée à l’heure où je vous parle. D’une, que c’est toujours la faute du réseau t’asson. Plus sérieusement :
– Quoi qu’on en dise, les migrations de clusters VSAN, qu’on soit dans le monde VxRail ou le monde VSAN Ready Nodes n’est pas une mince affaire et qu’il faut prendre le maximum de précautions, même si tout vous parait limpide dans l’ordonnancement.
– Que même si VxRail est une plateforme packagée, avec son support unique, vous n’êtes pas à l’abris de déconvenues et de difficultés, qu’il faut anticiper quoi qu’il arrive.
– Que lorsque vous planifiez une mise à jours VSAN/vSphere, vérifiez quarante fois s’il le faut la matrice de compatibilité et la matrice de support (que j’ai du vous linker au moins 20 ou 30 fois sur ce blog : la homepage est ici)
– Bon … vérifiez aussi vos gateway si jamais vous avez le même comportement que chez nous ^^. Un petit script PowerCLI rien que pour vous pourra vous y aider :

… en espérant que ce billet ne soit pas encore mis à jour. Oui, je ne vous ai pas dit, mais lors d’un passage de VSAN 6.6 à 6.7, il faut reformatter tous les diskgroup. On va se lancer bientôt, j’ai un peu la pression avant d’appuyer sur le bouton, je vous avoue ^^

EDITs : Compléments d’information

EDIT1: Après avoir lu mon billet, le copain Erwan (Twitter @erwanquelin) m’a proposé une autre compréhension du problème de gateway. Il semble que VMware préconise, plutôt que la default gateway, de créer des routes statiques vers les witness, comme l’indique la documentation ici-même. De par le fait, peut-être que notre souci n’est pas le fait que la gateway ait sauté, mais plutôt que ce soit les routes statiques rentrées au départ lors de la configuration initiale du cluster. Inspecteur Cédric mène l’enquête !

EDIT2: Il semble bien que le paramètre “default gateway” ait sauté. En relisant les docs d’installation, nous avions bien positionné cette gateway. Sauf que, d’après Erwan, ce n’est pas “la bonne méthode” préconisée par VMware. Donc, imaginons que l’ajout d’une gateway ne soit pas prise en compte par l’upgrade ESXi 6.5->6.7 mais que la route statique le soit… ça pourrait expliquer nos problèmes. L’installation n’aurait pas été faite “dans les règles de l’art” au départ. A suivre …

EDIT3: Pour l’instant on se concentre sur un hypothétique bug ou une régression quelconque sur vSphere 6.7. Mais cela pourrait aussi venir de VxRail, qui aurait “oublié” de ré-appliquer cette conf spécifique lors de l’upgrade… même si ça reste vraiment de la spéculation dans le sens ou les membres du cluster n’ont pas été réinstallées mais bien upgradés (contrairement au dernier serveur esx09). Ce serait surprenant que ce processus écrase spécifiquement la partie réseau. A suivre …

EDIT4: suite à quelques commentaires sur ce billet, il semble bien que nos soucis soient liés au non respect des best-practices en matière de routage L3 vers notre Witness. Tout semble indiquer que VMware ne préconise QUE les routes statiques. Autant Duncan que la documentation officielle d’ailleurs (merci aux contributeurs au passage !). A suivre …