Panne de l’API Cloudflare
(news.ycombinator.com)- Les incidents affectant le Dashboard et l’API de Cloudflare ont été résolus après le basculement de l’API du Control Plane et des services produits vers le principal datacenter de Portland
- Des échecs de requêtes et affichages d’erreurs ont pu se produire sur les fonctions du Dashboard, les Alerts, Zero Trust, WARP, Pages, Workers, etc., qui dépendaient de l’infrastructure API
- Cloudflare a évalué une perte d’alimentation électrique dans le datacenter et a procédé à un failover ; après une restauration partielle de l’électricité dans un datacenter clé d’Amérique du Nord, les services critiques ont été transférés vers un datacenter de secours afin de réduire l’impact
- L’impact a été séparé entre data plane et control plane, et Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream, DNS Updates, etc. sont passés selon les moments par les états unavailable, degraded et restored
- Une partie des logs Logpush et des données d’analyse a été perdue pendant l’incident ; les logs de fin d’incident pouvaient peut-être être récupérés, mais l’étendue complète de l’impact n’était pas encore confirmée pendant l’événement
Étendue de l’incident sur le Dashboard et l’API
- Cloudflare a enquêté sur et restauré les problèmes liés au Cloudflare Dashboard et aux API associées ; les utilisateurs ont pu rencontrer des échecs de requêtes Dashboard/API ou des affichages d’erreurs
- L’incident s’est étendu à plusieurs services dépendant de l’infrastructure API de Cloudflare
- Alerts
- Fonctionnalités du Dashboard
- Zero Trust
- WARP
- Cloudflared
- Waiting Room
- Gateway
- Stream
- Magic WAN
- API Shield
- Pages
- Workers
- Cloudflare a précisé que ce problème n’affectait ni la distribution de fichiers en cache par le CDN Cloudflare, ni les autres fonctions de sécurité de Cloudflare Edge
Failover après la perte d’alimentation et restauration à Portland
- Cloudflare a procédé au failover tout en évaluant la perte d’alimentation électrique ayant affecté le datacenter
- Après une restauration partielle de l’électricité dans un datacenter clé d’Amérique du Nord, certains services critiques ont basculé vers un datacenter de secours, ce qui a réduit l’impact
- Au cours de la restauration, plusieurs mises à jour ont répété les états « gradual improvement » et « restore full functionality »
- Dans la dernière phase, l’API du Control Plane et les services produits ont été renvoyés vers le principal datacenter de Portland
- À partir du 2023-11-06 17:00 UTC, la restauration de l’API du Control Plane et des Product Services a commencé vers les primary HA datacenters de Portland
- La durée des travaux était annoncée à environ 2 heures, durant lesquelles la disponibilité de l’API Cloudflare et du Dashboard pouvait être dégradée
- À partir du 2023-11-06 18:30 UTC, les API du Control Plane et Product Services de Pages et Workers ont également commencé à être restaurées vers le principal datacenter de Portland
- Même après la fin de la restauration, Cloudflare a continué à surveiller la stabilité et les edge cases
Fonctions perturbées sur le data plane
- L’impact sur le data plane est défini comme le périmètre dans lequel la fonctionnalité complète des produits a subi un impact partiel ou total
- Les services initialement affectés comprenaient Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API et Alert Notification System
- Les principaux services dont l’état a changé pendant la restauration sont les suivants
- Logpush : de nombreux clients n’ont pas reçu leurs logs, et une partie des logs a pu être perdue. Par la suite, davantage de jobs ont été rétablis, et la majorité d’entre eux devait être restaurée d’ici 07:00 UTC
- Analytics / GraphQL API : les analytics data de nombreux clients étaient unavailable dans le Dashboard et l’API ; ensuite, une partie ou la majorité des analytics a été restaurée, mais certains datasets restaient affectés
- Workers Analytics Engine : est resté unavailable dans plusieurs mises à jour
- Stream API : est passé de not available à degraded performance but available, puis à restored
- Healthchecks : est passé de not available à restored sans analytics, puis les Healthcheck analytics ont elles aussi été restored
- Radar : est resté en état degraded avant que Cloudflare Radar ne revienne à un statut operational
- Support Services : pendant que le portail de support était unavailable, les clients Enterprise pouvaient ouvrir un ticket via l’adresse email du support Enterprise ; ensuite, le Portal, le Phone et le Chat sont redevenus operational
- CASB : était en état not available ou degraded performance ; les CASB Findings existants restaient visibles, mais le scanning était offline. Ensuite, l’API CASB est revenue online, le moteur de scanning était en cours de restauration et aucune perte de données n’était attendue
- DEX : est passé de not available à une API DEX online ; les données fleet status, HTTP et Traceroute Test Result étaient en cours de restauration, avec un retour attendu autour du Saturday Nov 4 15:00 UTC
- DNS Updates : est passé de degraded à restored
Changements de configuration limités sur le control plane
- L’impact sur le control plane est défini comme le périmètre dans lequel les fonctions du produit continuent à fonctionner à l’edge, mais où les modifications de configuration existantes sont affectées
- Les services initialement affectés comprenaient Magic Transit, Argo Smart Routing, Workers KV, WAF, Rate Limiting, Rules, WARP/Zero Trust Registration, Waiting Room, Load Balancing and Healthchecks, Cloudflare Pages, Zero Trust Gateway, DNS Authoritative and Secondary, Cloudflare Tunnel, Workers KV namespace operations, Magic WAN et Cloudflare Images
- Les principaux services dont l’état a changé pendant la restauration sont les suivants
- Cloudflare API : a été mise à jour vers degraded but accessible ou restored
- Cloudflare Pages : est passé de degraded but online à restored ; pendant un temps, la création/suppression de projets et les direct upload deployments sont restés en état degraded
- Magic Transit / Magic WAN : sont passés d’un état où les changements étaient impossibles à un état où le configuration plane fonctionnait en interne ; pour les changements urgents, il était demandé de contacter l’account team
- Argo Smart Routing : la configuration fonctionnait, mais les smart updates et les analytics étaient offline
- Billing API / Registrar API : seules les opérations en lecture seule ont été possibles pendant un certain temps
- Lists : la mise à jour des éléments de liste a été temporairement suspendue ; cela fonctionnait dans le Dashboard, mais l’API pouvait renvoyer une erreur 429. Ensuite, le statut est passé à restored, mais les modifications n’étaient encore possibles que via le Dashboard pendant un temps
- SSL / SSL for SaaS : il y a eu des retards de provisioning SSL et de validation de custom hostname, puis le statut est passé à restored
- Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security, Direct Upload Deployments sont aussi passés, selon les mises à jour, par les états degraded, unavailable et restored
Logs perdus et analyse post-incident
- Cloudflare a indiqué qu’une partie des logs Logpush et des analytics data avait été perdue pendant l’incident
- Les logs proches de la fin de l’incident pouvaient éventuellement être récupérés, mais l’étendue complète de l’impact n’était pas encore connue pendant l’événement
- Une mise à jour indiquait que tous les pipelines de logs et d’analytics seraient operational d’ici Saturday 4th November 2023 7AM UTC
- Des mises à jour ultérieures ont indiqué que « la majorité des logs a été perdue pendant l’incident », et qu’une évaluation complète serait fournie après la résolution
- Plus de détails sont disponibles dans le post-mortem on Cloudflare control plane and analytics outage de Cloudflare
1 commentaires
Avis sur Hacker News
Quand j’y travaillais il y a un peu plus de 3 ans, l’architecture faisait que si PDX tombait, le système central tombait aussi
Des choses comme la protection DDoS étaient déjà traitées dans chaque PoP, donc les floods L3/L7 ou les nouvelles attaques passaient bien, mais pour presque tout le reste, les calculs étaient faits à PDX puis déployés sous forme de données de configuration vers chaque PoP
Le flux était : génération/collecte des données par les PoP → envoi vers PDX → calcul à PDX → distribution des mises à jour/données vers les PoP, et si PDX mourait, beaucoup de fonctions dépendant de données récentes continuaient à tourner dans un état de plus en plus obsolète
Je ne pense pas que tout ait changé depuis, donc plutôt qu’une simple « API down », il est probable qu’il s’agisse d’un état dégradé où des fonctions comme l’équilibrage de charge, le cache hiérarchique, Argo Smart Routing, Warp/Zero Trust tournent avec des informations d’état périmées faute de mises à jour depuis PDX
Même si ce n’était « qu’une API down », beaucoup d’automatisations clients bloquent les attaques via des appels API, ce qui ouvre une fenêtre d’opportunité assez importante pour les attaquants
Juste avant mon départ, il y avait des investissements pour mettre en place AMS, mais les gros tests de bascule n’avaient jamais réussi, et la plupart des services ayant besoin d’un état à jour ne connaissaient pas ce mécanisme
À noter aussi que la majeure partie de l’observabilité reposait sur PDX, donc soutien aux équipes et aux SRE qui doivent courir à l’aveugle en ce moment
Cloudflare a indiqué qu’ils évaluaient une perte d’alimentation ayant touché le datacenter tout en procédant au basculement des services
Le courant du réseau public a été coupé, ils sont passés sur générateur, mais le générateur a lui aussi échoué, et une partie de l’alimentation publique étant revenue, une restauration partielle du site semble en cours
https://puck.nether.net/pipermail/outages/2023-November/0149...
Cela dit, il y a toujours un écart entre l’intention et la réalité, et j’avais entendu plusieurs raisons pour lesquelles un basculement automatique, ou manuel en urgence, vers un datacenter à l’autre bout du globe n’était pas une solution réaliste pour beaucoup de workloads
Cloudflare fait beaucoup de chaos testing et teste aussi très régulièrement l’isolement réseau complet de datacenters entiers
J’aimerais bien me glisser discrètement dans la réunion où ils discutent de pourquoi cet incident a été si différent
Je n’en ai construit directement qu’une des deux, mais le marketing les regroupait toujours
À moins d’être un client enterprise qui personnalise la topologie de cache hiérarchique via API, une topologie de cache vieille de quelques jours ou quelques semaines devrait généralement rester acceptable
Mais comme je l’ai dit, beaucoup d’autres choses peuvent avoir des problèmes
Même avec une maintenance et une planification excellentes, la probabilité n’est jamais nulle qu’une condition imprévue, ou contre laquelle on n’a pas pu se prémunir pour des raisons de coût, fasse tomber l’infrastructure critique
L’interface du tableau de bord semble utiliser l’API pour les mises à jour, donc c’est probablement lié à la dégradation de l’accès API
Même si l’UI donnait l’impression que les mises à jour DNS avaient été prises en compte, elles n’étaient pas réellement propagées, et après l’incident il a fallu supprimer entièrement le domaine depuis le tableau de bord Cloudflare puis le recréer pour que SSL et la propagation DNS refonctionnent
12 heures ont passé et le problème continue toujours
Je suis un cours en ligne de production musicale, les vidéos sont hébergées sur Cloudflare Stream et aucune ne se lance
https://www.cloudflare.com/products/cloudflare-stream/
Le problème du point de défaillance unique pour la moitié d’Internet revient encore une fois sur le devant de la scène
https://www.cloudflarestatus.com/incidents/hm7491k53ppg
Je pensais que cela n’affectait que le tableau de bord et les fonctions à l’intérieur du tableau de bord, mais si le streaming vidéo de Cloudflare ne fonctionne pas, j’imagine que ce n’est pas le cas
Je ne sais pas trop, mais Cloudflare me met un peu mal à l’aise
Je ne comprends pas pourquoi autant de gens trouvent acceptable de laisser une seule entreprise concentrer une si grande partie d’Internet
Je me trompe peut-être, mais Cloudflare ressemble à un challenger crédible face aux énormes entreprises en situation d’oligopole, et j’aimerais qu’il y ait plus de Cloudflare
En pratique, je ne connais pas vraiment de service comparable offrant un niveau gratuit aussi généreux que Cloudflare
Quand TLS est utilisé correctement, il fournit une sécurité de bout en bout, mais avec Cloudflare, Cloudflare peut accéder à tout le trafic en clair
Si un petit site risque d’être la cible d’un DoS, il finit par devoir utiliser Cloudflare
C’est mon impression personnelle, et je peux me tromper
Je me demandais s’ils avaient recommité ce bug d’il y a quelques jours
https://blog.cloudflare.com/cloudflare-incident-on-october-3...
En fait non, ça ressemble à une panne électrique dans un datacenter central
Les détails sont dans d’autres commentaires
À ce stade, je me surprends à apprécier les pannes comme le chien de Pavlov
C’est déjà la deuxième panne rien que cette semaine
Pour répondre à un commentaire enterré, ça n’a absolument rien à voir avec le choix du langage de programmation
DreamHost a aussi des problèmes à PDX depuis 4 h 54, heure du Pacifique
https://www.dreamhoststatus.com
Il a été signalé que Flexential PDX02 a perdu l’alimentation à peu près au moment où tout cela a commencé
Cloudflare vient d’annoncer qu’ils évaluent une perte d’alimentation ayant affecté le datacenter tout en menant en parallèle les opérations de bascule pour l’interruption de service
Chez nous, Flexential a 5 générateurs, des batteries de secours en sous-sol et des zones d’isolement
Le plus impressionnant, c’est que la page de statut fonctionne réellement
Bien sûr, elle est probablement hébergée ailleurs, mais à chaque grosse panne j’ai toujours la même pensée et ça me fait rire
Ça n’a pas l’air très bon
J’espère que cet incident ne va pas les pousser à abandonner le dogfooding
Les déploiements Vercel et les edge functions en général ne fonctionnent pas non plus
La page de statut indique qu’« un problème chez l’un de nos fournisseurs en amont a été identifié comme cause racine, et nous collaborons avec lui pour atténuer l’impact »
Je me demande si les edge functions utilisent Workers en interne
Lien : https://www.vercel-status.com/
Un autre lien dans ce même fil indique que Flexential PDX02 a perdu l’alimentation au même moment
Le courant du réseau a été coupé, ils sont passés sur générateurs, mais les générateurs ont aussi échoué ; une partie du courant du réseau semble être revenue et une restauration partielle du site serait en cours
On dirait que tout le datacenter est tombé, et que le failover de Cloudflare n’a pas été aussi fluide qu’espéré
https://puck.nether.net/pipermail/outages/2023-November/0149...
Je ne sais pas s’il faut trouver rassurant ou inquiétant le fait qu’une bonne partie de ces produits ne soient en réalité que des wrappers autour des produits Cloudflare
Dans ce cas, ça ne semble pas être un simple wrapper, et l’App Platform de DO est assez sophistiquée pour ne pas être juste posée sur Workers
J’imagine que plusieurs charges de travail centrales utilisent Workers
Mauvais timing
Les résultats trimestriels sont annoncés cet après-midi