Migration VMware multi-sites vers Proxmox VE
Point de départ
Trois sites de production industrielle, ~250 VMs, dont une vingtaine de charges avec SLA internes stricts. Le renouvellement Broadcom avait été multiplié par 5 par rapport au contrat précédent. La décision de migrer était prise. Ce qui manquait : une méthode.
La pression commerciale poussait à démarrer vite. L'expérience de terrain poussait à démarrer juste.
:::Point critique Le PRA existait sur papier. Mais it n'avait jamais été exécuté dans un contexte de migration. Démarrer sans l'avoir rejoué, c'était exposer la production à un risque non mesuré. :::
Audit préalable : ce qu'on a trouvé
Avant de toucher à la première VM, deux semaines d'audit :
- Cartographie des flux réseau inter-sites et inter-VMs
- Inventaire des dépendances stockage (NFS, iSCSI, snapshots de production)
- Analyse des scripts d'exploitation et des procédures de basculement
- Exécution partielle du PRA pour mesurer le RTO réel
Le RTO déclaré dans les contrats SLA internes était de 15 minutes. Le RTO mesuré lors du test partiel était de 42 minutes. Ce delta a changé toute la séquence de migration.
:::Observation terrain Les fenêtres de maintenance "disponibles" selon le planning annuel ne correspondaient pas aux contraintes de production réelles. Trois des cinq fenêtres prévues ont été décalées lors de nos prises de contact avec les équipes métier. :::
Architecture Proxmox cible
Architecture retenue : clusters Proxmox VE multi-nœuds par site, avec réplication cross-site sur les charges critiques. Stockage distribué Ceph pour les charges qui le nécessitent, ZFS local pour les workloads à faible résilience requise.
Points de conception non négociables :
- Bascule automatique sans intervention humaine pour les charges prioritaires
- Réplication synchrone ou asynchrone selon la criticité (pas une architecture unique pour tout)
- Accès de gestion indépendant par site en cas de coupure WAN
- Pas de dépendance à un composant central unique
Séquence de migration
La migration a été découpée en 7 vagues sur 14 semaines :
- Vagues 1-2 : charges de développement et de test — pour valider les procédures V2V, la configuration réseau cible, et les runbooks d'opération
- Vagues 3-4 : infrastructure support (DNS, supervision, sauvegardes) — les outils nécessaires pour opérer la suite
- Vagues 5-6 : charges de production secondaires — premier contact avec le workload réel
- Vague 7 : charges critiques avec SLA — uniquement après validation du RTO réel sur les vagues précédentes
:::Arbitrage retenu Chaque vague se terminait par une validation RTO en conditions réelles avant que la vague suivante démarre. Le planning initial prévoyait 10 semaines. Il a pris 14, à cause de deux reports demandés par les équipes métier. C'était la bonne décision. :::
Coexistence VMware / Proxmox
L'environnement VMware est resté opérationnel jusqu'à la fin de la vague 7. Coexistence réelle, non symbolique : les charges critiques pouvaient être basculées en retour si nécessaire.
Cette décision avait un coût (licences VMware payées plus longtemps). Elle avait aussi une valeur : l'équipe de production a accepté la migration parce qu'elle ne se sentait pas dans un "point de non-retour" permanent.
:::Réalité production Le rollback n'a jamais été activé sur les charges critiques. Mais il a été activé deux fois sur des charges secondaires. Ces deux activations ont validé que le dispositif fonctionnait — et ont renforcé la confiance pour la suite. :::
Résultat
Infrastructure Proxmox VE opérationnelle sur les 3 sites. Réplication cross-site active. PRA documenté avec RTO mesuré inférieur à 8 minutes sur les charges critiques. Réduction de 70 % des coûts de licence dès la première année post-migration. Équipe exploitation autonome sur les procédures courantes après une session de formation en situation réelle.