Documentation Oracle Cloud Infrastructure

Migration en direct, au 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 transfert des instances de machine virtuelle et Bare Metal lors des é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, reportez-vous à Maintenance d'infrastructure.
Conseil

Migration d'hôte de machine virtuelle dédié : pour obtenir des informations sur le transfert d'hôtes de machine virtuelle dédiés lors d'événements de maintenance d'infrastructure, reportez-vous à Gestion de la migration de la réinitialisation de maintenance pour les hôtes de machine virtuelle dédiés.
Remarque

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

Migration en direct

L'instance en mauvais état est copiée sur un hôte en bon état alors que l'instance existante est toujours en cours d'exécution. L'interruption des instances en cours d'exécution est minimale.

Lors d'un événement de maintenance d'infrastructure, Oracle Cloud Infrastructuremigre en direct les instances de machine virtuelle prises en charge de l'hôte de machine virtuelle physique nécessitant une maintenance vers un hôte de machine virtuelle en bon état, avec une interruption 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 au redémarrage comprise entre 14 et 16 jours, et vous envoie une notification. Si vous ne redémarrez pas l'instance de façon proactive avant la date d'échéance, l'instance est migrée au redémarrage pour vous.

Par défaut, Oracle Cloud Infrastructure migre l'instance en direct sans envoyer de notification concernant la maintenance à venir. Au début et à la fin d'une migration en direct, 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, lorsqu'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 prenant en charge la migration en direct Le paramètre peut-il être modifié après la création de 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.E5Champ flexible
  • VM.Optimized3.Flex

Les autres formes de machine virtuelle, instances Bare Metal et instances sur des hôtes de machine virtuelle dédiés 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 à l'instance (la supprimer), mais ne pas supprimer le volume d'initialisation associé. Ensuite, utilisez le volume d'initialisation pour créer une 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 en direct l'instance.

 Non.
Type de lancement de réseau L'instance utilise des réseaux paravirtualisés. Oui, modifiez le type de lancement du réseau.
Instances protégées Non prise en charge. Non.
Windows Defender Credential Guard est activé Non prise en charge. Non.
Cartes d'interface réseau virtuelles Le nombre total maximal de cartes d'interface réseau virtuelles attachées est de six. Oui. Détachez et supprimez les cartes d'interface réseau virtuelles secondaires jusqu'à ce que six cartes d'interface réseau virtuelles au maximum soient attachées.

Pour déterminer si une instance prend en charge la migration en direct, procédez comme suit :

  1. Ouvrez le menu de navigation et cliquez sur Compute. Sous Compute, cliquez sur Instances.
  2. Cliquez sur l'instance qui vous intéresse.
  3. Vérifiez le champ Migration en direct de l'instance. Si le champ affiche Afficher 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 Visualiser les incompatibilités.

Migration au redémarrage

L'instance est arrêtée, migrée vers un hôte en bon état, puis redémarrée. Un petit temps d'inactivité survient durant la migration. Pour contrôler le moment où le temps d'inactivité survient, migrez l'instance au redémarrage de manière proactive avant la date d'échéance de la maintenance.

La migration au redémarrage est prise en charge pour les instances de machine virtuelle qui utilisent des formes standard, GPU et à E/S dense, ainsi que pour les instances Bare Metal 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 : dans les 24 heures suivant la date d'échéance de la maintenance, l'instance de machine virtuelle est arrêtée, migrée vers un hôte en bon état, puis redémarrée. Un petit temps d'inactivité survient durant la migration.

      Pour contrôler le moment où le temps d'inactivité survient, migrez l'instance au redémarrage de manière proactive avant la date d'échéance de la maintenance.

    • Formes à E/S dense : à la date d'échéance de la maintenance, l'instance de machine virtuelle est arrêtée, reconstruite, puis redémarrée. Le processus de maintenance provoque un temps d'inactivité de plusieurs heures.

      Si vous voulez réduire le temps d'inactivité et que vous êtes en mesure de supprimer le disque SSD NVMe attaché en local, vous pouvez redémarrer l'instance de manière proactive avant l'heure de maintenance programmée. L'instance sera migrée au redémarrage vers un hôte en bon état et le disque SSD sera supprimé définitivement. Un petit temps d'inactivité survient durant la migration.

  • Instances Bare Metal :

    • Formes standard : dans les 24 heures suivant la date d'échéance de la maintenance, l'instance Bare Metal est arrêtée, migrée vers un hôte en bon état, puis redémarrée. Un petit temps d'inactivité survient durant la migration.

      Pour contrôler le moment où le temps d'inactivité survient, migrez l'instance au redémarrage de manière proactive avant la date d'échéance de la maintenance.

      Si la migration au redémarrage échoue, Oracle Cloud Infrastructure envoie une notification. Vous devez alors migrer manuellement l'instance vers un hôte en bon état.

Le champ Redémarrage de maintenance est effacé une fois l'instance migrée au redémarrage. Cette modification indique que l'instance a bien été déplacée.

Important

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

Après une migration, l'instance est par défaut récupérée dans le même état de cycle de vie qu'avant l'événement de maintenance. Si vous appliquez un autre processus pour récupérer l'instance après une migration au redémarrage, vous pouvez configurer l'instance afin qu'elle reste arrêtée après sa migration vers le matériel en bon état. Pour plus d'informations sur la configuration des options de migration, y compris l'état de cycle de vie des instances après une migration, reportez-vous à Définition de la disponibilité d'instance lors des événements de maintenance.

Extension de la date limite de migration au redémarrage

Vous pouvez reporter la date d'échéance de la maintenance des instances pour lesquelles une migration au redémarrage est programmée. Le report de la date limite est pris en charge pour les instances de machine virtuelle et Bare Metal qui utilisent des formes standard. Oracle Cloud Infrastructure détermine le dernier moment possible auquel la date d'échéance peut être reportée.

Utilisation de la console : report de la date d'échéance de la maintenance d'une instance
  1. Ouvrez le menu de navigation et cliquez sur Compute. Sous Compute, cliquez sur Instances.

  2. Cliquez sur l'instance qui vous intéresse, puis vérifiez le champ Redémarrage de maintenance de l'instance. Si le bouton Reporter la date limite est actif, la date d'échéance de la maintenance peut être reportée.

  3. Cliquez sur Reporter la date limite.
  4. Dans la zone Nouvelle date limite, sélectionnez une nouvelle date et une nouvelle heure.

  5. Cliquez sur Enregistrer les modifications.

    La date d'échéance de la maintenance est reportée. Dans les 24 heures suivant la date d'échéance de la maintenance, l'instance est arrêtée, migrée vers un hôte en bon état, puis redémarrée. Un petit temps d'inactivité survient durant la migration.

Utilisation de l'API : report de la date d'échéance de la maintenance d'une instance
  1. Vérifiez le dernier moment auquel la date d'échéance peut être reportée à l'aide de l'opération GetInstanceMaintenanceReboot.

  2. Reportez la date d'échéance de la maintenance en effectuant l'une des opérations suivantes :

    • Machines virtuelles et instances Bare Metal : utilisez l'opération InstanceAction en transmettant la valeur REBOOTMIGRATE comme action à effectuer. Dans l'attribut timeScheduled, indiquez la date d'échéance mise à jour.
    • Machines virtuelles : utilisez l'opération UpdateInstance en transmettant la date d'échéance mise à jour dans l'attribut timeMaintenanceRebootDue.

    La date d'échéance de la maintenance est reportée. Dans les 24 heures suivant la date d'échéance de la maintenance, l'instance est arrêtée, migrée vers un hôte en bon état, puis redémarrée. Un petit temps d'inactivité survient durant la migration.

Prérequis pour la migration au redémarrage

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

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

  • Si l'instance utilise une forme à E/S dense, sauvegardez le disque SSD NVMe attaché en local :

    1. Créez des volumes de blocs et attachez-les à l'instance.
    2. Copiez les données des périphériques NVMe vers les volumes de blocs.

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

Une fois que vous avez suivi les prérequis, procédez comme suit :

  1. Arrêtez les applications en cours d'exécution.

  2. Utilisez la console, l'interface de ligne de commande ou le kit SDK pour redémarrer l'instance. La migration au 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 dense, suivez l'une des procédures ci-dessous :

    • Utilisation de la console : dans la boîte de dialogue Redémarrer l'instance, sélectionnez l'option Supprimer le disque SSD NVMe en local et migrer au redémarrage vers un hôte en bon état.
    • Utilisation de l'interface de ligne de commande ou du kit SDK : dans l'opération InstanceAction, définissez l'attribut allowDenseRebootMigration sur true.
    Attention

    Pour les instances à E/S dense, le disque SSD NVMe est supprimé définitivement. Nous vous recommandons de créer une sauvegarde du disque SSD avant de continuer.
  3. Vérifiez que le champ Redémarrage de maintenance ne comporte plus de date.
  4. Démarrez et testez les applications sur l'instance.

  5. Pour les instances à E/S dense, si vous voulez restaurer le disque SSD NVMe, procédez comme suit :

    1. Attachez les volumes de blocs utilisés pour sauvegarder les périphériques NVMe locaux.
    2. Copiez les données vers le stockage NVMe de la nouvelle instance.
    3. Détachez et éventuellement supprimez les volumes de blocs.

Déplacement d'une instance Bare Metal via une migration au redémarrage

Une fois que vous avez suivi les prérequis, procédez comme suit :

  1. Arrêtez les applications en cours d'exécution.

  2. Utilisez la console, l'interface de ligne de commande ou le kit SDK pour redémarrer l'instance. La migration au 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 Redémarrer la migration de l'instance vers un hôte en bon état.
    • Utilisation de l'interface de ligne de commande ou du kit SDK : dans l'opération InstanceAction, transmettez la valeur REBOOTMIGRATE en tant qu'action à effectuer. Pour procéder à la migration au redémarrage de l'instance immédiatement, laissez l'attribut timeScheduled vide.
  3. Après la migration, vérifiez que le champ Redémarrage de maintenance ne comporte plus de date.
  4. Démarrez et testez les applications sur l'instance.

Déplacement d'une instance via une migration manuelle

Pour les instances ne possédant pas de date dans le champ Redémarrage de maintenance (disponible dans la console, l'interface de ligne de commande et les kits SDK), vous devez déplacer l'instance manuellement. Cette méthode implique de supprimer l'instance (d'y mettre fin), puis de lancer une nouvelle instance à partir du volume d'initialisation conservé. Les instances qui disposent de cartes d'interface réseau virtuelles supplémentaires, d'adresses IP secondaires, de volumes de blocs attachés distants, pour lesquelles le module de plate-forme sécurisée est activé ou qui appartiennent à un ensemble de back-ends d'un équilibreur de charge nécessitent des étapes supplémentaires.

Limites et avertissements pour la migration manuelle

Tenez compte des limites et des avertissements suivants lorsque vous effectuez une migration manuelle :

  • Toutes les adresses IP publiques affectées à votre instance à partir d'un pool public réservé sont conservées. Toutes celles qui n'ont pas été affectées à partir d'un pool d'adresses IP publiques réservées seront modifiées. Les adresses IP privées ne changent pas.
  • Les adresses MAC, les ID d'UC et d'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 la gestion des licences ou à d'autres fins, notez ces informations avant de déplacer l'instance afin de vous aider à gérer la modification.
  • Les instances protégées présentent des limites supplémentaires. Reportez-vous à Migration d'instances protégées.

Prérequis pour la migration manuelle

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

    • Région, domaine de disponibilité et domaine de pannes de l'instance.
    • Nom d'affichage de l'instance.
    • Tous les sous-réseaux, noms et adresses IP privées. L'instance peut avoir plusieurs cartes d'interface réseau virtuelles, qui peuvent chacune comporter plusieurs adresses IP secondaires.
    • Tous les noms DNS privés. L'instance peut avoir plusieurs cartes d'interface réseau virtuelles, qui peuvent chacune comporter plusieurs adresses IP secondaires. Chaque adresse IP privée peut posséder un nom DNS.
    • Toute adresse IP publique affectée à partir d'un pool public réservé. L'instance peut avoir plusieurs cartes d'interface réseau virtuelles, qui peuvent chacune comporter plusieurs adresses IP privées secondaires. Une adresse IP publique peut être attachée à chaque adresse IP privée secondaire et à chaque carte d'interface réseau virtuelle.
    • Tout volume de blocs attaché à l'instance.
    • Toute balise sur l'instance ou les ressources attachées.

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

    • Assurez-vous que les volumes de blocs définis dans /etc/fstab utilisent les options recommandées.
    • Assurez-vous que les montages de service File Storage (NFS) utilisent l'option nofail.
    • Si vous avez défini statiquement des interfaces réseau appartenant à des cartes d'interface réseau virtuelles secondaires en utilisant leur adresse MAC, telles que celles définies dans /etc/sysconfig/network-scripts/ifcfg*, ces interfaces ne démarreront pas en raison de la modification de l'adresse MAC. Enlevez la correspondance statique.
    • Si vous utilisez le script fourni par Oracle pour configurer des cartes d'interface réseau virtuelles secondaires, assurez-vous qu'il s'exécute automatiquement au démarrage.

Déplacement manuel d'une instance

Une fois que vous avez suivi les prérequis, procédez comme suit :

  1. Arrêtez les applications en cours d'exécution.

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

    Attention

    Lorsque l'instance transférée démarre pour la première fois, les volumes de blocs, les cartes d'interface réseau virtuelles secondaires ou toute ressource qui utilise ces derniers ne sont pas attachés. L'absence de ces ressources peut entraîner des problèmes au niveau de l'application.

  3. Si l'instance utilise une forme à E/S dense, sauvegardez le disque SSD NVMe attaché en local :

    1. Créez des volumes de blocs et attachez-les à l'instance.
    2. Copiez les données des périphériques NVMe vers les volumes de blocs.
  4. Unmount any block volumes or File Storage service (NFS) mounts.
  5. Sauvegardez tous les volumes de blocs.

  6. Créez une sauvegarde du volume d'initialisation.

    Important

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

  7. Mettez fin à l'instance (supprimez-la) en conservant le volume d'initialisation attaché :

    Utilisation de la console

    Suivez les étapes de Terminaison d'une instance en vous assurant que la case Supprimer définitivement le volume d'initialisation attaché est désélectionnée. Vous conservez ainsi le volume d'initialisation associé à l'instance.

    Utilisation de l'API

    Utilisez l'opération TerminateInstance et transmettez le paramètre preserveBootVolume défini sur true dans la demande.

    Utilisation de l'interface de ligne de commande

    Utilisez l'opération de fin d'instance et définissez l'option preserve-boot-volume sur true.

  8. Créez une instance en utilisant le volume d'initialisation de l'instance ayant pris fin.

    Dans le flux de création de l'instance, indiquez l'adresse IP privée qui a été attachée à la carte d'interface réseau virtuelle principale. Si l'adresse IP publique a été affectée à partir d'un pool d'adresses IP réservées, 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 toute carte d'interface réseau virtuelle secondaire et toute adresse IP secondaire.

  11. Attachez des volumes de blocs.

    Remarque

    Cette étape comprend tous les volumes utilisés pour sauvegarder les périphériques NVMe locaux. Copiez les données vers le stockage NVMe de la nouvelle instance, puis détachez les volumes.
  12. Démarrez l'instance.
  13. Démarrez et testez les applications sur l'instance.
  14. Configurez les applications de sorte qu'elles démarrent automatiquement, si nécessaire.
  15. Recréez les balises requises.
  16. (Facultatif) Après avoir vérifié que l'instance et les applications sont en bon état, vous pouvez supprimer les sauvegardes de volume.