worth of juice, which meant the datacenter’s network gear had to go off-line well before its UPS systems were supposed to kick in. Over the course of the next 22 minutes, the datacenter’s network gear and servers were brought down, and the last of the equipment was powered down at 1209 UTC. Cloudflare’s plan was for its « single point of failure » (SPOF) back end to switch to its disaster recovery (DR) site, which it also has in the same city, but that failed to happen. The CDN provider’s DNS servers were able to detect the outage and reroute DNS requests away from the downed datacenter, but that didn’t help the company’s control plane, which at this point was entirely offline.’
Cloudflare a expliqué comment il pense avoir subi cette panne de plusieurs jours plus tôt. Le résumé est le suivant: un centre de données utilisé par Cloudflare a apparemment basculé sans avertissement, de deux sources d’alimentation électrique, à une source d’alimentation et des générateurs de secours, puis aux seules batteries de UPS, avant de ne plus rien avoir du tout, le tout en quelques heures et minutes. Cloudflare a ensuite découvert à ses dépens que ses plans de reprise après sinistre du centre de données vers d’autres installations ne fonctionnaient pas tout à fait comme prévu. Dans un rapport post-mortem après la panne, le PDG Matthew Prince a présenté la panne, qui a duré du 2 novembre à 11h43 UTC au 4 novembre à 04h25 UTC, du point de vue de son entreprise de CDN. Pendant la panne du matériel informatique, non seulement les services d’analyse de Cloudflare ont été perturbés ou indisponibles, notamment la journalisation, mais aussi le plan de contrôle; c’est l’interface client de tous ses services. On nous a dit que le plan de contrôle avait été restauré pour la plupart à 17h57 UTC le jeudi en utilisant une installation de secours. Le réseau principal et les fonctions de sécurité de Cloudflare ont continué à fonctionner normalement pendant toute la panne, même si les clients ne pouvaient pas modifier leurs services à certains moments, a déclaré Prince. En réalité, les batteries ont commencé à faiblir après seulement quatre minutes d’autonomie, ce qui signifie que le matériel de réseau du centre de données a dû être mis hors ligne bien avant que ses systèmes UPS ne entrent en action. Au cours des 22 minutes suivantes, le matériel de réseau et les serveurs du centre de données ont été éteints, et le dernier équipement a été mis hors tension à 12h09 UTC. Le plan de Cloudflare était que son backend « single point of failure » (SPOF) bascule vers son site de reprise après sinistre (DR), qu’il a également dans la même ville, mais cela n’a pas fonctionné. Les serveurs DNS de Cloudflare ont pu détecter la panne et rediriger les requêtes DNS away du centre de données hors service, mais cela n’a pas aidé le plan de contrôle de l’entreprise, qui à ce stade était entièrement hors ligne.
