Google Distributed Cloud est conçu pour limiter l'étendue des défaillances et donner la priorité aux fonctionnalités essentielles à la continuité des activités. Ce document explique l'impact sur les fonctionnalités de vos clusters en cas de défaillance. Ces informations peuvent vous aider à hiérarchiser les domaines à résoudre en cas de problème.
Si vous avez besoin d'aide supplémentaire, contactez l'assistance Cloud Customer Care.Les fonctionnalités de base de Google Distributed Cloud incluent les catégories suivantes:
- Exécuter des charges de travail: les charges de travail existantes peuvent continuer à s'exécuter. Il s'agit de l'élément le plus important à prendre en compte pour assurer la continuité de l'activité. 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 aspect le plus important pour effectuer le scaling des charges de travail lorsque le trafic augmente, même si le cluster présente un problème.
- Gérer des clusters d'utilisateur: vous pouvez gérer les nœuds, mettre à jour, mettre à niveau et supprimer des clusters d'utilisateur. Ce point est moins important que les considérations liées au cycle de vie de l'application. S'il y a de la capacité disponible sur les nœuds existants, l'impossibilité de modifier des clusters d'utilisateur n'affecte pas les charges de travail des utilisateurs.
- Gérer les clusters d'administrateur: vous pouvez mettre à jour le cluster d'administrateur. Il s'agit du point le moins important à prendre en compte, car le cluster d'administrateur n'héberge aucune charge de travail utilisateur. Si votre cluster d'administrateur rencontre un problème, les charges de travail de votre 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 de scénarios de défaillance spécifiques.
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 machine virtuelle (VM) hébergeant des nœuds Kubernetes peut cesser de fonctionner ou être partitionné par le réseau.
| Exécuter des charges de travail | Gérer les charges de travail | Gérer les clusters d'utilisateur | Gérer les clusters d'administrateur | |
|---|---|---|---|---|
| Perturbation | Perturbation possible et récupération automatique | Perturbation possible et récupération automatique | Perturbation et récupération automatique | Perturbation et récupération automatique |
| Explication | Les pods qui s'exécutent sur les VM hébergées par l'hôte défaillant sont interrompus et sont automatiquement reprogrammé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 d'échec, 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 | |
|---|---|---|---|---|
| Perturbation | Perturbation possible et récupération automatique | Perturbation possible et récupération automatique | Perturbation et récupération automatique/manuelle | Perturbation et récupération manuelle |
| Explication | Les pods qui s'exécutent sur les VM de nœud de calcul défaillantes sont interrompus et sont automatiquement reprogrammé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 d'échec, le contenu d'un fichier VMDK peut être corrompu en raison d'une mise hors tension incorrecte d'une VM, ou une défaillance du datastore peut entraîner la perte des données etcd et des 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 | |
|---|---|---|---|---|
| Perturbation | Aucune interruption | Perturbation possible et récupération manuelle | Perturbation et récupération manuelle | Perturbation 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 récupérer après la défaillance. | Google Distributed Cloud fournit un processus manuel pour la reprise après échec. | Google Distributed Cloud fournit un processus manuel pour la reprise après échec. |
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 | |
|---|---|---|---|---|
| Perturbation | Perturbation 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 | |
|---|---|---|---|---|
| Perturbation 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 durer jusqu'à deux secondes lorsque vous utilisez Seesaw, et jusqu'à 300 secondes avec F5. La durée de l'interruption du basculement de MetalLB augmente à mesure que le nombre de nœuds de l'équilibreur de charge augmente. Avec moins de 5 nœuds, l'interruption se produit dans les 10 secondes. |
|||
| Récupération | Seesaw HA détecte automatiquement la défaillance et bascule vers l'instance de sauvegarde. Google Distributed Cloud fournit un processus manuel de 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
Google Distributed Cloud s'appuie sur vSphere HA pour assurer la récupération en cas de défaillance d'un 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 procédure 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.
Le disque de démarrage de la VM est corrompu, par exemple un disque de démarrage qui passe en lecture seule en raison des journaux de spam.
Échec du démarrage de la VM en raison de problèmes de disque ou de configuration du réseau (par exemple, une VM qui ne peut pas démarrer, car aucune adresse IP ne peut lui être alloué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 des modules complémentaires d'administration, 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 du plan de contrôle administrateur, contactez Cloud Customer Care.
Récupération après une défaillance de l'espace de stockage
Certains des échecs de stockage peuvent être atténués par vSphere HA et vSAN sans affecter Google Distributed Cloud. Toutefois, 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) possède une base de données etcd qui stocke l'état (objets Kubernetes) du cluster.
- PersistentVolumes: utilisé à la fois par les composants système et par les charges de travail des utilisateurs.
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 et que cette sauvegarde est 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 de données etcd peut se produire 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. Ce scénario peut se produire dans un cluster à haute disponibilité, où les données de l'une des instances répliquées etcd sont corrompues ou perdues. Vous pouvez résoudre le problème sans aucune perte de données en remplaçant l'instance répliquée etcd défaillante par une nouvelle instance à l'état propre. Pour en savoir plus, consultez la section 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. Le remplacement des instances répliquées etcd défaillantes par de nouvelles n'est donc pas utile. 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 partenaires pour sauvegarder et restaurer les PersistentVolumes des applications utilisateur. Pour obtenir la liste des partenaires de stockage qualifiés pour Google Distributed Cloud, consultez la page Partenaires Anthos Ready Storage.
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 du plan de contrôle administrateur où il existe 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é, il utilise des nœuds de cluster comme équilibreurs de charge. La réparation automatique des nœuds n'est pas déclenchée en cas de problèmes d'équilibreur de charge. Vous pouvez suivre le processus manuel pour réparer le nœud.