Voici une publication que je n'aurais jamais imaginé devoir écrire : moins de cinq mois après une coupure de courant dans l'un de nos principaux datacenters, l'incident s'est produit une nouvelle fois, précisément dans le même datacenter. C'est nul, et si vous vous demandez « Mais pourquoi continuent-ils à utiliser ce datacenter ? », je ne vous en voudrai pas. Nous nous posons la même question. Toutefois, voici le problème : au cours de ces cinq mois passés, si peu de choses ont changé dans ce datacenter, beaucoup de choses ont changé chez Cloudflare. Et, alors qu'il y a cinq mois de cela, l'arrêt d'un datacenter essentiel était vraiment problématique, cette fois, ça n'était pas le cas.
Cet article explique, dans les grandes lignes, comment un datacenter à haute disponibilité a subi une coupure de courant pour la deuxième fois en cinq mois. Mais surtout, c'est le récit de la façon dont notre équipe a travaillé pour s'assurer que même si l'un de nos datacenters essentiels venait à subir une perte de courant, cela n'affecterait pas nos clients.
Le 2 novembre 2023, un de nos sites essentiels dans la région de Portland (Oregon, États-Unis), a subi une coupure de courant prolongée. L'incident s'est produit à la suite d'une série de défaillances en cascade, qui semblent avoir été causées par des opérations de maintenance réalisées par l'exploitant du réseau électrique, et ont entraîné un défaut de terre dans l'installation. La situation a ensuite été aggravée par une série d'incidents malheureux qui ont empêché le rétablissement du fonctionnement du site en temps opportun.
Si vous souhaitez lire tous les détails croustillants sur l'incident, vous pouvez les consulter ici.
C'est une situation très problématique lorsqu'un datacenter subit une perte de courant totale, toutefois, c'est une situation à laquelle nous étions censés nous attendre. Malheureusement, malgré ces attentes, nous n'avions pas appliqué, à nos produits, un certain nombre d'exigences qui auraient permis de garantir la continuité de leur fonctionnement, en dépit d'une panne majeure.
C'était une erreur, et nous ne nous permettrions plus jamais de la commettre.
Code Orange
L'incident a été suffisamment problématique pour que nous déclarions ce que nous avons appelé un incident « Code Orange ». Nous avons emprunté l'idée à Google qui, lorsque son activité est affectée par une menace existentielle, déclare un incident « Code Yellow » ou « Code Red », Et puisque notre logo est orange, nous avons légèrement modifié la formule.
Dans notre vision d'un Code Orange, la personne qui a supervisé l'incident (dans ce cas précis, notre SVP of Technical Operations, Jeremy Harman) serait habilitée à assigner n'importe quel technicien de notre équipe à ce qu'il considérait être le projet le plus prioritaire (à moins que nous ne déclarions entre-temps un Code Red, ce que nous avons fini par faire en raison d'un incident de piratage, et dont la priorité serait encore plus élevée. Si cela vous intéresse, vous pouvez en apprendre davantage à ce sujet ici).
Après avoir remédié aux aspects les plus urgents de l'incident, Jeremy a rapidement trié les tâches les plus importantes à accomplir afin de veiller à préserver notre disponibilité élevée, même en cas de nouvelle défaillance catastrophique d'un datacenter principal. Et l'équipe s'est mise au travail.
Comment nous sommes-nous débrouillés ?
Nous ne nous attendions pas à subir un test réel aussi approfondi et rapide, mais les voies de l'univers sont impénétrables. Le mardi 26 mars, soit à peine cinq mois après l'incident initial, le même site a subi une autre panne de courant de grande ampleur. Nous examinerons ci-dessous les raisons de cette nouvelle panne, mais le plus important, c'est qu'elle a constitué un test parfait pour le travail accompli par notre équipe dans le cadre de l'incident Code Orange. Alors, quels ont été les résultats ?
Pour commencer, revoyons les fonctions assurées par les datacenters de Cloudflare à Portland. Comme nous l'avons décrit dans l'article publié le 2 novembre, le plan de contrôle de Cloudflare est principalement constitué de l'interface utilisateur qui permet à nos clients de piloter l'ensemble de nos services, parmi lesquels notre site web et notre API. En outre, les services sous-jacents qui fournissent les pipelines d'analyse de données et de journalisation sont principalement servis depuis ces installations.
Comme en novembre, nous avons immédiatement été alertés au sujet de la perte de connectivité avec notre datacenter PDX01. Contrairement au mois de novembre, en revanche, nous avons très rapidement su avec certitude que notre datacenter avait subi une panne de courant totale, ce qui nous a placés exactement dans la même situation que cinq mois auparavant. Après un test de coupure interne réalisé au mois de février, nous savions également de quelle manière nos systèmes devaient réagir. Nous avions passé des mois à nous préparer, à mettre à jour d'innombrables systèmes et à activer d'immenses volumes de capacité réseau et de serveurs. L'aboutissement de tout cela a été un test visant à prouver que le travail que nous avions accompli avait l'effet escompté, à savoir assurer un basculement automatique vers les installations redondantes.
Notre plan de contrôle se compose de centaines de services internes et notre objectif est qu'en cas de perte de connectivité avec l'un des trois datacenters essentiels de Portland, ces services continuent de fonctionner normalement dans les deux installations restantes, et que nous continuons à opérer principalement depuis Portland. Nous disposons de la capacité d'effectuer un basculement vers nos datacenters européens, au cas où nos datacenters à Portland deviendraient complètement indisponibles. Il s'agit toutefois d'un objectif secondaire, et ce n'est pas une chose à laquelle nous aspirons dans l'immédiat.
Le 26 mars 2024, à 14h58 UTC, le datacenter PDX01 a subi une panne de courant et nos systèmes ont commencé à réagir. À 15h05 UTC, nos API et nos tableaux de bord fonctionnaient normalement, sans intervention humaine. Au cours de ces derniers mois, notre objectif principal a été de nous assurer que nos clients soient toujours en mesure de configurer et d'utiliser leur service Cloudflare en cas de panne similaire. Certains services spécifiques ont nécessité une intervention humaine, et leur rétablissement a donc demandé un peu plus de temps, mais le mécanisme d'interface principal fonctionnait comme prévu.
Pour mieux détailler ce propos, lors de l'incident du 2 novembre 2023, le plan de contrôle des services suivants est devenu indisponible pendant au moins six heures, et plusieurs services ont été fonctionnellement impactés pendant plusieurs jours.
API et tableau de bord
Zero Trust
Magic Transit
SSL
SSL for SaaS
Workers
KV
Waiting Room
Équilibrage de charge
Passerelle Zero Trust
Access
Pages
Stream
Images
Lors de l'incident du 26 mars 2024, tous ces services étaient opérationnels quelques minutes seulement après la coupure de courant, et pour beaucoup d'entre eux, aucun effet préjudiciable n'a été observé pendant le basculement.
Le plan de données, qui gère le trafic que les clients de Cloudflare acheminent à travers nos quelque 300 datacenters, n'a pas été affecté.
Notre plateforme d'analyses de données, qui offre une vue sur le trafic des clients, a été affectée, et son fonctionnement n'a été entièrement rétabli que plus tard dans la journée. Il s'agissait d'un comportement attendu, car la plateforme d'analyses de données dépend du datacenter PDX01. À l'instar du plan de contrôle, nous avons commencé à développer une nouvelle capacité de fourniture de services d'analyses de données immédiatement après l'incident du 2 novembre 2023. Toutefois, en raison de l'ampleur des travaux, sa mise en œuvre demande un peu plus de temps. Nous avons travaillé aussi rapidement que possible pour supprimer cette dépendance, et nous prévoyons de finaliser ce travail dans un avenir proche.
Après avoir validé la fonctionnalité des services de notre plan de contrôle, nous devions, une fois encore, gérer la complexité du démarrage à froid d'un très grand datacenter. Cette activité avait demandé environ 72 heures en novembre, mais cette fois, nous sommes parvenus à la réaliser en 10 heures environ. Il reste encore du travail à accomplir pour accélérer encore ce processus à l'avenir, et nous allons continuer à affiner nos procédures, au cas où un incident similaire se reproduirait.
Comment en sommes-nous arrivés là ?
Comme nous l'avons mentionné plus haut, la panne de courant survenue en novembre dernier nous a conduits à inaugurer Code Orange, une procédure qui nous permet de réorienter la plupart, voire l'ensemble de nos ressources techniques afin de résoudre le problème en cours en cas de crise ou d'incident important. Au cours des cinq derniers mois, nous avons réorienté l'ensemble des fonctions techniques non essentielles afin de prioriser l'assurance de la fiabilité de notre plan de contrôle.
Les équipes de tous nos services techniques ont travaillé ensemble afin d'assurer qu'à l'avenir, nos systèmes seraient plus résilients face à une défaillance similaire. Bien que l'incident du 26 mars ait été inattendu, il s'agissait d'un événement auquel nous nous étions préparés.
La différence la plus manifeste est la vitesse à laquelle les services du plan de contrôle et des API ont été rétablis. En l'absence de toute intervention humaine, il est redevenu possible de se connecter à Cloudflare et d'apporter des modifications à la configuration de la plateforme dans un délai de sept minutes après l'interruption de la connectivité avec PDX01. Cette efficacité était imputable aux efforts que nous avions réalisés pour déplacer toutes nos bases de données de configuration vers une topologie hautement disponible (HA, High Availability) et pré-provisionner une capacité suffisante pour absorber la perte de capacité. Plus de 100 bases de données présentes dans plus de 20 clusters de bases de données différents se sont simultanément déconnectées de l'installation affectée et ont assuré le rétablissement automatique des services. Il s'agissait en réalité de l'aboutissement de plus d'une année de travail, et nous réalisons désormais des tests hebdomadaires afin de pouvoir démontrer notre capacité à assurer un basculement efficace.
Les mises à jour de notre infrastructure Logpush constituent une autre amélioration significative. En novembre, l'arrêt du datacenter PDX01 nous a empêchés de transmettre les journaux à nos clients. Pendant l'événement Code Orange, nous avons investi dans le déploiement en disponibilité générale de l'infrastructure Logpush à haute disponibilité à Portland, et nous avons également créé une option de basculement actif à Amsterdam. Logpush a tiré parti de notre cluster Kubernetes massivement développé, qui couvre l'ensemble de nos installations à Portland et permet aux propriétaires de services de déployer avec fluidité des services haute disponibilité avec une résilience intégrée. En réalité, pendant notre exercice de simulation de chaos en février, nous avions identifié une faille dans notre déploiement haute disponibilité à Portland ; toutefois, les clients n'avaient pas été affectés, car l'infrastructure Logpush située à Amsterdam avait efficacement pris le relais. Pendant cet événement, nous avons constaté que les correctifs que nous avions appliqués depuis étaient efficaces, et nous avons pu transférer les journaux depuis la région de Portland.
Un certain nombre d'autres améliorations apportées à nos produits Stream et Zero Trust ont permis de limiter, voire d'annuler complètement l'impact de l'incident sur leur fonctionnement. Nos produits Stream, qui consomment une grande quantité de ressources informatiques pour assurer le transcodage de vidéos, ont pu être transférés avec fluidité vers notre installation d'Amsterdam, afin d'assurer la continuité des opérations. Des objectifs de disponibilité spécifiques aux services ont été assignés aux équipes, qui disposaient de différentes options pour les atteindre. Stream est un bon exemple d'un service qui a opté pour une architecture de résilience différente, mais a néanmoins été en mesure de remplir son rôle avec fluidité pendant cette panne. La vaste majorité des fonctionnalités de la solution de sécurité Zero Trust, qui avait également été affectée en novembre, a depuis été transférée vers nos centaines de datacenters, qui ont continué à fonctionner sans interruption pendant l'événement. En fin de compte, c'est la stratégie que nous incitons l'ensemble des produits Cloudflare à adopter, car nos plus de 300 datacenters offrent le niveau de disponibilité le plus élevé qui soit.
Qu'est-il arrivé à l'alimentation électrique au sein du datacenter ?
Le 26 mars 2024, à 14h58 UTC, PDX01 a subi une coupure de courant totale au sein de l'infrastructure physique de Cloudflare, apparemment à la suite d'une défaillance simultanée de quatre tableaux de commutateurs détenus et exploités par Flexential, desservant l'ensemble des cages de Cloudflare. Cet incident a entraîné la désactivation des voies d'alimentation principales et redondantes dans l'ensemble de l'environnement. Pendant leur enquête, les ingénieurs de Flextential se sont concentrés sur un ensemble d'équipements appelés « tableaux de contrôle de circuit ». Les tableaux de contrôle de circuit sont semblables à un tableau électrique, constitué d'un coupe-circuit d'entrée principal et d'un ensemble de coupe-circuits de sortie, plus petits. Les ingénieurs de Flexential ont indiqué que l'infrastructure en amont des tableaux de contrôle de circuit (alimentation électrique, générateur, système d'alimentation sans coupure et unité de distribution d'énergie/transformateur) n'était pas affectée et continuait à fonctionner normalement. De même, l'infrastructure en aval des tableaux de contrôle de circuit, à l'image des tableaux de téléalimentation et des commutateurs connectés, n'était pas affectée, ce qui implique que la panne était isolée au niveau des tableaux de contrôle eux-mêmes.
L'évaluation initiale de la cause fondamentale des défaillances des tableaux de contrôle de circuit de Flexential a notamment révélé que la configuration incorrecte des paramètres de coordination des coupe-circuits au sein des tableaux de contrôle de circuit était l'un des facteurs ayant contribué à l'incident. Des réglages de déclenchement trop restrictifs peuvent entraîner une protection trop sensible contre les surintensités et, éventuellement, provoquer des déclenchements intempestifs des équipements. Dans notre cas, le réglage des coupe-circuits de Flexential au sein des quatre tableaux de contrôle de circuit était censément trop bas par rapport aux capacités électriques provisionnées en aval. Lorsqu'un ou plusieurs de ces coupe-circuits se sont déclenchés, une défaillance en cascade des autres tableaux de contrôle de circuit actifs s'est produite, entraînant une coupure totale de l'alimentation servant la cage de Cloudflare et d'autres cages également au sein de l'infrastructure partagée. Pendant le triage de l'incident, nous avons été informés que l'équipe responsable des installations de Flexential avait remarqué des paramètres de déclenchement incorrects, réinitialisé les tableaux de contrôle de circuit et les avait réglés aux valeurs attendues, ce qui a permis à notre équipe de démarrer nos serveurs de manière échelonnée et contrôlée. Nous ne savons pas quand ces paramètres ont été configurés ; en règle générale, ils sont configurés/ajustés lors de la procédure de mise en service d'un datacenter et/ou d'une étude de coordination des coupe-circuits, préalablement à l'installation des charges critiques du client.
Et ensuite ?
Notre priorité absolue est de finaliser le programme de résilience de notre plateforme d'analyses de données. Les analyses de données sont plus que de simples jolis diagrammes affichés sur un tableau de bord. Si vous voulez consulter des informations sur le déroulement d'une attaque, les activités actuellement bloquées par un pare-feu ou même de l'état de Cloudflare Tunnel, vous avez besoin d'analyses de données. Nous avons la preuve que le modèle de résilience que nous adoptons fonctionne comme prévu ; cela demeure donc notre priorité absolue, et nous avons l'intention de continuer à le faire progresser aussi rapidement que possible.
Le redémarrage efficace de certains services nécessitait encore une intervention manuelle, et nous avons collecté des données et des informations exploitables pour chacun d'eux, afin de nous assurer qu'aucune action manuelle supplémentaire n'était nécessaire. Nous continuerons à réaliser des tests de coupure en production, afin de démontrer que l'ensemble de ces modifications et améliorations offrent la résilience attendue par nos clients.
Nous continuerons à travailler avec Flextential dans le cadre d'activités de suivi, afin d'élargir au maximum notre compréhension des procédures opérationnelles et d'évaluation du fournisseur. Bien que cet incident ait été limité à une seule installation, nous allons transformer cet exercice en un processus qui nous permettra d'obtenir une vision similaire de tous nos sites de datacenters essentiels.
Une fois encore, nous sommes vraiment désolés pour les répercussions sur nos clients, en particulier ceux qui dépendent d'Analytics Engine et n'ont pas pu accéder aux fonctionnalités du produit pendant l'incident. Notre travail au cours des quatre mois passés a produit les résultats attendus, et nous resterons absolument concentrés sur l'achèvement du travail restant.