Resumo

  • Uma combinação de falhas de dois enlaces de subida em Firehose 1.0 podia impedir a comunicação entre dois grupos de máquinas que ainda alcançavam outras máquinas. Esse projeto não chegou a transportar tráfego de produção.
  • A evolução para blocos independentes tornou algumas intervenções menores, mas não eliminou o risco comum em software, controle e configuração.
  • A função documentada de Urs Hölzle e sua coautoria permitem relacioná-lo a esse trabalho coletivo, sem transformá-lo no autor individual de cada solução.

Uma falha de rede nem sempre produz uma ilha bem delimitada. Duas máquinas podem continuar falando com outras e, mesmo assim, deixar de falar entre si. Para uma aplicação distribuída, essa diferença importa: dizer que o servidor está vivo não esclarece se a relação de comunicação necessária sobreviveu.

O artigo original de SIGCOMM 2015 descreve essa situação em Firehose 1.0. Se enlaces de subida em lados opostos de dois switches no topo dos racks falhassem dentro da mesma janela de reparo, as máquinas atendidas por eles podiam perder a comunicação mútua, embora alcançassem outras. Os autores explicam que as aplicações lidavam mal com essa conectividade não transitiva.

Há um limite indispensável no relato: Firehose 1.0 nunca levou tráfego de produção. Não se trata de uma notícia de indisponibilidade atual. O episódio pertence ao aprendizado de um projeto inicial que encontrou dificuldades suficientes para não entrar em operação e que informou as versões posteriores.

Uma liderança de infraestrutura, não uma autoria exclusiva

Urs Hölzle está entre os muitos coautores da retrospectiva. A biografia de Google Research o apresenta como Google Fellow em Google Cloud e informa que, até 2023, foi Senior Vice President for Technical Infrastructure. Nesse período, supervisionava projeto, instalação e operação dos servidores, redes e centros de dados usados pelos serviços de Google.

Essa responsabilidade aproxima decisões de arquitetura de questões de obra e operação. Uma rede precisa ser construída, receber cargas de trabalho e continuar funcionando durante mudanças. É por isso que a trajetória de Hölzle ajuda a situar a história. A assinatura coletiva, porém, não diz quem concebeu cada mecanismo, e o cargo não revela intenções particulares.

Uma publicação de maio de 2013 e o texto de Hölzle de março de 2020 sobre a rede documentam essa função em momentos datados. O segundo separa a infraestrutura de Google da última milha prestada pelos provedores de acesso. O usuário depende também de partes que não estavam dentro daquele controle operacional.

A dispersão dos riscos pede mais comunicação

O artigo técnico relaciona a distribuição de tarefas e armazenamento a uma necessidade de conectividade ampla. Espalhar trabalho entre diferentes domínios de alimentação e falha diminui a concentração de risco em um ponto local. Em contrapartida, reduz a proximidade que manteria os dados circulando em pequenos grupos de máquinas.

Uma topologia Clos com vários estágios oferece muitos caminhos usando numerosos elementos de comutação. Assim, é possível organizar uma grande rede sem depender apenas de um chassi enorme. O problema de Firehose 1.0 mostra que a multiplicidade de caminhos precisa ser avaliada nas combinações de falha relevantes. Caminhos desenhados não asseguram, por si, comunicação entre qualquer par que uma aplicação venha a exigir.

Firehose 1.1 alterou a montagem física e a topologia. Os servidores comuns que abrigavam chips de comutação deram lugar a gabinetes dedicados; havia uma rede de controle separada, switches de rack emparelhados e uma agregação modificada. A equipe relata maior robustez a falhas de enlaces. O trabalho de cabeamento e as restrições de posicionamento continuavam significativos. Para funcionar, a solução também tinha de caber nas rotinas de instalar, reconectar e substituir.

Uma intervenção menor exige uma definição precisa

Em Freedom, uma camada típica de conectividade era composta por quatro blocos independentes. Podia-se esvaziar o tráfego de um bloco e atualizá-lo, com uma redução de 25% da capacidade agregada. Isso tornava a unidade de manutenção menor que a camada inteira.

O número descreve aquele arranjo. Não garante desempenho inalterado para toda aplicação durante a retirada. A carga precisa caber nos recursos restantes, e a capacidade total não informa como cada caminho será utilizado.

Outra ilustração do artigo divide os chassis de uma rede Clos em quatro grupos para uma atualização em etapas. Desabilitar um grupo deixa 56,25% da capacidade, pois as perdas se combinam entre estágios. Oito grupos tornam a sequência mais suave, mas mais demorada. Esse desenho é distinto dos blocos independentes de Freedom; trocar seus percentuais seria apagar justamente a diferença operacional que interessa.

A escolha do lote de manutenção, portanto, não pode se basear apenas no número de equipamentos. É preciso examinar a conectividade que sobra e como o trabalho se redistribui sobre ela.

O risco que atravessa a separação física

Para Firehose, Watchtower e Saturn, o artigo descreve Firepath distribuindo uma visão comum de topologia e estado dos enlaces. Os switches calculam localmente suas tabelas de encaminhamento. É uma coordenação logicamente centralizada, não uma decisão central para cada pacote. Instâncias de controle redundantes e uma rede separada sustentavam a operação. Os detalhes do controle de Jupiter ficam expressamente fora do escopo do trabalho.

Antes de Jupiter, poucos parâmetros de cluster também geravam listas de materiais, planos de racks e cabos, dados de monitoramento e configurações comuns. Menos escolhas facilitavam a construção repetida. A mesma conveniência ampliava o peso de uma especificação compartilhada correta.

Os episódios operacionais relatados mostram outras formas de acoplamento. Em uma reinicialização simultânea da rede, verificações de atividade e cálculo de rotas disputaram a CPU limitada dos switches. Enlaces internos e de controle envelhecidos expuseram estados insuficientemente monitorados. Em uma alteração BGP em Freedom, uma leitura simultânea sem bloqueio interferiu com a escrita e produziu uma configuração parcial. A equipe descreve a reversão e o reforço das ferramentas.

Esses casos explicam mecanismos históricos. Os trechos não fornecem duração, dano a clientes ou uma taxa geral de falhas. Eles deixam claro, porém, que a separação do hardware precisa ser acompanhada de observação e transições de software e configuração seguras.

O resultado que a história sustenta

A publicação de 2015 e a edição de CACM de 2016 são versões do mesmo trabalho, não duas verificações independentes. O relato do operador revela aprendizado sem provar a implementação atual de seus centros de dados.

O vínculo documentado de Hölzle com essa história é uma responsabilidade ampla de infraestrutura e a participação em um esforço coletivo para tornar a rede modificável por partes. O teste duradouro dessa capacidade está no momento da intervenção: o que continua conectado, o que pode ser observado e o que pode ser recuperado quando uma parte deixa de estar disponível.

Fontes