Documentation sur Oracle Cloud Infrastructure

Migration réelle, de redémarrage et manuelle : Déplacement d'une instance de calcul vers un nouvel hôte

Cette rubrique fournit des informations sur les actions de maintenance qui impliquent le déplacement d'instances de machine virtuelle et sans système d'exploitation lors d'événements de maintenance d'infrastructure. Les actions disponibles sont les suivantes :

Important

Pour plus d'informations sur le moment où une machine virtuelle doit être migrée, voir Maintenance de l'infrastructure.
Conseil

Migration d'hôte dédié de machine virtuelle : Pour plus d'informations sur le déplacement des hôtes dédiés de machine virtuelle lors des événements de maintenance d'infrastructure, voir Gestion de la migration avec redémarrage de maintenance pour les hôtes dédiés de machine virtuelle.
Note

Oracle Platform Services : Pour les instances créées avec Oracle Platform Services et situées dans le compartiment ManagedCompartmentForPaaS, vous devez utiliser l'interface pour le service Platform Service spécifique pour redémarrer les instances.

Migration en direct

La migration en direct est un mécanisme permettant de déplacer une machine virtuelle d'un serveur physique à un autre pendant que la machine virtuelle est toujours en cours d'exécution. Lors d'une migration en direct, l'instance de machine virtuelle source continue de s'exécuter lorsque le service de calcul copie la mémoire et tous les composants virtuels vers la nouvelle instance de machine virtuelle cible. Lorsque la copie est terminée, il n'y a qu'une légère pause, généralement mesurée en dizaines de millisecondes, lorsque le système passe à la nouvelle machine virtuelle.

Lors d'un événement de maintenance d'infrastructure, Oracle Cloud Infrastructure migre en direct les instances de MV prises en charge d'un hôte de MV physique sain qui a besoin d'une maintenance vers un hôte de MV sain avec une perturbation minimale des instances en cours d'exécution.

Si une instance ne peut pas être migrée en direct, Oracle Cloud Infrastructure programme une date d'échéance pour la migration avec redémarrage dans un délai de 14 à 16 jours et vous envoie un avis. Si vous ne redémarrez pas l'instance de manière proactive avant la date d'échéance, elle fait l'objet d'une migration avec redémarrage pour vous.

Par défaut, Oracle Cloud Infrastructure migre l'instance en direct sans envoyer d'avis concernant la maintenance à venir. Lorsqu'une migration en direct commence et se termine, un événement de maintenance d'infrastructure est émis. Vous pouvez utiliser l'automatisation pour suivre les événements de maintenance d'infrastructure.

Prise en charge de la migration en direct

Lorsque vous créez une instance, sélectionnez des paramètres compatibles avec la migration en direct. Pour une instance existante, si elle est prise en charge, vous pouvez activer la migration en direct en modifiant l'instance afin d'utiliser des paramètres compatibles avec la migration en direct. Certains paramètres incompatibles avec la migration en direct ne peuvent pas être modifiés après la création d'une instance.

Le tableau suivant présente les critères qui rendent une instance compatible avec la migration en direct. Tous les critères doivent être remplis pour qu'une instance prenne en charge la migration en direct.

Catégorie Critères qui prennent en charge la migration en direct Peut-on modifier le paramètre après avoir créé l'instance?
Domaine La location se trouve dans le domaine commercial. Non.
Forme

L'instance utilise l'une des formes suivantes :

  • Série VM.Standard1
  • VM.Standard.A1.Flex
  • Série VM.Standard.B1
  • Série VM.Standard2
  • VM.Standard3.Flex
  • Série VM.Standard.E2
  • VM.Standard.E2.1.Micro
  • VM.Standard.E3.Flex
  • VM.Standard.E4.Flex
  • VM.Standard.E5. Champ flexible
  • VM.Standard.E6. Champ flexible
  • VM.Optimized3.Flex

Les autres formes de machine virtuelle, instances sans système d'exploitation et instances sur des hôtes dédiés de machine virtuelle ne prennent pas en charge la migration en direct.

Oui, pour certaines formes. Remplacez la forme de l'instance par une forme prise en charge.

Vous pouvez également mettre fin (supprimer) à l'instance, mais ne supprimez pas le volume de démarrage associé. Ensuite, utilisez le volume de démarrage pour créer une nouvelle instance à l'aide d'une forme qui prend en charge la migration en direct.
Image

Les instances qui utilisent des images de plate-forme Linux ou Windows prennent en charge la migration en direct.

Pour les instances qui utilisent des images personnalisées ou des images Oracle Cloud Infrastructure Marketplace, Oracle Cloud Infrastructure tente de migrer l'instance en direct.

 Non.
Type de lancement de réseau L'instance utilise un réseau paravirtualisé. Oui, modifiez le type de lancement du réseau.
Instances dotées d'une protection maximale Pas de prise en charge. Non.
Windows Defender Credential Guard est activé Pas de prise en charge. Non.
Cartes d'interface réseau virtuelle (vNIC) Le nombre total maximal de cartes vNIC attachées est de six. Oui, détachez et supprimez les cartes vNIC secondaires jusqu'à ce que six cartes vNIC ou moins soient attachées.

Pour déterminer si une instance prend en charge la migration en direct :

  1. Ouvrez le menu de navigation et sélectionnez Calcul. Sous Calcul, sélectionnez Instances.
  2. Sélectionnez l'instance qui vous intéresse.
  3. Vérifiez le champ Migration en direct de l'instance. Si le champ affiche Voir les incompatibilités, l'instance ne prend pas en charge la migration en direct.
  4. (Facultatif) Pour voir quels paramètres ne sont pas compatibles avec la migration en direct, cliquez sur Voir les incompatibilités.

Migration avec redémarrage

Avec la migration avec redémarrage, l'instance est arrêtée, migrée vers un hôte sain, puis redémarrée. Un court temps d'arrêt se produit pendant la migration. Vous pouvez contrôler le moment où le temps d'arrêt se produit en migrant de manière proactive l'instance avec redémarrage avant la date d'échéance de la maintenance.

La migration avec redémarrage est prise en charge pour les instances de machine virtuelle qui utilisent des formes standard, GPU et E/S denses et pour les instances sans système d'exploitation qui utilisent des formes standard. L'action de maintenance par défaut dépend de la forme de l'instance.

  • Instances de machine virtuelle :

    • Formes standard/GPU (y compris Flex) : Dans les 24 heures après la date d'échéance de maintenance, l'instance de machine virtuelle est arrêtée, migrée vers un hôte sain, puis redémarrée. Un court temps d'arrêt se produit pendant la migration.

      Vous pouvez contrôler le moment où le temps d'arrêt se produit en migrant de manière proactive l'instance avec redémarrage avant la date d'échéance de la maintenance.

    • Formes DenseIO (y compris Flex) : À la date d'échéance de la maintenance, l'instance de machine virtuelle est arrêtée, reconstruite, puis redémarrée. Un temps d'arrêt de plusieurs heures se produit pendant le processus de maintenance.

      Si vous voulez réduire le temps d'arrêt et pouvoir supprimer le SSD NVMe attaché localement, vous pouvez redémarrer l'instance de manière proactive avant l'heure de maintenance programmée. L'instance fera l'objet d'une migration avec redémarrage vers un hôte sain et le SSD sera supprimé définitivement. Un court temps d'arrêt se produit pendant la migration.

  • Instances sans système d'exploitation :

    • Formes standard : Dans les 24 heures suivant la date d'échéance de la maintenance, l'instance sans système d'exploitation est arrêtée, migrée vers un hôte sain, puis redémarrée. Un court temps d'arrêt se produit pendant la migration.

      Vous pouvez contrôler le moment où le temps d'arrêt se produit en migrant de manière proactive l'instance avec redémarrage avant la date d'échéance de la maintenance.

      Si la migration avec redémarrage échoue, Oracle Cloud Infrastructure envoie un avis. Vous devez migrer manuellement l'instance vers un hôte sain.

Une fois l'instance migrée avec redémarrage, le champ Redémarrage de maintenance est effacé. Cette modification indique que l'instance a été déplacée avec succès.

Important

Utilisez la console, l'interface de ligne de commande ou la trousse SDK pour effectuer une migration avec redémarrage de l'instance de machine virtuelle. Le redémarrage de l'instance à partir du système d'exploitation ne migre pas l'instance vers un nouveau matériel.

Après une migration, l'instance est récupérée par défaut au même état du cycle de vie qu'avant l'événement de maintenance. S'il existe un autre processus pour récupérer l'instance après une migration avec redémarrage, vous pouvez configurer l'instance pour qu'elle demeure arrêtée après avoir été migrée vers un matériel sain. Pour plus d'informations sur la configuration des options de migration, notamment l'état du cycle de vie des instances après une migration, voir Définition de la disponibilité d'une instance lors des événements de maintenance.

Conseil

Vous pouvez prolonger la date d'échéance pour la migration avec redémarrage, voir Prolongation de la date limite de maintenance

Préalables pour la migration avec redémarrage

Préparez l'instance pour la migration avec redémarrage :

  • Assurez-vous que tous les volumes par blocs définis dans /etc/fstab utilisent les options recommandées.
  • Assurez-vous que le montage du service Stockage de fichiers (NFS) utilise l'option nofail.
  • Si vous utilisez le script fourni par Oracle pour configurer des cartes d'interface réseau virtuelle secondaires, assurez-vous qu'il s'exécute automatiquement au démarrage.

  • Si l'instance utilise une forme à E/S denses, sauvegardez le SSD NVMe attaché localement :

    1. Créez un ou plusieurs volumes par blocs et attachez-les à l'instance.
    2. Copiez les données des appareils NVMe vers les volumes par blocs.

Déplacement d'une instance de machine virtuelle au moyen d'une migration avec redémarrage

Après avoir terminé les préalables :

  1. Arrêtez toute application en cours d'exécution.

  2. Utilisez la console, l'interface de ligne de commande ou la trousse SDK pour redémarrer l'instance. La migration avec redémarrage n'est pas effectuée lorsque vous redémarrez l'instance à partir du système d'exploitation.

    Si l'instance utilise une forme à E/S denses :

    • Utilisation de la console : Dans la boîte de dialogue Redémarrer l'instance, sélectionnez l'option Supprimer le SSD NVMe local et effectuer une migration avec redémarrage vers un hôte sain.
    • Utilisation de l'interface de ligne de commande ou de la trousse SDK : Dans l'opération InstanceAction, réglez l'attribut allowDenseRebootMigration à true.
    Attention

    Pour les instances à E/S denses, le SSD NVMe est supprimé définitivement. Nous vous recommandons de créer une sauvegarde du SSD avant de continuer.
  3. Vérifiez que l'événement de maintenance dans l'onglet Maintenance a l'état Succeeded. (Il existe trois états finaux possibles : Succeeded, Canceled, Failed).
  4. Démarrez et testez toute application sur l'instance.

  5. Pour les instances à E/S denses, si vous voulez restaurer le SSD NVMe :

    1. Attacher les volumes par blocs utilisés pour sauvegarder les appareils NVMe locaux.
    2. Copiez les données dans le stockage NVMe sur la nouvelle instance.
    3. Détachez et, facultativement, supprimez le volume par blocs.

Déplacement d'une instance sans système d'exploitation au moyen d'une migration avec redémarrage

Après avoir terminé les préalables :

  1. Arrêtez toute application en cours d'exécution.

  2. Utilisez la console, l'interface de ligne de commande ou la trousse SDK pour redémarrer l'instance. La migration avec redémarrage n'est pas effectuée lorsque vous redémarrez l'instance à partir du système d'exploitation.

    • Utilisation de la console : Dans la boîte de dialogue Redémarrer l'instance, sélectionnez l'option Effectuer une migration avec redémarrage vers un hôte sain.
    • Utilisation de l'interface de ligne de commande ou de la trousse SDK : Dans l'opération InstanceAction, transmettez la valeur REBOOTMIGRATE comme action à entreprendre. Pour lancer la migration avec redémarrage de l'instance immédiatement, laissez l'attribut timeScheduled vide.
  3. Vérifiez que l'événement de maintenance dans l'onglet Maintenance a l'état Succeeded. (Il existe trois états finaux possibles : Succeeded, Canceled, Failed).
  4. Démarrez et testez toute application sur l'instance.

Déplacement d'une instance avec migration manuelle

Pour les instances sans date dans le champ Redémarrage de maintenance (disponible dans la console, l'interface de ligne de commande et les trousses SDK), vous devez déplacer l'instance manuellement. Cette méthode nécessite que vous supprimez (arrêtez) l'instance, puis lancez une nouvelle instance à partir du volume de démarrage conservé. Les instances qui comportent des cartes vNIC supplémentaires, des adresses IP secondaires, des volumes par blocs attachés distants, le module de plate-forme sécurisée (TPM) activé ou ce qui appartiennent au jeu dorsal d'un équilibreur de charge nécessitent des étapes supplémentaires.

Limitations et avertissements pour la migration manuelle

Tenez compte des limitations et des avertissements suivants lors de l'exécution d'une migration manuelle :

  • Toutes les adresses IP publiques affectées à l'instance à partir d'un groupe public réservé sont conservées. Toutes les adresses non affectées à partir d'un groupe d'adresses IP publiques réservé seront modifiées. Les adresses IP privées ne changent pas.
  • Les adresses MAC, les CPUID et les autres identificateurs matériels uniques sont modifiés lors du déplacement. Si des applications exécutées sur l'instance utilisent ces identificateurs pour des licences ou à d'autres fins, veillez à prendre note de ces informations avant de déplacer l'instance pour mieux gérer la modification.
  • Les instances dotées d'une protection maximale ont des limites supplémentaires. Voir Migration des instances dotées d'une protection maximale.

Préalables pour la migration manuelle

  1. Avant de déplacer l'instance, documentez tous les détails critiques :

    • La région de l'instance, le domaine de disponibilité et le domaine d'erreur.
    • Le nom d'affichage de l'instance.
    • Toutes les adresses IP privées, les noms et les sous-réseaux. Notez que l'instance peut avoir plusieurs cartes d'interface réseau virtuelle et chaque carte d'interface réseau virtuelle peut avoir plusieurs adresses IP secondaires.
    • Tous les noms de DNS privés. L'instance peut avoir plusieurs cartes d'interface réseau virtuelle et chaque carte d'interface réseau virtuelle peut avoir plusieurs adresses IP secondaires. Chaque adresse IP privée peut avoir un nom de DNS.
    • Toute adresse IP publique affectée à partir d'un groupe public réservé. Notez que l'instance peut avoir plusieurs cartes d'interface réseau virtuelle et chaque carte d'interface réseau virtuelle peut avoir plusieurs adresses IP privées secondaires. Chaque carte d'interface réseau virtuelle et chaque adresse IP privée secondaire peut avoir une adresse IP publique attachée.
    • Tout volume par blocs attaché à l'instance.
    • Tout marqueur sur l'instance ou les ressources attachées.

  2. Préparez l'instance pour la migration manuelle :

    • Assurez-vous que tous les volumes par blocs définis dans /etc/fstab utilisent les options recommandées.
    • Assurez-vous que le montage du service Stockage de fichiers (NFS) utilise l'option nofail.
    • Si vous avez défini statiquement toutes les interfaces réseau appartenant aux cartes d'interface de réseau virtuelle secondaires à l'aide de leurs adresses MAC, telles que définies dans /etc/sysconfig/network-scripts/ifcfg*, ces interfaces ne démarrent pas en raison de la modification de l'adresse MAC. Supprimez le mappage statique.
    • Si vous utilisez le script fourni par Oracle pour configurer des cartes d'interface réseau virtuelle secondaires, assurez-vous qu'il s'exécute automatiquement au démarrage.

Déplacement manuel d'une instance

Après avoir terminé les préalables, procédez comme suit.

  1. Arrêtez toute application en cours d'exécution.

  2. Assurez-vous que ces applications ne démarrent pas automatiquement.

    Attention

    Lors du premier démarrage de l'instance déplacée, les volumes par blocs, les cartes vNIC secondaires et toutes les ressources qui en dépendent ne sont pas attachés. L'absence de ces ressources peut entraîner des problèmes avec l'application.

  3. Si l'instance utilise une forme à E/S denses, sauvegardez le SSD NVMe attaché localement :

    1. Créez un ou plusieurs volumes par blocs et attachez-les à l'instance.
    2. Copiez les données des appareils NVMe vers les volumes par blocs.
  4. Démontez tous les volumes par blocs ou montages du service Stockage de fichiers (NFS).
  5. Sauvegardez tous les volumes par blocs.

  6. Créez une sauvegarde du volume de démarrage.

    Important

    Ne généralisez ou ne spécialisez pas les instances Windows.

  7. Mettez fin (supprimez) à l'instance, en conservant le volume de démarrage attaché :

    Utilisation de la console

    Suivez les étapes sous Interruption d'une instance, en veillant à désélectionner la case à cocher Supprimer définitivement le volume de démarrage attaché. Le volume de démarrage associé à l'instance est ainsi conservé.

    Utilisation de l'interface de ligne de commande

    Utilisez l'opération arrêt de l'instance et réglez l'option preserve-boot-volume à true.

    Utilisation de l'API

    Utilisez l'opération TerminateInstance et transmettez le paramètre preserveBootVolume réglé à true dans la demande.

  8. Créez une instance à l'aide du volume de démarrage de l'instance arrêtée.

    (Facultatif) Si l'instance se trouve sur un nouvel hôte de machine virtuelle dédié :

    • Dans la section Positionnement, sélectionnez Afficher les options avancées.
    • Pour Type de capacité, sélectionnez Hôte dédié.
    • Sélectionnez l'hôte dédié de machine virtuelle sur lequel vous voulez placer l'instance.

    Dans le flux de création de l'instance, spécifiez l'adresse IP privée qui a été attachée à la carte vNIC principale. Si l'adresse IP publique a été affectée à partir d'un groupe d'adresses IP réservé, veillez à affecter la même adresse IP.

  9. Lorsque l'état de l'instance passe à En cours d'exécution, arrêtez l'instance.
  10. Recréez les cartes d'interface réseau virtuelle secondaires et les adresses IP secondaires.

  11. Attachez tous les volumes par blocs.

    Note

    Cette étape comprend tous les volumes utilisés pour sauvegarder les appareils NVMe locaux. Copiez les données dans le stockage NVMe sur la nouvelle instance, puis détachez les volumes.
  12. Démarrez l'instance.
  13. Démarrez et testez toute application sur l'instance.
  14. Configurez les applications pour qu'elles démarrent automatiquement, le cas échéant.
  15. Recréez les marqueurs requis.
  16. (Facultatif) Après avoir vérifié que l'instance et les applications sont saines, vous pouvez supprimer les sauvegardes de volume.