.
A Cloudflare explicou como acredita ter sofrido aquela interrupção anterior do plano de controle e análise de vários dias.
O resumo executivo é: um datacenter usado pela Cloudflare aparentemente mudou com pouco ou nenhum aviso de operar com duas fontes de energia da concessionária, para uma fonte da concessionária e geradores de emergência, para apenas baterias UPS, para nada, tudo no espaço de horas e minutos. E então a Cloudflare descobriu da maneira mais difícil que seus planos de failover daquele datacenter para outras instalações não funcionavam conforme o esperado.
Em um relatório post mortem após o período de inatividade, o CEO Matthew Prince examinou a interrupçãoque ocorreu das 11h43 UTC de quinta-feira, 2 de novembro, a sábado, 4 de novembro, às 04h25 UTC, do ponto de vista de sua equipe CDN.
Durante o colapso da TI, não apenas os serviços de análise da Cloudflare foram interrompidos ou totalmente indisponíveis, o que incluía registro, mas também o plano de controle; essa é a interface voltada para o cliente para todos os seus serviços. Fomos informados de que o avião de controle foi praticamente restaurado às 17h57 UTC de quinta-feira, usando uma instalação de recuperação de desastres. As principais tarefas de rede e segurança da Cloudflare continuaram normalmente durante a interrupção, mesmo que os clientes às vezes não pudessem fazer alterações em seus serviços, disse Prince.
Na realidade, as baterias começaram a falhar após apenas quatro minutos
No centro da questão está um datacenter nos EUA que, segundo dizem, é administrado pela Flexential. A Cloudflare chama essa instalação de PDX-DC04 ou PDX-04, e é um dos três centros separados em Hillsboro, Oregon, onde a Cloudflare abriga principalmente os servidores que fornecem seu plano de controle e serviços de análise.
De acordo com a Cloudflare, o PDX-04 possui duas alimentações de energia elétrica de 12,47kV da Portland General Electric (PGE), uma coleção de geradores de emergência e um banco de baterias UPS. Se as duas alimentações da concessionária forem cortadas, os geradores poderão assumir a carga total do datacenter e as baterias funcionarão por 10 minutos.
Às 08h50 UTC de quinta-feira, uma dessas linhas de serviços públicos ficou inoperante. Como disse Prince, a PGE teve “um evento de manutenção não planejado que afetou uma ou suas fontes de energia independentes para o edifício”. Neste ponto, o PDX-04 ainda tinha sua segunda alimentação de serviço público, mas decidiu ligar seus geradores de qualquer maneira.
Prince nos disse que “contrariando as melhores práticas, a Flexential não informou à Cloudflare que eles haviam falhado na energia do gerador” e, portanto, não tinha um aviso de que talvez as coisas estivessem potencialmente prestes a ir para o sul e que as contingências deveriam estar no lugar.
“Não obtivemos uma resposta clara por que eles usavam energia de serviços públicos e geradores”, acrescentou. Também entramos em contato com a Flexential e não recebemos resposta.
Pode ser que a Flexential não confiasse na segunda linha e que a PGE pudesse ter outro “evento de manutenção não planejado” e, portanto, os operadores colocaram os geradores on-line, apenas por precaução. A Cloudflare, alegando que ainda não obteve todas as respostas que queria da Flexential, especulou que a empresa de datacenter tinha um acordo com a PGE no qual a empresa usaria seus geradores locais para fornecer energia adicional à rede quando necessário, com a concessionária empresa que auxilia na manutenção e operação desses geradores.
Seja qual for o motivo, pouco menos de três horas depois, às 11h40 UTC (03h40 horário local), um transformador abaixador da PGE no datacenter – que se acredita estar conectado à segunda linha de serviço público de 12,47 kV – sofreu uma falta à terra. Isso fez com que a instalação cortasse a segunda linha e os geradores como medida de segurança.
Naquele ponto, de acordo com a Cloudflare, o PDX-04 não estava funcionando sem linhas externas de serviços públicos e sem geradores.
Isso significava que a Flexential teve que recorrer às baterias do UPS, que, segundo Prince, deveriam fornecer 10 minutos de energia para que houvesse tempo suficiente para reativar os geradores e manter um fornecimento ininterrupto. “Na realidade, as baterias começaram a falhar depois de apenas quatro minutos, com base no que observamos na falha do nosso próprio equipamento”, disse ele.
Com isso, ele se refere às 11h44 UTC – quatro minutos após a falta de aterramento do transformador – os roteadores de rede da Cloudflare no PDX-04, que conectava os servidores da gigante da nuvem ao resto do mundo, perderam energia e ficaram off-line, como todo o resto no prédio. .
Neste ponto, você esperaria que os servidores nos outros dois datacenters do trio de Oregon compensassem automaticamente e mantivessem os serviços críticos em execução na ausência do PDX-04, e foi isso que a Cloudflare disse ter projetado sua infraestrutura pendência. Algumas coisas não críticas seriam interrompidas temporariamente, mas as coisas críticas continuariam a funcionar.
É aqui que as coisas ficam um pouco confusas porque, de acordo com Prince, “geralmente funcionou conforme planejado”. No entanto, também fomos informados de que “infelizmente” um subconjunto desses serviços tinha dependências que estavam “executando exclusivamente no PDX-04”. Parece que havia dois serviços de análise em particular que só rodavam no PDX-04, e outros serviços dependiam deles. Sem o PDX-04, esses serviços interconectados não voltariam facilmente.
“Nunca testamos totalmente a colocação off-line de todas as instalações do PDX-04. Como resultado, perdemos a importância de algumas dessas dependências”, escreveu Prince, e agradecemos a honestidade.
No final das contas, quando as luzes se apagaram no PDX-04, a recuperação não foi tão rápida e tranquila quanto se esperava, e alguns serviços deixaram de ser confiáveis ou indisponíveis, como os clientes descobriram.
Tenho o poder
Fomos informados de que os geradores estavam finalmente começando a ficar on-line novamente às 12h48 UTC – o suficiente para aquela janela de 10 minutos do UPS. A Flexential foi ligar os disjuntores para a parte do datacenter da Cloudflare, e os disjuntores estavam com defeito, fomos informados, talvez devido à falha de aterramento, talvez por algum outro motivo.
A Flexential não tinha peças funcionais suficientes para substituir os disjuntores, afirma, deixando os servidores e equipamentos de rede da Cloudflare off-line.
Isso levou a Cloudflare, às 13h40 UTC, a decidir fazer failover de algumas tarefas para sistemas na Europa, o que por sua vez levou a um “problema de rebanho estrondoso”, onde uma onda de chamadas de API de clientes sobrecarregou esses servidores, o que não ajudou na recuperação.
Os serviços do plano de controle puderam voltar a ficar online, permitindo que os clientes fizessem alterações intermitentemente, e foram totalmente restaurados cerca de quatro horas depois do failover, de acordo com a empresa de nuvem. Outros serviços tiveram que esperar mais, alguns até que o PDX-04 estivesse totalmente ligado novamente.
Parece-nos que a Cloudflare conseguiu equilibrar pelo menos alguns de seus serviços, especialmente o plano de controle, em seus outros dois datacenters de Oregon depois que o PDX-04 ficou escuro e, eventualmente, falhou em uma parte desse trabalho de plano de controle para a Europa para aliviar o fardo. E outros serviços, especialmente os de análise, foram devolvidos gradualmente à medida que o negócio negociava o seu caminho através da tempestade.
Lições aprendidas
Quando um datacenter falha, os serviços em nuvem não deveriam ficar offline como aconteceu com o Cloudflare, e Prince cometeu vários erros a esse respeito.
“Acreditávamos que tínhamos sistemas de alta disponibilidade que deveriam ter impedido uma interrupção como essa, mesmo quando um de nossos principais provedores de data center falhou catastroficamente”, disse Prince.
“E, embora muitos sistemas tenham permanecido online conforme projetados, alguns sistemas críticos tinham dependências não óbvias que os tornavam indisponíveis”.
“As proteções contra redundância que implementamos funcionavam de forma inconsistente dependendo do produto”, acrescentou o CEO.
Como resultado do tempo de inatividade, Prince disse que a Cloudflare está fazendo diversas mudanças operacionais, incluindo a remoção de dependências nos datacenters principais para configuração do plano de controle, testando o “raio de explosão” de falhas do sistema para minimizar o número de serviços afetados por uma falha em uma única instalação. , implementando testes mais rigorosos de “todas as funções do datacenter” e fazendo melhorias na auditoria do datacenter.
A Cloudflare se recusou a responder às nossas perguntas pedindo mais detalhes.
“Sinto muito e estou envergonhado por este incidente e pela dor que causou aos nossos clientes e à nossa equipe”, disse Prince. “Isso terá toda a minha atenção e a atenção de grande parte da nossa equipe ao longo do balanço do ano”. ®
.
