De VMware à OpenShift Virtualization : un runbook de migration

Partir de la décision, pas de l’outil

Ce runbook suppose la décision déjà prise : tout ou partie de vos charges VMware tourneront comme machines virtuelles sur Red Hat OpenShift Virtualization. Si ce choix reste ouvert, tranchez-le d’abord. Notre cadre de décision sur la question VMware passe en revue les options, et chacune mène à un plan différent.

Red Hat accompagne la transition avec le Migration Toolkit for Virtualization (MTV), un Operator qui s’exécute sur le cluster OpenShift cible. MTV se connecte à vCenter, copie les disques, convertit chaque système invité pour KVM et crée la VM sur OpenShift. Il fait bien ce travail. Il ne décide pas quelles VM doivent partir, dans quel ordre, vers quels réseaux et quel stockage, ni ce qui se passe si une bascule tourne mal. C’est le rôle du runbook.

Inventorier et classer chaque VM

Listez chaque VM avec son système d’exploitation, son responsable, ses dépendances, la taille de ses disques, son taux de changement et l’interruption tolérée. Le système invité doit être certifié pour OpenShift Virtualization et pris en charge pour la conversion vers KVM avec virt-v2v. Vérifiez chacun sur les deux listes plutôt que de supposer qu’une famille de systèmes courante est couverte.

Certaines VM demandent un traitement particulier ou ne peuvent pas être migrées avec MTV. Les disques rattachés à plusieurs VM en mode multi-writer ne peuvent être migrés qu’à froid ; cela concerne les disques partagés entre VM, pas toute VM dont les disques résident sur un stockage partagé. MTV indique ne pas pouvoir migrer les VM Microsoft Windows qui utilisent Measured Boot ; l’alternative de Red Hat consiste à les recréer sur OpenShift Virtualization. Les invités chiffrés sont pris en charge sous conditions : les volumes LUKS nécessitent la fourniture de leurs phrases de passe ou un déverrouillage configuré avec Clevis et Tang, et BitLocker est pris en charge, mais Red Hat documente des échecs de conversion pour certaines versions de Windows : testez d’abord des builds représentatifs. La validation de MTV signale les problèmes connus de chaque VM avant la migration, et son option Deep Inspection analyse les images disque pour trouver ce que l’inspection standard ne voit pas. Lancez les deux tôt, tant qu’il reste du temps pour corriger ce qu’elles trouvent.

Regroupez ensuite les VM en vagues. Gardez dans la même vague les niveaux applicatifs qui échangent en permanence, et placez en premier les VM dont les responsables tolèrent une interruption plus longue.

Choisir à froid ou à chaud pour chaque VM

Une migration à froid copie une VM arrêtée. Elle fonctionne depuis toutes les sources prises en charge par MTV et c’est la voie la plus simple, mais l’interruption dure toute la copie et la conversion. Une migration à chaud garde la VM en marche pendant que l’essentiel des données est transféré. Elle n’est disponible que depuis VMware vSphere et Red Hat Virtualization.

La migration à chaud se déroule en deux étapes. Pendant l’étape de précopie, la VM continue de tourner pendant que MTV copie ses disques de façon incrémentale grâce à des instantanés changed block tracking (CBT), avec un intervalle de précopie par défaut de 60 minutes, modifiable. L’étape de bascule démarre au moment que vous planifiez ou déclenchez : la VM est arrêtée, les derniers changements sont copiés et l’invité est converti. Une migration à chaud exige donc toujours cet arrêt : ce n’est pas une live migration. La durée de la bascule dépend du volume de données modifiées depuis le dernier instantané : les bases de données très actives ont besoin d’une fenêtre de bascule dimensionnée par la mesure, pas par l’espoir.

La migration à chaud depuis VMware a des prérequis. CBT doit être activé sur la VM et sur ses disques, et VMware Tools doit être installé. Les VM Windows ont aussi besoin des services Volume Shadow Copy et VMware Snapshot Provider activés, en mode Manuel ou Automatique, sinon la création d’instantanés échoue. La live migration, presque sans interruption, n’existe dans MTV qu’entre clusters OpenShift Virtualization ou entre namespaces d’un même cluster, à partir de MTV 2.10 avec OpenShift Virtualization 4.20. Elle n’est pas disponible depuis VMware.

Construire la zone d’accueil avant la première copie

Le stockage d’abord. Chaque datastore source correspond à une storage class OpenShift : les classes doivent donc exister avec les performances, la capacité et les modes d’accès dont les charges ont besoin. Une base de données qui tournait sur du flash rapide dans vSphere verra la différence si elle atterrit sur une classe généraliste.

Les réseaux ensuite. Chaque port group vSphere correspond à un réseau cible : le réseau des pods, ou une network attachment definition Multus qui place la VM sur un VLAN existant. Décidez de l’adressage IP vague par vague. Les interfaces réseau virtuelles changent pendant la migration : une configuration d’IP statique liée au nom de l’interface dans l’invité peut donc être perdue. Cochez l’option de conservation des IP statiques, assurez-vous que les informations sur les interfaces réseau de la VM source sont disponibles pour MTV et validez le réseau après chaque migration. Les règles de pare-feu, les enregistrements DNS et les licences liés à une adresse MAC ou IP demandent la même attention.

Pour les performances de transfert, créez une image VMware Virtual Disk Development Kit (VDDK). Red Hat recommande fortement d’utiliser VDDK pour transférer des disques depuis vSphere, et elle est obligatoire lorsque les VM source sont sur vSAN. Un réseau de migration dédié côté fournisseur source tient le trafic de copie à l’écart du trafic de production. Si ce réseau utilise une MTU différente de la valeur par défaut, le réseau de transfert OpenShift doit utiliser la même valeur.

Correspondances, plans et hooks

Dans MTV, les network maps et storage maps décrivent comment les réseaux et datastores source atterrissent sur la cible, et un plan de migration relie un ensemble de VM à ces correspondances, à un namespace cible et à un type de migration. Un plan par vague garde chaque vague vérifiable et reproductible.

Les hooks avant et après migration exécutent de l’automatisation autour de chaque VM : mettre une application au repos, mettre à jour le DNS ou un répartiteur de charge, enregistrer la nouvelle VM dans la supervision et la sauvegarde. Tout ce qu’une personne ferait à la main à 2 h du matin est un bon candidat pour un hook. Notez qu’un hook avant migration nécessite VMware Tools sur la VM source. MTV permet aussi de donner à des non-administrateurs le droit de créer correspondances et plans dans leurs propres namespaces sans pouvoir créer de fournisseurs ni modifier les paramètres système, ce qui convient aux équipes applicatives responsables de leurs vagues.

Mener une vague pilote et la mesurer

Choisissez une vague pilote qui ressemble à la production, avec les mêmes systèmes, le même stockage et les mêmes réseaux, mais dont les responsables tolèrent un incident. Migrez-la de bout en bout, puis mesurez ce dont dépend le plan : débit de transfert, durée de précopie, durée de bascule par VM et temps de validation de chaque application.

Validez l’exploitation, pas seulement le démarrage. Les nouvelles VM peuvent-elles être sauvegardées et restaurées ? La supervision et les alertes les voient-elles ? L’équipe peut-elle les patcher, les redimensionner et en récupérer une après une panne ? Un pilote qui prouve seulement que les VM démarrent n’a testé que la partie facile.

Basculer avec un retour arrière

Planifiez chaque bascule dans une fenêtre de maintenance convenue, gelez les changements sur les VM de la vague et écrivez qui peut arrêter la bascule et sur quels signaux. Après la bascule, vérifiez que chaque VM démarre, dispose de ses disques et de ses adresses et passe ses tests applicatifs avant que quiconque ne déclare le succès.

Conservez les VM source intactes, éteintes, jusqu’à l’acceptation formelle de la vague. Dans le déroulement normal de MTV, la VM source reste dans vSphere après la copie de ses données, mais vérifiez-le pour votre fournisseur et pour tout hook qui agit sur la source. Une source éteinte ne contient rien de ce qui a été écrit sur la nouvelle VM après la bascule. Revenir en arrière signifie donc arrêter ou isoler la nouvelle VM, décider comment les données écrites depuis la bascule sont récupérées ou réconciliées, et seulement ensuite redémarrer la source et repointer le DNS ou le répartiteur. Convenez à l’avance de la durée maximale d’une vague avant retour arrière, pour que la décision se prenne selon le plan et non sous la pression.

Là où les migrations perdent du temps

Quelques problèmes expliquent la plupart des retards : CBT non activé sur les VM ou les disques prévus pour une migration à chaud, absence d’image VDDK, un network map ou storage map auquel il manque un port group ou un datastore, un stockage cible plus lent que la source, et des règles de pare-feu ou des licences liées aux anciennes adresses. Chacun coûte peu à trouver pendant l’inventaire et cher à découvrir pendant une fenêtre de bascule.

Planifiez aussi le démantèlement. Les licences, hôtes et contrats de support VMware ne cessent de coûter que lorsque l’environnement source est réellement retiré : la dernière vague n’est donc pas la fin du projet.

Notre approche

Voici la séquence que nous suivons : inventaire et validation d’abord, une zone d’accueil construite et testée avant la première copie, un plan de migration par vague, un pilote mesuré, et des bascules avec un retour arrière documenté. Notre Sprint d’évaluation de deux semaines livre une architecture cible écrite et une séquence de migration avec des plans de retour arrière, pour que la migration parte de faits vérifiés plutôt que d’estimations.