Queda da API da Cloudflare
(news.ycombinator.com)- A interrupção do Cloudflare Dashboard e da API foi marcada como resolved depois que a Control Plane API e os serviços de produto foram retornados ao principal datacenter de Portland
- Recursos do Dashboard, Alerts, Zero Trust, WARP, Pages e Workers, entre outros, que dependiam da infraestrutura de API puderam apresentar falhas de requisição e exibição de erros
- A Cloudflare avaliou uma perda de energia no datacenter e fez failover dos serviços; após a recuperação parcial da energia no datacenter principal da América do Norte, transferiu serviços críticos para um datacenter de backup para reduzir o impacto
- O impacto foi dividido entre data plane e control plane, e Logpush, Analytics, Workers Analytics Engine, Radar, CASB, DEX, Stream e DNS Updates passaram por estados de unavailable, degraded e restored em diferentes momentos
- Alguns logs do Logpush e dados de analytics foram perdidos durante o incidente; logs próximos ao fim da ocorrência ainda poderiam ser recuperados, mas a extensão total do impacto não havia sido confirmada durante o andamento
Escopo do impacto da interrupção no Dashboard e na API
- A Cloudflare investigou e recuperou problemas no Cloudflare Dashboard e nas APIs relacionadas, e os usuários puderam enfrentar falhas em requisições do Dashboard/API ou exibição de erros
- A interrupção se espalhou para vários serviços que dependem da infraestrutura de API da Cloudflare
- Alerts
- Funcionalidade do Dashboard
- Zero Trust
- WARP
- Cloudflared
- Waiting Room
- Gateway
- Stream
- Magic WAN
- API Shield
- Pages
- Workers
- A Cloudflare afirmou que esse problema não afetou a entrega de arquivos em cache pela Cloudflare CDN nem outros recursos de segurança no Cloudflare Edge
Failover após a perda de energia e recuperação em Portland
- A Cloudflare fez failover dos serviços enquanto avaliava a perda de energia que afetou o datacenter
- Depois da recuperação parcial da energia no datacenter principal da América do Norte, alguns serviços essenciais passaram por failover para um datacenter de backup, reduzindo o impacto
- Durante a recuperação, várias atualizações repetiram os estados de “gradual improvement” e “restore full functionality”
- Na etapa final, a Control Plane API e os serviços de produto foram retornados ao principal datacenter de Portland
- A partir de 2023-11-06 17:00 UTC, foi iniciada a restauração da Control Plane API e dos Product Services para os primary HA datacenters de Portland
- O trabalho de restauração foi estimado em cerca de 2 horas, e durante esse período a disponibilidade da Cloudflare API e do Dashboard poderia ficar degradada
- A partir de 2023-11-06 18:30 UTC, Pages e Workers Control Plane API e Product Services também começaram a ser restaurados para o principal datacenter de Portland
- Mesmo após a conclusão da restauração, a Cloudflare continuou monitorando a estabilidade e edge cases
Funcionalidades afetadas no data plane
- O impacto no data plane foi definido como o escopo em que a funcionalidade total dos produtos sofreu impacto parcial ou total
- Os serviços inicialmente afetados incluíram Logpush, WARP/Zero Trust device posture, Cloudflare dashboard, Cloudflare API, Stream API, Workers API e Alert Notification System
- Os principais serviços cujo estado mudou durante a recuperação foram os seguintes
- Logpush: muitos clientes não receberam logs, e alguns logs podem ter sido perdidos. Depois, mais jobs foram recuperados, e foi informado que a maioria dos jobs seria restaurada até 07:00 UTC
- Analytics / GraphQL API: os analytics data de muitos clientes ficaram unavailable no Dashboard e na API; depois, parte ou a maior parte dos analytics foi recuperada, mas alguns datasets ainda permaneceram afetados
- Workers Analytics Engine: permaneceu unavailable em várias atualizações
- Stream API: passou de not available para degraded performance but available e depois para restored
- Healthchecks: passou de not available para restored sem analytics, e depois os Healthcheck analytics também foram restaurados
- Radar: permaneceu em estado degraded até que o Cloudflare Radar voltou ao status operacional
- Support Services: enquanto o portal de suporte estava unavailable, clientes Enterprise puderam abrir tickets pelo Enterprise support email address; depois, Portal, Phone e Chat voltaram ao estado operacional
- CASB: ficou em estado not available ou degraded performance; os CASB Findings existentes podiam ser visualizados, mas o scanning estava offline. Depois, a CASB API ficou online, o scanning engine entrou em recuperação, e foi informado que não era esperada perda de dados
- DEX: saiu de not available para DEX API online, enquanto fleet status, HTTP e Traceroute Test Result data estavam em recuperação, com expectativa de normalização por volta de Saturday Nov 4 15:00 UTC
- DNS Updates: passou de degraded para restored
Alterações de configuração limitadas no control plane
- O impacto no control plane foi definido como o escopo em que as funções do produto continuavam operando no edge, mas mudanças em configurações existentes foram afetadas
- Os serviços inicialmente impactados incluíram 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, operações de namespace do Workers KV, Magic WAN e Cloudflare Images
- Os principais serviços cujo estado mudou durante a recuperação foram os seguintes
- Cloudflare API: foi atualizada para estados como degraded but accessible ou restored
- Cloudflare Pages: passou de degraded but online para restored, e por um tempo a criação/remoção de projetos e direct upload deployments permaneceram em estado degraded
- Magic Transit / Magic WAN: saiu de um estado em que mudanças não eram possíveis para um estado em que o configuration plane funcionava internamente, com orientação para contatar a account team em caso de mudanças urgentes
- Argo Smart Routing: a configuração funcionava, mas smart updates e analytics estavam offline
- Billing API / Registrar API: por um período, apenas operações read-only ficaram disponíveis
- Lists: atualizações de itens de lista foram temporariamente suspensas; no Dashboard funcionavam, mas pela API podiam retornar erro 429. Depois, passaram a restored, mas por algum tempo ainda só podiam ser editadas pelo Dashboard
- SSL / SSL for SaaS: houve atraso no SSL provisioning e na validação de custom hostname, e depois o status voltou a restored
- Access API, Images API, SOC Proactive Alerts, ZT Gateway, Area 1 Email Security e Direct Upload Deployments também passaram por estados de degraded, unavailable e restored conforme as atualizações
Logs perdidos e análise pós-incidente
- A Cloudflare informou que alguns logs do Logpush e dados de analytics foram perdidos durante o incidente
- Logs próximos ao encerramento do incidente ainda poderiam ser recuperados, mas durante o andamento ainda não era possível saber toda a extensão do impacto
- Em uma atualização, foi informado que todos os pipelines de logs e analytics estariam operacionais até Saturday 4th November 2023 7AM UTC
- Em atualizações posteriores, a empresa afirmou que “a maior parte dos logs foi perdida durante o incidente” e que forneceria uma avaliação completa após a resolução
- Mais detalhes podem ser vistos no post-mortem on Cloudflare control plane and analytics outage da Cloudflare
1 comentários
Opiniões no Hacker News
Quando trabalhei lá, há pouco mais de 3 anos, a arquitetura era tal que, se o PDX caísse, o sistema central caía junto
Coisas como defesa contra DDoS já eram tratadas dentro de cada PoP, então floods L3/L7 ou ataques novos ficavam OK, mas quase todo o restante era calculado no PDX e depois distribuído como dados de configuração para cada PoP
O fluxo era: o PoP gerava/coletava dados → enviava para o PDX → o PDX calculava → distribuía atualizações/dados para os PoPs; se o PDX morresse, muitos recursos que dependiam de dados recentes passavam a operar cada vez mais com estado defasado
Não acho que tudo tenha mudado desde então, então, mais do que simplesmente “API fora do ar”, é provável que recursos como balanceamento de carga, cache hierárquico, Argo Smart Routing e Warp/Zero Trust estejam em um estado degradado, rodando com informações de estado antigas sem atualizações do PDX
Mesmo que fosse “só a API fora do ar”, muitas automações de clientes bloqueiam ataques por chamadas de API, então isso abre uma janela de oportunidade bem grande para atacantes
Pouco antes de eu sair, eles estavam investindo em colocar o AMS de pé, mas nenhum grande teste de failover havia dado certo, e a maioria dos serviços que precisava de estado recente não sabia lidar com esse modelo
Além disso, boa parte da observabilidade também era baseada no PDX, então deixo minha solidariedade às equipes e aos SREs que provavelmente estão correndo às cegas agora
A Cloudflare disse que estava avaliando a perda de energia que afetou o datacenter e, ao mesmo tempo, realizando failover dos serviços
A energia da concessionária caiu e houve comutação para geradores, mas os geradores também falharam; parece que parte da energia da concessionária voltou e a recuperação de partes do site está em andamento
https://puck.nether.net/pipermail/outages/2023-November/0149...
Mas intenção e realidade sempre divergem, e ouvi vários motivos pelos quais fazer failover automático, ou manual de emergência, para um datacenter do outro lado do planeta não era uma solução realista para muitas cargas de trabalho
A Cloudflare faz muitos testes de caos e também testa com bastante regularidade o isolamento total da rede de um datacenter
Eu adoraria entrar escondido na reunião em que discutem por que este incidente foi tão diferente
Eu só construí diretamente um dos dois, mas o marketing sempre os agrupava
Se você não for um usuário enterprise que customiza a topologia de cache hierárquico pela API, acho que uma topologia de cache desatualizada por dias ou semanas geralmente não seria um grande problema
Mas, como você disse, muitas outras coisas podem ter problemas
Por melhor que sejam a manutenção e o planejamento prévio, a chance de surgir alguma condição não prevista, ou para a qual não se investiu por custo, e derrubar infraestrutura crítica não é zero
Como a UI do painel parece usar a API para atualizações, é bem provável que tenha sido por degradação no acesso à API
Mesmo quando a UI mostrava que as atualizações de DNS tinham sido aplicadas, elas não eram propagadas de fato; depois do incidente, foi preciso apagar o domínio inteiro no painel da Cloudflare e recriá-lo para que a propagação de SSL e DNS voltasse a funcionar
Já se passaram 12 horas e o problema ainda continua
Estou fazendo um curso online de produção musical, os vídeos estão no Cloudflare Stream e nenhum deles toca
https://www.cloudflare.com/products/cloudflare-stream/
O problema de ponto único de falha de metade da internet continua aparecendo
https://www.cloudflarestatus.com/incidents/hm7491k53ppg
Eu achava que o impacto era só no painel e em recursos dentro do painel, mas, se o streaming de vídeo da Cloudflare não funciona, talvez não seja bem isso
Não sei bem, mas a Cloudflare me deixa meio desconfortável
Não entendo por que tanta gente acha aceitável deixar uma parte grande da internet depender de uma única empresa
Talvez minha percepção esteja errada, mas a Cloudflare me parece uma desafiante confiável frente às gigantes oligopolistas, e eu gostaria que houvesse mais Cloudflares
Na prática, não conheço bem serviços parecidos que ofereçam uma camada gratuita tão generosa quanto a da Cloudflare
Quando usado corretamente, TLS fornece segurança ponta a ponta, mas, ao usar Cloudflare, a Cloudflare pode acessar todo o tráfego em texto claro
Se um site pequeno pode virar alvo de DoS, no fim ele precisa usar Cloudflare
É minha impressão pessoal, e posso estar errado
Pensei que talvez tivessem commitado de novo aquele bug de alguns dias atrás
https://blog.cloudflare.com/cloudflare-incident-on-october-3...
Não era isso; parece mais uma falha de energia no datacenter central
Mais detalhes estão em outros comentários
A esta altura, já virei pavloviano e comecei a curtir as panes
Já é a segunda pane só na semana passada
Somando à resposta de um comentário morto: isso não tem nada a ver com a escolha da linguagem de programação
A DreamHost também está com problemas em PDX desde 4h54 da manhã, horário do Pacífico
https://www.dreamhoststatus.com
Foi informado que a Flexential PDX02 perdeu energia por volta do mesmo horário em que isso começou
A Cloudflare acabou de anunciar que está avaliando uma perda de energia que afetou um datacenter e, ao mesmo tempo, realizando failover dos serviços
A Flexential do nosso lado tem 5 geradores, backup de baterias no subsolo e área de isolamento
O mais impressionante é que a página de status realmente funciona
Claro, é bem provável que esteja hospedada em outro lugar, mas sempre penso a mesma coisa e dou risada quando acontece uma pane grande
Não parece nada bom
Espero que isso não faça com que parem de usar os próprios serviços
Os deploys da Vercel e as funções de edge em geral também não estão funcionando
A página de status diz: “identificamos como causa raiz um problema em um dos nossos provedores upstream e estamos trabalhando com eles para mitigar”
Fico pensando se as funções de edge usam Workers internamente
Link: https://www.vercel-status.com/
Outro link na mesma thread diz que a Flexential PDX02 perdeu energia no mesmo horário
Parece que a energia da concessionária caiu, houve mudança para geradores, mas os geradores também falharam, e parte da energia da concessionária voltou, permitindo restaurar partes do site
Soa como se o datacenter inteiro tivesse caído, e o failover da Cloudflare não tivesse lidado com isso tão bem quanto se esperava
https://puck.nether.net/pipermail/outages/2023-November/0149...
Não sei se devo ficar impressionado ou assustado com o fato de muitos desses produtos serem praticamente apenas wrappers em volta de produtos da Cloudflare
Neste caso, acho que não é um wrapper; a App Platform da DO é sofisticada demais para rodar apenas em cima de Workers
Suspeito que vários workloads centrais estejam usando Workers
Péssimo timing
A divulgação dos resultados trimestrais é hoje à tarde