Le 26 octobre, nous avons rendu compte, d'après le rapport préliminaire, de la panne de courant qui a mis hors service la zone europe-west2-b de Google Cloud à Londres. Le 4 novembre, Google Cloud a publié sur sa page d'état son rapport d'incident final, avec une cause bien plus précise que dans le rapport préliminaire. Selon le rapport final, l'impact principal a été résolu en 6 heures et 8 minutes (le rapport préliminaire indiquait 6 heures 10 minutes).

La cause : une configuration de maintenance et l'emplacement d'un capteur

  • Le site repose sur une alimentation 2N : deux arrivées électriques indépendantes, A et B, secourues par un parc de groupes électrogènes haute tension piloté par un automate programmable (PLC) redondant. Les batteries des onduleurs (UPS) tiennent environ cinq minutes, de quoi laisser le PLC détecter la sous-tension, démarrer et synchroniser les groupes diesel puis transférer la charge.
  • Un essai trimestriel en charge des groupes électrogènes, le 14 octobre, a révélé des problèmes ; pour réparer l'arrivée B, son disjoncteur a été ouvert, plaçant le site dans une configuration de maintenance temporaire à une seule arrivée (1N), l'arrivée A portant toute la charge critique.
  • Le 19 octobre à 22:53, heure du Pacifique (06:53 BST le 20), l'arrivée A a été coupée à cause d'un défaut de câble souterrain sur le réseau électrique, à l'extérieur du site. La détection de sous-tension du PLC était câblée en amont des disjoncteurs d'arrivée : le disjoncteur de l'arrivée B était ouvert, mais la ligne au-dessus restait sous tension, si bien que les deux PLC, actif et de secours, exécutant la même logique, ont vu « une source électrique saine » et n'ont jamais ordonné le démarrage des groupes. Lorsque l'équipe sur place a tenté un transfert de charge à distance via le PLC, la même mesure l'en a empêchée.
  • Estimant que les onduleurs seraient à court avant que les opérations à distance puissent être réglées, l'équipe a basculé le site sur l'alimentation de secours du réseau, mais les batteries se sont épuisées pendant le transfert et les salles informatiques ont perdu l'alimentation.

Pourquoi la reprise a pris six heures

  • Toutes les heures sont en BST : l'impact a commencé à 07:00 ; l'alimentation de secours a été rétablie à 07:54, les salles informatiques ont retrouvé le courant à 08:20, les clusters ont commencé à repartir à 08:40 et les équipements réseau sont revenus à 08:45.
  • Le stockage a été la partie lente : la coupure brutale a laissé un grand nombre de périphériques de stockage arrêtés de façon non propre, dont la récupération a commencé à 08:50, et les équipes ont volontairement retenu les services qui auraient aggravé la situation. Vu le nombre d'appareils, cela a pris longtemps ; le stockage n'a été suffisamment rétabli qu'à 11:13, et le trafic a été réadmis progressivement à partir de 11:45.
  • Les services et API de Google Cloud étaient entièrement disponibles à 12:11 (certaines machines virtuelles GCE n'étaient pas encore revenues), la perturbation centrale de la plateforme a pris fin à 12:29, à 13:08 99,5 % des machines virtuelles GCE étaient saines et de nouvelles pouvaient être créées, et l'avis de clôture a été publié à 15:03.
  • Les deux autres zones ont aussi souffert : les appels inter-zones vers la zone hors ligne expiraient, et la charge redirigée par le basculement a saturé la capacité de calcul des zones restantes, provoquant des erreurs 500 et 503 intermittentes dans toute la région.

Les mesures de Google, et les leçons pour vos propres serveurs

Parmi les actions de Google : le PLC a été reconfiguré et validé le 20 octobre puis à nouveau le 26 octobre, date à laquelle un essai de transfert sur les groupes électrogènes avec toute la charge critique a aussi été réalisé ; le gestionnaire du réseau électrique a localisé le défaut de câble le 26 octobre, prévoit de réparer l'arrivée A d'ici le 13 novembre, et d'ici le 17 novembre le site devrait revenir sur les arrivées A et B avec un nouvel essai en charge des groupes ; enfin, une revue complète du code du PLC est prévue d'ici le 6 novembre. Pour nos propres serveurs, trois points méritent d'être retenus : la redondance devient discrètement un point de défaillance unique pendant une maintenance, car pendant qu'une machine est en intervention, l'autre est la seule ; la supervision doit vérifier l'état réel, pas un seul signal en amont ; et après une coupure brutale, c'est souvent la récupération du stockage qui est la plus lente, alors gardez une copie de vos données ailleurs grâce à l'une de ces stratégies de sauvegarde. Pour la logique des déploiements multirégions, voir pourquoi un seul nœud ne suffit pas, et pour choisir vos emplacements, voir choisir un nœud de centre de données à faible latence.