Processus de migration à chaud lors d'événements de maintenance

Lors d'un événement de maintenance planifié sur le matériel sous-jacent d'une instance de machine virtuelle (VM), Compute Engine peut déplacer la VM vers un autre hôte. Pour qu'une VM reste en cours d'exécution lors d'un événement hôte, Compute Engine effectue une migration à chaud de la VM vers un autre hôte de la même zone. Pour en savoir plus sur les événements hôtes, consultez la page À propos des événements hôtes.

La migration à chaud permet à Google Cloud d'effectuer une maintenance sans interrompre une charge de travail, redémarrer une VM ni modifier les propriétés de la VM, telles que les adresses IP, les métadonnées, les données du stockage de blocs, l'état de l'application et les paramètres réseau.

En plus de maintenir les VM en cours d'exécution pendant les événements hôtes planifiés, la migration à chaud les maintient en cours d'exécution dans les situations suivantes :

  • Maintenance de l'infrastructure. La maintenance de l'infrastructure comprend le matériel hôte, le réseau informatique et les réseaux électriques dans les centres de données, ainsi que les OS et BIOS de l'hôte.

  • Mises à jour de sécurité et modifications de la configuration système. Cela inclut des événements tels que l'installation de correctifs de sécurité et la modification de la taille de la partition racine de l'hôte pour le stockage des packages et de l'image d'OS de l'hôte.

  • les défaillances matérielles ; Cela inclut les défaillances affectant la mémoire, les processeurs, les cartes d'interface réseau et les disques. Si le matériel tombe en panne ou empêche la migration à chaud, la VM s'arrête et redémarre automatiquement, et Compute Engine enregistre une erreur hostError.

Compute Engine effectue uniquement une migration à chaud des VM pour lesquelles la stratégie de maintenance de l'hôte est définie pour la migration. Pour en savoir plus sur la modification des stratégies de maintenance de l'hôte, consultez la page Définir la stratégie de maintenance de l'hôte d'une VM.

Processus de migration à chaud et disques SSD locaux

Compute Engine peut migrer à chaud des VM auxquelles sont rattachés des disques SSD locaux, en déplaçant les VM et leur disque SSD local vers une nouvelle machine avant toute maintenance planifiée.

Limites

La migration à chaud n'est pas compatible avec les types de VM suivants :

  • Certaines instances Confidential VM. La migration à chaud n'est compatible qu'avec les types de machines N2D dotés de plates-formes de processeur AMD EPYC Milan exécutant AMD SEV. Tous les autres types de Confidential VM doivent être configurés pour s'arrêter et éventuellement redémarrer. Pour plus d'informations, consultez la section Migration à chaud.

  • VM avec GPU associés. Les instances de VM avec des GPU associés doivent être configurées pour s'arrêter et éventuellement redémarrer. Compute Engine envoie une notification 60 minutes avant l'arrêt d'une instance de VM avec un GPU rattaché. Pour en savoir plus sur ces notifications d'événements de maintenance, consultez la section Recevoir les avis de migration à chaud.

    Pour en savoir plus sur la gestion de la maintenance des hôtes avec GPU, consultez la section Gérer la maintenance de l'hôte dans la documentation concernant les GPU.

  • Cloud TPU. Les processeurs Cloud TPU ne sont pas compatibles avec la migration à chaud.

  • VM préemptives. Vous ne pouvez pas configurer la migration à chaud sur une VM préemptive. Le comportement de maintenance des instances préemptives est toujours défini sur TERMINATE par défaut et cette option n'est pas modifiable. Vous ne pouvez pas définir l'option de redémarrage automatique pour les instances préemptives. Vous pouvez toutefois redémarrer manuellement des VM préemptives à partir de la page Détails de l'instances de VM une fois préemptées.

    Si vous devez modifier votre instance pour la rendre non préemptive, dissociez le disque de démarrage de votre instance préemptive et associez-le à une nouvelle instance qui n'est pas configurée pour être préemptive. Vous pouvez également créer un instantané du disque de démarrage et l'utiliser pour créer une nouvelle instance sans préemption.

  • VM Spot Les VM Spot ne peuvent pas utiliser la migration à chaud pour devenir des VM standards pendant leur exécution, ni être configurées pour redémarrer automatiquement en cas d'événement hôte.

  • VM optimisées pour le stockage. Les VM Z3 ne sont pas compatibles avec la migration à chaud. Le comportement de maintenance des VM Z3 est défini sur TERMINATE.

Fonctionnement du processus de migration à chaud

Lorsque la migration à chaud d'une VM est planifiée, Google Cloud envoie une notification. Lors de la migration à chaud, Google Cloud garantit une durée d'interruption minimale, généralement inférieure à une seconde. Si la migration à chaud n'est pas configurée, Compute Engine arrête la VM pendant la maintenance de l'hôte. Les VM configurées pour s'arrêter lors d'un événement hôte s'arrêtent et (éventuellement) redémarrent.

Lorsque Google Cloud migre une VM en cours d'exécution d'un hôte à un autre, l'état complet de la VM est transféré de la source vers la destination de manière transparente pour l'OS invité et les ressources qui communiquent avec elle. Pour que cela fonctionne avec une parfaite fluidité, de nombreux composants entrent en jeu. L'illustration suivante présente les étapes majeures :

Migrer une VM et chacune de ses ressources vers un nouveau système hôte sans nécessiter le redémarrage du système d'exploitation invité
Composants de la migration à chaud

Le processus commence par une notification indiquant que les VM doivent être déplacées de leur machine hôte actuelle. La notification peut commencer par une modification de fichier indiquant une nouvelle version disponible du BIOS, une opération de maintenance matérielle programmée ou un signal automatique suite à une défaillance matérielle imminente.

Le logiciel de gestion des clusters de Google Cloud surveille en permanence ces événements et les planifie en fonction des règles qui contrôlent les centres de données, telles que les taux d'utilisation des capacités et le nombre de VM qu'un seul client peut migrer simultanément.

Une fois la VM sélectionnée pour la migration, Google Cloud envoie une notification à l'invité indiquant qu'une migration va bientôt avoir lieu. Après un délai d'attente, un hôte cible est sélectionné et est invité à configurer une nouvelle VM vierge "cible" "pour recevoir la VM "source" à migrer. L'authentification est utilisée pour établir une connexion entre la source et la cible.

La migration de la VM se déroule en trois étapes :

  1. Brownout source. La VM s'exécute toujours sur la source, tandis que la plupart des états sont envoyés de la source à la cible. Par exemple, Google Cloud copie toute la mémoire de l'invité sur la cible, tout en effectuant le suivi des pages modifiées sur la source. Le temps passé en brownout source est fonction de la taille de la mémoire de l'invité et du taux de modification des pages.

  2. Arrêt complet. Pendant ce moment très bref d'absence totale d'exécution, la VM est interrompue et tous les états restants nécessaires pour commencer l'exécution sur la cible sont envoyés. La VM entre dans la phase d'arrêt complet lorsque l'état d'envoi pendant la phase de brownout source atteint un point de rendement décroissant. L'utilisation d'un algorithme permet d'équilibrer le nombre d'octets de mémoire envoyés par rapport au taux auquel la VM invitée effectue les modifications.

    Lors des événements d'arrêt complet, l'horloge système semble avancer d'un maximum de cinq secondes. Si un événement d'arrêt complet dépasse cinq secondes, Google Cloud arrête et resynchronise l'horloge à l'aide d'un daemon inclus dans les packages invités de la VM.

  3. Brownout cible. La VM s'exécute sur la VM cible. La VM source est présente et peut fournir des fonctionnalités compatibles avec la VM cible. Par exemple, jusqu'à ce que le tissu réseau soit mis à jour avec le nouvel emplacement de la VM cible, la VM source fournit des services de transfert de paquets vers et depuis la VM cible.

Enfin, la migration est terminée et le système supprime la VM source. Vous pouvez constater que la migration a eu lieu dans vos journaux de VM.

Processus manuel de migration à chaud

Lorsque votre charge de travail s'exécute, vous pouvez déplacer les VM vers un nœud ou un groupe de nœuds différent. La location unique vous permet de déplacer des VM vers un nœud à locataire unique spécifique ou vers un groupe de nœuds. Si vous déplacez une VM vers un groupe de nœuds, Compute Engine détermine le nœud sur lequel la placer. Pour en savoir plus sur la location unique, consultez la page Présentation de la location unique.

Pour déplacer des VM à locataire unique vers un autre nœud ou groupe de nœuds, vous pouvez lancer manuellement une migration à chaud. Vous pouvez également lancer manuellement une migration à chaud pour déplacer une VM mutualisée vers une location unique. Pour en savoir plus, consultez la page Migrer à chaud des VM manuellement.

Étape suivante