Résumé

  • Une mise à jour de la configuration réseau de Google Cloud a perturbé les clusters étendus (stretched clusters) de VMware Engine à Sydney, Melbourne et Francfort pendant près de 12 heures
  • Les services de calcul et de stockage sont restés disponibles, mais l'échec des communications entre les zones des clusters et le témoin (witness) a entraîné l'isolement de certaines machines virtuelles

L'incident

Une mise à jour de la configuration réseau de Google Cloud a perturbé les clusters étendus de VMware Engine à Sydney, Melbourne et Francfort le 14 juillet. L'incident a duré 11 heures et 46 minutes. Google a rétabli le service en annulant la configuration pour revenir à la dernière version stable connue.

Google a déclaré que le calcul et le stockage semblaient être restés disponibles, mais que la connectivité entre les zones des clusters avait échoué. Les zones concernées ont également perdu la connexion avec l'appareil témoin (witness appliance), empêchant les clusters de synchroniser leur état en toute sécurité. Certaines machines virtuelles se sont retrouvées isolées et ont risqué de rester sans données accessibles en écriture. Google a conseillé aux clients de consulter le support avant de migrer les charges de travail affectées vers la partie saine du cluster.

Évaluation

L'incident a touché les clients qui utilisent des clusters étendus pour maintenir la disponibilité entre les zones. Le calcul et le stockage ont continué de fonctionner, mais les connexions réseau et de témoin nécessaires pour coordonner les clusters ont échoué. Pour les équipes cloud et de continuité des activités des entreprises, cela signifie que les charges de travail pouvaient rester actives alors que le système chargé de maintenir la synchronisation des deux côtés ne fonctionnait plus normalement.

Les clusters étendus de VMware Engine placent les nœuds de données dans deux zones et utilisent un témoin dans une troisième zone. Une fois la connexion perdue entre eux, certaines machines virtuelles se sont retrouvées isolées et ont risqué de perdre l'accès aux données accessibles en écriture. Google a recommandé de migrer les charges de travail affectées vers la partie saine dans la mesure du possible, mais a également incité les clients à consulter le support en raison des risques d'échec du basculement (failover) et de l'incertitude concernant l'état de la zone secondaire.

Par conséquent, la récupération a dépendu à la fois de la conception du cluster et de la réponse opérationnelle de Google.

Pour les lecteurs de BTW, la répartition des charges de travail sur plusieurs zones ne rend pas chaque partie du service indépendante. Les clients dépendent toujours du réseau du fournisseur et du service de témoin pour maintenir le fonctionnement de ces zones comme un seul cluster. Les plans de continuité doivent couvrir la perte de ce chemin de communication, y compris la manière de migrer les charges de travail et le moment où l'assistance du fournisseur est requise.

Ce qu'il faut surveiller

Suivez de près le rapport final de Google sur la cause racine, les modifications de ses contrôles de mise à jour réseau, ainsi que toute directive de récupération révisée pour les pannes affectant la connectivité entre les zones ou la connexion au témoin.