Cloudflare nov/2023: queda de energia derruba o plano de controle

01 · CONTEXTO

Uma queda que, segundo a empresa, não deveria acontecer

Em 2 de novembro de 2023, o plano de controle e os serviços de analytics da Cloudflare sofreram uma queda. Segundo o post-mortem, o incidente durou das 11:44 UTC de 2 de novembro até as 04:25 UTC de 4 de novembro.

O post-mortem define o plano de controle como a interface voltada ao cliente para todos os serviços, incluindo o site e as APIs; já os serviços de analytics incluem logging e relatórios de análise.

A empresa afirma que acreditava ter sistemas de alta disponibilidade capazes de impedir uma queda assim, mesmo com a falha catastrófica de um provedor de data center. Muitos sistemas ficaram no ar como projetado, mas alguns sistemas críticos tinham dependências não óbvias que os tornaram indisponíveis.

02 · O DESENHO PRETENDIDO

Três data centers independentes e uma rede à parte

O plano de controle e o analytics rodam principalmente em servidores de três data centers na região de Hillsboro, em Oregon. Eles são independentes entre si, cada um com várias alimentações de energia e várias conexões de rede redundantes e independentes.

A distância entre eles foi escolhida para reduzir a chance de um desastre natural atingir os três, mas curta o bastante para operar clusters de dados ativo-ativo. Os dados são sincronizados continuamente, de modo que, por projeto, a perda de um deles não para os demais. Veja também recuperação de desastres.

1. O cliente usa o painel e as APIs do plano de controle, que rodam em servidores de três data centers perto de Hillsboro, em Oregon.

2. Os data centers são independentes e sincronizam dados continuamente; por projeto, se um deles ficar offline, os demais continuam operando.

3. O maior dos três, operado pela Flexential, abriga o maior cluster de analytics e mais de um terço das máquinas do cluster de alta disponibilidade.

4. Os sistemas de logging ficam fora do cluster de alta disponibilidade de propósito: os logs seriam enfileirados na borda da rede, e atrasar o analytics foi considerado aceitável.

5. O tráfego dos clientes passa pela rede global, que seguiu funcionando como esperado mesmo com o plano de controle fora do ar.

A migração para esse cluster de alta disponibilidade ainda não estava completa: alguns serviços, sobretudo de produtos mais novos, não tinham sido adicionados a ele. Os sistemas de logging ficavam de propósito fora do cluster, com os logs enfileirados na borda enquanto o local de logging estivesse offline.

03 · A CADEIA DE FALHAS

Da manutenção da concessionária ao apagão total

O data center afetado, o maior dos três, é operado pela Flexential. Nele ficam o maior cluster de analytics da Cloudflare e mais de um terço das máquinas do cluster de alta disponibilidade.

A concessionária de energia, a PGE, fez uma manutenção não planejada que afetou uma das alimentações do prédio. A Flexential não avisou a Cloudflare de que passara a operar com geradores, e as ferramentas de observabilidade da Cloudflare não detectaram a mudança da fonte de energia.

Por volta das 11:40 UTC houve uma falha de aterramento em um transformador da PGE no data center. A medida de proteção elétrica também desligou todos os geradores do prédio, e as baterias UPS, que deveriam sustentá-lo por cerca de 10 minutos, começaram a falhar após 4 minutos; a Flexential levou bem mais de 10 minutos para restaurar os geradores.

A Cloudflare relata, sem confirmação oficial, que funcionários lhe disseram haver três fatores que atrasaram o retorno dos geradores: reinício manual presencial, controle de acesso sem bateria de reserva e uma equipe noturna sem especialista experiente em operações ou elétrica.

04 · DEPENDÊNCIAS OCULTAS

O que deveria estar no cluster, mas não estava

A expectativa da Cloudflare era que o analytics ficasse offline, os logs fossem enfileirados na borda e atrasados e serviços de menor prioridade, fora do cluster de alta disponibilidade, ficassem temporariamente offline até serem restaurados em outro local. Os outros dois data centers assumiriam o cluster e manteriam os serviços críticos, o que em geral funcionou como planejado.

1. Os serviços do cluster de alta disponibilidade rodam nos três data centers; se o da Flexential falhasse, os outros dois assumiriam os serviços críticos.

2. Kafka e ClickHouse, que processam logs e sustentam o analytics, estavam disponíveis apenas dentro do data center da Flexential.

3. Mesmo assim, serviços do cluster de alta disponibilidade dependiam desses dois componentes.

4. Com o data center sem energia, esses componentes saíram do ar, e sistemas críticos que dependiam deles ficaram indisponíveis.

Segundo a Cloudflare, serviços do cluster de alta disponibilidade dependiam de componentes que só existiam no data center afetado, e foram dependências não óbvias como essa que tornaram sistemas críticos indisponíveis. A própria empresa diz que essas dependências não deveriam ser tão rígidas, deveriam falhar de forma mais graciosa e deveriam ter sido detectadas.

Os testes de falha da empresa tinham retirado do ar cada um dos outros dois data centers e a parte de alta disponibilidade do afetado, mas nunca o data center inteiro. A Cloudflare reconhece que, por isso, não percebeu a importância de algumas dependências. Admite também que exigia pouco que novos produtos se integrassem ao cluster e que não o exigia formalmente antes de serem declarados GA, o que fez as proteções de redundância funcionarem de forma desigual conforme o produto.

05 · A RECUPERAÇÃO

Failover para a Europa, rajada de chamadas e reinício do zero

1. O data center afetado fica sem energia, e a maior parte dos serviços continua rodando no cluster de alta disponibilidade, nos dois data centers ativos.

2. Às 12:48 UTC a Flexential reiniciou os geradores; ao religar os circuitos da Cloudflare, os disjuntores se mostraram defeituosos. Às 13:40 UTC, a Cloudflare decidiu fazer failover para seus sites de recuperação de desastres na Europa, e só foi preciso transferir uma pequena porcentagem do plano de controle.

3. Os primeiros serviços subiram no site de recuperação às 13:43 UTC, e as chamadas de API que vinham falhando sobrecarregaram os serviços (thundering herd); a Cloudflare aplicou limites de taxa.

4. Às 17:57 UTC o que foi movido ao site de recuperação estava estável e a maioria dos clientes já não era diretamente afetada; processamento de logs e algumas APIs sob medida seguiram indisponíveis até a restauração do data center.

5. Produtos em geral mais novos não subiram direito no site de recuperação, por falta de procedimento totalmente implementado e testado; a equipe seguiu duas frentes, reimplantá-los lá e migrá-los para o cluster de alta disponibilidade.

6. A Flexential confirmou energia limpa às 22:48 UTC; a volta ao data center exigiu um bootstrap completo da instalação, e os serviços estavam totalmente restaurados em 4 de novembro, às 04:25 UTC.

Com a energia limpa confirmada, o CEO decidiu que a maioria da equipe descansasse e iniciasse a volta ao data center na manhã seguinte. Segundo ele, a decisão atrasou a recuperação completa, mas reduziu a chance de novos erros. Como o estado dos serviços era desconhecido, o único processo seguro foi um bootstrap completo do prédio.

O processo exigiu levantar primeiro os servidores de gerenciamento de configuração, o que levou 3 horas. Depois, cada servidor levou de 10 minutos a 2 horas para ser reconstruído. Isso pôde ser feito em paralelo entre vários servidores, mas dependências entre serviços exigiam que alguns voltassem em sequência.

O impacto nos dados foi desigual: como parte do analytics também fica nos data centers europeus, a maioria dos clientes não deve ter perdido dados de analytics, mas conjuntos não replicados na UE terão lacunas permanentes. Os serviços de logs brutos ficaram indisponíveis para a maioria dos clientes durante todo o incidente, e quem usa log push não terá de volta os logs que não recebeu.

06 · LIÇÕES

O que a Cloudflare vai mudar e o que levar para o seu desenho

A empresa decidiu criar o que chamou de Code Orange, uma versão própria dos processos Code Yellow e Code Red do Google, e passou todas as funções de engenharia não críticas a focar a confiabilidade do plano de controle.

A Cloudflare diz que muitos serviços dependem da disponibilidade do núcleo e falham se ele fica indisponível, e que precisa usar para todos os seus serviços os produtos distribuídos que oferece aos clientes, para que sigam funcionando mesmo com o núcleo interrompido.

Perguntas úteis ao revisar um desenho parecido: onde ficam os componentes de apoio, como filas e armazenamento de analytics, de cada serviço marcado como redundante? O teste de falha (engenharia do caos) remove o domínio de falha inteiro ou só a parte redundante dele? Existe um plano de recuperação de desastres testado antes de um produto ser liberado para todos? Esses cuidados se aproximam da arquitetura em células, que limita o raio de impacto de cada falha.