À propos des événements hôtes

Vous pouvez choisir la manière dont vos instances de machines virtuelles (VM) répondent pendant ou après un événement hôte en définissant la stratégie de maintenance de l'hôte lors de leur création. Un évènement hôte peut inclure une maintenance régulière de l'infrastructure Compute Engine ou une erreur hôte sur une VM. Par défaut, les VM sont configurées pour migrer à chaud lors des événements du système hôte, mais vous pouvez les configurer pour qu'elles s'arrêtent et éventuellement redémarrent. Les VM Z3 font exception à la migration à chaud, car elles redémarrent sur place par défaut.

Les événements hôtes suivants entraînent la migration à chaud ou l'arrêt de votre VM en fonction de la stratégie de maintenance de l'hôte que vous avez définie :

Événements de maintenance

Un événement de maintenance se produit lorsque Compute Engine arrête une VM pour effectuer une mise à jour matérielle ou logicielle. Si vous activez la stratégie de maintenance de l'hôte de migration à chaud, Compute Engine déplace la VM vers un nouvel hôte, sans aucune interruption de votre application.

Le comportement d'une VM lors d'un événement de maintenance peut varier en fonction de la location de la VM. Le tableau suivant montre certaines différences entre le comportement des VM mutualisées et des VM à locataire unique lors d'événements de maintenance.

Location de l'hôte Fréquence approximative* Migration à chaud vers un nouvel hôte Sélection de l'hôte
Mutualisé 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
* Ces fréquences sont approximatives. Compute Engine peut occasionnellement effectuer des opérations de maintenance plus fréquentes.

Compute Engine applique également certains hyperviseurs légers et mises à niveau réseau en arrière-plan sans interruption.

Stratégie de maintenance de l'hôte

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

  • En cas d'événement de maintenance nécessitant que Google déplace une VM vers une autre machine hôte
  • En cas d'erreur d'hôte amenant Google à arrêter ou à redémarrerà une VM

Vous pouvez configurer les VM 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 VM à tout moment pour contrôler son comportement.

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

  • Comportement de maintenance : indique si la VM 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 la VM si elle se bloque ou rencontre une erreur d'hôte.
  • 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 VM 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 des disques SSD locaux sont perdues si le temps spécifié s'écoule sans une récupération réussie.

Planification des maintenances

Google Cloud propose des fonctionnalités permettant un contrôle plus strict de la maintenance. En utilisant certaines familles de VM, vous pouvez spécifier des préférences de maintenance pour recevoir des notifications sur plusieurs jours via Cloud Logging. Dès réception d'une notification, vous pouvez déclencher la maintenance à tout moment jusqu'à l'événement planifié.

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.

Migration à chaud

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

Lorsque Compute Engine migre votre VM, 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 migration à chaud sont associés au type d'opération suivant :

    compute.instances.migrateOnHostMaintenance

Arrêter et (éventuellement) redémarrer

Si vous ne souhaitez pas que votre VM migre à chaud, vous pouvez choisir de l'arrêter et éventuellement de la redémarrer. Pour les VM configurées pour s'arrêter et éventuellement redémarrer, Compute Engine envoie un signal d'arrêt automatique pour arrêter la VM. Ensuite, il attend 60 secondes que la VM s'arrête correctement, arrête la VM et la redémarre hors de l'événement de maintenance. Si la VM ne s'arrête pas correctement en 60 secondes, elle est arrêtée.

Cette option est idéale si vos VM 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 VM.

Lorsque Compute Engine arrête et redémarre des VM, 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 d'arrêt sont associés au type d'opération suivant :

compute.instances.terminateOnHostMaintenance

Lorsque la VM redémarre, elle utilise le même disque de démarrage persistant et rattache tous les disques persistants secondaires que vous avez configurés. Les données sur ces disques persistent lors de la migration et du redémarrage de la VM.

Les données SSD locales ne persistent pas lorsqu'une VM est arrêtée en raison d'un événement de maintenance. Lorsque la VM redémarre, elle crée un nouveau disque SSD local que vous devez formater et installer.

Les données des disques SSD locaux sont conservées sur les VM Z3 optimisées pour le stockage (preview). En cas d'événement de maintenance, la VM Z3 redémarre sur place au lieu de migrer vers un nouvel hôte. À la fin de la maintenance de routine, votre VM est redémarrée. 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.

Redémarrage automatique

Si la VM 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, vous pouvez configurer Compute Engine pour qu'il la redémarre automatiquement en définissant le champ automaticRestart sur true. Ce paramètre ne s'applique pas si la VM est mise hors ligne par une action utilisateur, telle que l'utilisation de la commande sudo shutdown, ou pendant une indisponibilité de zone.

Lorsque Compute Engine redémarre automatiquement une VM, 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

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 hébergeant votre VM, ce qui a entraîné le plantage de votre VM. Une erreur d'hôte qui implique une défaillance matérielle totale ou d'autres problèmes matériels peut empêcher la migration à chaud de votre VM. Si votre VM est configurée pour redémarrer automatiquement, ce qui est le paramètre par défaut, Google 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.

VM dotées de disques SSD locaux

Si une erreur d'hôte se produit sur une VM associée à un ou plusieurs disques SSD locaux, Compute Engine tente de se reconnecter à la VM et de préserver les données du disque SSD local. Lors de la restauration de votre VM et de votre disque SSD local par Compute Engine, le système hôte et le disque sous-jacent ne répondent pas.

Vous pouvez spécifier le temps que Compute Engine passe à récupérer des données de disques SSD locaux en définissant le délai de récupération des disques SSD locaux.

Pour en savoir plus sur le comportement des disques SSD locaux lorsqu'une erreur d'hôte se produit, consultez la section Persistance des données des disques SSD locaux.

VM qui ne répondent pas

Il peut arriver qu'une VM ne réponde plus avant qu'une erreur d'hôte ne soit détectée. Vous pouvez réduire le temps d'attente de Compute Engine avant le redémarrage ou l'arrêt de la VM 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.

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 à la VM. Vous pouvez contrôler le temps que Compute Engine passe à récupérer les données avec le délai de récupération de SSD local. Par défaut, Compute Engine passe une heure à récupérer les données, mais les valeurs valides sont comprises entre 0 et 168, par incréments d'une heure. La seule exception à cette règle est Z3, dont le temps de récupération par défaut est de 6 heures.

Si le délai d'expiration expire et que les données ne peuvent toujours pas être récupérées, Compute Engine redémarre la VM sans le disque SSD local. Compute Engine associe un nouveau disque SSD local vide à la VM redémarrée.

Si le délai avant expiration est d'une heure ou plus, la VM est à l'état REPAIRING pendant que Compute Engine récupère tous les disques SSD locaux associés. La VM et les disques SSD locaux ne répondent pas lors de la récupération.

Si le délai avant expiration est égal à 0, Compute Engine ne tente pas de récupérer les disques SSD locaux et les données sont irrécupérables. Vous pouvez définir le délai avant expiration de la récupération sur 0 si la reprise de la charge de travail est plus importante que la récupération des données du disque SSD local.

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

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

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

Pour définir le délai avant expiration de récupération de SSD local, consultez la page Définir les règles de maintenance d'hôte de VM.

Étapes suivantes