La situation
La demande semblait classique : remplacer un environnement VMware à trois hôtes, déplacer les charges de production, passer de vSphere 7 à 8 et retirer l’ancien matériel. En pratique, le risque se situait dans la transition. Réseau des hôtes, accès des hôtes au stockage, commutation, licences et charges de production devaient rester clairement définis et permettre un retour arrière pendant que l’infrastructure sous-jacente évoluait.
Ce que j’ai découvert
L’inventaire détaillé a distingué la configuration encore nécessaire de celle qui avait simplement survécu. Il a aussi révélé un problème de résilience moins évident : la machine virtuelle du contrôleur Wi-Fi était, de fait, liée à un seul ancien hôte et à un seul chemin réseau. L’évaluation du stockage montrait une faible marge de capacité, tandis que les changements de licences VMware qui se profilaient faisaient aussi du moment de l’achat un élément de la décision technique.
Ce que j’ai changé
J’ai préparé les nouveaux hôtes avec une version compatible avec l’environnement en production, les ai intégrés au cluster, configuré l’accès des hôtes au stockage SAN et validé les chemins réseau avant de déplacer les machines virtuelles de production avec vMotion. Ce n’est qu’une fois les charges sur le nouveau matériel que j’ai mis la plateforme à niveau vers vSphere 8 et mis à niveau la version du matériel virtuel des machines virtuelles. J’ai également recréé la connectivité nécessaire au contrôleur Wi-Fi sur toute la nouvelle infrastructure et ajusté la conception des liaisons pour répondre aux besoins de résilience sans coûts inutiles.
Le résultat
Les charges de production ont rejoint la nouvelle plateforme à trois hôtes, l’environnement a été mis à niveau et les anciens hôtes ont été retirés. La dépendance cachée du contrôleur Wi-Fi a été éliminée, les performances et la marge de capacité du stockage ont progressé, et la mise en œuvre a été réalisée en interne, avec les décisions de plateforme et de licences documentées pour le support.
Ce que je retiens pour la suite
Migration et mise à niveau représentent des risques différents. Les garder dans des étapes séparées a rendu chaque changement plus facile à valider, plus facile à annuler et nettement moins mouvementé que de tout regrouper au seul motif qu’une fenêtre de maintenance était disponible.