Ce Datacenter est une des trois AZ utilisée par T-Cloud Public dans la région NL. Donc techniquement la destruction d’un Datacenter n’empêche pas le fonctionnement du Cloud mais l’arrêt électrique d’un Datacenter impose une reconfiguration des services Cloud (console, API) qui a pris quelques heures.
Les serveurs qui fonctionnaient sur les 2 AZ non touchés ont continué de fonctionner sans souci. Mais la console du Cloud et les API n’étaient plus disponibles.
Donc pour les serveurs qui sont dans le Datacenter arrêté, il a fallu attendre le retour de la console et des API pour reconstruire les serveurs impactés sur les 2 AZ non touchées.
Les impacts sur Nuabee et le redémarrage des services
Nous avons des remontées d’erreurs à 9h52 alors que notre industrialisation termine la préparation d’un test de PRA d’un client pour 14h. Nous allons voir à 10 heures le statut de T-Cloud Public et il est indiqué qu’un incident majeur a lieu. Nous recevons également un mail à 10h45 de notre SDM nous indiquant que le Datacenter est en feu.
Nous organisons une réunion de la cellule de crise à 11h30
Nous faisons une analyse de l’infrastucture Nuabee impactée par l’arrêt de cette AZ : environ 10 VM impactées que nous devons migrer vers une autre AZ. Mais pour l’instant les API / la CLI, nous permettant d’activer notre PRA interne, ne sont pas rétablies.
Le stockage des sauvegardes des clients n’est pas du tout impacté car il est redondé sur 3 AZ (et l’incendie ayant démarré le matin, cela n’a pas perturbé la réalisation des sauvegardes de la veille).
Les API Cloud seront rétablies à 13h10, le PRA interne Nuabee est lancé.
Le serveur le plus critique qui héberge notre Vault est restauré vers le nouvel AZ dans l’heure
Le reste suit sous les 2 heures
Vers 17h, nous analysons la situation :
Les serveurs critiques pour notre industrialisation sont remontés
Il reste des serveurs importants (tickets, syslogs, orchestrateur) qui ne sont pas remontés car ils étaient en classe de Backup avec test
Nous décidons de les relancer et nous détectons quelques erreurs de redémarrage
Les derniers serveurs sont redémarrés vers 21h (sauf le serveur Web Nuabee qui attendra lundi matin)
Retour d’expérience
Nous organisons régulièrement des test de PRA interne sur notre infrastructure interne “On-prem”. Nous faisions moins de tests spécifiques sur notre infra Cloud car la résilience d’un Cloud public est importante.
Néanmoins l’incendie d’un Datacenter (AZ) nous a démontré :
Qu’il fallait intégrer ce scénario de risques dans nos tests même si deux autres AZ restaient “disponibles” mais provisoirement non accessibles via la console Cloud et les API
Que nous allions rajouter des serveurs dans la classe PRA (gestion des tickets, reverse proxy, syslogs, serveurs web …)
Qu’il fallait certainement mettre en place une solution pour basculer rapidement vers une autre région (Allemagne) et savoir lancer automatiquement un PRA client depuis cette région.
