01La recette technique, machine par machine
Cette liste se passe intégralement, sur chaque machine, juste après le premier démarrage. Elle tient en quelques minutes et évite de découvrir un mois plus tard qu'un réglage manque sur quarante machines.
# configuration complete : controleur, agent, ostype, demarrage qm config 101 # l'agent invite repond, donc arret propre et sauvegarde coherente qm agent 101 ping qm guest cmd 101 network-get-interfaces # la machine doit pouvoir se deplacer a chaud entre noeuds qm migrate 101 pve-02 --online qm migrate 101 pve-01 --online
| Contrôle | Attendu | Si l'attendu manque |
|---|---|---|
| Démarrage sans intervention | Système en service | Pilotes ou firmware, chapitre 02 |
| Adresse IP et VLAN | Conformes à l'inventaire | Table de correspondance réseau |
| Agent invité | Répond | Installer, puis réactiver l'option |
| Contrôleur disque | VirtIO SCSI single | Performances en retrait |
| Migration à chaud | Aller-retour réussi | Type de processeur ou passage direct |
| Résidus VMware Tools | Aucun | Services fantômes, à nettoyer |
| Heure système | Synchronisée | Source de temps à revoir |
| Journaux du premier démarrage | Sans erreur matérielle | Périphérique absent ou renommé |
02La recette fonctionnelle, par le métier
La recette technique est faite par l'administrateur, la recette fonctionnelle par le propriétaire du service. Les deux sont nécessaires, et elles ne se remplacent pas : une machine peut être techniquement parfaite et rendre un service dégradé.
- Le propriétaire du service est identifié à l'inventaire et prévenu de la fenêtre. Il valide nominativement, par écrit.
- La liste des tests métier est écrite avant la bascule, pas improvisée après. Trois à cinq parcours suffisent : une connexion, une opération d'écriture, une impression ou un export, une intégration avec un autre système.
- Le service n'est rouvert aux utilisateurs qu'une fois cette validation obtenue.
03Mesurer avant et après
Six mois après une migration, quelqu'un dira que c'était plus rapide avant. Sans chiffre, la discussion est perdue d'avance. Prenez les mesures sur la source, avant la bascule, puis sur la cible, dans les mêmes conditions.
# ecriture aleatoire 4 Ko, le profil le plus revelateur fio --name=alea4k --rw=randwrite --bs=4k --size=4G \ --numjobs=4 --iodepth=32 --direct=1 --runtime=120 \ --time_based --group_reporting # sequentiel 1 Mo, pour les sauvegardes et les gros transferts fio --name=seq1m --rw=write --bs=1M --size=8G \ --numjobs=1 --iodepth=8 --direct=1 # conserver la latence au 99e centile, pas seulement la moyenne
Trois chiffres suffisent et se conservent dans le dossier de migration : opérations par seconde en aléatoire 4 Ko, débit séquentiel, latence au 99e centile. Ajoutez un débit réseau mesuré entre deux machines, et le temps de démarrage complet du service applicatif.
Un aléatoire 4 Ko en net retrait pointe presque toujours vers le stockage ou vers un réglage de disque oublié, cache ou file d'entrées-sorties. Un séquentiel correct mais une latence de queue élevée pointe vers une contention sur le cluster, souvent une autre migration en cours. Mesurer permet de distinguer les deux, et donc de corriger la bonne chose.
04Les sauvegardes avant tout le reste
Une machine migrée sort du périmètre de sauvegarde de l'ancienne plateforme au moment où elle est éteinte côté VMware. Si elle n'est pas immédiatement entrée dans celui de Proxmox Backup Server, elle n'est plus sauvegardée du tout, et personne ne s'en aperçoit.
- Première sauvegarde dans la fenêtre elle-même, pas le lendemain. C'est une ligne du déroulé du chapitre 04.
- Machine ajoutée au travail de sauvegarde périodique, avec la bonne rétention et le bon espace de noms.
- Une restauration test par vague, sur une machine tirée au sort, avec la durée mesurée.
- Vérification PBS activée : une sauvegarde jamais relue n'est qu'une hypothèse.
C'est l'incident le plus fréquent des migrations, et le plus coûteux. Entre l'extinction de la source et l'entrée effective dans le plan de sauvegarde cible, il existe une période sans filet. Elle doit durer quelques minutes, pas quelques semaines. Un indicateur simple le rend visible : le nombre de machines en service sans sauvegarde réussie de moins de 26 heures, tel que décrit au chapitre KPI du guide cluster.
05Le point de non-retour
Le repli reste possible tant que la machine source existe. Sa suppression est donc une décision en soi, à prendre explicitement, jamais par manque de place sur un datastore.
Nos critères, tous requis, pour prononcer la fin du repli sur un lot :
- Recette technique et recette fonctionnelle prononcées, par écrit.
- Au moins deux semaines de service nominal, incluant une clôture mensuelle ou un traitement périodique si le service en comporte.
- Sauvegardes réussies et vérifiées sur toute la période, avec une restauration test réalisée.
- Aucun incident ouvert imputable à la migration.
- Mesures de performance dans l'épure de la référence.
Avant de supprimer une machine source, exportez-la et conservez l'export hors ligne quelques mois. Cela coûte de l'espace d'archivage et supprime la tentation de garder l'ancienne plateforme allumée par précaution, ce qui revient beaucoup plus cher en licences et en électricité.
06Décommissionner vSphere
Le décommissionnement est la partie qui finance le projet. Elle est souvent repoussée, et chaque mois de retard annule une part du gain.
| Étape | Contenu | Point de vigilance |
|---|---|---|
| Libération | Hôtes vidés au fur et à mesure des vagues | Regrouper les reliquats pour libérer des hôtes entiers |
| Licences | Arrêt des renouvellements, résiliation | Respecter le préavis contractuel |
| Sauvegarde | Retrait des travaux et des agents côté ancien outil | Conserver les archives et leur moyen de relecture |
| Supervision | Suppression des sondes vSphere | Vérifier qu'aucune alerte utile n'en dépendait |
| Comptes et accès | Révocation des comptes d'import et de service | Y compris les jetons d'API des outils tiers |
| Matériel | Réinstallation des ESXi en noeuds Proxmox VE | Contrôleurs en mode direct, pas de RAID matériel |
| Documentation | Schémas, plan d'adressage, procédures à jour | Le dossier de migration devient le dossier d'exploitation |
Un hôte ESXi libéré devient un noeud du cluster, à condition que son contrôleur de disques puisse exposer les disques directement, sans couche RAID. C'est le seul point matériel qui bloque parfois : une carte RAID sans mode direct peut rendre un serveur inutilisable pour Ceph. Vérifiez-le au cadrage, pas au moment de réinstaller.
Ce qui change pour les exploitants
- Une interface unique par cluster, sans serveur de gestion séparé à maintenir.
- Les opérations courantes se font aussi en ligne de commande et par API, ce qui ouvre l'automatisation à des équipes qui la pratiquaient peu.
- Le placement des machines devient une décision explicite, faute d'équilibrage automatique. Cela demande de regarder la marge N+1 régulièrement, ce qui n'est pas un mal.
- La formation de l'équipe fait partie du projet. Une plateforme bien construite mais mal maîtrisée produit les mêmes incidents qu'une plateforme mal construite.
Une migration réussie se reconnaît à un signe : plus personne n'en parle trois mois après. Les services rendent le même service, les sauvegardes tournent, et la seule trace du projet est une ligne budgétaire en moins. C'est atteignable, à condition d'accepter que l'essentiel du travail se passe avant la première copie de disque.
Une migration VMware a cadrer, a executer ou a securiser
Nous accompagnons les sorties de VMware vers Proxmox VE, du cadrage et de l'audit de l'existant jusqu'a la recette et a la formation des equipes. Nous intervenons aussi en renfort ponctuel sur les lots les plus sensibles d'une migration deja engagee.