Google Distributed Cloud est conçu pour limiter la portée des défaillances et donner la priorité aux fonctionnalités essentielles à la continuité des opérations. Ce document explique l'impact d'une défaillance sur le fonctionnement de vos clusters. Ces informations peuvent vous aider à hiérarchiser les problèmes à résoudre en cas de problème.
Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.Les principales fonctionnalités de Google Distributed Cloud sont les suivantes :
- Exécuter les charges de travail : les charges de travail existantes peuvent continuer à s'exécuter. Il s'agit du critère le plus important pour maintenir la continuité des opérations. Même si votre cluster rencontre un problème, les charges de travail existantes peuvent continuer à s'exécuter sans interruption.
- Gérer les charges de travail : vous pouvez créer, mettre à jour et supprimer des charges de travail. Il s'agit du deuxième élément le plus important pour faire évoluer les charges de travail lorsque le trafic augmente, même si le cluster présente un problème.
- Gérer les clusters d'utilisateur : vous pouvez gérer les nœuds, mettre à jour, mettre à niveau et supprimer des clusters d'utilisateur. Cela est moins important que les considérations liées au cycle de vie de l'application. Si les nœuds existants disposent d'une capacité suffisante, l'impossibilité de modifier les clusters d'utilisateur n'affecte pas les charges de travail des utilisateurs.
- Gérer les clusters d'administrateur : vous pouvez mettre à jour et mettre à niveau le cluster d'administrateur. Il s'agit de la considération la moins importante, car le cluster d'administrateur n'héberge aucune charge de travail d'utilisateur. Si votre cluster d'administrateur rencontre un problème, vos charges de travail d'application continuent de s'exécuter sans interruption.
Les sections suivantes utilisent ces catégories de fonctionnalités de base pour décrire l'impact de types spécifiques de scénarios de défaillance.
Modes de défaillance
Les types de défaillance suivants peuvent affecter les performances des clusters Google Distributed Cloud.
Défaillance de l'hôte ESXi
Dans ce scénario de défaillance, un hôte ESXi qui exécute des instances de machines virtuelles (VM) hébergeant des nœuds Kubernetes peut cesser de fonctionner ou se transformer en réseau partitionné.
| Exécuter des charges de travail | Gérer les charges de travail | Gérer les clusters d'utilisateur | Gérer les clusters d'administrateur | |
|---|---|---|---|---|
| Interruption | Interruption possible et récupération automatique | Interruption possible et récupération automatique | Interruption et récupération automatique | Interruption et récupération automatique |
| Explication | Les pods s'exécutant sur des VM hébergées par l'hôte défaillant sont interrompus et automatiquement replanifiés sur d'autres VM opérationnelles. Si les applications utilisateur disposent d'une capacité de charge de travail supplémentaire et sont réparties sur plusieurs nœuds, les interruptions ne sont pas perceptibles par les clients qui mettent en œuvre de nouvelles tentatives. |
Si la défaillance de l'hôte affecte la VM de plan de contrôle dans un cluster d'utilisateur standard ou plusieurs VM de plan de contrôle dans un cluster d'utilisateur à haute disponibilité, cela entraîne une interruption. | Si la défaillance de l'hôte affecte la VM de plan de contrôle ou les VM de nœud de calcul du cluster d'administrateur, cela entraîne une interruption. | Si la défaillance de l'hôte affecte la VM de plan de contrôle dans le cluster d'administrateur, cela entraîne une interruption. |
| Récupération | vSphere HA redémarre automatiquement les VM sur des hôtes opérationnels. | vSphere HA redémarre automatiquement les VM sur des hôtes opérationnels. | vSphere HA redémarre automatiquement les VM sur des hôtes opérationnels. | vSphere HA redémarre automatiquement les VM sur des hôtes opérationnels. |
| Prévention | Déployez vos charges de travail sur un cluster à haute disponibilité de façon à réduire le risque d'interruption. | Utilisez des clusters d'utilisateurs à haute disponibilité pour minimiser les risques d'interruption. | — | — |
Défaillance de la VM
Dans ce scénario de défaillance, une VM peut être supprimée de manière inattendue, un disque de démarrage peut être corrompu ou une VM peut être compromise en raison de problèmes liés au système d'exploitation.
| Exécuter des charges de travail | Gérer les charges de travail | Gérer les clusters d'utilisateur | Gérer les clusters d'administrateur | |
|---|---|---|---|---|
| Interruption | Interruption possible et récupération automatique | Interruption possible et récupération automatique | Interruption et récupération automatique/manuelle | Interruption et récupération manuelle |
| Explication | Les pods s'exécutant sur les VM de nœud de calcul défaillantes sont interrompus. Ils sont automatiquement replanifiés sur d'autres VM opérationnelles par Kubernetes. Si les applications utilisateur disposent d'une capacité de charge de travail supplémentaire et sont réparties sur plusieurs nœuds, les interruptions ne sont pas perceptibles par les clients qui mettent en œuvre de nouvelles tentatives. |
Si la VM avec plan de contrôle d'un cluster d'utilisateur standard ou plusieurs VM de plan de contrôle dans un cluster d'utilisateur haute disponibilité échouent, cela comporte une interruption. | En cas de défaillance de la VM du plan de contrôle ou des VM de nœud de calcul dans le cluster administrateur, il y a interruption. | Si la VM du plan de contrôle du cluster d'administrateur échoue, une interruption se produit. |
| Récupération | La VM défaillante est automatiquement récupérée si la réparation automatique des nœuds est activée dans le cluster d'utilisateur. | La VM défaillante est automatiquement récupérée si la réparation automatique de nœuds est activée dans le cluster d'administrateur. | La VM de nœud de calcul défaillante dans le cluster d'administrateur sera automatiquement récupérée si la réparation automatique des nœuds est activée dans le cluster d'administrateur. Pour récupérer la VM du plan de contrôle du cluster d'administrateur, consultez la section Réparer la VM du plan de contrôle du cluster administrateur. |
Pour récupérer la VM du plan de contrôle du cluster d'administrateur, consultez la section Réparer la VM du plan de contrôle du cluster administrateur. |
| Prévention | Déployez vos charges de travail sur un cluster à haute disponibilité de façon à réduire le risque d'interruption. | Utilisez des clusters d'utilisateurs à haute disponibilité pour minimiser les risques d'interruption. | — | — |
Défaillance de l'espace de stockage
Dans ce scénario de défaillance, le contenu d'un fichier VMDK peut être altéré en raison d'une mise hors tension concertée d'une VM ou d'une défaillance du datastore ce qui peut provoquer la perte de données etcd et de volumes PersistentVolumes (PV).
défaillance etcd
| Exécuter des charges de travail | Gérer les charges de travail | Gérer les clusters d'utilisateur | Gérer les clusters d'administrateur | |
|---|---|---|---|---|
| Interruption | Aucune interruption | Interruption possible et récupération manuelle | Interruption et récupération manuelle | Interruption et récupération manuelle |
| Explication | — | En cas de défaillance du stockage etcd d'un cluster utilisateur standard ou de plusieurs instances dupliquées etcd dans un cluster utilisateur haute disponibilité, il y a une interruption. | En cas de défaillance du stockage etcd d'un cluster utilisateur standard ou de plusieurs instances dupliquées etcd dans un cluster utilisateur haute disponibilité, il y a une interruption. Si l'instance dupliquée etcd d'un cluster d'administrateur échoue, une interruption se produit. |
Si l'instance dupliquée etcd d'un cluster d'administrateur échoue, une interruption se produit. |
| Prévention | — | Google Distributed Cloud fournit un processus manuel pour effectuer la récupération après défaillance. | Google Distributed Cloud fournit un processus manuel de récupération après défaillance. | Google Distributed Cloud fournit un processus manuel de récupération après défaillance. |
Défaillance du PV de l'application utilisateur
| Exécuter des charges de travail | Gérer les charges de travail | Gérer les clusters d'utilisateur | Gérer les clusters d'administrateur | |
|---|---|---|---|---|
| Interruption | Interruption possible | Aucune interruption | Aucune interruption | Aucune interruption |
| Explication | Les charges de travail qui utilisent le PV défaillant sont concernées. Déployez vos charges de travail sur un cluster à haute disponibilité de façon à réduire le risque d'interruption. |
— | — | — |
Défaillance de l'équilibreur de charge
Dans ce scénario de défaillance, une défaillance de l'équilibreur de charge peut affecter les charges de travail des utilisateurs qui exposent des services de type LoadBalancer.
| Exécuter des charges de travail | Gérer les charges de travail | Gérer les clusters d'utilisateur | Gérer les clusters d'administrateur | |
|---|---|---|---|---|
| Interruption et récupération manuelle | ||||
| Explication |
Quelques secondes d'interruption avant que l'équilibreur de charge de secours rétablisse la connexion d'adresse IP virtuelle du plan de contrôle administrateur. L'interruption de service peut prendre jusqu'à deux secondes en cas d'utilisation de Seesaw et jusqu'à 300 secondes avec F5. La durée de l'interruption de basculement de MetalLB augmente à mesure que le nombre de nœuds d'équilibreur de charge augmente. Avec moins de cinq nœuds, la perturbation dure moins de 10 secondes. |
|||
| Récupération | Seesaw HA détecte automatiquement l'échec et bascule vers l'utilisation de l'instance de sauvegarde. Google Distributed Cloud fournit un processus manuel pour la récupération après une défaillance de Seesaw. |
|||
Récupération d'un cluster défectueux
Les sections suivantes expliquent comment récupérer un cluster défectueux.
Récupération après défaillance de l'hôte ESXi
GKE On-Prem s'appuie sur vSphere HA pour assurer une récupération en cas de défaillance de l'hôte ESXi. vSphere HA peut surveiller en continu les hôtes ESXi et redémarrer automatiquement les VM sur d'autres hôtes si nécessaire. Cette opération est transparente pour les utilisateurs de Google Distributed Cloud.
Récupération après une défaillance de la VM
Les défaillances de VM peuvent inclure les éléments suivants :
Suppression inattendue d'une VM.
Corruption du disque de démarrage de VM, par exemple lorsqu'un disque de démarrage devient en lecture seule en raison des journaux de journal anti-spam.
Échec du démarrage de la VM en raison de problèmes de performances du disque ou de la configuration du réseau, par exemple si la VM ne peut pas démarrer, car une adresse IP ne peut pas lui être attribuée.
Corruption du système de fichiers de superposition Docker.
Perte de la VM de plan de contrôle administrateur en raison d'un échec de mise à niveau.
Problèmes liés au système d'exploitation.
Google Distributed Cloud fournit un mécanisme de récupération automatique pour les nœuds complémentaires d'administrateur, les plans de contrôle d'utilisateur et les nœuds utilisateur. Cette fonctionnalité de réparation automatique des nœuds peut être activée pour chaque cluster d'administrateur et chaque cluster d'utilisateur.
La VM de plan de contrôle administrateur est spéciale, car elle n'est pas gérée par un cluster Kubernetes et sa disponibilité n'affecte pas la continuité des opérations. Pour la récupération des défaillances de VM de plan de contrôle administrateur, contactez Cloud Customer Care.
Récupération après une défaillance de l'espace de stockage
Certaines défaillances de l'espace de stockage peuvent être atténuées par vSphere HA et par VSAN sans affecter Google Distributed Cloud. Cependant, certains échecs de stockage peuvent survenir au niveau de vSphere, ce qui entraîne une corruption ou une perte de données sur divers composants Google Distributed Cloud.
Les informations avec état d'un cluster et des charges de travail d'utilisateur sont stockées aux emplacements suivants :
- etcd : Chaque cluster (cluster d'administrateur et cluster d'utilisateur) dispose d'une base de données etcd qui stocke l'état (objets Kubernetes) du cluster.
- PersistentVolumes : Utilisés par les composants du système et les charges de travail de l'utilisateur.
Récupération après corruption ou perte de données d'etcd
etcd est la base de données utilisée par Kubernetes pour stocker tous les états de cluster, y compris les fichiers manifestes de l'application d'utilisateur. Les opérations du cycle de vie de l'application cesseront de fonctionner si la base de données etcd du cluster d'utilisateur est corrompue ou perdue. Les opérations du cycle de vie du cluster d'utilisateur cesseront de fonctionner si la base de données etcd du cluster d'administrateur est corrompue ou perdue.
etcd ne dispose pas d'un mécanisme intégré fiable pour détecter la corruption des données. Vous devez consulter les journaux des pods de l'etcd si vous pensez que les données de l'etcd sont corrompues ou perdues.
Un pod etcd en attente/d'erreur/crash-looping ne signifie pas nécessairement que les données etcd sont corrompues ou perdues. Cela peut être dû à des erreurs sur les VM hébergeant les pods de l'etcd. Pour l'interruption ou la perte de données, vous devez vous cantonner à effectuer la récupération etcd suivante :
Pour pouvoir récupérer (un état de cluster récent) à partir d'une corruption ou d'une perte de données etcd, les données etcd doivent être sauvegardées après toute opération de cycle de vie dans le cluster (par exemple, création, mise à jour ou mise à niveau). Pour sauvegarder les données etcd, consultez les pages Sauvegarder un cluster d'administrateur et Sauvegarder un cluster d'utilisateur.
La restauration des données etcd rétablit l'état précédent du cluster. Si une sauvegarde est effectuée avant le déploiement d'une application, puis utilisée pour restaurer le cluster, l'application récemment déployée ne s'exécutera pas dans le cluster restauré. Par exemple, si vous utilisez l'instantané etcd d'un cluster d'administrateur instantané avant de créer un cluster d'utilisateur, le plan de contrôle du cluster d'utilisateur restauré sera supprimé du cluster d'administrateur restauré. Par conséquent, nous vous recommandons de sauvegarder le cluster après chaque opération critique du cluster.
La corruption ou la perte des données d'etcd peut entraîner une défaillance dans les scénarios suivants :
Un nœud unique d'un cluster etcd à trois nœuds (cluster d'utilisateur haute disponibilité) est définitivement défectueux en raison d'une corruption ou d'une perte de données. Dans ce cas, un seul nœud est défectueux, mais le quorum etcd existe toujours. Cela peut se produire dans un cluster à haute disponibilité, dans lequel les données de l'une des instances répliquées etcd sont corrompues ou perdues. Le problème peut être résolu, sans perte de données, en remplaçant l'instance répliquée d'etcd défaillante par une nouvelle instance dans un état propre. Pour en savoir plus, consultez la page Remplacer une instance répliquée etcd en échec.
Deux nœuds d'un cluster etcd à trois nœuds (cluster d'utilisateur haute disponibilité) sont définitivement défectueux en raison d'une corruption ou d'une perte de données. Le quorum est perdu. Il n'est donc pas utile de remplacer les instances répliquées etcd défaillantes par de nouvelles. L'état du cluster doit être restauré à partir de données de sauvegarde. Pour en savoir plus, consultez la page Restaurer un cluster d'utilisateur à partir d'une sauvegarde (haute disponibilité).
Un cluster etcd à nœud unique (cluster d'administrateur ou cluster d'utilisateur standard) est définitivement défectueux en raison d'une corruption ou d'une perte de données. Le quorum est perdu. Vous devez donc créer un cluster à partir de la sauvegarde. Pour plus d'informations, consultez la section Restaurer un cluster d'utilisateur à partir d'une sauvegarde (standard).
Récupération après perte ou corruption PV de l'application utilisateur.
Vous pouvez utiliser certaines solutions de stockage de partenaires pour sauvegarder et restaurer des volumes persistants d'applications utilisateur. Pour obtenir la liste des partenaires de stockage qualifiés pour Google Distributed Cloud, consultez la page Partenaires de stockage Anthos Ready.
Récupération après une défaillance de l'équilibreur de charge
Dans le cas d'un équilibreur de charge Seesaw groupé, vous pouvez récupérer des défaillances en recréant l'équilibreur de charge. Pour recréer l'équilibreur de charge, effectuez une mise à niveau de Seesaw vers la même version que celle indiquée dans la section Mettre à niveau l'équilibreur de charge de votre cluster d'administrateur.
En cas de défaillance de l'équilibreur de charge du cluster d'administrateur, le plan de contrôle peut être hors de portée. Exécutez la mise à niveau sur la VM de plan de contrôle administrateur permettant un accès au plan de contrôle.
Pour les équilibreurs de charge intégrés (F5), contactez l'assistance F5.
Pour l'équilibreur de charge MetalLB groupé, les nœuds du cluster sont utilisés comme équilibreurs de charge. La réparation automatique des nœuds n'est pas déclenchée en cas de problème avec l'équilibreur de charge. Vous pouvez suivre le processus manuel pour réparer le nœud.