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 :
Pour plus d'informations sur le moment où une machine virtuelle doit être migrée, reportez-vous à Maintenance d'infrastructure.
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.
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 afin de 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 Compute 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 bascule vers la nouvelle machine virtuelle.
Lors d'un événement de maintenance d'infrastructure, Oracle Cloud Infrastructure migre en direct les instances de machine virtuelle prises en charge d'un hôte de machine virtuelle physique en bon état 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 :
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é. Utilisez ensuite 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 :
- Ouvrez le menu de navigation et cliquez sur Compute. Sous Compute, cliquez sur Instances.
- Cliquez sur l'instance qui vous intéresse.
- 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.
- (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
Avec la 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/GPU (y compris Flex) : 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émarrer. 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 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. 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.
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.
Vous pouvez prolonger la date d'échéance de la migration au redémarrage. Reportez-vous à Extension de la date limite de maintenance
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 :
- Créez des volumes de blocs et attachez-les à l'instance.
- 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 :
- Arrêtez les applications en cours d'exécution.
-
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
surtrue
.
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. - 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
). - Démarrez et testez les applications sur l'instance.
-
Pour les instances à E/S dense, si vous voulez restaurer le disque SSD NVMe, procédez comme suit :
- Attachez les volumes de blocs utilisés pour sauvegarder les périphériques NVMe locaux.
- Copiez les données vers le stockage NVMe de la nouvelle instance.
- 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 :
- Arrêtez les applications en cours d'exécution.
-
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'attributtimeScheduled
vide.
- 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
). - 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
-
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.
-
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.
- Assurez-vous que les volumes de blocs définis dans
Déplacement manuel d'une instance
Une fois que vous avez suivi les prérequis, procédez comme suit.
- Arrêtez les applications en cours d'exécution.
-
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. -
Si l'instance utilise une forme à E/S dense, sauvegardez le disque SSD NVMe attaché en local :
- Créez des volumes de blocs et attachez-les à l'instance.
- Copiez les données des périphériques NVMe vers les volumes de blocs.
- Démontez tous les volumes de blocs ou les montages de service File Storage Mount.
- Sauvegardez tous les volumes de blocs.
-
Créez une sauvegarde du volume d'initialisation.
Important
Ne généralisez ou ne spécialisez pas les instances Windows. -
Mettez fin à l'instance (supprimez-la) en conservant le volume d'initialisation attaché :
Utilisation de la consoleSuivez 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'APIUtilisez l'opération TerminateInstance et transmettez le paramètre
preserveBootVolume
défini surtrue
dans la demande.Utilisation de l'interface de ligne de commandeUtilisez l'opération de fin d'instance et définissez l'option
preserve-boot-volume
surtrue
. -
Créez une instance en utilisant le volume d'initialisation de l'instance ayant pris fin.
(Facultatif) Si l'instance se trouve sur un nouvel hôte de machine virtuelle dédié :
- Dans la section Placement, cliquez sur Afficher les options avancées.
- Dans Type de capacité, sélectionnez Hôte dédié.
- Sélectionnez l'hôte de machine virtuelle dédié sur lequel placer l'instance.
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.
- Lorsque l'état de l'instance passe à En cours d'exécution, arrêtez l'instance.
- Recréez toute carte d'interface réseau virtuelle secondaire et toute adresse IP secondaire.
-
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. - Démarrez l'instance.
- Démarrez et testez les applications sur l'instance.
- Configurez les applications de sorte qu'elles démarrent automatiquement, si nécessaire.
- Recréez les balises requises.
- (Facultatif) Après avoir vérifié que l'instance et les applications sont en bon état, vous pouvez supprimer les sauvegardes de volume.