Facebook: BGP e DNS fora do ar

01 · CONTEXTO

Uma backbone, muitos data centers

No post de engenharia sobre a queda global do Facebook, a origem é descrita como um trabalho de manutenção rotineiro. Um comando foi emitido com a intenção de avaliar a disponibilidade da capacidade da backbone global, e acabou derrubando todas as conexões dessa rede, o que desconectou os data centers entre si. Os sistemas da empresa foram desenhados para auditar comandos assim, mas um bug na ferramenta de auditoria impediu que o comando fosse barrado a tempo.

1. Em operação normal, os data centers conversam entre si pela backbone.

2. O comando de manutenção derruba as conexões da backbone, e os data centers ficam desconectados.

02 · DNS E BGP

O healthcheck que apagou o servidor do mapa

Os servidores de nomes autoritativos ficam em instalações menores e têm seus endereços anunciados ao resto da internet por BGP. Para operar com confiabilidade, esses servidores desativam os anúncios BGP quando não conseguem falar com os data centers, pois isso indica uma conexão de rede doente. Com a backbone inteira fora de operação, todos eles se declararam não saudáveis e retiraram os anúncios. O resultado foi que os servidores DNS ficaram inalcançáveis mesmo funcionando, e o resto da internet deixou de encontrar os serviços. Aqui o balanceamento de carga e roteamento global falhou por uma regra de proteção: um healthcheck correto para cada nó produziu uma falha coletiva.

1. O servidor de nomes só se considera saudável enquanto consegue falar com os data centers pela backbone.

2. Sem a backbone, o servidor de nomes se declara não saudável e retira seus anúncios BGP.

3. O resto da internet não encontra mais o servidor de nomes, embora ele continue em funcionamento.

03 · OPERAÇÃO

Sem rede e sem ferramentas

Enquanto os engenheiros tentavam entender o que acontecia, encontraram dois obstáculos grandes. Primeiro, não era possível acessar os data centers pelos meios normais, porque as redes deles estavam fora do ar. Segundo, a perda total de DNS quebrou muitas das ferramentas internas usadas normalmente para investigar e resolver quedas. Em termos de monitoramento e observabilidade, o caminho de diagnóstico e de acesso de emergência dividia o mesmo domínio de falha do sistema que precisava ser consertado.

1. Normalmente, as equipes usam ferramentas internas para alcançar os data centers e investigar problemas.

2. Com DNS e rede fora do ar, as ferramentas deixam de funcionar e o acesso normal aos data centers some.

04 · RECUPERAÇÃO

Segurança física, tempo e uma religação gradual

Com o acesso normal e o de emergência fora do ar, a equipe enviou engenheiros aos data centers. Isso levou tempo, pois as instalações têm alto nível de segurança física e de sistemas, e foi preciso ativar protocolos de acesso seguro antes de colocar pessoas para trabalhar nos servidores. Restaurada a backbone, o post diz que ligar tudo de uma vez poderia causar uma nova rodada de falhas por pico de tráfego. Data centers individuais relatavam quedas de consumo de energia na faixa de dezenas de megawatts, e reverter isso de repente colocaria em risco desde sistemas elétricos até caches. Esse é um caso de recuperação de desastres, em que religar é uma etapa de risco por si só.

1. Engenheiros vão fisicamente ao data center, porque os caminhos remotos estão fora do ar.

2. A backbone volta a operar e os data centers voltam a se conectar.

3. A carga é devolvida aos poucos, para evitar um pico de tráfego e de consumo de energia.

05 · LIÇÕES

O que levar para o seu projeto

A empresa afirma que o preparo veio de exercícios chamados de storm, nos quais se simula uma grande falha tirando do ar um serviço, um data center ou uma região inteira. Segundo o post, a experiência desses exercícios deu confiança para trazer tudo de volta com cuidado, mas nunca tinham simulado a backbone global fora do ar e pretendiam buscar formas de simular eventos assim. É a prática de chaos engineering aplicada à rede. O autor também reconhece um custo: o endurecimento de segurança diário retardou a recuperação, e ele considera a troca válida, pois a segurança aumenta muito no dia a dia contra uma recuperação mais lenta num evento raro.