Après une première partie consacrée aux préparatifs, voici donc le deuxième opus plus concret encore, la mise à jour de nos trois vCenter vers vSphere 7.0u2. Cette opération, qui s’annonçait assez tranquille, a finalement pris pas mal de retard et a nécessité l’intervention du support VMware. Une petite semaine de stress, d’une vingtaine de tentatives, avec des conclusions intéressantes.
Note préalable importante
Avant de se lancer dans le récit, il me faut vous dire quelque chose concernant la première partie. Je n’ai pas voulu faire d’update spécifique sur le le premier post car ça me paraissait important de le laisser tel quel, avec un petit commentaire de Boris qui m’a fait me rendre compte que mon bel exercice de préparation avec moulte détails, avec un coté « vous avez vu comme on fait ça bien chez nous », s’est fait complètement applatir sur une erreur grossière : nous n’aurions pas du choisir l’update2 mais l’update1, tout simplement parce qu’à l’heure où j’écris ces lignes, le 25 Avril, Veeam v10 en fin de vie et v11 ne SUPPORTENT pas officiellement l’update2 mais uniquement l’update1, contrairement à ce que j’ai pu laisser entendre …
Dans la pratique, pour l’instant et heureusement pour nous, cela n’a pas de conséquences sur notre production (tout fonctionne bien et nos tests récents n’ont détecté aucune régression ou problème spécifique). Ceci étant, nous sommes, à cause de ce défaut de support potentiel et d’un manque de de vigilance de ma part, dans une situation un peu inconfortable, tant que nous n’avons pas mis à jour notre production Veeam dans la futur version supportée v11.x, qui ne saurait tarder. Première conclusion, donc, avant même de vous avoir parlé de l’upgrade lui-même, vérifiez deux fois, voire, mieux, faite vérifier à un collègue votre matrice de compatibilité avant de vous lancer. On a beau afficher des super badges vExpert machin, vExpert truc, personne n’est à l’abris d’une erreur.
Merci sincèrement à Boris (que je ne connait pas, au demeurant) pour me l’avoir glissé, simplement, sans chichi. Un beau rappel à l’ordre.
Revenons za nos moutons, upgrade time
Comme je l’ai dit, nous disposons actuellement de trois VCSA en 6.7, au sein d’un domaine SSO commun, en Enhanced Linked Mode. C’est terriblement pratique, mais ça nous oblige, pour ne prendre aucun risque, à réaliser avant toute mise à jour majeure ou mineure une sauvegarde/snapshot à froid des trois appliances, pour garantir un état cohérent de ses machines. Une fois ces backups réalisés (snapshot à froid, machines arrêtées puis sauvegarde de ces machines par Veeam avec ces snaps par Veeam), on pouvait se lancer dans l’aventure.
Les deux premiers vCenter, admin et pré-production, ont été réalisés sans problème en déroulant l’upgrade via l’UI. Tout cela s’est parfaitement déroulé, avec environ une trentaine de minutes pour chaque machine. Pas de surprise, ni erreurs spécifiques lors de l’assistant. Ensuite nous avons laissé tourner quelques jours, pour valider la stabilité globale de ce mode « hybride » 6.7-7.0.
En dehors des vCenter par contre, nous avons tout de suite noté un point très important : nos VxRail, qui disposent de licences vSAN intégrées, se sont retrouvé avec des licences trail, oops. Il a fallu creuser un peu pour tomber sur ce KB#80691, laconique. En gros, vos licences intégrées automatiquement lors des installations, ne respectent plus le nouvel algorithme des licences 7.0 et ne sont pas compatibles. Pour autant, rassurons-nous, le cluster, même non licencié, continuera à fonctionner jusqu’à son upgrade. Si vous êtes sous maintenance, vous pouvez directement contacter le support Dell EMC pour obtenir des nouvelles licences vSAN, en indiquant les PSTN/TAGS de vos serveurs HCI. Le processus est encore en cours chez nous, je vous tiendrai au courant de l’avancement et des difficultés/péripéties éventuelles ^^
Est venu, enfin, la grande opération, la mise à jour de notre vCenter de production, le gros de l’affaire : plusieurs milliers de VMs, 8 clusters, dont trois VxRail.
Première tentative : ça a bien commencé, le déploiement de l’appliance cible s’est bien passé, puis lors du stage 2 « pre-check », ah, non, ça passe pas. Une première erreur survient, pas du tout explicite, je dirait même cabalistique, car quasi introuvable sur Internet : « Pre-upgrade check failed due to the following problem: invalide field source_info in structure com.vmware.vcenter.deployment.check_info ». Autant dire que personne n’a du l’avoir à part nous, comme toujours ^^. C’est là que le support VMware intervient. Après un petit échange avec un ingénieur, on se rend compte que l’erreur en question est lié à un montage NFS, présent sur le vCenter, dont la taille est supérieure à 1 Po. Derrière cela, se cache, il y a plusieurs années, des tests que nous avions réalisé avec les Content Libraries. A l’époque (sans doute la 6.0, de mémoire), les content libraries montées en NFS l’étaient aussi directement au sein de la VCSA. Personnellement, impossible de retrouver le pourquoi du comment, mais, malgré tout, le point de montage spécifique était toujours là, dans notre vCenter. Sauf que ce point de montage était servi pour notre Isilon… dont l’espace provisionné aujourd’hui dépasse le pétaoctet ^^. Visiblement, le wizard d’upgrade a du mal avec des espaces aussi imposants, visiblement et se plante quand il s’agit d’interpréter la volumétrie … Au final, cette erreur était une bonne chose, sachant qu’on avait « oublié » cet espace non utilisé aujourd’hui (finalement les content libraries ne sont toujours pas adaptées à nos besoins). Nous avons supprimé la content library et le volume a été supprimé de la VCSA du même coup.
Deuxième tentative : Petite note en mode mini-rognotudju, avant de vous décrire ce deuxième essai. Faites attention à prévoir de la place et du CPU de libre. En effet, l’assistant est sensé vous présenter des options pour le déploiement de la VCSA cible qui va récupérer toute la configuration existante : Tiny/Large/Xlarge en matière d’empreinte de VM, mais aussi en matière de stockage. Dans la pratique ce petit malin ne vous laisse qu’un choix limité, voir pas de choix du tout car il force celui-ci à partir de l’analyse de votre vCenter actuel ! La encore, je trouve ça limite pour des productions moyennes comme les nôtres. Provisionner un vCenter avec 64 Go de RAM, 24 Processeurs (!!) et 3 To de disque pour un environnement d’une cinquantaine de serveurs ESXi et de 2500 VMs … comment dire, NON. VMware, dites, laissez-nous le choix ! On est grand, on saura s’adapter si ça rame …
Mais, bref, deuxième tentative, donc : le stage 2 se passe correctement, la copie des données du vCenter source démarre correctement et au bout de quelques minutes, une nouvelle erreur, cette fois-ci lié à un souci de place sur la partition « / » de la VCSA source. Là, par contre, beaucoup d’information sur le net (voir par exemple ce petit billet) mais, problème, le formulaire de l’iso vSphere 7u2 ne présente PLUS/PAS le champ « Export directory » permettant de modifier le chemin de l’archive à créer pour la copier vers la cible. Il faut dire que l’archive en question pesait plus de 10 Go chez nous, alors que la partition root initiale de la VCSA ne faisait que 7,9 Go. Du coup, il a fallu se rabattre ver une opération plus risquée, à mon sens : étendre le volume de la partition /. Pour cela, je me suis basé sur le KB#2145603 en utilisant, après extension du disque de la VM, le petit script « grow.sh » indiqué. Au passage, cela justifie, lorsque vous voulez sécuriser le retour arrière éventuel, de ne pas se baser que sur des snapshots. En effet, si vous devez modifier la configuration de la VM source pour corriger un souci quelconque, les snapshots en cours vous l’interdirons. Le mieux, clairement : étendez votre partition root AVANT l’upgrade, histoire d’être tranquille. Je vous conseille de voir large, disons 25/30 Go, histoire de ne pas vous retrouver face à ce type de difficulté.
Enfin, la troisième tentative a été la bonne et la mise à jour est allé à son terme, nous transportant vers du full vSphere 7. Hormis les problématiques de licences VxRail, le reste a consisté à relancer une configuration HA par ci par là, ou valider des alertes « normales » (oui, ok, des alertes normales, c’est pas normal, mais on fait avec ^^).
La conclusion de cette petite tranche de vie récente au sein de notre service est en fait dans l’introduction de ce billet : avant même d’imaginer avoir des erreurs, qui sont toujours possibles : vérifier votre scénario et vos matrices d’upgrade/compatibilité ; tutututttt, vous n’avez pas assez vérifiez … re-vérifiez ; re-re-vérifiez derrière (private joke avec Antoine un collègue, @yoltie sur Twitter).
Et moi je m’en vais corriger ce problème de support avec Veeam … :(
