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

Lors d'un événement de maintenance planifié pour le matériel sous-jacent d'une instance de machine virtuelle (VM) ou d'une instance bare metal, le serveur hôte n'est pas disponible. Pour qu'une instance reste en cours d'exécution lors d'un événement hôte, Compute Engine effectue une migration à chaud de l'instance vers un autre serveur 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 instance ni modifier les propriétés de l'instance, telles que les adresses IP, les métadonnées, les données de stockage de blocs, l'état de l'application ou les paramètres réseau.

La migration à chaud permet de maintenir les instances 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 le système d'exploitation (OS) et le 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 la défaillance est détectée avant qu'elle ne se produise complètement sur le serveur, Compute Engine effectue une migration préventive en direct de l'instance vers un nouveau serveur hôte. Si le matériel tombe en panne ou empêche la migration à chaud, l'instance s'arrête et redémarre automatiquement.

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 instances auxquelles sont rattachés des disques SSD locaux (à l'exception des instances Z3). Compute Engine déplace les instances de VM ainsi que leurs données de 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 :

  • Instances Bare Metal Les instances bare metal C3 et X4 ne sont pas compatibles avec la migration à chaud. Le comportement de maintenance de ces instances est défini sur TERMINATE et RESTART, respectivement.
  • La plupart des instances Confidential VM La migration à chaud des instances Confidential VM n'est compatible qu'avec les types de machines N2D dotés de plates-formes de processeur AMD EPYC Milan exécutant AMD SEV. Toutes les autres instances Confidential VM ne sont pas compatibles avec la migration à chaud et doivent être configurées pour s'arrêter et éventuellement redémarrer lors d'un événement de maintenance de l'hôte. Pour en savoir plus, 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 sur les GPU.

  • Cloud TPU. Les Cloud TPU ne sont pas compatibles avec la migration à chaud.
  • 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, Compute Engine envoie une notification pour que vous puissiez préparer vos charges de travail et vos applications à cette interruption de migration à chaud. 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 qu'une VM doit être déplacée de sa 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 source 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 les modifications de l'état d'envoi pendant la phase de brownout source atteignent 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 synchronise 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 prendre en charge 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 les journaux Cloud Logging de votre VM.

Migration à chaud des VM à locataire unique

Lorsque votre charge de travail s'exécute, vous pouvez déplacer les VM vers un autre nœud ou groupe de nœuds à locataire unique. 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 sur un hôte multi-tenant vers un nœud à locataire unique. Pour en savoir plus, consultez la page Migrer à chaud des VM manuellement.

Étape suivante