Bonjour à tous ! Voila plusieurs semaines/mois que nous préparons la mise à jour de notre production vSphere 6.7 à vSphere 7.0. La route est souvent longue pour organiser et valider ce genre d’update majeure, avant le grand jour. Et, malgré toutes les précautions prises, il y a quelques fois des difficultés non anticipées qui compliquent pas mal la vie et augmente le stress de plusieurs facteurs pendant le jour J. Petit récit de cette grosse opération qui s’est étalée, pour nous, sur plusieurs jours, alors qu’elle ne devait au final durer qu’une demi-journée …
J’ai connu pas mal de upgrades majeures de vSphere depuis que je connais VMware et qu’on utilise son écosystème en production. Le premier galop dans les années 2000 ne compte pas, avec GSX Server et les premiers ESXi 3.0 autonomes ^^. Une fois le premier vCenter installé en 4.0, s’en est suivi une jolie collection vers 4.1, puis 5.0 et 5.5, la grosse 6.0 et son passage en VCSA pour nous, 6.5 et enfin 6.7 (qui a été une promenade de santé, au passage). Cette « journey » comme disent les anglais, s’accompagne aussi d’une évolution assez impressionnantes à notre échelle de nos infrastructures mutualisées. Le fait est que plus vous avancez, plus votre prodution devient complexe, intégrée, et surtout composée de nombreuses solutions « compagnons » qu’il faut prendre en compte. Quand on commence avec un petit vCenter dans son coin, tout se passe assez bien en général, mais quand vous êtes rendus à gérer ça :
– Citrix XenApp 7 (et ses systèmes MCS, voire PVS)
– Veeam Backup et Replication
– VMware vRealize Operations
– VMware NSX-V (legacy)
– VMware vCloud Director, puis récemment Cloud Director
– VMware NSX-T Datacenter
– Dell EMC VxRail 4.5 (plusieurs clusters)
– Dell EMC VxRail 4.7 (plusieurs clusters)
– Des tonnes de scripts PowerShell, du Ansible …
… le fait est que quelques fois, on s’arrache un peu les cheveux ^^. Si on y rajoute des changements de stratégie chez VMware même, obligeant à jouer avec les PSC internes, puis externes, puis à nouveau convergées, ça vous donne pas mal de travail pour préparer l’arrivée de la 7.0 aujourd’hui. Notre le guide le plus important a été de suivre le chemin de la matrice d’interopérabilité (qui a changé de look récemment, d’ailleurs), sésame absolu pour des mises à jours supportées. Comme toujours il faut commencer par ça.
Il faut biens sûr vérifier aussi si vous n’avez pas des « vieux machins » qui tournent encore mais qui ne seront plus pris en charge lors du passage à la prochaine version. Nous étions dans ce cas, avec notamment un vieux cluster ESXi de production ultra critique en 6.0, auquel on essaye de toucher le moins possible car sinon « ya des gens qui meurent » (littéralement… je vous raconterai un jour, peut-être …). Mais pour le coup on devait le mettre à jour, plus le choix, ESXi 6.0 n’étant plus pris en charge par vCenter 7. Pour couronner le tout, ce cluster fonctionnait sur des serveurs non compatibles avec la 6.7, autant dire qu’il fallait jouer de la transplantation et déplacer tout le workload sur de nouvelles machines. Ça nous a occupé pas mal d’heures et une belle nuit de travail.
Coté vCloud Director aussi, nous partions de loin, avec une version 9.5 qui n’était plus supportée, mais déjà migrée sur PostgreSQL heureusement. J’ai donc réalisé une série de migration en 9.5, puis 9.7, 10.0, 10.1 et enfin 10.2 … j’ai d’ailleurs prévu un billet spécifique pour vous en parler, car j’ai réalisé cette opération plusieurs fois en test, pour blinder la procédure, avant de passer en production. Un parcours intéressant ^^. Mais comme je suis en mode flemmard en ce moment (j’en suis encore désolé), je n’ai pas encore accouché dudit article.
Coté Citrix et Veeam, aucun souci – ouf! – sachant que les deux éditeurs suivent d’assez près les version de VMware et les supportent rapidement. Coté NSX-V, là aussi, pas trop de souci à se faire a priori, car il s’agissait de mettre à jour le manager de la version 6.4.6 à 6.4.8 (à l’époque, une 6.4.10 est dispo depuis). Nous n’utilisons que les fonctionnalités de Edge Gateways avec vCloud Director aujourd’hui.
NSX-T Datacenter, notre petit chouchou depuis quelques temps, suit son propre cycle de mise à jour et nous sommes passé en 3.1.1 en Mars dernier, compatible avec vSphere 7 depuis un moment. Un souci de moins !
Plus laborieux, il fallait aussi vérifier et mettre à jour, pour être eux-même compatibles, ou plus exactement « supportés », nos différents clusters VxRail. Ce n’est pas compliqué en soit, mais le temps et les précautions à prendre (mise à jour de tous les ESXi, nombreux passage en maintenance et reboot), a rendu la préparation plus longue et a retardé d’autant notre passage à 7. En général, nous sommes assez conservateurs (sauf urgence vulnérabilité évidemment) en matière de mise à jour de nos ESXi de production, le plus important restant, pour nous, la stabilité, gage de tranquillité pour le reste de nos activités (applications, système d’information). Une production se doit d’être la plus stable possible, de mon point de vue. Nous sommes parti sur un cycle de mises à jours semi-annuelle de nos gros clusters. Dites-moi, d’ailleurs, comment vous fonctionnez de votre coté, je suis intéressé pour avoir vos retours la dessus.
Après tout l’écosystème autour de nos vCenters, il restait à préparer aussi les VCSA à leur upgrades. Précision importante : nos trois vCenters, préprod/test, admin, et production sont actuellement en « enhanced linked mode ». Elles partage un même domaine SSO sur leurs PSC, donc.
Premièrement : Il fallait converger les PSC que nous avions externalisées il y a quelques années. Ben ouais, VMware nous disait à l’époque « c’est trop bien, les PSC externes, faut faire comme ça »… sauf que maintenant, VMware nous dit « c’est trop bien, les PSC convergées/internes, faut faire comme ça » … la vie n’est qu’un éternel recommencement qu’ils disaient … (soupir). A ce sujet, depuis vCenter 6.7 l’UI dispose d’un outil intégré pratique et qui fonctionne très bien pour cela, dont acte faisons un peu de clicodrome, même si je ne suis pas fan ^^. L’opération elle-même s’est très bien passée, par contre, ce que nous n’avions pas anticipé, c’était que les VxRail rattachés aux psc externes, au moment de leur installation, n’ont pas apprécié la jolie blague et il a fallu les re-configurer ! Pensez-y, si vous êtes dans ce cas, n’oubliez pas vos VxRail Manager !
Deuxièmement, il fallait valider que les trois appliances étaient, depuis leur convergence de PSC, dans un mode de réplication dit « ring mode », comme l’indique cette KB#2127057. Lisez-là avec soin et suivez les instructions pour bien structurer votre arbre de réplication. Attention, ce n’est pas explicitement dit, mais lors que vous mettez en place un partenaire de réplication, faite-les dans les deux sens, la réplication est unidirectonnelle !
Troisièmement, en raison des récentes alertes de sécurité sur vCenter, nous étions à la quasi dernière release des VCSA, vCenter 6.7u3l. Il nous fallait déterminer la version cible vers laquelle nous allions migrer. vSphere 7 update2, sortie en Mars dernier semblait la meilleure option a priori, même si un bug plutôt embêtant sur l’upgrade ESXi avait provoqué pas mal de fumée en Mars (voir cette KB#83063 ainsi que cette KB#83107). Bon il se trouve que ça concernait, sans rentrer dans le détail, un souci d’upgrade de ESXi si vous utilisiez DEJA vSphere 7 avec vLCM. Pour nous, donc, aucun impact.
Au final, ce chemin, débuté en Octobre dernier est arrivé à un « bon à tirer » fin Mars (6 mois). Décision a donc été prise : on était go pour upgrade !
Et cette upgrade a eu lieu la semaine dernière du Mardi 20 Mars matin … au Jeudi 22 Mars après-midi.
Bientôt la suite…
