À 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 subir 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 hôte. Vous pouvez choisir la manière dont vos instances de VM et de 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. Vous pouvez ignorer 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 en direct, comme les instances bare metal ou les VM avec des GPU connectés. Ces instances s'arrêtent lors des événements hôte. Pour en savoir plus, consultez la section Comportements de maintenance et de redémarrage.

Types d'événements hôtes

Il existe deux types d'événements hôte, 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 une interruption de l'instance.

Événements de maintenance

Un événement de maintenance se produit lorsque Compute Engine doit effectuer une activité de maintenance ou de réparation nécessitant 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, avec une interruption minimale de votre application.

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. Le tableau suivant récapitule le comportement des événements de maintenance planifiée.

Location de l'hôte Fréquence approximative des événements de maintenance
 Migration à chaud compatible Sélection de l'hôte
Multi-tenant (partagé) Toutes les deux semaines Oui Compute Engine
Locataire unique Toutes les 4 à 6 semaines Dépend de la stratégie de maintenance de l'hôte Dépend de la stratégie de maintenance de l'hôte
X4 90 jours minimum Non Compute Engine
C3 30 jours minimum Non Compute Engine

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.

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 (bêta). Pour en savoir plus, consultez la section 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 :

Google propose également des services gérés tels que App Engine et l'environnement flexible App Engine.

Présentation des stratégies 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 hôtes 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 plante, 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.
  • Temps de récupération SSD local:temps maximal que Compute Engine passe à récupérer des données sur les disques SSD locaux après avoir détecté une erreur d'hôte. Les données du SSD local sont perdues si le temps spécifié s'écoule sans une récupération réussie.

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

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 demander à Compute Engine de la redémarrer automatiquement.

Les séries de machines suivantes ne sont pas compatibles avec la migration à chaud et s'arrêtent lors des événements hôtes:

Migration à chaud

Par défaut, la plupart des types d'instances sont configurés pour la migration à chaud, à l'exception des suivants:

  • Instances avec GPU et TPU rattachés
  • Instances bare metal C3 ou X4
  • Instances Z3

Lors de la 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 votre instance connaisse une courte période de baisse de 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 votre 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'autoriser Google Cloud à arrêter l'instance lorsqu'un événement hôte se produit. Avec cette configuration, si un événement hôte se produit, Compute Engine envoie un signal d'arrêt automatique pour arrêter l'instance. Il attend ensuite 60 secondes que l'instance s'arrête correctement, puis définit son état 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 d'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 de manière à s'arrêter en cas d'événement de maintenance ou de plantage lié à 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 associées à des disques SSD locaux 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. Les temps d'attente par défaut des instances Z3 et X4 sont différents. Ces types d'instances redémarrent sur le même serveur hôte après l'arrêt de l'instance.

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é zonale ou par une action utilisateur, 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 Persistent Disk etHyperdisk sont des systèmes de stockage connectés au réseau, lorsque votre instance redémarre, Compute Engine réassocie le disque de démarrage et les éventuels disques secondaires à l'instance. Les données sur ces disques persistent lors de la migration à chaud et des redémarrages d'instances.

Compute Engine conserve les données sur les disques SSD locaux à la suite d'un événement hôte dans la mesure du possible. Toutefois, Compute Engine ne garantit pas la persistance des données des disques SSD locaux.

  • Les disques SSD locaux sont conservés si:

    • Vous configurez votre instance pour la migration à chaud, et un événement de maintenance de l'hôte survient.
    • Une erreur d'hôte se produit et Compute Engine reconnecte l'instance aux disques SSD locaux dans le délai avant expiration.
    • Une instance de calcul avec des disques SSD locaux associés qui n'accepte que l'arrêt et le redémarrage automatique fait l'objet d'un événement de maintenance. L'instance redémarre sur place, en conservant les données du SSD local, au lieu de migrer vers un nouvel hôte.

  • Les disques SSD locaux ne sont pas conservés si:

    • Vous arrêtez le système d'exploitation invité et forcez l'arrêt de l'instance.
    • Vous configurez l'instance pour qu'elle s'arrête en cas d'événements de maintenance de l'hôte, et ce type d'événement survient.
    • Une erreur d'hôte se produit et Compute Engine ne peut pas reconnecter les disques à l'instance avant l'expiration du délai. Dans ce cas, l'instance est redémarrée sans récupérer les disques SSD locaux. Lorsque l'instance redémarre, Compute Engine lui associe des disques SSD locaux vides. Vous devez formater et installer ces disques pour que l'instance puisse les utiliser. Les données des disques SSD locaux d'origine sont irrécupérables.

Google Cloud fait tout son possible pour garantir la conservation des données de vos disques SSD locaux. Cependant, dans certains cas, les données ne peuvent pas être récupérées, par exemple en cas d'expiration du délai. Pour en savoir plus sur les cas de conservation des disques SSD locaux, consultez la section Persistance des données des disques SSD locaux.

Délai avant expiration de la récupération de SSD local

Lorsqu'une erreur d'hôte se produit, Compute Engine tente de récupérer tous les disques SSD locaux associés à l'instance. Vous pouvez contrôler le temps que Compute Engine passe à récupérer les données avec le paramètre localSsdRecoveryTimeout de la stratégie d'hôte.

Par défaut, Compute Engine passe une heure à récupérer les données, mais les valeurs valides pour ce paramètre sont comprises entre 0 et 168, par incréments d'une heure. Pour les instances Z3, la valeur par défaut est 6, ce qui signifie que les instances Z3 tentent de récupérer les données du SSD local pendant six heures avant d'atteindre la limite de délai avant expiration.

Si vous définissez le délai avant expiration de la récupération du SSD local sur 0, Compute Engine ne tente pas de récupérer les disques SSD locaux associés. L'instance est redémarrée dès que possible, et les données du disque SSD local sont irrécupérables. Utilisez cette configuration si la reprise de la charge de travail est plus importante que la récupération des données du disque SSD local.

Si le délai avant expiration de la récupération n'est pas défini sur 0, mais que la limite de temps est atteinte avant que les données du disque SSD local ne soient récupérées, Compute Engine redémarre l'instance sans le disque SSD local. Compute Engine associe de nouveaux disques SSD locaux vides à l'instance redémarrée. Vous devez formater et installer ces disques avant que l'instance puisse les utiliser.

L'instance est à l'état REPAIRING pendant que Compute Engine tente de récupérer les disques SSD locaux. L'instance et les disques SSD locaux ne sont pas disponibles pendant cette période.

Si vous définissez le délai avant expiration de la récupération des disques SSD locaux sur la valeur maximale de 168, l'instance reste à l'état REPAIRING pendant un maximum de sept jours, pendant que Compute Engine tente de récupérer les disques SSD locaux.

Arrêter la récupération du disque SSD local

Vous pouvez interrompre le processus de récupération du disque SSD local avant que Compute Engine n'atteigne la limite de délai de récupération. Pour ce faire, exécutez la commande gcloud compute instances stop avec l'option --discard-local-ssd=True.

Cette commande arrête le processus de récupération, arrête l'instance de calcul et supprime les données du disque SSD local. Vous pouvez ensuite redémarrer l'instance. Pour en savoir plus, consultez la section Arrêter une instance avec un SSD local.

Pour définir le délai avant expiration de récupération de SSD local, consultez la section Définir la stratégie de maintenance de l'hôte d'une instance.

Planification des maintenances

Google Cloud 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 d'événements de maintenance à venir via Cloud Logging, le serveur de métadonnées de l'instance, la commande compute instances describe de la gcloud CLI ou la méthode REST instances.describe. Dès réception d'une notification, vous disposez d'un délai pendant lequel vous pouvez 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, qui correspond à 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 afin qu'elle soit adaptée à votre charge de travail.

Étape suivante