Quand vCenter, après un reboot, se met à faire n’importe quoi (mais ce n’est sans doute pas de sa faute), ça donne un petit coup de stress pendant pas loin de deux heures, cet après-midi. Retour à chaud …
On parle souvent ensemble de problèmes complexes, de solutions très avancées et de transformation SDDC sur ce blog, et ce, depuis des années. Mais il arrive de temps à autre que je vous présente un petit retex technique bien concret, suite à des déconvenues, des erreurs de manipulation, des bugs divers, voire des situations improbables. C’est exactement ce qui vient de se passer, cet après-midi, sur un de nos vCenters. Évidemment, comme à chaque fois, rien ne présageait, encore 2 minutes avant, la galère à venir. Heureusement pour moi, la pluparts des soucis ont été réglés les uns après les autres et se sont bien terminés (après tout de même environ 2 heures de travail).
En prévision d’une future mise à jour de nos vCenters, je réalise en général quelques tâches préparatoires de bon aloi, comme vérifier l’expiration des mots de passe root, l’état des filesystems de chaque VCSA et leur taux de remplissage (je vous conseille de prendre le temps de faire cela avant, histoire de ne pas planter votre update pour des mauvaises raisons, et ceci même si vous avez de la supervision adaptée).
Quand le vCenter change d’IP tout seul …
Cela n’a pas manqué, un de nos vCenters récemment installé (environ 3/4 mois, tiens tiens) avait son mot de passe root expiré (il faut vraiment qu’on supervise cela, mais on a toujours plus prioritaire à faire évidemment). Il fallait le réinitialiser pour récupérer l’accès. C’est une procédure simple disponible dans les KB VMware (KB#2147144), que vous connaissez sans doute toutes et tous : reboot en single-user du Linux de la VCSA, puis modification du mot de passe et changement de paramètres d’expiration éventuellement). Donc, allons-y, programmons un petit reboot, qui, soit dit en passant, ne fait pas de mal, quand vos vCenters tournent non stop depuis quelques semaines.
Dont acte : je reboot, passe en single et modifie le password, et redémarre le bouzin. La machine se lance jusqu’au bout mais ne pingue plus. Oops, c’est balô. Je me connecte en mode console et constate assez vite que … l’IP de référence de ce vCenter n’est plus la bonne, argl !!!! Le petit stress s’installe : que s’est-il passé ? Je vérifie mes notes et copies d’écran en mode single (là encore, petit conseil, même si vous connaissez la procédure par coeur, faites des copies d’écran de vos manip …), tout semble correct !
La première chose à faire très vite, rebooter une fois de plus en single pour inspecter les logs système et la configuration réseau. Pour le coup, je connaissait l’IP parasite, donc un petit grep sur le /etc pour retrouver, avec un peu de chance la coupable dans un des fichiers de configuration. (c’est une plateforme Photon OS, mais ça reste un Linux classique au final). Et là, que vois-je ? suprème surprise ? la configuration réseau dans systemd est incorrecte ? QUE ? QUOI ? Bon, priorité à la production, je ne me pose pas de question et je replace les bon settings dans le fichier fichier /etc/systemd/network/10-eth0.network en ayant fait un backup au préalable au cazoo. Puis reboot…
It works ! Ouf. Par contre impossible de savoir réellement ce qui s’est passé. L’IP parasite en question est liée à un ancien VCSA que nous avons dû réinstaller totalement pour des raisons de changement de topologie réseau. Est-ce qu’il est resté des entrées incorrectes dans notre DNS ? Un problème avec les reverses ? Aucune idée, mais toujours est-il que la VCSA, lors de sa réinstallation en fin d’année dernière n’avait pas été rebootée une seule fois ? RETEX1 : ne jamais oublier, une fois un déploiement d’une VCSA ou une update à chaud quelconque, REBOOTEZ là au moins une à deux fois dans la journée, pour être certain que tout va bien…
Quand le mot de passe changé est encore expiré …
Ok, j’avais donc réussi à relancer la machine avec succès, mais, par acquis de conscience, je me connecte en ssh sur la machine après avoir vérifié que les options de diagnostic sont bien toujours activées (c’est un choix assumé chez nous, même si on baisse un peu le niveau de sécurité de la VCSA. Vous désactivez l’accès root et activez le lockdown sur les ESXi de votre coté ? Curieux de vous entendre dans les comm’).
Ben quand ça veut pas. Le mot de passe root semble être accepté, mais pour autant, je me fais jeter tout de suite, que ce soit via SSH ou via la IU vCenter Server Manager et MEME, plus grâve, depuis la console locale des diagnostics. J’en suite quitte pour un nouveau reboot en single (je ne suis plus à ça prêt). Bon, là, le compteur tourne et ma manip qui devait durer 15 minutes max, en est à plus d’une heure (je vous ait passé les détails croustillants sur les mappings de clavier QWERTY, le coup de voiture entre chez moi et le boulot pour cause de télétravail ce jour là … etc. … galère je vous dit). Aux grands maux les grands moyens, je sais vous allez trouver que c’est sâle mais il me fallait retrouver l’accès à la console SSH sous root, ne serait que pour appeler VMware à l’aide ensuite plus sereinement. Ni une ni deux : j’ajoute un “fake user” avec l’UID 0/GID 0 directement dans le /etc/passwd et le /etc/shadow et je boot. Ozana ! j’ai à nouveau accès via ce fake user à ma console. RETEX2 : pas forcément un conseil, mais si vous savez ce que vous faites, n’hésitez pas à traiter la VCSA comme un Linux, au moins pour auditer votre système (log, fichiers de configuration standard dans /etc, petites manips avec un snapshot à froid par sécurité avant, j’en ai fait au moins une dizaine en tout pendant les 2 heures qu’on duré ce troubleshooting)
Et des services qui se relancent tout seul, le ponpon …
Je tente un petit chage et je tombe sur une erreur Linux : “Your account has expired; please contact your system administrator. chage: User account has expired”. Heu … mais, MAIS, tu ne va me résister longtemps, saloperie de VCSA, c’est moi qui teuldi ! Désespéré, je me prépare à appeler VMware… mais j’essaye tout de même un dernier truc de vieux routard de linux, je reboot une dernière fois en single et je fais une copie de /etc/shadow pour modifier d’autorité directement la ligne du compte root, avec un petit “root::::::::”. Bingo ! le compte root est de nouveau accessible. OK, tout semble marcher à nouveau correctement.
… ou pas ! Après quelques minutes, je suis les logs de la machine pour être certain que tout marche bien … et je constate que certains services se plantent et redémarrent ! Qui plus est la machine est très poussive même en ssh. Je commence à devenir fou, mais je regarde par acquis de conscience la quantité de RAM de la machine. 12 petis gigas. Même si c’est très peu pour une VCSA de prod, elle a tout de meme fonctionné des mois sans vraiment broncher ! J’ai déjà vu ce genre de comportements sur mon vLab qui était à une époque, très contraint par la RAM, je me dis, peu convaincu, qu’un petit ajout de mémoire au pire ne changera rien. Shutdown/Edit Settings … passage de 12 Go à 24 Go./Start.
… suspense …
Et bien c’était ça les amis !!! La machine redémarre parfaitement, est opérationnelle en moins de 5 minutes et la fluidité n’a rien à voir. Plus de redémarrage de services intempestifs. Je pense que ce sizing lui allait tout juste et le restart régulier des services devaient passer inaperçu (il y a peu de serveurs ESXi et de VM pour le moment sur ce vCenter). Quoi qu’à bien y réfléchir, on a eu certains petits soucis plus ou moins bloquants durant ces quelques semaines de prod, qu’on arrivait pas à expliquer réellement… RETEX3 : Vérifier bien le dimensionnement de vos vCenters, vos machines d’admin diverses, on a souvent tendance à sous-estimer ces outils quotidiens, que ce soit chez VMware ou chez d’autres éditeurs..
Bref !
RETEX4 : ne montez pas “à l’arrache” des machines aussi structurantes que vCenter. De notre coté, nous avons clairement pêché par excès de confiance et nous n’avons pas assez pris notre temps à designer cette machine, car “c’est simple à installer, en deux coup de cuillère à pot”. C’est faussement simple : DNS, sizing correct, anticiper les supervisions, cahiers de tests divers, etc. Je ne vous fait pas l’article, mais c’est toute la diffculté de notre métier aujourd’hui, je le répète souvent dans ces lignes, la pression du delivery nous pousse souvent à ne pas passer assez de temps sur des briques essentielles. Les cordonniers sont les plus mal chaussés, c’est bien connu ^^
Sur ce, je vais faire le tour de toutes appliances VMware (et on en a beaucoup aujourd’hui) et réaliser checkup complet …
