Google Cloud jun/2019: automação desagenda o plano de controle da rede

01 · CONTEXTO

Uma tarde de domingo, congestionamento em várias regiões

Em 2 de junho de 2019, projetos do Google Cloud que rodavam serviços em várias regiões dos EUA tiveram perda elevada de pacotes por congestionamento de rede, por um período entre 3 h 19 min e 4 h 25 min. A duração e o grau de perda variaram bastante de região para região.

O relatório lista as regiões em que houve latência maior, erros intermitentes e perda de conectividade: us-central1, us-east1, us-east4, us-west2, northamerica-northeast1 e southamerica-east1. Instâncias em us-west1 e em todas as regiões da Europa e da Ásia não tiveram congestionamento regional.

Do lado dos usuários, o Google informou que o YouTube mediu queda de 2,5% nas visualizações por uma hora e que o Google Cloud Storage mediu redução de 30% no tráfego. Já a Busca registrou só um aumento curto de latência ao passar a servir de regiões não afetadas.

02 · COMO A REDE ERA ORGANIZADA

Clusters lógicos, plano de controle e fail static

Dentro de cada local físico, as máquinas do Google são separadas em vários clusters lógicos, e cada um tem seu próprio software de gerenciamento de clusters. O desenho dá resiliência à falha de qualquer gerenciador individual.

O plano de controle da rede também roda sob instâncias do mesmo software de gerenciamento de clusters. Em cada local há várias instâncias, de modo que a falha de uma delas não tem impacto na capacidade da rede.

Esse software tem papel relevante na automação de manutenção de datacenters, como mudanças na infraestrutura de energia ou ampliação da rede. Em escala global, manutenções são comuns, embora raras em um único local. Cada job é rotulado com o que deve fazer diante de uma manutenção: em geral, ser movido para uma máquina fora da manutenção ou parar e ser reagendado depois.

1. O gerenciador de clusters participa da automação dos eventos de manutenção do datacenter.

2. Os jobs do plano de controle da rede rodam sob instâncias desse mesmo software, em cada local.

3. Cada job carrega um rótulo que diz como reagir à manutenção: ser movido para outra máquina ou parar e ser reagendado depois.

4. A rede foi desenhada para seguir funcionando por um período mesmo sem o plano de controle presente, uma linha extra de defesa.

O Google descreve esse desenho como defesa em profundidade: mesmo com um plano de controle projetado para ser muito resiliente, a rede entra em modo fail static como camada adicional.

03 · A CADEIA DE FALHAS

Duas configurações benignas e um bug

O relatório afirma que duas configurações normalmente benignas e um bug específico de software se combinaram para iniciar a interrupção.

1. O evento de manutenção começa em um único local físico, e a automação monta a lista de jobs a desagendar nesse local.

2. Os clusters lógicos da lista também continham jobs de controle de rede de outros locais físicos.

3. A automação desagenda cada cluster lógico da lista, incluindo os jobs de controle de rede e a infraestrutura de apoio em vários locais.

4. Sem o plano de controle, a rede segue operando normalmente por alguns minutos.

5. Passado esse período, o roteamento BGP entre os locais afetados é retirado, a capacidade da rede cai bastante e algumas regiões ficam inacessíveis.

O impacto para o usuário final começou a aparecer entre 11:47 e 11:49 (horário do Pacífico), e os engenheiros foram alertados dois minutos depois do início da falha.

04 · CONGESTIONAMENTO E RECUPERAÇÃO

Quando as ferramentas dividem a rede que precisam consertar

A depuração foi muito prejudicada porque as ferramentas passaram a competir pelo uso de uma rede já congestionada. O Google tinha planos de contingência robustos, mas usá-los, o que incluiu engenheiros indo a instalações seguras e a redução de prioridade de classes de tráfego menos críticas, somou tempo à depuração.

1. Com a capacidade reduzida, o tráfego tentou caber no que restou e a rede ficou congestionada.

2. A rede priorizou o tráfego pequeno e sensível a latência e descartou o tráfego maior e menos sensível.

3. As ferramentas dos engenheiros disputavam a mesma rede congestionada, o que prejudicou a depuração.

4. Equipes de vários serviços direcionaram o tráfego para longe das regiões afetadas, para continuar servindo de outros lugares.

O escopo e a escala da interrupção, somados ao dano colateral às ferramentas, dificultaram no início identificar o impacto com precisão e comunicar-se com os clientes.

Às 13:01 (horário do Pacífico) a causa raiz estava identificada e os engenheiros interromperam a automação responsável pelo evento de manutenção. A recuperação ainda teve um segundo atraso: com todas as instâncias do plano de controle desagendadas em vários locais, a configuração tinha sido perdida e precisou ser reconstruída e redistribuída.

1. Os engenheiros interrompem a automação responsável pelo evento de manutenção.

2. Com todas as instâncias do plano de controle desagendadas, a configuração tinha sido perdida e precisava ser reconstruída e redistribuída.

3. Conforme o plano de controle é reagendado em cada local e a configuração é recriada e distribuída, a capacidade da rede volta.

05 · O QUE O GOOGLE SE COMPROMETEU A MUDAR

Limitar o alcance da automação e acelerar a recuperação

O relatório descreve a automação que desagenda jobs diante de manutenção como interrompida de imediato, e só reativada depois de haver salvaguardas contra desagendar jobs em vários locais físicos ao mesmo tempo. O gerenciador de clusters também será endurecido para rejeitar esses pedidos, qualquer que seja a origem.

Para a recuperação, o plano de controle de cada local passaria a persistir sua configuração, para que ela não precise ser reconstruída e redistribuída se todos os jobs forem desagendados. A rede também continuaria em fail static por mais tempo, ampliando a janela de recuperação sem impacto ao usuário.