12.5. Annulation d’une migration
Vous pouvez annuler une migration en utilisant la console Web MTC ou la CLI.
Vous pouvez également annuler une migration manuellement.
12.5.1. Annulation d’une migration à l’aide de la console Web MTC Copier lienLien copié sur presse-papiers!
Vous pouvez annuler une migration en utilisant la console Web MTC (Migration Toolkit for Containers).
Les ressources suivantes restent dans les espaces de nommage migrés en vue du débogage après l’échec d’une migration directe de volumes (DVM) :
- Objets ConfigMap (clusters source et de destination)
-
Objets
Secret(clusters source et de destination) -
CR
Rsync(cluster source)
Ces ressources n’affectent pas l’annulation. Vous pouvez les supprimer manuellement.
Si, par la suite, vous exécutez le même plan de migration avec succès, les ressources de la migration qui a échoué seront automatiquement supprimées.
Si votre application a été arrêtée au cours d’une migration qui a échoué, vous devez annuler la migration pour éviter une corruption des données dans le volume persistant.
L’annulation n’est pas nécessaire si l’application n’a pas été arrêtée pendant la migration, car l’application d’origine est toujours en cours d’exécution sur le cluster source.
Procédure
- Dans la console Web MTC, cliquez sur Migration plans.
-
Cliquez sur le menu Options
à côté d'un plan de migration et sélectionnez Rollback sous Migration.
Cliquez sur Rollback et attendez que le processus d’annulation soit terminé.
Dans les détails du plan de migration, le message Rollback succeeded est affiché.
Vérifiez que l’annulation a réussi dans la console Web OpenShift Container Platform du cluster source :
-
Cliquez sur Home
Projects. - Cliquez sur le projet migré pour afficher son état.
- Dans la section Routes, cliquez sur Location pour vérifier que l’application fonctionne correctement, le cas échéant.
-
Cliquez sur Workloads
Pods pour vérifier que les pods s’exécutent dans l’espace de nommage migré. -
Cliquez sur Storage
Persistent volumes pour vérifier que le volume persistant migré est correctement mis en service.
-
Cliquez sur Home
12.5.2. Annulation d’une migration à partir de l’interface de ligne de commande Copier lienLien copié sur presse-papiers!
Vous pouvez annuler une migration en créant une ressource personnalisée (CR) MigMigration à partir de l’interface de ligne de commande.
Les ressources suivantes restent dans les espaces de nommage migrés en vue du débogage après l’échec d’une migration directe de volumes (DVM) :
- Objets ConfigMap (clusters source et de destination)
-
Objets
Secret(clusters source et de destination) -
CR
Rsync(cluster source)
Ces ressources n’affectent pas l’annulation. Vous pouvez les supprimer manuellement.
Si, par la suite, vous exécutez le même plan de migration avec succès, les ressources de la migration qui a échoué seront automatiquement supprimées.
Si votre application a été arrêtée au cours d’une migration qui a échoué, vous devez annuler la migration pour éviter une corruption des données dans le volume persistant.
L’annulation n’est pas nécessaire si l’application n’a pas été arrêtée pendant la migration, car l’application d’origine est toujours en cours d’exécution sur le cluster source.
Procédure
Créez une CR
MigMigrationsur la base de l’exemple suivant :Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Indiquez le nom de la CR
MigPlanassociée.
- Dans la console Web MTC, vérifiez que les ressources de projet ayant fait l’objet d’une migration ont été supprimées du cluster cible.
- Vérifiez que les ressources migrées sont présentes dans le cluster source et que l’application est en cours d’exécution.
12.5.3. Annulation manuelle d’une migration Copier lienLien copié sur presse-papiers!
Vous pouvez annuler manuellement une migration qui a échoué en supprimant les pods stage et en réactivant l’application.
Si vous exécutez le même plan de migration avec succès, les ressources de la migration qui a échoué sont automatiquement supprimées.
Les ressources suivantes restent dans les espaces de nommage migrés après l’échec d’une migration directe des volumes (DVM) :
- Objets ConfigMap (clusters source et de destination)
-
Objets
Secret(clusters source et de destination) -
CR
Rsync(cluster source)
Ces ressources n’affectent pas l’annulation. Vous pouvez les supprimer manuellement.
Procédure
Supprimez les pods
stagesur tous les clusters :oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>)
$ oc delete $(oc get pods -l migration.openshift.io/is-stage-pod -n <namespace>)1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Espaces de nommage spécifiés dans la CR
MigPlan.
Réactivez l’application sur le cluster source en dimensionnant les réplicas sur leur nombre d’avant la migration :
oc scale deployment <deployment> --replicas=<premigration_replicas>
$ oc scale deployment <deployment> --replicas=<premigration_replicas>Copy to Clipboard Copied! Toggle word wrap Toggle overflow L’annotation
migration.openshift.io/preQuiesceReplicasdans la CRDeploymentaffiche le nombre de réplicas d’avant la migration :Copy to Clipboard Copied! Toggle word wrap Toggle overflow Vérifiez que les pods d’application sont en cours d’exécution sur le cluster source :
oc get pod -n <namespace>
$ oc get pod -n <namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow