Incendie Global Switch : réflexions sur la résilience des Clouds Publics
02/05/2023
L’un des centres de calcul d’un grand hébergeur mondial, Global Switch, situé à Clichy en région parisienne, a été victime d’un incendie dans la semaine du 24 avril 2023.
Ces incendies sont rares, mais ils se produisent de temps en temps et aucune entreprise n’est à l’abri d’un tel accident dans un centre de calcul, qu’il soit:
- Géré directement par l’entreprise, “On Premise”.
- Chez un hébergeur.
- Sous la responsabilité d’un acteur du Cloud Public.
Cet incendie a immédiatement déclenché une polémique sur la qualité des services proposés par les géants du cloud public américain. Pourquoi? Le Cloud Public GCP de Google a été touché et des services proposés par une “Zone France Paris” ont été indisponibles pendant plusieurs heures.
Mon ami Alain Garnier, PDG de Jamespot, a immédiatement publié sur LinkedIn une vidéo pour commenter cet incident. Il m’a personnellement cité en me reprochant gentiment d'être un “suppôt” des géants du Cloud Public.
Suppôt, non, mais grand fan, oui. Sur ce point, il a tout à fait raison et je ne m’en suis jamais caché, depuis plus de 15 ans.
Cette mise en cause et cet accident m’ont donné l’envie et l’occasion d’apporter des éclaircissements sur les différentes implantations géographiques des géants du Cloud Public.
C’est un sujet qui est rarement abordé et amène trop d’entreprises à faire des erreurs qu’elles pourraient éviter quand elles travaillent avec les grands acteurs du Cloud Public.
Ce que j'explique dans ce texte est valable pour tous les grands acteurs du Cloud Public, AWS d’Amazon, Azure de Microsoft et GCP de Google.
L’incendie: les faits
Dans la nuit du 25 au 26 avril 2023, un incendie a éclaté dans un des centres de calcul de l’hébergeur Global Switch, situé à Clichy, en région parisienne. Cet incendie a entraîné l’arrêt de ce centre de calcul.
De nombreuses organisations qui hébergeaient leurs services numériques dans ce centre de calcul ont annoncé que ces services étaient indisponibles. Parmi les organisations importantes touchées, on peut citer le service Cybermalvaillance du gouvernement français et la ville de Lille.
C'est à chacune de ces entreprises qu’il incombe la responsabilité d’avoir préparé leur PRA, Plan de Reprise d’Activité. J’espère que c’était le cas pour la majorité d’entre elles.
Mais c’est bien évidemment le “client” Google-GCP de ce centre de calcul qui a retenu l’attention et fait couler le plus d’encre, ce qui est logique.
Un géant du Cloud Public, un “Hyperscaler” qui subit une panne, c’est suffisamment rare pour que la planète numérique française s’en émeuve.
J’ai un “scoop” pour les personnes qui sont ravies de pouvoir critiquer le supposé manque de résilience des géants du Cloud Public: des pannes, ils en ont en permanence, et j’y reviens longuement dans le prochain paragraphe.
Depuis des années, Google met à la disposition de ses clients un tableau de bord de l’état de fonctionnement de tous ses services, dans chaque région géographique.
Il est mis à jour en temps réel. Voilà un instantané d’une partie de ce tableau, le 26 avril 2023: il indique clairement que tous les services dans la “Zone Europe-West9, Paris” sont indisponibles.
Cette zone de GCP est répartie chez quatre hébergeurs différents, comme le rappelle Google dans un communiqué:
“ Google Cloud se reposant sur trois autres datacenters de la région parisienne (Interxion, Data4 et Telehouse), la firme a proposé à ses clients de « basculer » temporairement et d’éviter la zone affectée (europe-west9).”
La redondance, le PRA natif font partie des services standards de GCP.
Aucun client n’a perdu de données comme le rappelait Emmanuelle Olivié-Paul, utilisatrice de GCP dans cette zone, dans sa réponse au billet LinkedIn d’Alain Garnier que je cite au début de ce billet.
Ce deuxième instantané du tableau de disponibilité des services de GCP, pris le 29 avril 2023, montre que la situation est normalisée.
Les Clouds Publics, des pannes en permanence
Qui peut croire, ou tenter de faire croire que les infrastructures géantes des fournisseurs de Clouds Publics ne tombent jamais en panne?
Je n’ai jamais, je ne tiendrai jamais un tel discours, ce serait ridicule.
Dans un billet de blog publié en 2019, il y a quatre ans, sur le thème “Clouds Publics, la confiance”, j’abordais une fois encore ce sujet. J’avais inséré ce graphique qui mettait en évidence les temps de panne de GCP, AWS et Azure pour l’année 2018.
Toute personne qui essaie de me faire dire le contraire, ou est de mauvaise foi, ou n’a jamais lu mes écrits.
Une étude très récente, publiée en mars 2023 par Parametrix, société spécialisée dans l’assurance des risques numériques, fait le point sur toutes les pannes qui se sont produites en 2022 chez AWS, GCP et Azure.
J’ai extrait de ce rapport cette phrase qui résume bien la situation:
“In 2022, Parametrix identified a total of 1190 performance disruptions across this cloud landscape. Some 41.4% of these events, 492 in total, were classified by Parametrix as critical.” (C’est moi qui ai mis en gras quelques mots.)
Oui, vous avez bien lu, près de 1200 incidents en une année, plus de 3 par jour! Ils sont nuls, ces géants du Cloud Public!
Ce graphique, présent dans ce rapport, indique les principales causes de ces incidents.
Les incidents matériels sur les infrastructures physiques, comme les incendies, sont de loin les… moins fréquents, à 8,33%, 3,5 fois moins que ceux causés par des erreurs humaines.
Ce que demandent les clients d’AWS, GCP ou Azure, ce n’est pas qu’ils leur garantissent qu’ils n’auront jamais de pannes, ce qui serait une demande idiote.
Ce que demandent ces clients, c’est qu’AWS, GCP ou Azure mettent en œuvre toutes les procédures et méthodes nécessaires pour les mettre à l’abri de ces pannes inévitables.
Et cela, AWS, GCP et Azure le font, et le font très bien!
Ce n’est pas pour cela que les entreprises doivent basculer dans les Clouds Publics sans prendre des précautions importantes, au contraire.
L’une des premières décisions à prendre, et elle est essentielle, c’est de bien choisir la ou les zones géographiques dans lesquelles elles vont déployer leurs applications.
C’est ce que j’analyse dans le paragraphe qui suit.
Les différentes familles d’implantation des géants du Cloud Public
Les informations que j’utilise sont publiques; toutes les entreprises peuvent y accéder quand elles doivent choisir leurs fournisseurs d’infrastructures Cloud Public.
Je vais illustrer mon analyse par l’exemple de GCP de Google, qui a été mis en cause à la suite de cet incendie.
Comme je l’ai écrit plus haut, j’aurais pu faire la même démonstration pour AWS ou Azure.
Les fournisseurs de Cloud Public proposent trois grandes familles d’implantations:
- Les centres de calcul dont ils sont propriétaires et qu’ils gèrent eux-mêmes.
- Des centres de calcul qui appartiennent à des hébergeurs et où ils localisent une partie de leurs services IaaS.
- Des points de présence: ce sont des petits sites qui ont pour fonction principale de proposer des accès par fibres optiques à des centres de calcul GCP. Ils sont utilisés pour réduire la latence.
Cette liste, disponible sur le site de GCP, identifie en toute transparence ces différentes familles d’implantations.
Centres de calculs appartenant à GCP
Un grand centre de calcul, construit et géré par GCP, représente un investissement supérieur à 500 millions de dollars et peut atteindre 1 ou 2 milliards de dollars.
Cette carte du monde montre l’implantation des centres de calculs qui appartiennent à GCP.
Google dispose de centres de calcul en propre dans 36 régions, réparties sur 109 zones. Ils sont en priorité installés aux Etats-Unis et en Europe.
Centres de calculs “Edge”, hébergés
Pour assurer une présence dans le plus grand nombre possible de pays, Google GCP installe une partie de ses services chez des hébergeurs locaux, comme Global Switch en France.
Dans cette configuration, GCP n’est pas maître de la gestion des centres de calcul, qui est déléguée aux hébergeurs.
C’est ce qui permet à GCP d’annoncer une présence dans plus de 200 pays.
Ce sont souvent des installations “politiques”, réalisées pour répondre aux exigences de certains pays ou entreprises qui exigent que leurs données soient stockées sur leur territoire.
“Edge” ne veut pas dire une installation unique: pour des raisons évidentes de résilience, GCP répartit ses installations “Edge” chez des hébergeurs différents. Dans le cas de Paris, ils sont quatre.
On le voit sur cette carte, où sont aussi indiqués les centres de calcul en périphérie, nommés “Edge".
Il existe un moyen simple de vérifier si une zone géographique GCP est gérée par Google en direct ou hébergée: il suffit de compter le nombre de services disponibles. Ils sont beaucoup plus nombreux dans les zones gérées en direct par Google.
Cette carte met aussi en évidence un autre investissement majeur de Google, dans les fibres optiques sous-marines.
Points de présence
Sur cette autre carte Google, les principaux points de présence sont visualisés.
Google annonce qu’il dispose de 7 500 points de présence dans le monde. C’est une bonne nouvelle. Ceci permet à toute entreprise, où qu’elle soit située, de trouver un point de présence proche qui garantit un accès rapide, par fibre optique, à GCP.
Le cas de l’Europe
En analysant les données fournies par Google, j’ai pu construire ce tableau qui fait le point sur la situation actuelle des implantations de GCP en Europe. Ce n’est qu’une photographie à un instant donné, de nouveaux investissements étant réalisés en permanence.
Au moment où je publie ce texte, GCP est présent dans la majorité des grands pays européens, dans 35 villes:
- 6 implantations de centres de calcul appartenant à Google. Ils sont tous situés dans des pays de l’Europe du Nord.
- 29 implantations “Edge”, hébergés.
- C’est le cas de la France, où il n’y a pas de centres de calcul appartenant à Google, mais deux “Edge” à Paris et Marseille.
Dans le paragraphe qui suit, je présente mes recommandations concernant les différentes options qui s’offrent à une entreprise, publique ou privée, quand elle doit choisir les zones géographiques où elle souhaite déployer ses usages numériques dans un Cloud Public.
Recommandations
L’immense majorité des entreprises publiques et privées ont le libre choix du pays où elles peuvent utiliser des services de Clouds Publics, et c’est une très bonne chose.
Il y a quelques exceptions, variables selon les pays.
En France, la plus connue est celle liée aux données de Santé. Il est obligatoire d’obtenir une certification HDS, Hébergement de Données de Santé, pour proposer des services dans ce domaine. Comme le montre cette liste officielle, publiée par le ministère de la Santé et de la Prévention, plusieurs centaines d’organisations sont certifiées HDS.
AWS, GCP et Azure font partie de cette liste, et cela ne surprendra personne.
Conséquence: Google est obligé d’utiliser les zones hébergées en France pour les données de santé et ne peut pas les porter sur des centres de calcul qu’il gère en direct.
Pour toutes les autres entreprises, le choix est libre, même s’il y a souvent des pressions politiques pour que l’hébergement ait lieu en France.
Si votre entreprise décide ou préfère héberger ses applications et ses données en France, elle a le choix entre des grands acteurs du Cloud Public, tous présents en France, ou des acteurs français eux aussi présents en France.
Si je fais le choix de travailler avec GCP pour tout ou partie de mes usages numériques, j’ai plusieurs options:
- Je choisis un “Edge” en France: si tous les services dont j’ai besoin sont disponibles dans cette zone, c’est une piste raisonnable.
- Je choisis une zone gérée directement par Google, par exemple en Belgique ou aux Pays-Bas. Je suis certain d’accéder à tous les services disponibles et à des infrastructures uniquement dédiées à GCP.
- Je choisis d’utiliser plusieurs zones pour mes usages. C’est une évidence pour les entreprises qui sont présentes à l’international.
Depuis peu, GCP propose aux entreprises un nouveau service: Cloud Region Picker.
Il permet de choisir la zone où elles peuvent exécuter leurs programmes en tenant compte du poids respectif que l’on donne à trois paramètres:
- L’impact carbone.
- Le coût.
- La latence.
Les réponses varient toutes les 5 minutes, en fonction des conditions météos des différentes zones et des taux d’utilisation des ressources.
Dans cet exemple, réalisé à Paris le 1er mai 2023 à 13h, j’ai regardé deux options. Dans les deux cas j’ai gardé une latence identique, à 50% d’importance:
- Option du haut: prix,critère essentiel. Impact carbone, critère pas important.
- Option du bas: prix, critère pas important. Impact carbone, critère essentiel.
Les résultats sont spectaculaires: GCP propose 4 zones pour chaque option, et ce sont au total 8 zones différentes qui sont proposées.
Je trouve cette initiative excellente et elle n’est disponible que chez les géants du Cloud Public, qui ont des installations dans le monde entier et peuvent faire profiter leurs clients de toutes les possibilités d’ensoleillement ou de vent.
C’est une excellente opportunité pour les entreprises de montrer concrètement qu’elles ont envie d’œuvrer pour une véritable frugalité numérique.
Reste une option que je n’ai pas encore abordée, le multi-cloud. Elle est recommandée par Alain Garnier dans la vidéo dont je parle au début.
Que faut-il en penser?
Multi Cloud et résilience
Une démarche Multi Cloud consiste à utiliser plusieurs fournisseurs différents de services Cloud pour son entreprise.
C’est une idée vieille comme le monde, celle qui consiste à ne pas mettre “tous ses œufs dans un même panier”.
Est-ce une bonne idée d’utiliser une démarche Multi Cloud pour améliorer la résilience de son Système d’Information en cas d’accidents comme l’incendie de Global Switch?
La réponse est claire: non, non et non!
Pourquoi? Imaginez que vous utilisez GCP pour votre application de gestion commerciale et que le site qui l’héberge prend feu. Combien de temps vous faudrait-il pour trouver une version de cette application compatible avec un autre Cloud comme AWS et l’y déployer? Poser la question, c’est y répondre.
Si la réponse Multi Cloud n’est pas la bonne, quelle démarche faut-il privilégier?
Elle est beaucoup plus simple, et je l’ai présentée dans ce billet: une démarche multi sites chez le même fournisseur de Cloud. Rien de plus simple! La réplication dans une autre zone géographique prendra instantanément le relais, sans aucun délai.
Ceci ne veut absolument pas dire que la démarche Multi Cloud n’a aucun intérêt, au contraire. La majorité des entreprises avec lesquelles je travaille ont choisi deux ou au maximum trois fournisseurs parmi AWS, GCP ou Azure.
Ce n’est jamais pour répondre à des problèmes de résilience.
Quelles sont les raisons qui militent pour le Multi Cloud?
- Résilience? Non.
- Services Clouds de base? Non. Tous les fournisseurs proposent des services de base en calcul, stockage, bases de données qui sont très proches les uns des autres.
- Services avancés différents? Oui. C’est de loin la raison principale. Chaque grand acteur a des domaines spécialisés pour lesquels il propose des services meilleurs que ses concurrents. C’est le cas avec AWS pour l’informatique industrielle et IoT. C’est le cas pour GCP dans le domaine du Big Data et du décisionnel.
- Faire jouer la concurrence entre les fournisseurs? C’est parfois le cas, mais moins souvent qu’on ne le croit.
Résumé
J’ai eu l’opportunité d’acquérir en France une formation d’ingénieur, qui m’a aidé à avoir des raisonnements scientifiques, rationnels et pragmatiques.
Ce texte ne parle que de la meilleure manière de garantir la fiabilité et la résilience de ses infrastructures dans des Clouds Publics, de garantir une continuité de services quand des catastrophes comme un incendie ou une erreur humaine se produisent, incidents qui sont inévitables.
Traiter les sujets importants, un par un, c’est la seule manière rationnelle de progresser que je connaisse.
Rappel: Il y a de nombreux autres sujets “chauds” quand on aborde le thème des Clouds Publics. Ils ne sont pas traités dans ce texte.
J’ai écrit des dizaines de billets sur mon blog qui parlent de toutes les autres facettes du Cloud Public, et ce depuis 15 ans.