Depuis plus d’un mois maintenant, il me tardait de pouvoir ENFIN mettre la main sur le fameux VSAN 6.2. C’est désormais chose faite depuis la sortie en GA de vSphere 6.0 update 2, comme chacun sait. Il n’en fallait pas plus, évidemment, pour que je précipite sur cette nouvelle release afin d’upgrader mon vLab comme il se doit !
Voici le récit d’un “voyage” qui m’a fait découvrir les nouvelles fonctionnalités de VSAN 6.2 mais aussi les premières “joies” d’une migration VSAN 6.1 vers 6.2, au final réussie, mais avec pas mal d’embuches …
Avant tout, je tiens à remercier Erik Bussink (Ingénieur NSX et auteur du blog http://www.bussink.ch ) et William Lam (l’auteur du célèbre blog virtuallyGhetto) qui m’ont chacun aidé à arriver à mes fins rapidement ! Ils font d’ailleurs partie intégrante de ce récit.
La première chose à faire, c’était l’update de mon vCenter 6. De ce coté là, aucun souci, la mise à jour s’est déroulée sans encombre, tout comme Update Manager. Aucune erreur ou difficulté à signaler. Une fois vCenter à jour, on constate tout de suite qu’il y a de nouvelles alertes spécifiques sur VSAN, donc je me suis précipité dans la section “Monitor” du cluster VSAN, pour diagnostiquer les erreurs en question :
Effectivement, le service “VSAN Health Service” réclame au minimum une upgrade des ESXi du cluster VSAN avant de pouvoir refaire son job correctement. Pour autant, dans la pratique, le cluster VSAN lui-même fonctionne sans problème et toutes mes VM sont encore – heureusement ! – accessibles. C’est donc parti pour l’update des ESXi 6.0u1 vers 6.0u2. Chaque machine a été mise en maintenance, updatée grâce à Update Manager qui avait déjà téléchargé les vib de l’update 2, puis sortie de maintenance. Au final, et après une 20 vingtaine de minutes en tout et un nouveau “retest” dans la section Health de VSAN, j’obtenais un état encore non satisfaisant, mais sans alertes majeures :
La première chose que j’ai noté c’est que, logiquement (c’était annoncé depuis quelques temps), il me restait à upgrader le format des diskgroup de mon cluster VSAN. Dont acte, on clique sur le bouton “Upgrade on-disk format”. On obtient un popup indiquant grosso modo que cette opération est irréversible, surtout pour d’éventuels ESXi 5.5 qui souhaiteraient intégrer le cluster a posteriori… je valide :)
La tâche se lance et au bout de quelques secondes… oups, vCenter me renvoie une erreur critique :
Failed to realign following Virtual SAN objects: 8a16ad56-6f9b-0e0a-32cc-685b357d8c8d, 8a16ad56-6937-6633-6988-685b357d8c8d, 8cf8c456-0cbc-8138-335d-406c8f35a1d4, 06a1ac56-f26f-c959-bd1b-0c4de9bd5a1c, 07a1ac56-f54e-dcf2-ca4b-0c4de9bd5a1c, due to being locked or lack of vmdk descriptor file, which requires manual fix.Bon, ça se complique. Je commence à Googler, forcément. A ce moment, ou presque, Erik me contacte sur Twitter pour m’alerter au sujet de problèmes d’upgrades rapportés sur les forums dans certains cas et notamment lorsqu’il existe des objets orphelins sur le volume VSAN. En échangeant sur le sujet, il m’apprend qu’il existe un outil, intégré à vCenter depuis la 6.0, RVC (Ruby vSphere Console) – que je ne connaissais pas, honte à moi ! – qui dispose de tout un tas de commandes pour débugguer les problèmes de VSAN. Ni une, ni deux, je me précipite sur quelques blogs (je vous présenterai une liste complète en fin d’article) pour découvrir et apréhender “la bête”. Après quelques dizaines de minutes, j’arrive à la conclusion que les objets qui sont précisés dans l’erreur critique sont en fait des fichiers swap et vmdk de certaines de mes machines.
J’avoue que n’ayant pas trop de recul sur VSAN, ni personnellement, ni en production, j’ai choisi la facilité pour contourner le problème : j’ai évacué mes VMs sur un volume classique iSCSI pour ensuite re-tenter le on-disk upgrade… Et … non, toujours pas, encore une erreur sur certains objets. Pourtant, si vous me suivez, vous savez sans doute que l’installation de mon cluster VSAN est très récente et ne contient normalement rien de vraiment bidouillé ou issu de plusieurs cycles de mises à jour. En désespoir de cause, j’ai pris la décision d’être plus radical en procédant à la main à la suppression des diskgroups de chaque membre du cluster et à leur re-création au format v3. Pour le coup, cette méthode a fonctionné ! Après quelques minutes, j’avais un VSAN en v3 flambant neuf ou presque. Ce n’est pas très satisfaisant et je ne désespère pas de trouver ce qui n’allait pas au départ, mais en l’état, l’objectif était atteint :
Après une – courte – nuit de sommeil et un Vendredi chargé, de retour sur mon vLab, j’entreprends d’activer une des fonctions phares de VSAN, la supervision des performances du cluster intégrée à vSphere Web Client. Pour se faire, il faut se rendre dans la section Manage de votre cluster, onglet “VSAN-Health/Performance” et cliquer sur le bouton “Turn on”. On obtient ce type de fenêtre :
… ha, mais, tiens, normalement, on doit avoir une politique de stockage qui s’affiche (au moins la politique VSAN par défaut créé par vCenter). Boooon, encore un souci étrange. Je google… mais, sans vraiment trouver mon bonheur. Pendant ce temps là, il se trouve (je vous raconte ma vie …) que je twittais pas mal et je vois que William discute aussi avec d’autres twittos. Ni une ni deux, je tente de lui demander de l’aide. Environ 2 minutes plus tard, les Internets sont vraiment formidables pour ça ^^, William me répond de vérifier que les VASA Provider de VSAN sont bien actifs et détectés par vCenter. Bonne pioche ! Effectivement et sans doute suite à mes nombreuses manipulations, vCenter ne listait plus les providers (autant que de noeuds VSAN, normalement) dans la section ad-hoc. Je tente un petit “refresh” et bingo, re-voila mes 3 ESXi :
Je retourne dans la section Health/Performance et tente une réactivation du monitoring, je vois bien ma politique par défaut et l’activation se passe parfaitement !
Pour l’instant, j’en suis resté là, tout simplement car je n’ai pas le hardware nécessaire pour activer les fonctions de compression et déduplication, malheureusement (il me manque trois SSD pour le capacity tier). En tout cas et comme toujours, j’ai découvert plein de choses intéressantes pendant cette opération (notamment RVC que je vais dévorer maintenant que je sais qu’il existe !) et je compte bien les mettre à profit dans de futurs chantiers :)
Pour aller plus loin sur VSAN en général et VSAN 6.2 en particulier, je vous conseille fortement la série d’articles de Cormac Hogan, un des membres du staff VMWare, qui présente par le menu toute l’architecture, les fonctionnalités et les concepts de VSAN sur son blog (à suivre évidemment) :
http://cormachogan.com/vsan/
J’ai découvert également un nouveau blog qui semble particulièrement pointu et qui m’a permit d’avancer lors de mes tentatives de diagnostic des erreur de migration de version des diskgroups, ça s’appelle ACM Computers et vous pouvez le trouver ici :
http://www.acmcomputers.co.uk
Enfin, si vous voulez (comme moi !) avancer dans la connaissance de RVC, voici “la bible”, notamment sur les fonctions VSAN sur Virten.net, un autre blog à marque-ta-pager :
http://www.virten.net/2015/01/manage-virtual-san-with-rvc-complete-guide/
Pour terminer, voici les comptes twitter (suivez-les vite si ce n’est pas le cas) de Eric et William, ils le valent bien !
Erik Bussink : https://twitter.com/ErikBussink
William Lam : https://twitter.com/lamw