Base de Dados numa Só Zona: o Que a Falha de 20 de Outubro em Londres Ensina Sobre Alta Disponibilidade

A 20 de Outubro, uma zona do Google Cloud em Londres ficou seis horas e dez minutos sem energia. A rede eléctrica falhou, as baterias seguraram a carga e os geradores não arrancaram. Havia dois sistemas de automação para os ligar, o principal e o de reserva. Nenhum dos dois deu a ordem.

O caso é de um centro de dados, mas a pergunta que levanta é de arquitectura: onde corre a base de dados principal, e o que acontece quando essa zona deixa de existir durante uma manhã inteira?

O que aconteceu a 20 de Outubro

Segundo o relatório preliminar do Google Cloud, o incidente decorreu na região europe-west2 (Londres) entre as 07:00 e as 13:10, hora de Londres, num total de 6 horas e 10 minutos. Uma falha na rede eléctrica atingiu o centro de dados que aloja a zona europe-west2-b. A carga passou para as baterias enquanto os geradores a gasóleo arrancavam.

O sistema de automação dos geradores, o principal e o de reserva, não conseguiu iniciar a transferência automática. Quando as reservas das baterias se esgotaram, os servidores físicos, a rede e o armazenamento local da zona perderam energia e ficaram fora de serviço.

Convém ler o relatório como o que é: preliminar. O relatório final pode mudar detalhes da causa, e este artigo será actualizado se isso acontecer.

O detalhe que importa: o impacto fora da zona

O mesmo relatório diz que alguns clientes com cargas em zonas que não perderam energia, europe-west2-a e europe-west2-c, também sentiram impacto. As causas indicadas foram picos súbitos de procura na capacidade de computação das zonas saudáveis e dependências de validação do plano de controlo que atravessam as fronteiras entre zonas.

Ao mesmo tempo, o relatório refere que o Cloud SQL, o AlloyDB, o Memorystore for Redis e o Cloud Bigtable passaram, durante o incidente, para zonas próximas que não foram afectadas. Houve, portanto, bases de dados que mudaram de zona e continuaram a funcionar.

Duas leituras decorrem daqui. A primeira é que uma réplica noutra zona faz diferença. A segunda é que uma réplica noutra zona não isenta de impacto: quando uma zona cai, as restantes recebem a carga que deixou de caber na primeira, e partilham serviços de controlo com ela. Este segundo ponto é leitura da xGrowth a partir do relatório, não uma conclusão do Google.

Zona, região, fornecedor: três níveis de falha

Uma base de dados pode falhar a três escalas, e cada uma pede uma resposta diferente.

1. Falha de zona. Uma zona deixa de estar disponível, como em Londres. A resposta é ter uma réplica noutra zona da mesma região e um processo de promoção testado.
2. Falha de região. Várias zonas, ou a região inteira, ficam afectadas. A resposta é ter uma réplica noutra região, com o custo e a latência que isso implica.
3. Falha do fornecedor. O problema atravessa regiões ou está do outro lado do contrato. A resposta é ter uma cópia fora do fornecedor, que permita reconstruir o serviço noutro sítio.

O artigo sobre a falha do fornecedor cloud e o disaster recovery trata do terceiro nível. O de Londres obriga a olhar para o primeiro, que é o mais frequente e o mais subestimado: uma base de dados que corre numa única zona não tem para onde falhar.

Porque quase ninguém testa

Ter uma réplica desenhada no diagrama não é o mesmo que saber quanto tempo demora a usá-la.

O caso de Londres é a versão em grande escala do mesmo hábito. Os geradores e os dois sistemas de automação existiam. O relatório não diz há quanto tempo os controladores foram testados pela última vez, e este artigo não afirma que não o tenham sido. O que o relatório mostra é que existir e funcionar quando é preciso são coisas distintas.

Como começar a testar

Um teste de mudança de zona não exige ferramentas novas. Exige uma janela e um cronómetro.

Começar fora de produção. Numa cópia do ambiente, desligar ou isolar a zona onde corre a base de dados principal.

Cronometrar do início ao fim. Do momento em que a zona cai até à aplicação voltar a servir pedidos. Esse número, medido e não estimado, é o tempo de recuperação real (RTO).

Verificar a aplicação. A réplica ser promovida não chega. A aplicação tem de voltar a ligar-se sozinha à nova base de dados, sem alguém a editar uma configuração às três da manhã.

Escrever o que falhou. Cada surpresa do teste é uma correcção que não terá de ser descoberta durante uma falha real.

Repetir antes de cada pico de carga. Para o comércio, o próximo é a Black Friday, a 27 de Novembro. Faltam pouco mais de quatro semanas, tempo suficiente para um primeiro teste.

Perguntas frequentes

Uma réplica noutra zona garante que não há paragem? Não. Reduz o risco de a base de dados ficar indisponível quando uma zona falha, mas há sempre um tempo de promoção, e o relatório de Londres mostra que as zonas vizinhas também podem sentir impacto. A garantia só existe quando o tempo foi medido.

É preciso uma segunda região? Depende do que custa uma hora de paragem de cada serviço. Para muitas cargas, uma réplica noutra zona, testada, cobre a maior parte do risco. A segunda região justifica-se quando o custo de uma falha regional é superior ao custo de a manter.

Quem deve decidir a mudança de zona? Alguém com autoridade e substituto nomeados antes do incidente. Uma mudança que exige reunir uma comissão a meio de uma falha perde o tempo que a réplica devia ter poupado.

Conclusão

A falha de 20 de Outubro afectou uma zona e, ainda assim, teve consequências fora dela. A redundância da infraestrutura existia, mas não funcionou quando foi preciso. O mesmo pode acontecer com uma réplica de base de dados que nunca foi usada de propósito.

Para medir o tempo real de recuperação da base de dados principal e preparar o primeiro teste de mudança de zona, é possível agendar uma Sessão de Esclarecimento, sem compromisso, sobre fiabilidade de sistemas (SRE) e de bases de dados (DBRE).