Mesures d'atténuation des risques et stratégies de retour en arrière pour la migration vers IBM Cloud VPC

Réduire les risques liés à la migration d' IBM Cloud VPC s — pannes réseau, corruption des données, problèmes de performances — et mettre en place des procédures de restauration.

Risques courants liés à la migration

Les informations suivantes couvrent les difficultés courantes que vous pouvez rencontrer après une migration.

Risque : défaillance de la connectivité du réseau

Symptôme : Après la migration, le serveur virtuel ne peut pas communiquer avec d'autres systèmes.

Détection : Les tests de connectivité post-migration échouent.

2Correctif :

  • Accès via la console VNC (Virtual Network Computing) pour le dépannage
  • Vérifier la configuration de l'interface réseau virtuelle (VNI) (adresse IP, groupes de sécurité)
  • Vérifier les tables de routage dans le VPC et le Transit Gateway
  • Examiner les règles des groupes de sécurité (utiliser les journaux de flux du VPC pour voir les paquets abandonnés)

Retour en arrière : Redémarrer les serveurs virtuels VMware et mettre à jour les DNS et les équilibreurs de charge pour qu'ils pointent vers VMware.

La prévention :

  • Tester minutieusement la connectivité de Transit Gateway avant la migration
  • Vérifier que les règles du groupe de sécurité autorisent le trafic nécessaire
  • Tester la résolution DNS dans le VPC cible

Risque : l'application ne démarre pas

Symptôme: Le service d'application ne démarre pas après la migration, ou démarre mais ne fonctionne pas.

Détection: Le service ne démarre pas ou démarre mais les contrôles de santé échouent.

Correction:

  • Vérifiez si les journaux d'application contiennent des erreurs
  • Vérifier les fichiers de configuration
  • Vérifier les variables d'environnement
  • Vérifier la connectivité de la base de données
  • Vérifier les problèmes de licence

Retour en arrière: Arrêter l'application dans le VPC, redémarrer dans un environnement VMware.

Prévention:

  • Vérifiez que toutes les dépendances sont migrées ou accessibles via Transit Gateway.
  • Tester les procédures de démarrage des applications qui font partie de la vague pilote.
  • Documenter la configuration spécifique à l'application que vous pourriez avoir à ajuster.

Risque : corruption des données

Symptôme: Données corrompues, erreurs du système de fichiers ou incohérences des données de l'application.

Détection: Erreurs de vérification du système de fichiers, l'application signale des erreurs de données, la base de données ne démarre pas

Correction:

  • Tenter une réparation du système de fichiers
  • Si la réparation échoue, il faut réessayer la migration à partir du serveur virtuel source
  • Vérifier que le serveur virtuel source a été arrêté proprement

Revenir en arrière: Abandonnez le serveur virtuel VPC corrompu, redémarrez le serveur virtuel source et recherchez la cause première avant de réessayer la migration.

Prévention:

  • Arrêter proprement les serveurs virtuels avant la migration
  • Vérifier les transferts à l'aide de sommes de contrôle, dans la mesure du possible
  • Utilisez blockdev --flushbufs avant de détacher des volumes

Risque : dégradation des performances

Symptôme: L'application fonctionne moins bien dans VPC que dans VMware.

Détection: Augmentation des temps de réponse et diminution du débit

Correction:

  • Vérifier les mesures de l'unité centrale, de la mémoire, des entrées/sorties de disque et de la bande passante du réseau
  • Vérifier que le profil de stockage dispose d'un nombre suffisant d'IOPS
  • Vérifier que le profil d'instance dispose d'une bande passante suffisante
  • Vérifier la configuration de l'application
  • Envisager la mise à niveau des profils d'instance ou de stockage

Revenir en arrière: Si la situation est critique, revenez à VMware pendant que vous examinez les performances.

Prévention:

  • Performances de base sur VMware avant la migration
  • Sélectionner des profils d'instance et de stockage appropriés, basés sur des lignes de base
  • Activer l'allocation de la bande passante pour le stockage en commun

Conception d'une stratégie de retour en arrière

Utilisez les critères suivants pour déterminer si vous devez procéder à un retour en arrière.

  • Plus de 20 % des serveurs virtuels d'une vague ne démarrent pas
  • Les tests fonctionnels des applications critiques échouent
  • Des données corrompues sont trouvées dans les serveurs virtuels migrés
  • Dégradation des performances de plus de 50 % par rapport à la situation de référence, sans solution rapide
  • Les erreurs de configuration des groupes de sécurité exposent des services sensibles

Renvoi de l'autorité de décision :

  • Définir qui peut prendre la décision de retour en arrière
  • Définir la voie d'escalade en cas de désaccord entre les décideurs
  • Décision sur le démantèlement de la boîte à rythme

Procédures d'annulation

La section suivante explique les phases de la procédure de retour en arrière.

Utilisation de la procédure de retour en arrière de la phase 1

Avant que les serveurs virtuels ne soient créés pendant la migration, suivez ces étapes pour utiliser la procédure de retour en arrière de la phase 1. Ce processus prend environ 30 minutes.

  1. Arrêter la migration.
  2. Supprimer les serveurs virtuels et les volumes de travail.
  3. Redémarrez les serveurs virtuels d' VMware.
  4. Mettre à jour les communications sur l'état de la situation.

Utilisation de la procédure de retour en arrière de la phase 2

Après les serveurs virtuels créés pendant la migration, mais avant le basculement DNS, suivez ces étapes pour utiliser la procédure de retour en arrière de la phase 2. Ce processus dure environ 1 heure.

  1. Arrêter et supprimer les serveurs virtuels migrés.
  2. Redémarrez les serveurs virtuels d' VMware.
  3. Vérifier que les serveurs virtuels VMware sont fonctionnels.
  4. Mettre à jour les communications sur l'état de la situation.

Utilisation de la procédure de retour en arrière de la phase 3

Après le basculement des DNS pendant la migration, les données peuvent changer. Les étapes suivantes permettent d'utiliser la procédure de retour en arrière de la phase 3. Selon la taille des données, ce processus prend de 2 à 4 heures.

  1. Arrêtez les serveurs virtuels, mais ne les supprimez pas.
  2. Mettez à jour les DNS et les équilibreurs de charge pour qu'ils pointent vers VMware.
  3. Redémarrez les serveurs virtuels d' VMware.
  4. Décision sur les données :
    • Si aucune donnée n'a été modifiée, procédez au retour en arrière.
    • Si les données ont changé dans le VPC, vous devez les synchroniser avec VMware avant de pouvoir revenir en arrière.
  5. Synchroniser les données, si nécessaire.
  6. Vérifier que les serveurs virtuels VMware sont fonctionnels.
  7. Après la période de vérification, supprimer les serveurs virtuels VPC

Préservation du serveur virtuel source

Pour vous assurer que les serveurs virtuels sources sont préservés, utilisez les informations suivantes.

  • Ne supprimez pas les serveurs virtuels VMware immédiatement après la migration.
  • La période de conservation est de 7 à 30 jours, en fonction de votre tolérance au risque.
  • Créer des instantanés VMware.
  • Documentez les emplacements des instantanés et vos politiques de conservation.