Por que um cluster de dois nós é a pior escolha: a questão da maioria

Você comprou o segundo servidor e montou um cluster. Sente-se mais tranquilo: agora há duas máquinas, e se uma cair a outra segue.

Não segue. Um cluster de dois nós é mais frágil do que um nó sozinho, e o dia em que você descobre isso costuma ser um dia ruim.

Por quê

As decisões de um cluster são tomadas por maioria. Se dois de três nós estão de pé há maioria e o cluster continua funcionando. Se um dos dois nós cai, o único nó restante não é maioria, então o cluster se tranca: as máquinas continuam rodando, mas a configuração não pode mudar, nenhuma máquina nova sobe e a maior parte do trabalho de administração para.

Isso não é um defeito, é um projeto deliberado. A alternativa é bem pior: quando dois nós deixam de se enxergar, ambos dizem "eu estou de pé, o outro caiu" e sobem a mesma máquina virtual em dois lugares. Escreve-se no mesmo disco pelos dois lados e os dados são danificados sem volta.

Ou seja, o cluster te protege trancando você. Mas com dois nós essa proteção dispara na metade das falhas.

O número certo é três

Num cluster de três nós, se um cai sobram dois, a maioria se mantém e a vida continua. É por isso que o número três aparece em todo lugar na documentação de cluster.

A terceira máquina não precisa ser potente. Ela apenas dá um voto, não precisa rodar trabalho nenhum. Uma máquina pequena, até um computador velho, dá conta.

Se você realmente não quer uma terceira máquina, dá para montar no lugar um pequeno nó testemunha que existe só para votar. Não é um nó completo e você não pode rodar máquinas nele, mas ele completa a conta da maioria até três. Se for ficar em dois nós, monte pelo menos esse.

Se você vai ficar em dois nós, saiba

Quando um nó entra em manutenção, o nó restante também fica ingovernável. Ou seja, até uma atualização planejada deixa você trancado.

É possível dizer na mão "deixe um nó sozinho também decidir", mas isso reabre exatamente o risco de duplo início descrito acima. Faz-se de forma temporária, consciente e curta; não é uma solução permanente.

Montar um cluster não é fazer backup

São as duas coisas mais confundidas. Um cluster serve para disponibilidade: para que o trabalho continue quando uma máquina cai. Um backup serve para recuperação: para voltar atrás depois que os dados se corromperam ou foram apagados por engano.

Um cluster não traz de volta uma máquina virtual que você apagou sem querer. O apagamento se espalha para todos os nós na hora, porque um cluster existe justamente para que enxerguem a mesma coisa. Mesmo com cluster, você vai precisar de backup.

O que o Atlas faz

O Atlas trata o cluster não como um conceito, mas como um estado: quantos nós existem, quantos votam, se a maioria se mantém agora.

Onde isso mais ajuda é na atualização. Antes de um nó ser atualizado, o Atlas olha quantas das máquinas que rodam nele podem passar para outro nó e sugere uma ordem. A sugestão continua sendo sugestão: o comando de migração não roda sozinho, o botão você aperta.

Um detalhe importa especialmente aqui, e vai direto ao assunto deste artigo. O comando que pergunta o estado do cluster falha do mesmo jeito em duas situações diferentes: ser de fato uma máquina isolada, e ser membro de um cluster cuja camada de cluster desabou. Se as duas não forem distinguidas, o produto diz "sem cluster, maioria em ordem" exatamente no momento em que o cluster desabou. Ou seja, constrói a frase mais tranquilizadora no instante mais perigoso.

O Atlas as distingue olhando se o arquivo de configuração existe: esse arquivo é escrito junto com a adesão e continua no lugar mesmo quando a camada de cluster desaba. A distinção mora num único lugar, porque antes estava escrita separadamente em três pontos diferentes e os três tinham o mesmo erro.