Les bases d'Oracle Cloud Migrations
Cette section vous fournit des informations sur la compréhension et la connaissance des bases de la migration à l'aide d'Oracle Cloud Migrations.
Présentation de la migration des tests et de la migration de la production
La fonctionnalité du service Oracle Cloud Migrations ne fait pas la distinction entre les migrations de machines virtuelles à des fins de test et de production. Cependant, la fonctionnalité de planification et d'exécution de la migration traite les migrations de machines virtuelles à des fins de test et de production différemment. Par conséquent, nous vous recommandons de planifier d'abord une migration de test, puis d'effectuer la migration de production.
Pour une telle fonctionnalité de migration, nous vous recommandons de créer deux plans de migration distincts dans le même projet de migration, l'un pour la migration de test et l'autre pour la migration de production.
Exigences pour le test de planification de migration
Assurez-vous de répondre aux exigences suivantes lors de la création d'un plan de migration de test :
- Rendre les machines virtuelles et les applications opérationnelles : L'objectif de la migration de test est de s'assurer que les machines virtuelles et les applications ou services que vous migrez sont entièrement opérationnels après leur migration vers OCI. Si vous identifiez que d'autres modifications sont nécessaires pour les rendre opérationnelles, automatisez ces modifications ou notez-les. Cette action vous aide à les reproduire rapidement et de manière fiable lors de la migration en production.
- Créer la connectivité réseau requise : Assurez-vous de créer la connectivité réseau requise pour vos instances migrées dans l'environnement de destination. Pour apporter les modifications requises dans la configuration du réseau, modifiez les piles terraform générées dans les plans de migration.
- Vérifier l'ensemble de l'application qui utilise plusieurs machines virtuelles : Si vous migrez des services ou des applications qui utilisent plusieurs machines virtuelles, vérifiez l'ensemble de l'application lors du test de migration. Cela signifie que vous devez vérifier la migration et le lancement de l'application entière à l'aide de plusieurs machines virtuelles et pas seulement des composants individuels s'exécutant sur des machines virtuelles distinctes.
- Vérifiez les incohérences en arrêtant la source : Notez que vous pouvez effectuer une migration de test à l'aide d'instantanés des machines virtuelles sources pendant que ces machines virtuelles continuent de s'exécuter dans le déploiement initial.
Notez également que l'instantané des différentes machines virtuelles n'est pas pris en même temps. Par conséquent, il peut y avoir des incohérences pour les applications complexes qui nécessitent que les données de différents serveurs restent synchronisées. Dans un tel scénario, effectuez une migration de test où la source est arrêtée, similaire à la migration de production. Toutefois, cette option nécessite un temps d'arrêt de l'environnement source. Par conséquent, assurez-vous de planifier correctement la migration de test.
- Planifier la portée des tests requis pour la migration de production : Assurez-vous de planifier la portée des tests pour la migration de production à l'avance. Vous pouvez terminer le test planifié avec succès pendant le créneau horaire de maintenance disponible.
- Terminer des modifications de configuration supplémentaires : Assurez-vous que toutes les configurations supplémentaires à effectuer pour la migration sont terminées. Il peut s'agir de modifications de pare-feu, de mises à jour DNS, de configurations de client, etc.
- Garder un plan de repositionnement à portée de main : Si la migration de test ne se déroule pas comme prévu, assurez-vous qu'il existe une liste d'étapes disponibles pour repositionner une configuration partiellement ou entièrement modifiée. Vous pouvez décider d'annuler les configurations partiellement ou totalement, selon que la tentative de migration a échoué. Vous devez restaurer rapidement les fonctions d'origine.
Vous pouvez effectuer la migration de test dès qu'une réplication pour chaque ressource est terminée. En général, la première réplication nécessite un transfert de données complet. Par conséquent, la première réplication est la plus longue.
Exigences pour la planification de la migration de production
Assurez-vous de répondre aux exigences suivantes lors de la création d'un plan de migration de production :
- Atténuer l'interruption de service : Pour atténuer une interruption de service pendant la migration, planifiez une fenêtre de maintenance pour l'interruption.
- S'assurer qu'aucune transaction n'est perdue : Pour vous assurer qu'aucune transaction n'est perdue pendant la migration, arrêtez vos ressources sources et effectuez une réplication supplémentaire. Ainsi, l'état le plus récent est transféré aux actifs cibles.
Veillez à prendre en compte le temps nécessaire pour effectuer une réplication supplémentaire dans la fenêtre de maintenance de la migration.
- Marquer les ressources sources pour une identification facile : Assurez-vous d'avoir un moyen facile d'identifier les ressources sources dans la console de gestion (par marquage ou une méthode similaire) où vous les gérez. Ainsi, vous pouvez identifier rapidement et de manière fiable ces ressources qui doivent être désactivées avant la dernière session de réplication.
- Fiez-vous à l'automatisation : Notez que vous disposez d'un temps limité pour terminer la migration pendant l'intervalle de la fenêtre de maintenance. Veillez à utiliser les scripts d'automatisation et à tenir à jour les enregistrements pendant les migrations de test. Plus tard, vous pouvez mettre votre plan d'action pour une période spécifique et suivre votre progression par rapport à l'intervalle de la fenêtre de maintenance.
- Avoir un plan d'action prêt : Bien que la réussite de la tentative de migration en production ne soit pas garantie, préparez-vous à décider en fonction de la tentative de migration en production. Ensuite, ayez un plan d'action pour les scénarios de réussite et d'échec.
Si la tentative de migration échoue, annulez la configuration et relancez les ressources sources. Notez ce qui ne s'est pas passé comme prévu, puis prévoyez d'aborder la tentative de migration lors de la prochaine tentative.
Si la migration en production réussit et que les services fonctionnent maintenant dans OCI, marquez vos projets de migration comme terminés afin que les réplications de données s'arrêtent. En général, vous pouvez conserver les données sources disponibles pendant un certain temps afin de pouvoir relancer les ressources sources en cas d'erreur de migration. Toutefois, n'oubliez pas qu'Oracle Cloud Migrations ne prend pas en charge la réplication inverse. Par conséquent, une migration inverse peut être plus complexe et vous devez effectuer un transfert manuel de données pour la sauvegarde ou la restauration d'applications. Dans un tel cas, envisagez d'abord de résoudre les problèmes dans l'environnement de destination, car cela peut nécessiter le moins d'efforts.
Restauration de l'environnement source après la migration
Une fois la migration terminée, vous devez nettoyer l'environnement source et arrêter toutes les ressources migrées pour vous assurer que la migration est terminée et que vous pouvez maintenant utiliser le nouvel environnement OCI. Si vous ne parvenez pas à nettoyer l'environnement source, certains clients peuvent rester connectés aux anciennes ressources et effectuer des opérations sur des données obsolètes.
Pour nettoyer l'environnement source :
- Arrêtez toutes les machines virtuelles migrées qui sont migrées vers OCI.
- Nettoyez tous les instantanés sur VMware vCenter en fonction des politiques de votre organisation.
- Supprimez toutes les machines virtuelles migrées de VMware vCenter et nettoyez le serveur vCenter.
- Mettre hors service toutes les routes de réseau inutiles, au besoin.