Migration à chaud

Compute Engine propose une migration à chaud pour que vos instances de machine virtuelle continuent de s'exécuter même lorsqu'un événement, tel qu'une mise à jour logicielle ou matérielle, se produit sur le système hôte. Compute Engine migre à chaud vos instances en cours d'exécution vers un autre hôte situé dans la même zone, au lieu de nécessiter un redémarrage de vos VM. Cela permet à Google d'effectuer une maintenance essentielle à la protection et à la fiabilité de l'infrastructure sans interrompre vos VM.

Grâce à la migration à chaud, vos instances continuent de s'exécuter pendant les opérations suivantes :

  • Maintenance et mises à niveau régulières de l'infrastructure.
  • Maintenance du réseau informatique et du réseau électrique dans les centres de données.
  • Défaillances matérielles affectant la mémoire, le processeur, les cartes d'interface réseau, les disques, l'alimentation, etc. L'opération s'effectue de la façon la plus optimale possible. Si un matériel tombe en panne ou empêche la migration à chaud, la VM se bloque et redémarre automatiquement, et une erreur hostError est enregistrée.
  • Mises à niveau du système d'exploitation hôte et du BIOS.
  • Mises à jour de sécurité, qui exigent de réagir rapidement.
  • Modifications de la configuration système, y compris modification de la taille de la partition racine de l'hôte, pour le stockage des packages et images hôtes.

La migration à chaud ne modifie aucun attribut ni aucune propriété de la VM elle-même. Le processus de migration à chaud transfère simplement une VM en cours d'exécution d'une machine hôte vers une autre machine hôte au sein de la même zone. Toutes les propriétés et tous les attributs de la VM restent inchangés, y compris les adresses IP internes et externes, les métadonnées d'instance, les données et volumes de stockage de blocs, l'état du système d'exploitation et des applications, les paramètres et connexions réseau, etc.

Fonctionnement du processus de migration à chaud

Lorsque Google procède à la migration d'une instance de VM en cours d'exécution d'un hôte à un autre, l'état complet de l'instance est transféré de la source vers la destination de manière transparente pour le système d'exploitation invité et les personnes qui communiquent avec elle. Pour que cela fonctionne avec une parfaite fluidité, de nombreux composants entrent en jeu, comme le montre le schéma des étapes de haut niveau ci-dessous :

Composants de la migration à chaud

Le processus commence par une notification indiquant que les VM doivent être supprimées de leur machine hôte actuelle. La notification commence 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 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 envoie une notification à l'invité indiquant qu'une migration est imminente. 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 :

  • Pendant la phase de brownout pré-migration, 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 copie toute la mémoire de l'invité sur la cible, tout en effectuant le suivi des pages modifiées sur la source. La durée de la phase de brownout pré-migration est fonction de la taille de la mémoire de l'invité et du taux de modification des pages.

  • Pendant l'arrêt complet, qui est un 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 pré-migration atteint un point de retours décroissants. 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.

  • Pendant la phase de brownout post-migration, la VM s'exécute sur la VM cible. La VM source est présente et peut fournir des fonctionnalités d'assistance pour la VM cible. Par exemple, jusqu'à ce que la structure réseau ait rejoint le nouvel emplacement de la VM cible, la VM source fournit des services de transfert pour les paquets en provenance et à destination de 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. La migration à chaud est un composant essentiel de notre plate-forme. Ainsi, Google teste en permanence la migration à chaud avec un niveau de contrôle très élevé. Pendant les tests, nous utilisons l'injection de pannes pour déclencher des défaillances à tous les points d'intérêt de l'algorithme de migration. Nous générons des défaillances actives et passives pour chaque composant. La réalisation de ce processus complexe et multiforme nécessite une intégration poussée dans toute l'infrastructure, ainsi qu'un ensemble puissant de processus de planification, d'orchestration et d'automatisation.

Migration à chaud et GPU

Les instances avec des GPU rattachés ne peuvent pas être migrées à chaud. Elles 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 relative aux GPU.

Migration à chaud et SSD locaux

Compute Engine peut également migrer des instances avec des disques SSD locaux rattachés. Avant une maintenance programmée, les VM avec leur disque SSD local sont alors transférées sur une nouvelle machine.

Migration à chaud des instances préemptives

Vous ne pouvez pas configurer la migration à chaud sur des instances préemptives. Le comportement de maintenance des instances préemptives est toujours défini sur TERMINATE par défaut et cette option n'est pas modifiable. Il n'est pas possible de définir l'option redémarrage automatique pour les instances préemptives. Vous pouvez toutefois les redémarrer manuellement après leur préemption.

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.

Étapes suivantes

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Documentation Compute Engine