Planification des vagues de migration des serveurs virtuels sur IBM Cloud VPC

Planifiez les vagues de migration d' IBM Cloud VPC s en cartographiant les dépendances des machines virtuelles ( VM ), en estimant la vélocité et en programmant les fenêtres de basculement pour les piles d'applications.

Planification de la dépendance

Avant de commencer vos vagues de migration, vous devez mettre en correspondance les dépendances de l'application suivantes :

Basé sur les niveaux :

  • Niveau web → Niveau applicatif
  • Niveau de l'application → Niveau de la base de données
  • Base de données → Stockage et services partagés

Application croisée :

  • Authentification
  • Monitoring
  • Backup
  • Agrégation de journaux
  • DNS et NTP

Outils de découverte :

  • VMware vRealize Network Insight ( ) vRNI
  • Outils de cartographie des dépendances des applications
  • Analyse des flux de réseaux
  • Documentation manuelle des propriétaires de l'application

Pour chaque serveur virtuel, enregistrez les informations suivantes dans votre plan de migration :

  • Dépendances entrantes
  • Dépendances sortantes
  • Ressources partagées

Conception de la vague de migration des essais

La première vague de migration est la vague d'essai (pilote). Pour mettre en œuvre une vague de tests réussie, vous devez respecter les informations suivantes :

Représentation correcte de vos serveurs virtuels :

  • Serveur virtuel à disque unique « Linux »
  • Serveur virtuel « Linux » à disques multiples
  • Serveur virtuel Windows à disque unique
  • Serveur virtuel Windows multi-disques
  • Application avec dépendances (application à trois niveaux)

Utiliser des options à "risque minimum" :

  • Mettre en œuvre la migration dans un environnement de non-production. Ou encore, utilisez un environnement de production qui comporte de larges fenêtres de maintenance.
  • Connaître la procédure de retour en arrière de vos applications.

Effectuer une migration complète :

  • Test complet de bout en bout des méthodes choisies
  • Note timing de migration versus timing estimé
  • Découverte de problèmes qui n'ont pas été détectés lors des tests

Critères de réussite de la migration :

  • Tous les serveurs virtuels démarrent avec succès
  • Les applications fonctionnent correctement
  • Vérification de la connectivité du réseau
  • Les performances atteignent ou dépassent le niveau de référence
  • Pas de perte ou de corruption de données
  • La documentation relative à la migration est complète et exacte

Lignes directrices sur la structure des vagues

Regroupement basé sur les sous-réseaux :

N'oubliez pas que vous ne pouvez pas étendre un sous-réseau entre VMware et VPC. Cela signifie que vous devez effectuer les actions suivantes :

  • Regrouper les serveurs virtuels par sous-réseau
  • Migrer des sous-réseaux entiers en une seule vague ou savoir que vous devez ré-IPer certains serveurs virtuels
  • Planifier le mappage des sous-réseaux vers les sous-réseaux VPC au plus tôt

Regroupement des piles d'applications pour les applications multi-niveaux :

  • Migrer l'ensemble de la pile en une seule vague, si possible.
  • Si votre migration est trop importante, migrez d'abord la base de données, puis les applications, et ainsi de suite.
  • Assurez la connectivité entre les niveaux migrés et non migrés via IBM Cloud Transit Gateway.

Regroupement de piles d'applications pour un séquençage tenant compte des dépendances :

  • Migrer d'abord les services d'infrastructure (DNS, surveillance, sauvegarde).
  • Migrer les services partagés avant les applications dont ils ont besoin.
  • Examinez les effets de chaque vague et évaluez l'impact en cas d'échec.

Capacités de migration parallèle :

La méthode 3 Transfert en direct sur le réseau(recommandée pour Scale) est la meilleure :

  • Approvisionnement de plusieurs instances de serveurs virtuels de travail
  • Migration simultanée de plusieurs serveurs virtuels
  • Limité par la bande passante du réseau et les ressources de l'instance du serveur virtuel du travailleur
  • Typique : 4 à 8 migrations simultanées par instance de serveur virtuel de travailleur

Structure de l'exemple d'onde de test

L'exemple suivant montre une migration de 50 serveurs virtuels.

Vague 0 (test): 5 serveurs virtuels

  • 1x Disque unique Linux (test de la méthode 1)
  • 1x Multi-disques Linux (test de la méthode 2)
  • 1x Windows à disque unique (méthode 1 avec sysprep)
  • 1x Windows multi-disques (Méthode 2 avec virt-v2v )
  • 1x application de test à trois niveaux (méthodes 2 et 3, pile complète)

Vague 1 (infrastructure): 8 serveurs virtuels

  • Serveurs DNS
  • Surveillance des serveurs
  • Hôtes de saut ou serveurs de bastion
  • Serveurs de fichiers partagés ayant migré vers le stockage de fichiers VPC

Vague 2 (application A): 12 serveurs virtuels

  • Base de données (3 serveurs virtuels)
  • App tier (6 serveurs virtuels)
  • Niveau Web (3 serveurs virtuels)
  • Sous-réseau 10.50.10.0/24 → sous-réseau VPC 10.240.10.0/24

Vague 3 (application B): 10 serveurs virtuels

  • Base de données et applications combinées (4 serveurs virtuels)
  • Niveau Web (6 serveurs virtuels)
  • Sous-réseau 10.50.20.0/24 → sous-réseau VPC 10.240.20.0/24

Vague 4 (application C): 15 serveurs virtuels

  • Grande application multi-niveaux
  • Sous-réseau 10.50.30.0/24 → sous-réseau VPC 10.240.30.0/24

Conception de la fenêtre de basculement

Chaque vague a besoin d'une fenêtre de transition bien définie.

Délai de pré-découpage (7 jours jusqu'au jour de la migration):

  • Finaliser le plan d'ondes et le cahier des charges
  • Confirmer la connectivité de Transit Gateway
  • Approvisionnement des instances de serveurs virtuels de travail et des volumes cibles
  • Communiquer la fenêtre de transition aux parties prenantes
  • Réduire les TTL DNS pour les services en cours de migration
  • Notifier les utilisateurs de la fenêtre de maintenance

Exécution de la bascule ( T-0 )

Les informations suivantes décrivent les phases de basculement.

Phase 1 : Suspension et migration (heures 0 à 4)

  1. Drainer les connexions - retirer les connexions des équilibreurs de charge et attendre que les sessions se ferment.
  2. Arrêter les applications en douceur
  3. Arrêter les serveurs virtuels ou démarrer à partir de l'ISO live pour la méthode 3
  4. Commencer le transfert de disque
  5. Suivre l'évolution des transferts

Phase 2 : transformation et mise à disposition (heures 4 à 6)

  1. Lancez virt-v2v, si nécessaire, pour injecter les pilotes
  2. Vérifier les transferts de disques (fdisk, sommes de contrôle)
  3. Vider les tampons et détacher les volumes du travailleur
  4. Créer les instances de serveurs virtuels à partir des volumes migrés
  5. Démarrer les instances de serveurs virtuels

Phase 3 : Validation et transition (heures 6-8)

  1. Démarrer les instances de serveurs virtuels et y accéder via la console VNC si nécessaire
  2. Vérifier la configuration du réseau et l'adapter si nécessaire
  3. Lancer les candidatures
  4. Tests fonctionnels (l'application fonctionne, les données sont accessibles)
  5. Ajouter aux équilibreurs de charge et mettre à jour le DNS
  6. Surveillance des performances de l'application

Phase 4 : Stabilisation (heures 8 à 12)

  1. Contrôler les problèmes
  2. Vérifier la connectivité externe
  3. Vérifiez si les journaux d'application contiennent des erreurs
  4. Comparer les performances à la référence

Points de décision pour le retour en arrière de la migration :

  • Après la phase 1 : retour en arrière facile (redémarrage des serveurs virtuels VMware )
  • Après la phase 2 : Difficulté moyenne (suppression des instances de serveurs virtuels, redémarrage des serveurs virtuels VMware, restauration des DNS)
  • Après la phase 3 : difficile (il peut y avoir de nouvelles données dans le VPC, ce qui nécessite une synchronisation des données vers VMware )

Recommandation en matière de conception : Définir des points de contrôle explicites. Exemples :

  • Après la phase 2, si plus de 20 % des instances de serveurs virtuels ne démarrent pas, procéder à un retour en arrière.
  • Après la phase 3, si les tests fonctionnels de l'application échouent, il faut procéder à un retour en arrière.
  • Après la phase 4, si les performances sont inférieures de plus de 30 % au niveau de référence, il convient d'examiner la situation, mais pas de procéder à un retour en arrière.

Estimation de la vitesse de migration

Estimez le temps de migration par serveur virtuel pour planifier des tailles de vagues et des fenêtres réalistes. Le calendrier suivant est réalisable, mais vous devez vous rendre sur le site PoC avant la migration proprement dite.

Éléments temporels :

Exporter les estimations de temps en utilisant les méthodes 1-2 :

  • serveur virtuel de 100 Go : 20-30 minutes
  • serveur virtuel de 500 Go : 2-3 heures
  • Dépend de la performance du stockage VMware

Estimation du temps de transfert :

  • Réseau : 100 GB = 20-25 minutes
  • Réseau : 500 GB = 90-120 minutes
  • Méthode 3 avec compression : souvent 2 ou 3 fois plus rapide grâce à la compression

Estimation du temps de transformation avec virt-v2v:

  • Linux: 5 à 10 minutes
  • Fenêtres : 10-20 minutes
  • Dépend de la performance de l'instance du serveur virtuel du travailleur

Estimation du temps d'approvisionnement :

  • Création d'une instance de serveur virtuel : 5 minutes
  • Démarrage et configuration du réseau : 5-10 minutes

Exemples d'estimations de temps :

Petit serveur virtuel Linux (1 disque, 100 GB, Méthode 3):

  • Pas d'exportation : 0 minute
  • Transfert avec compression : 25 minutes
  • Transformation : 5 minutes
  • Approvisionnement : 10 minutes
  • Total : 40 minutes

Estimation de la durée d'un grand serveur virtuel Windows en utilisant la méthode 2 avec 4 disques, 1 TB au total :

  • Exportation : 3 heures
  • Transfert : 2 heures
  • Transformation ( virt-v2v ): 20 minutes
  • Approvisionnement : 10 minutes
  • Total : 5.5 heures

Efficacité de la migration parallèle en utilisant à la fois la méthode 3, 4 et l'estimation du temps :

  • 4x serveurs virtuels de 100 Go migrés en parallèle
  • 30 minutes chacun
  • Durée totale de l'onde : 35 minutes, y compris les temps de démarrage et d'arrêt

Par rapport à la migration de 4x serveurs virtuels de 100 Go que vous migrez en série :

La durée totale de l'onde est de 120 minutes

Le parallélisme permet une amélioration de 3 à 4 fois pour ce scénario.