Global Switch – Google Cloud : trois questions/réponses sur l’incident

Que s’est-il passé chez Global Switch ?

La mailing list du FRnOG (FRench Network Operators Group) donne un bon aperçu du déroulement des faits.

L’incident s’est produit dans l’un des deux datacenters du campus Global Switch à Clichy (7-9 rue Petit). Le plus petit en l’occurrence (16 703 m² d’espace brut), classé tier III.

Il était environ 3 heures du matin, ce mercredi 26 avril, quand une canalisation s’est rompue sur le circuit de refroidissement, en raison d’un problème de pompe. Il en a résulté un dégât des eaux au sous-sol, dans le local batteries, entraînant un incendie.

Les murs coupe-feu et l’intervention des pompiers ont permis de confiner le problème à la salle technique. Il y a des incertitudes sur d’éventuels dégâts dans une salle adjacente : la MMR (Meet Me Room), où arrivent les câbles et les fibres du datacenter.

Les onduleurs/batteries qui ont brûlé sont dédiés au niveau 1. Il n’y a pas eu de coupure électrique aux étages supérieurs. Certaines infrastructures se sont toutefois mises en veille pour éviter une surchauffe.

En début d’après-midi, l’infrastructure technique – dont la climatisation – est redevenue opérationnelle. L’accès physique aux étages a ensuite été progressivement rétabli, à commencer par les trois derniers, sous réserve de la présence d’un accompagnant Global Switch.

Les batteries qui ont brûlé seraient des modèles au lithium. Elles présentaient d’autant plus de risque d’incendie, en tout cas par rapport à des batteries au plomb.

On aura noté que pour la détection des fuites d’eau sur ses datacenters de Paris, Global Switch est client de l’entreprise française TTK.

Qui en a subi les conséquences  ?

Payplug et ses clients

La fintech Payplug, filiale de BPCE, fait partie des victimes. Une première alerte était apparue vers 9 heures du matin sur sa page de statut. Elle faisait état d’une interruption de service liée à un prestataire d’hébergement.

Vers 10 heures apparaissait le nom de Google Cloud. En fin de matinée, on nous annonçait une première estimation de rétablissement pour 15 heures. Payplug l’a finalement repoussée à plusieurs reprises. Jusqu’à affirmer, vers 20 heures, que les paiements, bloqués depuis une demi-journée, « [commençaient] à repasser ».

Entre-temps, invectivée par l’un de ses clients (Scaleway), la fintech avait plaidé le « scénario improbable ».

Vers 21 heures, Payplug expliquait avoir créé des serveurs de bases de données dans la région Belgique de Google Cloud. Et avoir finalisé la migration des données de production essentielles au traitement. Dans le même temps, l’entreprise reconnaissait que son plan de sécurité prévoyait un hébergement multizonal et non multirégional. Elle assurait néanmoins que ses données « n’étaient pas hébergées au même endroit, mais bien dans trois groupes de datacenters différents ».

Il a fallu attendre la soirée du 27 avril (18 heures) pour que l’incident soit considéré comme entièrement résolu. Le rétablissement aura pris plus de temps pour certains services, dont la télécollecte des paiements en magasin, les exports comptables et les virements quotidiens.

Mailo… via Ecritel

La société Mailo, qui édite le service de messagerie du même nom, a aussi subi le contrecoup. Pas en tant que cliente de Google Cloud, mais d’un autre hébergeur locataire chez Global Switch : Ecritel.

Les salles dans lesquelles se trouvaient les serveurs d’Ecritel n’ont pas été touchées. L’hébergeur n’a donc pas perdu de machines, mais a dû en relancer. Le gros de son infrastructure avait redémarré en début d’après-midi, grâce à des interventions à distance (les infrastructures bilocataires avaient basculé sur le second datacenter en PCA dans la matinée). Vers 19 heures, « moins de 1 % » des machines présentaient encore des difficultés, affirmait Ecritel.

Côté Mailo, la restauration s’est échelonnée jusqu’en début de soirée. Des problèmes d’accès ont pu persister en raison d’un délai de propagation des DNS très long chez certains fournisseurs d’accès (Bouygues Telecom et SFR notamment).

Au lendemain de l’incident, Mailo faisait à ses utilisateurs la promesse qu’ils retrouveraient l’accès à toutes leurs données. Et d’ajouter : « Les messages qui vous ont été envoyés pendant l’indisponibilité vont normalement être délivrés ».

Diverses collectivités et des services publics

Cannes, Courbevoie, Lille et Saint-Brieuc font partie des villes dont le site a été indisponible pendant quelques heures du fait de l’incident chez Global Switch. Même chose pour le département de Saône-et-Loire.

Cybermalveillance.gouv.fr (hébergé chez Ecritel) a aussi connu une indisponibilité.

Google Cloud touché : quelle ampleur et pourquoi ?

Le ticket de suivi de l’incident chez Google Cloud a été ouvert vers 3 heures du matin le 26 avril, coïncidant avec la survenue de l’incident. Il était alors question de multiples services affectés dans une des zones de disponibilité de la région europe-west-9 (Paris). En l’occurrence, la zone A.

Vers 7 heures, il n’était plus question d’un dysfonctionnement sur une zone, mais sur toute la région (zones A, B et C), en raison d’une « panne multicluster ».

En fin de matinée, on apprenait que le problème avait des conséquences au-delà de la région concernée. Dans le monde entier, l’accès aux pages Compute Engine dans la console Google Cloud était perturbé. Alerte que des témoignages sont vite venus corroborer. Le conseil : utilisez gcloud à la place.

En dehors de la région affectée, le problème sur la console aura officiellement duré entre une et deux heures. D’autres soucis d’ampleur mondiale ont touché, dans la matinée, le plan de contrôle GCE (Google Container Engine). D’une part, pour qui utilisait le DNS global. De l’autre, pour qui réalisait un inventaire global s’il disposait de ressources dans la région touchée.

Aux dernières nouvelles (c’est-à-dire, au moment où nous écrivons ces lignes, le 28 avril vers 3 heures), certains services n’ont toujours pas récupéré dans la zone A. Google Cloud ne précise pas lesquels. La veille, en début d’après-midi, il signalait que GCE, Cloud Run, GLCB (Google Cloud Load Balancer), DataProc et Cloud SQL n’avaient pas encore récupéré dans ladite zone.

Cloud Pub/Sub et BigQuery, tous deux rétablis dans la nuit du 26 au 27, avaient leurs tickets de suivi respectifs.

La thèse du point de défaillance unique

Le datacenter Global Switch abrite-t-il les trois zones de la région Google Cloud ? Soulever l’hypothèse est tentant… et certains l’ont fait.

On sait qu’en plus de sa présence chez Global Switch, le groupe américain a des ancrages chez Interxion Paris 7 (La Courneuve), DATA4 Paris (Marcoussis) et Telehouse – Paris 2 (Voltaire – Léon Frot). Mais il s’agit là de ses interconnexions.

Au lancement de cette région l’an dernier, Google Cloud évoquait des zones de disponibilité localisées dans des datacenters distants d’au moins 10 km les uns des autres.

Sa documentation est moins claire. En tout cas les différentes pages que nous avons consultées. Parmi elles, une sous-rubrique de la catégorie Compute. On peut y lire :

Google Cloud conçoit les zones de façon à minimiser le risque de défaillances corrélées liées à des pannes d’infrastructure matérielle, telles que l’alimentation, le refroidissement ou la mise en réseau.

Cette même page permet de constater une différence entre la zone A et les deux autres : les VM T2D n’y sont pas disponibles…

Sur une autre page de doc, relative quant à elle à la distribution géographique du cloud de Google, on peut lire :

Google Cloud compte proposer au moins trois zones de disponibilité (zones physiques et logiquement distinctes) dans chaque région à usage général.

Troisième page de doc (sur la récupération après sinistre), troisième nuance :

Les zones présentent un degré élevé d’indépendance en termes d’infrastructure physique et logique.

Microsoft définit les zones de disponibilité Azure comme des « centres de données séparés physiquement et de manière logique et qui disposent de leurs propres sources d’alimentation, réseau et refroidissement indépendants ».

AWS, pour sa part, communique comme suit :

– Fonctionnement par région, « emplacement physique dans le monde où nous regroupons des centres de données »

– Chaque groupe de centres de données logiques est appelé « zone de disponibilité »

– Chaque région se compose d’au moins trois zones de disponibilité, « isolées et physiquement séparées au sein d’une zone géographique »

AWS évoque une « distance significative, c’est-à-dire plusieurs kilomètres ». Tout en précisant que les zones de disponibilité se trouvent toutes à moins de 100 km (60 miles) les unes des autres.

L’incertitude sur l’architecture de la région Google Cloud pousse à explorer d’autres points de défaillance potentiels. Parmi elles, il y a évidemment le logiciel. Et le réseau, vu les dommages éventuels sur la MMR.