L'incident GCP : L'importance de la topologie dans le cloud.
Tags: cloud, devops
Published: 2023-04-28 08:59:39

_Vous allez lire la première partie d’une série de 3 billets de blog qui se sert (sans remords) de l’actualité de Google Cloud Platform (GCP) pour vous parler des datacenters et de leur fonctionnement._

---

Avant de commencer à parler de la panne de GCP il est important de rappeler des termes de base, surtout pour ceux qui ne sont pas habitué (et même les autres) à créer des ressources dans le cloud. Les différents termes que vous allez souvent entendre quand un datacenter a une panne, ce sont :
- Région
- Zone
- Datacenter

Quand vous voulez mettre votre application dans le cloud, vous devez sélectionner la partie géographique où vos ressources vont être créées (_Pro tip, ne créez pas vos ressources en Asie, si vos utilisateurs sont en Europe_). Ces différentes zones géographiques sont donc des régions, Paris – France, est une des régions de GCP, elle est désignée comme europe-west 9, ce qui est beaucoup plus simple quand on est aussi doué en géographie que les Américains.

Les régions sont découpées en zones. Europe-west 9 a par exemple 3 zones (_Une région a entre 3 et 4 zones chez GCP, mais peut en avoir plus chez d'autre clodu provider_), Si vous avez une VM du coup, vous allez la déployer dans 1 des 3 zones possible.

Enfin on a le datacenter, c’est l’infrastructure physique qui contient les machines, lui vous ne le chosiez pas directement.

---

Et là, première question ou confusion assez fréquente.

> Est-ce que les zones, sont dans le même datacenter ?

Ça dépend, déjà des cloud provider, mais aussi des régions. Mais oui c’est possible.

Pour comprendre comment assurer la tolérance aux pannes d'une région avec un seul datacenter il faut aller voir comment le datacenter est organisé. Les datacenters peuvent être eux-mêmes séparés en cluster, ces clusters sont indépendants les uns des autres, ils ont leur propre infrastructure. Chaque cluster a donc son alimentation, son système de refroidissement, etc. Certain élément de l'infrastructure en revanche peuvent être transverse si on les considère comme très, très fiable et donc une panne sur un de ces éléments peut faire tomber tous vos clusters et votre région.

Maintenant quelle est la relation entre une zone et un cluster, de façon assez simple au départ, une zone = un cluster, donc un problème sur un cluster va avoir un impact sur une zone, mais pas une autre.

![Each zone has its own cluster with individual resources](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/gcuoc4tdmqw6uy195yhq.png)



Bien sûr, une zone peut être supportée par plusieurs clusters si nécessaire, on a une relation 1. * - 1.1, plusieurs clusters pour une zone, mais le cluster ne supporte qu'une zone.

![Two of the three zones have expanded and now have two clusters](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/cc9x7zdx1t5yj4i30m3j.png)


---

> Mais moi j'étais sûr qu'une zone était séparée par un nombre minimum de kilomètre pour éviter l'impact des catastrophes ?

En effet, la distance physique entre 2 zones est une bonne mesure de sécurité. C'est la façon de faire de AWS, pour qui une région est un cluster de datacenter et qui peuvent donc se permettre d'avoir des zones éloignées physiquement. Mais ce qui est fait chez Amazon ne l'est pas forcément fait par tous les cloud providers.

Pour résumer, oui avoir une application sur plusieurs zones, aide à la résilience de votre application quand une des zones à une panne. Cependant, une panne importante sur un même datacenter peut impacter plusieurs voir toutes les zones (donc la région) si le cloud provider n'as qu'un datacenter dans la région. D'où l'importance de bien choisir votre cloud provider et de comprendre l'implémentation physique. 

Pour éviter ce problème il faut faire en plus du multi-zone du multi-régions. Cela a quelques inconvénients. Déjà il faut que les services que vous utilisez soient disponibles sur d'autres régions, les services les plus courant le sont, mais certain ne sont pas disponible partout. Il faut aussi que votre application le supporte, enfin il faut avoir mis en place l'architecture et configurer les ressources, la réplication des données, les entrées DNS… Cela a aussi bien sûr un coût supplémentaire qu'il faut inclure. Finalement, il faut que vous puissiez légalement être présent dans d'autre zone.


![Highly available multi-region web application](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wrq5bfa7ixd2pvjjaac9.png)


A ne pas oublier aussi, il faut tester le failover de façon périodique pour s'assurer que tous fonctionnent le jour où vous en aurez besoin.

Et parce que tout est toujours possible, il se peut qu'un jour plusieurs régions soient impactées par une même panne. Des pannes complètes parce qu'un service clé du cloud provider se produit, n'est pas de la science-fiction.

En attendant la réplication interplanétaire opérationnel pour continuer votre business même en cas d'impact avec un météore, prévoyez si nécessaire le cas ou votre cloud provider sera indisponible

---

_Dans la seconde partie, nous parlerons des protections misent en place dans les datacenters pour se prémunir des catastrophes les plus courantes._