Cloud
Quelles leçons les DSI doivent tirer de l’incident Global Switch ?
Par Laurent Delattre, publié le 03 mai 2023
Un incendie dans le datacenter Global Switch de Clichy la semaine dernière a fortement perturbé plusieurs hébergeurs dont Google Cloud. Un incident qui doit servir de piqure de rappel et alerter les DSI autour des fragilités du cloud et de la résilience des workloads qui y sont hébergés.
C’est une lapalissade. Plus il y a de datacenters dans le monde, plus les incidents qui les affectent sont nombreux… et visibles.
Après l’incendie en 2021 d’un datacenter d’OVH, l’incident qui a touché le datacenter de Clichy de Global Switch doit inviter les DSI à se repencher sur la réelle résilience de leurs opérations dans le cloud.
Pour rappel, le 27 avril dernier, une intrusion d’eau dans la salle des batteries du datacenter de Global Switch à Clichy a provoqué un incendie aux multiples répercussions. L’augmentation des températures a endommagé certains serveurs et conduit à l’extinction automatique d’autres. Or ce datacenter est l’un des plus importants de France. Il héberge notamment des fournisseurs comme Ecritel qui est lui-même l’hébergeur de sites comme « cybermalveillance.gouv.fr » ou « mailto ». Des sites officiels de Courbevoie, Lille, Saint-Brieuc, Cannes, du département de Saône-et-Loire ou encore de Lyon Aéroports se sont retrouvés indisponibles.
Google Cloud région France partiellement au tapis…
Mais l’incident a été d’autant plus visible que ce datacenter constitue aussi l’un des piliers de la zone France de Google Cloud. Cette « zone de disponibilité » est dispatchée entre 4 datacenters : Global Switch à Clichy, Interxion à La Courneuve, Telehouse à Paris et Data4 à Marcoussis. En théorie, la chute d’un datacenter doit avoir un impact limité sur les services de Google.
Mais entre la théorie et la pratique, il y a toujours un gouffre. Dit autrement, si toutes les instances des clients hébergés dans ce datacenter sont bien évidemment devenues indisponibles, plus de 90 services Google de la zone « europe-west9-a » ont également été affectés. Peu de temps après le début de la catastrophe, Google expliquait « nous prévoyons une indisponibilité générale de la région europe-west9. Il n’y a pas d’heure prévue pour la reprise des opérations dans la région europe-west9 à l’heure actuelle, mais on s’attend à une interruption prolongée. Il est conseillé aux clients de basculer vers d’autres régions s’ils sont touchés. »
Parmi les 90 services Google affectés on peut citer Anthos Service Mesh, Google Compute Engine, Google Kubernetes Engine, Cloud Memorystore, Google Cloud BigTable, Persistent Disk, Google Cloud SQL, Database Migration Service, Google Cloud Dataproc, Cloud Filestore. Que des services par nature hautement répartis et théoriquement résilients. Et nombre de ces services sont toujours en partie affectés une semaine après le drame.
Surtout, des clients comme la FinTech Payplug ont découvert, à cette occasion, que la résilience « multizonale » qu’ils pensaient avoir mise en place sur Google Cloud ne suffisait pas à assurer une vraie résilience de leurs services. Il est important d’ajouter que si les services ont été indisponibles, dans le cadre de cet incident, aucune donnée n’a été perdue.
À LIRE AUSSI :
Une résilience à construire soi-même
Comme pour tout service dont on dépend, le Cloud est une question de confiance. Mais c’est aussi une question de préparation et d’anticipation. Et dans le cloud, les dépendances sont souvent plus nombreuses qu’on ne l’imagine. Parce que votre fournisseur, même lorsqu’il s’appelle Google Cloud, est souvent (notamment en France) hébergé dans des datacenters qui ne sont pas les siens. Ces datacenters dépendent eux-mêmes de partenaires de colocation et d’interconnexion. Et cette chaîne de dépendance ne doit pas être négligée. Car sa résilience n’est jamais totale et surtout n’est pas assurée par défaut.
L’incident de Global Switch rappelle ainsi à tous les DSI que le Cloud – malgré les promesses marketing – n’est pas infaillible. Certes on peut bâtir sa résilience sur le cloud – ou plutôt les clouds – mais il faut… la construire. Elle ne s’hérite pas par magie. Il vient rappeler que le cloud n’est pas en soi une garantie de résilience, mais un moyen de l’atteindre. Et plusieurs leçons doivent en être tirées :
1. Le cloud peut tomber
Comme dans un avion, les incidents dans les grands clouds publics sont très nombreux mais passent souvent inaperçus parce que leur conception offre un certain niveau de résilience de base. Seuls les incidents majeurs ont des répercussions sur les clients (ils sont quand même moins catastrophiques que sur un avion). Et, il faut non seulement ne jamais perdre de vue qu’ils peuvent se produire à tout instant mais il faut aussi les anticiper.
2. La résilience du cloud public impose le multi-région
À l’instar de ce qu’a découvert la Fintech Payplug, avoir opté pour une résilience multizone du stockage ne suffit pas. Il faut adopter une approche multi-régionale globale et ne jamais perdre de vue que, tels que sont aujourd’hui conçus les Clouds publics (notamment sur une région comme la France où les opérateurs n’ont pas leurs propres datacenters), une région entière peut disparaître malgré l’utilisation de multiples datacenters. Il faut donc construire et imaginer les processus qui permettent de basculer sur une autre région dès qu’une région s’effondre. C’est la seule façon d’être résilient dans le cloud.
On notera que Google a un outil nommé Region Picker qui permet de choisir les régions de résilience les plus adaptées à vos contraintes techniques et réglementaires.
3. Le multicloud est une piste complexe à mettre en œuvre
Le multicloud est souvent présenté comme l’ultime forme de résilience : de même qu’on ne met jamais tous ses œufs dans un même panier, on ne met pas tous ses workloads dans un même cloud. C’est vrai quand on parle de workloads différents. C’est plus compliqué pour un même workload car cela suppose d’arriver à le rendre indépendant des services IaaS et PaaS des fournisseurs. Une opération pas infaisable mais chronophage et complexe, donc coûteuse. La complexité peut être en partie masquée en reposant sur Nutanix ou VMware et leurs solutions déployées presque identiquement sur les différents clouds. Du pur Kubernetes ou des solutions comme Azure Arc sont aussi des pistes à suivre, mais elles demandent des compétences particulières.
4. Il existe toujours des dépendances, même en multicloud
Il est très rare qu’un Workload ne dépende pas aujourd’hui d’un service de base de données (BigQuery par exemple), d’un service ML ou d’API IA propres à un cloud donné qui, quand il tombe, fait tomber tout le workload même si l’essentiel est hébergé dans un autre cloud. Dit autrement, il faut s’assurer de la résilience des dépendances pour assurer la résilience d’un Workload.
5. Tester sa résilience est compliqué mais nécessaire
La résilience (tout comme la restauration des backups), doit être testée régulièrement. D’autant que les univers cloud sont très dynamiques. Mais ces tests ne sont pas faciles à mettre en place. Tester l’indisponibilité d’une région et le basculement vers une autre est finalement aussi chronophage et complexe que de mettre en place le mécanisme. Il faut de l’organisation et de l’automatisation. Et s’inspirer des approches de « ingénierie du chaos ».
Bref, l’incident Global Switch ne doit pas interpeler que les clients de la région Paris de Google Cloud. Il doit interpeler tous ceux qui utilisent le Cloud, que celui-ci se nomme GCP, Azure, AWS, OVHcloud ou autre. Il doit inviter toutes les équipes à se réinterroger sur les procédures de résilience qui ont été imaginées, sur leur pertinence dans le cadre d’un évènement majeur comme celui de Global Switch, et sur les processus mis en place pour évaluer la résilience.
À LIRE AUSSI :
