À 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. 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 à chaud, comme les instances Z3 avec plus de 18 Tio de SSD Titanium associés, les instances bare metal ou les instances avec des GPU associés. Ces instances s'arrêtent lors des événements hôte. 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 applicables à des séries de machines spécifiques, consultez la comparaison des séries de machines.

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 :

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

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.
  • Temps de récupération SSD local : temps maximal que Compute Engine passe à récupérer les données sur les disques SSD locaux après avoir détecté une erreur d'hôte. Les données des disques SSD locaux 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 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'autoriserGoogle Cloud à 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. Les instances Z3 et X4 ont des temps d'attente par défaut 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é 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 Persistent Disk etHyperdisk 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.

Compute Engine conserve les données sur les disques SSD locaux après un événement d'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 dans les cas suivants :

    • 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 les limites du délai d'expiration.
    • Une instance de calcul avec des disques SSD locaux associés qui ne prend en charge que l'arrêt et le redémarrage automatique fait l'objet d'un événement de maintenance. L'instance redémarre sur place, ce qui préserve les données du SSD local, au lieu de migrer vers un nouvel hôte.

  • Les disques SSD locaux ne sont pas conservés dans les cas suivants :

    • 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ération des disques SSD locaux. Lorsque l'instance redémarre, Compute Engine associe des disques SSD locaux vides à l'instance redémarrée. Vous devez formater et installer ces disques avant 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 conserver intactes les 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 la conservation des disques SSD locaux, consultez 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 à essayer de récupérer les données avec le paramètre localSsdRecoveryTimeout de la stratégie de l'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 de 6, ce qui signifie que les instances Z3 essaieront de récupérer les données du SSD local pendant six heures avant d'atteindre la limite de délai.

Si vous définissez le délai avant expiration de récupération des SSD locaux 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 la récupération des données du disque SSD local, 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 de récupération des disques SSD locaux sur la valeur maximale de 168, l'instance reste à l'état REPAIRING pendant sept jours maximum, tandis 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 du 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 Arrêter une instance avec un SSD local.

Cette option n'est pas disponible avec les instances Z3.

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

Planification de la maintenance

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 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