De vSphere 6.0 à vSphere 6.5 – Première partie : orgueil et préjugés

Démarrée le Mardi 17 à 9h02 précise, la migration vSphere 6.5 de notre environnement de production n’a pas été de tout repos. Et en matière de repos, je ne parle pas seulement des 3 jours consécutifs de 12/13 de travail quotidien, mais également des rebondissements et du stress engendré par ceux-ci. Le fait est que c’était prévisible, malgré une grosse préparation et des tests largement anticipés, nous avons été contraint de faire quelques choix disruptifs du type “on continue/on revert”… quand l’orgueil et les préjugés sur votre conviction d’avoir “tout prévu” vous joue des tours, quoi qu’il arrive. Le fait est que la loi de Murphy et la complexité vous rattrapent souvent !

Histoire d’exorciser cette semaine mouvementée mais qui finalement se finira bien, voici un résumé des événements de la première journée. J’espère qu’il seront riches d’enseignement pour vous qui n’avez pas encore franchi le pas ou qui êtes justement en train de planifier cette opération sur vos propres environnements.

Le Lundi … H-24h

Afin d’être totalement en phase avec la matrice de compatibilité VMware, nous avions prévu de réaliser une mise à jour mineure de notre vCloud Director de production de 8.10 en 8.20, dernière version 8 en date (il faut que je vous parle aussi de vCloud Director 9, mais c’est une autre histoire !).

La migration elle-même s’est bien passée, mais nous avons pas mal lutté pour mettre à jour nos certificats publics sur la plate-forme. Pourtant, nous étions partis de mon EXCELLENT billet sur ce sujet ^^. Tellement excellent qu’en définitive, nos soucis étaient dû au fait qu’entre la publication de ce post et aujourd’hui, les choses ont pas mal évolué (dans le bon sens) et que ce que je décrivais à l’époque a été remplacé par un outil dédié beaucoup plus simple. Je vous prépare un petit post spécifique la dessus dès que possible.

Au final, notre vCloud Director était en 8.20 en début d’après-midi et prêt, [teasing mode=on]pensions-nous …[teasing mode=off] pour être connecté à un vCenter 6.5u1.

Mardi 8h00 … H-1

Préparatifs

De 8h00 à 9h00 : Communication interne sur l’imminence de la maintenance.
De 9h02 à 9h13 : Passage des clusters DRS en “Partially Automated” pour éviter des déplacements de VM avant et après la migration : on stabilise les workloads
De 9h14 à 9h23 : Extraction CSV des positions respectives de chaque machine virtuelle sur chaque host. Envoi de ce document aux collègues de la production. L’objectif ici était pour chacun de pouvoir se connecter rapidement sur un host donné si une opération directe sur une VM devait s’avérer nécessaire (stop/start, snap, console etc.)
De 9h23 à 9h29 : connexion aux différents hosts hébergeant les machines qui forment l’ensemble vSphere chez nous : nos deux Platform Service Controllers, notre vCenter évidemment, et quelques autres machines de pilotage, pour le cas où.

Image cohérente et migration des platform service controllers

De 9h30 à 10h29 : Arrêt de l’ensemble des machines : PSC, vCenter et sa base Oracle, NSX Manager. Snapshots à froid de toutes ces machines puis enfin, relance. Vous noterez ici qu’on a “oublié” vCloud Director à ce moment là… erreur, qui sera corrigée plus tard. Un premier enseignement déjà : Snappez absolument tout ce que vous pouvez, n’oubliez rien, soyez exhaustif, même vous devez y passer un peu plus de temps.
De 10h30 à 10h53 : Démarrage de la migration de la PSC02 de backup (nous ne faisons pas de Load Balancing pour le moment). Tout se déroule sans accroc et la machine est migrée en moins de 25 minutes ! Ca commence très bien :)
De 10h54 à 11h22 : Re-point de notre vCenter de pré-production sur la PSC migrée, puis tests de fonctionnement. Pas d’erreurs ni de problèmes d’authentification, du coup, nous faisons un re-point des deux autres vCenter, celui de la production (à migrer) et celui de l’admin.
De 11h23 à 11h48 : Migration de la PSC01 primaire. La encore le processus se passe sans problème et à 12h00, l’ensemble de nos PSC sont en 6.5 !

Première tentative de migration vCenter

12h40 à 14h10 : Après une petite pause déjeuner, retour aux choses sérieuses. Migration de NSX Manager vers la 6.2.8 puis ensuite vers la 6.3.3, version supportée par vCenter 6.5u1 et vCenter 6.0u2 (voir ici). Nous avons pris un – petit – risque vis à vis de vCloud Director : en fait nous n’avions pas trop le choix, malheureusement. Très exactement, nous nous sommes aperçus que la 6.2.8 ne pouvait pas migrer vers la 6.3.2 mais uniquement en 6.3.3. Or, comme le montre cette matrice, vCloud Director 8.20 ne “supporte” pas la 6.3.3 (même si on nous a confirmé que ça fonctionnait bien pour notre usage). Au pire, nous avions quand même la possibilité de migrer vers vCloud Director 9.0. Même si cette release est récente, au moins nous conservions un support VMware complet. Deuxième enseignement : vérifiez bien 10 ou 20 fois vos chemins de migrations !! Je vous ferai peut-être un billet dédié à cette opération car je ne détaille pas mais nous sommes aussi passé par des upgrades de Edge Gateway anté-dilluviennes et des préparations NSX d’ESXi (sans mise en maintenance, heureusement !)
De 14h10 à 16h37 : Nous étions donc parés : NSX 6.3.3, PSCs en 6.5u1, il fallait se lancer dans la migration vCenter ! GO …
De 16h37 à 16h40 : Et paf … première erreur (on était forts, on était préparés, mais quand même …). Après l’extraction des données de la base, l’outil de compression de ces mêmes données qui s’exécutait sur le serveur vCenter 6.0 s’est planté avec un joli message “The compressed (zipped) folder is invalid or corrupted.”. Premier réflexe : google est ton ami. Après quelques recherches, nous tombons sur un blog détaillant le même problème rencontré et la cause probable de l’incident : il s’agit des données d’Update Manager qui provoquent des chemins trop longs dans l’archive… La solution : désinstaller Update Manager avant de migrer. Finalement, une idée pas si bête sachant que c’est sans doute le produit le plus facile à réinstaller à partir de zéro, étant désormais intégré à vCenter 6.5.
Pour terminer l’après-midi, nous avons donc essayé – vainement – de désinstaller update manager directement via Windows. Mais les fenêtres de sauvegardes approchant à grand pas (18h00 pêtantes chez nous), nous avons pris la sage décision de revert notre snapshot de vCenter et sa base Oracle pour assurer la nuit (backups, astreintes etc.) et retenter cela calmement le lendemain.

… à suivre !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *