Cette page décrit ce qui se passe lors d'un test avec un type de défaillance Fail Compute et les mesures à prendre si Fault Injection Testing ne peut pas arrêter le test.
Fonctionnement de la défaillance Fail Compute
La défaillance Fail Compute utilise des tags de ressource pour marquer les VM et une stratégie de pare-feu avec des règles qui ciblent ces tags afin de bloquer tout le trafic entrant et sortant. Cette configuration donne l'impression que les ressources ciblées sont en panne, tout en veillant à ce qu'elles restent intactes et rapidement récupérables.
La cible de cette défaillance peut être l'une des suivantes :
- Instances de machines virtuelles
- VM basées sur un tag de ressource spécifié
- VM au sein d'un groupe d'instances géré (MIG) zonal ou régional spécifié
- VM ne faisant pas partie d'un MIG dans une zone et VM dans des MIG zonaux
- VM ne faisant pas partie d'un MIG dans une région et VM dans tous les MIG
Que se passe-t-il lors de l'exécution du test ?
Au fur et à mesure que le test progresse dans les états, les ressources impliquées subissent les modifications suivantes.
Ressource |
|
|
|
VM |
Aucun |
Lier le tag de ressource |
Dissocier le tag de ressource |
MIG / MIG régionaux |
Aucun |
Désactiver l'autoréparation et l'autoscaling (s'ils sont actifs) |
Restaurer les paramètres d'autoréparation et d'autoscaling |
Tag |
Créer une ressource TagValue unique pour le test |
Aucun |
Supprimer TagValue |
Stratégie de pare-feu |
Créer une ressource FirewallPolicy au niveau du système |
Remplir avec des règles DENY et lier la stratégie aux VPC pertinents |
Dissocier des VPC et supprimer FirewallPolicy |
Récupération manuelle d'urgence
En cas de défaillance catastrophique du backend où Fault Injection Testing ne peut pas arrêter automatiquement un test, vous pouvez restaurer manuellement la connectivité aux ressources de VM en supprimant manuellement les tags de ressource liés aux VM concernées. La stratégie de pare-feu du système, qui cible ces tags, ne s'appliquera plus, ce qui détachera efficacement les VM de la défaillance d'isolation.
Autorisations requises
Vous devez disposer des autorisations IAM suivantes :
- Obligatoire pour afficher les instances de VM :
compute.instances.getcompute.instances.list
- Obligatoire pour afficher et supprimer les liaisons de tags :
resourcemanager.tagValueBindings.listresourcemanager.tagValueBindings.delete
Récupération manuelle à l'aide de l' Google Cloud interface utilisateur de la console
Pour effectuer une récupération à l'aide de la Google Cloud console :
- Accédez à la page Instances de VM dans la Google Cloud console.
- Sélectionnez les instances de VM spécifiques affectées par la défaillance d'isolation.
- Sur la page d'informations de l'instance, accédez à la section de gestion des tags.
- Identifiez la liaison de tag spécifique au test associée à la défaillance Fail Compute de Fault Injection Testing.
- Supprimez la liaison de tag de la VM.
Une fois le tag supprimé, la stratégie de pare-feu associée ne ciblera plus la VM et la connectivité sera rétablie.
Récupération manuelle à l'aide de la gcloud CLI
Vous pouvez supprimer manuellement la liaison de tag de test d'une VM à l'aide de la Google Cloud CLI. Dans les commandes suivantes, remplacez TAG_VALUE_NAME,
PROJECT_NUMBER, ZONE et VM_NAME par les valeurs spécifiques à votre
environnement.
Commencez par récupérer le nom de la valeur de tag spécifique au test en listant les liaisons de tags actuelles pour la VM :
gcloud resource-manager tag bindings list --resource=//compute.googleapis.com/projects/PROJECT_NUMBER/zones/ZONE/instances/VM_NAME
Utilisez le résultat de la commande précédente pour déterminer le TAG_VALUE_NAME requis pour l'étape de suppression :
gcloud resource-manager tag bindings delete --tag-value=TAG_VALUE_NAME --resource=//compute.googleapis.com/projects/PROJECT_NUMBER/zones/ZONE/instances/VM_NAME
Une fois le tag supprimé, la stratégie de pare-feu associée ne ciblera plus la VM et la connectivité sera rétablie.