À propos des événements hôtes

Au cours de la durée de vie d'une instance de machine virtuelle (VM) ou d'une instance Bare Metal, la machine hôte sur laquelle votre instance s'exécute peut être affectée par plusieurs événements hôtes. Un événement hôte peut inclure la maintenance régulière de l'infrastructure Compute Engine ou, dans de rares cas, une erreur d'hôte. Vous pouvez choisir la manière dont vos instances de VM et bare metal répondent pendant ou après un événement hôte en configurant la stratégie de maintenance de l'hôte.

Par défaut, la plupart des instances sont configurées pour la migration à chaud lors des événements hôtes. Pour toutes les séries de machines, à l'exception de la série Z3, vous pouvez remplacer ce comportement et définir explicitement les instances pour qu'elles s'arrêtent et, éventuellement, redémarrent. Certains types de machines ne sont pas compatibles avec la migration à chaud, comme les instances bare metal, les instances avec GPU associés ou les instances Z3 avec plus de 18 Tio de SSD Titanium associés. Ces instances sont arrêtées lors d'événements hôtes. Pour en savoir plus, consultez Comportements de maintenance et de redémarrage.

Types d'événements hôtes

Il existe deux types d'événements hôtes, décrits plus en détail dans les sections suivantes :

Si votre instance ne répond plus, cela peut également déclencher un redémarrage ou un arrêt de l'instance.

Événements de maintenance

Un événement de maintenance se produit lorsque Compute Engine doit effectuer une opération de maintenance ou de réparation qui nécessite le déplacement des VM hors du serveur hôte. Si vous activez la stratégie de maintenance de l'hôte de migration à chaud pour un type d'instance compatible, Compute Engine déplace l'instance vers un nouvel hôte, sans aucune interruption de votre application.

Compute Engine applique également certains hyperviseurs légers et mises à niveau réseau en arrière-plan sans interruption en conservant l'instance sur le même hôte.

Le comportement d'une instance lors d'un événement de maintenance peut varier en fonction de la location de l'instance et du type de machine. Vous trouverez des informations sur le comportement de maintenance de chaque type de machine sur la page de la famille de machines correspondante :

Pour en savoir plus sur les règles de maintenance des instances avec GPU associés, consultez Gérer les événements de maintenance de l'hôte GPU.

Pour les VM à locataire unique, la fréquence approximative des événements de maintenance planifiée de l'hôte est de quatre à six semaines. La compatibilité avec la migration à chaud dépend de la stratégie de maintenance de l'hôte de la VM à locataire unique.

Erreurs de l'hôte

Une erreur d'hôte (compute.instances.hostError) signifie qu'un problème matériel ou logiciel s'est produit sur la machine physique ou l'infrastructure du centre de données hébergeant votre instance de calcul, ce qui a entraîné le plantage de votre instance. Une erreur d'hôte impliquant une défaillance matérielle totale ou d'autres problèmes matériels peut empêcher la migration à chaud de votre instance. Si votre instance est configurée pour redémarrer automatiquement, ce qui est le paramètre par défaut, Compute Engine la redémarre, généralement dans les trois minutes suivant la détection de l'erreur. Selon le problème, le redémarrage peut prendre jusqu'à 5,5 minutes.

Il peut arriver qu'une instance de calcul ne réponde plus avant qu'une erreur d'hôte ne soit signalée. Vous pouvez réduire le temps d'attente de Compute Engine avant le redémarrage ou l'arrêt de l'instance en définissant le délai avant expiration de récupération d'erreur de l'hôte. Pour en savoir plus, consultez Définir des règles de disponibilité.

Des pannes matérielles et logicielles peuvent se produire occasionnellement, mais sont rares. Pour protéger vos applications et vos services des événements système potentiellement perturbateurs, consultez les ressources suivantes :

Présentation de la stratégie de maintenance de l'hôte

La stratégie de maintenance de l'hôte d'une instance détermine son comportement lors des événements d'hôte suivants :

  • Événement de maintenance
  • Événement d'erreur de l'hôte ou instance ne répondant pas

Vous pouvez configurer les instances pour qu'elles continuent à fonctionner pendant la maintenance de l'hôte, tandis que Compute Engine les migre à chaud vers un autre hôte. Vous pouvez également choisir de les arrêter.

Vous pouvez modifier la stratégie de maintenance de l'hôte d'une instance en configurant les paramètres suivants :

  • Comportement de maintenance : indique si l'instance est migrée à chaud ou arrêtée lors d'un événement de maintenance.
  • Comportement de redémarrage : indique si Compute Engine redémarre ou arrête l'instance si elle se bloque, rencontre une erreur d'hôte ou ne répond plus.
  • Temps de détection des erreurs d'hôte : durée maximale pendant laquelle Compute Engine attend avant de redémarrer ou d'arrêter une instance après avoir détecté qu'elle ne répondait pas.

Vous pouvez modifier la stratégie de maintenance de l'hôte d'une instance à tout moment pour contrôler le comportement de vos instances.

Comportements de maintenance et de redémarrage

Lorsqu'un événement hôte se produit, l'instance de calcul peut utiliser la migration à chaud ou être arrêtée. Si une instance est arrêtée, vous pouvez choisir de la redémarrer vous-même ou de laisser Compute Engine la redémarrer automatiquement.

Les séries de machines suivantes ne sont peut-être pas compatibles avec la migration à chaud et nécessitent plutôt un arrêt lors d'événements hôtes :

Migration à chaud

Par défaut, la plupart des types d'instances sont configurés pour la migration à chaud, à l'exception de ceux mentionnés dans la section précédente.

Lors d'une migration à chaud, Compute Engine migre automatiquement votre instance hors d'un événement de maintenance de l'infrastructure, mais celle-ci reste en cours d'exécution pendant la migration. Il est possible que l'instance connaisse une courte période de baisse des performances. Cependant, aucune différence n'est généralement constatée pour la plupart des instances. Ceci est idéal pour les instances qui nécessitent une activité constante et peuvent tolérer une courte période de performances réduites.

Lorsque Compute Engine migre l'instance, il signale un événement système qui est publié dans la liste des opérations de la zone et dans les journaux des événements système. Vous pouvez consulter cet événement en affichant les opérations Compute Engine concernant une zone spécifique. Les événements de migration à chaud sont associés au type d'opération suivant :

compute.instances.migrateOnHostMaintenance

Arrêter et redémarrer

Si vous ne souhaitez pas que votre instance migre à chaud ou si votre type d'instance n'est pas compatible avec la migration à chaud, vous pouvez choisir d'autoriserTrusted Cloud by S3NS à arrêter l'instance lorsqu'un événement d'hôte se produit. Avec cette configuration, si un événement hôte se produit, Compute Engine envoie un signal d'arrêt progressif pour arrêter l'instance. Il attend ensuite 60 secondes que l'instance s'arrête correctement et définit l'état de l'instance sur TERMINATED. Si l'instance ne s'arrête pas correctement en 60 secondes, elle est arrêtée de force.

Cette option est idéale si vos instances exigent des performances constantes et maximales, et si l'ensemble de votre application est conçu pour gérer les défaillances ou les redémarrages des instances.

Lorsque Compute Engine arrête une instance en raison d'un événement hôte, il signale un événement système qui est publié dans la liste des opérations de la zone et dans les journaux des événements système. Vous pouvez consulter cet événement en affichant les opérations Compute Engine concernant une zone spécifique. Les événements d'arrêt d'instance sont associés au type d'opération suivant :

compute.instances.terminateOnHostMaintenance

Redémarrage automatique

Si votre instance est configurée pour s'arrêter en cas d'événement de maintenance ou si elle plante en raison d'un problème matériel sous-jacent, Compute Engine peut la redémarrer automatiquement. L'instance est redémarrée sur le même serveur hôte ou déplacée vers un autre serveur de la même zone qui ne participe pas à l'événement de maintenance.

Par défaut, Compute Engine tente de récupérer les instances avec des disques SSD locaux associés pendant une heure. Si la limite de temps est atteinte, Compute Engine tente de redémarrer l'instance sur un autre serveur hôte de la même zone.

Pour configurer le redémarrage automatique, définissez le champ de règle de maintenance de l'hôte automaticRestart sur true. Ce paramètre ne s'applique pas si l'instance est mise hors ligne en raison d'une indisponibilité de zone ou d'une opération manuelle, telle que l'appel de sudo shutdown dans l'OS invité.

Lorsque Compute Engine redémarre automatiquement une instance, il signale un événement système qui est publié dans la liste des opérations de la zone. Vous pouvez consulter cet événement en affichant les opérations Compute Engine concernant une zone spécifique. Les événements de redémarrage automatique sont associés au type d'opération suivant :

compute.instances.automaticRestart

Persistance du disque après l'arrêt de l'instance

Étant donné que Hyperdisk sont des stockages associés au réseau, lorsque votre instance redémarre, Compute Engine réassocie le disque de démarrage et tous les disques secondaires à l'instance. Les données sur ces disques persistent lors de la migration à chaud et des redémarrages d'instances.

Planification de la maintenance

Trusted Cloud by S3NS propose des fonctionnalités permettant un contrôle plus strict de la maintenance. En utilisant certaines familles de machines, vous pouvez spécifier des préférences de maintenance et recevoir des notifications concernant les événements de maintenance à venir via Cloud Logging, le serveur de métadonnées de l'instance, la commande compute instances describe de gcloud CLI ou la méthode instances.describe de REST. Dès réception d'une notification, vous disposez d'un certain temps pour démarrer la maintenance planifiée à l'heure de votre choix. Si vous ne déclenchez pas la maintenance planifiée, l'événement de maintenance se produit à la fin de la période de notification, c'est-à-dire à l'heure planifiée indiquée dans la notification.

Vous pouvez utiliser ces fonctionnalités conjointement avec votre stratégie de maintenance de l'hôte pour personnaliser la planification de la maintenance afin qu'elle soit adaptée à votre charge de travail.

Étapes suivantes