🏂🏻 👩🏿‍🤝‍👨🏽 🛳️ Cluster de dois nós

Olá Habr! Apresento a você a tradução do artigo "Dois nós - o diabo está nos detalhes", de Andrew Beekhof.

Muitas pessoas preferem clusters de dois nós porque parecem conceitualmente mais simples e também 33% mais baratos que seus colegas de três nós. Embora seja possível montar um bom cluster de dois nós, na maioria dos casos, devido a cenários não contabilizados, essa configuração criará muitos problemas não óbvios.

O primeiro passo para criar qualquer sistema de alta disponibilidade é procurar e tentar eliminar pontos individuais de falha, frequentemente abreviados como SPoF (ponto único de falha).

Deve-se ter em mente que em qualquer sistema é impossível eliminar todos os riscos possíveis de tempo de inatividade. Isso decorre pelo menos do fato de que uma proteção de risco típica é a introdução de alguma redundância, o que leva a um aumento na complexidade do sistema e ao surgimento de novos pontos de falha. Portanto, inicialmente comprometemos e focamos em eventos relacionados a pontos individuais de falha, em vez de em cadeias de eventos relacionados e, portanto, cada vez menos prováveis.

Dadas as compensações, não estamos apenas buscando o SPoF, mas também equilibrando os riscos e as conseqüências, como resultado, a conclusão é o que é crítico e o que não pode ser diferente para cada implantação.

Nem todo mundo precisa de fornecedores alternativos de eletricidade com linhas de energia independentes. Embora a paranóia tenha compensado pelo menos um cliente quando o monitoramento detectou um transformador com defeito. O cliente ligou por telefone, tentando avisar a empresa de energia, até que um transformador com defeito explodisse.

O ponto de partida natural é a presença de mais de um nó no sistema. No entanto, antes que o sistema possa mover os serviços para o nó sobrevivente após a falha, em geral, é necessário garantir que os serviços que estão sendo movidos não estejam ativos em nenhum outro local.

Um cluster de dois nós não possui desvantagens se, como resultado de uma falha, os dois nós atendem ao mesmo site estático. No entanto, tudo muda se, como resultado, ambas as partes gerenciam independentemente a fila de tarefas compartilhadas ou fornecem acesso de gravação descoordenado ao banco de dados replicado ou ao sistema de arquivos compartilhados.

Portanto, para evitar a corrupção de dados devido à falha de um nó - contamos com o que é chamado de "dissociação» (esgrima).

Princípio da separação

O princípio da separação é baseado na pergunta: um nó concorrente pode causar corrupção de dados? Caso a corrupção de dados seja um cenário provável, isolar o nó das solicitações recebidas e do armazenamento persistente é uma boa solução. A abordagem mais comum para desengatar é desabilitar nós defeituosos.

Existem duas categorias de métodos de separação que chamarei de diretos e indiretos , mas igualmente podem ser chamados de ativos e passivos. Os métodos diretos incluem ações de colegas sobreviventes, como interagir com um dispositivo IPMI (Intelligent Platform Management Interface - uma interface para monitorar e gerenciar remotamente o estado físico de um servidor) ou iLO (um mecanismo de gerenciamento de servidor na ausência de acesso físico a eles), enquanto os métodos indiretos confiam no nó com falha para reconhecer de alguma forma que ele está em estado insalubre (ou pelo menos impedir que o restante dos membros se recupere) e sinalizar ao watchdog de hardware sobre a necessidade de desconectar o nó com falha.

Um quorum ajuda no caso de usar métodos diretos e indiretos.

Dissociação direta

No caso de dissociação direta, podemos usar um quorum para evitar corridas de exclusão no caso de uma falha na rede.

Tendo o conceito de quorum, o sistema possui informações suficientes (mesmo sem conectar-se a seus parceiros) para que os nós saibam automaticamente se devem iniciar a separação e / ou recuperação.

Sem quorum, os dois lados do compartilhamento de rede assumem, com razão, que o outro lado está morto e procurarão dissociá-lo. Na pior das hipóteses, os dois lados conseguem desconectar o cluster inteiro. Um cenário alternativo é o deathmatch, um loop interminável de nós aparecendo, sem ver seus pares, recarregando-os e iniciando a recuperação apenas para uma reinicialização quando seus pares seguem a mesma lógica.

O problema da exclusão é que os dispositivos usados com mais freqüência se tornam inacessíveis devido aos mesmos eventos de falha nos quais queremos nos concentrar na recuperação. A maioria das placas IPMI e iLO é instalada nos hosts que eles controlam e, por padrão, usam a mesma rede, por causa da qual os nós de destino assumem que os outros nós estão offline.

Infelizmente, os recursos da operação dos dispositivos IPMI e iLo raramente são considerados no momento da compra do equipamento.

Separação Indireta

Um quorum também é importante para gerenciar a exclusão indireta; se tudo for feito corretamente, um quorum poderá permitir que os sobreviventes suponham que os nós perdidos entrem em um estado seguro após um certo período de tempo.

Com essa configuração, o timer do watchdog de hardware é redefinido a cada N segundos se o quorum não for perdido. Se o cronômetro (geralmente um múltiplo de N) expirar, o dispositivo executará um desligamento sem força da energia (não desligamento).

Essa abordagem é muito eficaz, mas sem quorum, não há informações suficientes dentro do cluster para gerenciá-las. Não é fácil determinar a diferença entre uma interrupção na rede e uma falha no host do parceiro. A razão pela qual isso importa é que, sem a capacidade de distinguir entre dois casos, você é forçado a escolher o mesmo comportamento nos dois casos.

O problema com a escolha de um modo é que não há maneira de ação que maximize a acessibilidade e evite a perda de dados.

Se você decidir assumir que o nó do parceiro está ativo, mas, de fato, houve uma falha, o cluster interromperá desnecessariamente os serviços que precisariam trabalhar para compensar a perda de serviços do nó do parceiro que caiu.
Se você decidir assumir que o nó não está funcionando, mas foi apenas uma falha de rede e o nó remoto está realmente funcionando, na melhor das hipóteses, você se inscreve em alguma reconciliação manual futura dos conjuntos de dados resultantes.

Não importa qual heurística você use, é trivial criar uma falha que força ambos os lados a trabalhar ou força o cluster a desconectar os nós sobreviventes. Não usar o quorum realmente rouba o conjunto de uma das ferramentas mais poderosas em seu arsenal.

Se não houver outra alternativa, a melhor abordagem seria sacrificar a acessibilidade (aqui o autor se refere ao teorema da PAC). A alta disponibilidade de dados corrompidos não ajuda ninguém e a reconciliação manual de vários conjuntos de dados também não é um prazer.

Quorum

Quorum parece ótimo, certo?

A única desvantagem é que, para tê-lo em um cluster com N membros, você precisa manter a conexão entre N / 2 + 1 de seus nós. O que é impossível em um cluster com dois nós após a falha de um nó.

Em última análise, o que nos leva a um problema fundamental com dois nós: um
quorum não faz sentido em dois grupos de nós e, sem isso, é impossível determinar com segurança o curso de ação que maximiza a acessibilidade e evita a perda de dados.
Mesmo em um sistema de dois nós conectados por um cabo cruzado, é impossível finalmente distinguir entre desconectar a rede e a falha de outro nó. Desconectar uma extremidade (cuja probabilidade é, obviamente, proporcional à distância entre os nós) será suficiente para refutar qualquer suposição de que o canal esteja funcionando igual à integridade do nó parceiro.

Fazendo o Cluster de Dois Nós Trabalhar

Às vezes, o cliente não pode ou não deseja comprar um terceiro nó, e somos forçados a procurar uma alternativa.

Opção 1 - Método de separação duplicada

O dispositivo iLO ou IPMI do nó é um ponto de falha porque, no caso de uma falha, os sobreviventes não podem usá-lo para colocar o nó em um estado seguro. Em um cluster de 3 ou mais nós, podemos atenuar isso calculando o quorum e usando o watchdog de hardware (um mecanismo de desativação indireto, conforme discutido anteriormente). No caso de dois nós, devemos usar os interruptores de energia da rede (unidades de distribuição de energia ou PDUs).

Após a falha, o sobrevivente tenta primeiro entrar em contato com o dispositivo de separação principal (iLO ou IPMI interno). Se isso der certo, a recuperação continua como de costume. Somente no caso de uma falha do dispositivo iLO / IPMI, a chamada para a PDU ocorre, se a chamada for bem-sucedida, a recuperação poderá continuar.

Coloque a PDU em uma rede que não seja o tráfego do cluster; caso contrário, uma única falha na rede bloqueará o acesso aos dispositivos de isolamento e a recuperação do serviço.

Aqui você pode perguntar - a PDU não é um ponto único de falha? Para qual a resposta é claro.

Se esse risco for significativo para você, você não está sozinho: conecte os dois nós a duas PDUs e instrua o software de cluster a usar os dois ao ativar e desativar os nós. Agora, o cluster permanece ativo se uma PDU morrer e uma segunda falha de outro dispositivo PDU ou IPMI for necessária para bloquear a recuperação.

Opção 2 - Adicionando um árbitro

Em alguns cenários, embora o método de separação duplicada seja tecnicamente possível, é politicamente complexo. Muitas empresas gostam de ter uma certa separação entre administradores e proprietários de aplicativos, e os administradores de rede preocupados com a segurança nem sempre estão entusiasmados em passar o acesso às PDUs a qualquer pessoa.

Nesse caso, a alternativa recomendada é criar um terceiro neutro que possa complementar o cálculo do quorum.

No caso de uma falha, o nó deve poder ver a transmissão de seu parceiro ou árbitro para restaurar os serviços. O árbitro também inclui a função de interromper a conexão, se os dois nós puderem vê-lo, mas não se verem.

Essa opção deve ser usada em conjunto com um método indireto de dissociação, como um cronômetro de vigilância de hardware, configurado para desligar a máquina se ela perder a conexão com seu nó parceiro e o árbitro. Portanto, o sobrevivente pode assumir com confiança que seu nó parceiro estará em um estado seguro após a expiração do cronômetro do watchdog de hardware.

A diferença prática entre o árbitro e o terceiro nó é que o árbitro requer muito menos recursos para seu trabalho e, potencialmente, pode servir a mais de um cluster.

Opção 3 - O fator humano

A última abordagem é que os sobreviventes continuem executando os serviços que já executaram, mas não iniciem novos, até que o problema seja resolvido (restauração da rede, reinicialização do nó) ou a pessoa não se responsabilize por confirmar manualmente que o outro lado está morto.

Opção de bônus

Eu mencionei que você pode adicionar um terceiro nó?

Duas prateleiras

Por uma questão de argumento, vamos imaginar que eu os convenci dos méritos do terceiro nó, agora devemos considerar a localização física dos nós. Se eles são colocados (e alimentados) no mesmo rack, isso também representa o SPoF e um que não pode ser resolvido com a adição de um segundo rack.

Se isso for surpreendente, considere o que acontecerá se o rack com dois nós ficar inativo e como o nó sobrevivente fará a distinção entre esse caso e a falha na rede.

Resposta curta: isso não é possível e, novamente, estamos lidando com todos os problemas no caso de dois nós. Ou sobrevivente:

ignora o quorum e tenta incorretamente iniciar a recuperação durante quedas de rede (a possibilidade de concluir a separação é uma história separada e depende se as PDUs estão envolvidas e se compartilham energia de qualquer um dos racks) ou
respeita o quorum e se desconecta prematuramente quando seu nó parceiro falha

De qualquer forma, dois racks não são melhores que um e os nós devem receber fontes de energia independentes ou distribuídos entre três (ou mais, dependendo de quantos nós você possui) racks.

Dois data centers

Neste ponto, os leitores que não são mais avessos ao risco podem considerar se recuperar de um acidente. O que acontece quando um asteróide entra em um único datacenter com nossos três nós distribuídos em três racks diferentes? Obviamente, coisas ruins, mas dependendo de suas necessidades, a adição de um segundo data center pode não ser suficiente.

Se tudo for feito corretamente, o segundo datacenter fornecerá (e isso é razoável) uma cópia atualizada e consistente dos seus serviços e dos dados deles. No entanto, como nos cenários com dois nós e dois racks, o sistema não possui informações suficientes para garantir a máxima disponibilidade e evitar danos (ou divergência dos conjuntos de dados). Mesmo se houver três nós (ou racks), sua distribuição em apenas dois data centers deixa o sistema incapaz de tomar com segurança a decisão certa no caso de um evento (agora muito mais provável) que os dois lados não podem conectar.

Isso não significa que uma solução com dois data centers nunca se encaixe. As empresas geralmente querem que as pessoas estejam cientes antes de dar um passo excepcional ao mudar para um data center de backup. Lembre-se de que, se você deseja automatizar a falha, precisará de um terceiro datacenter para que o quorum faça sentido (diretamente ou através de um árbitro) ou você encontrará uma maneira de desativar com segurança todo o datacenter.

Cluster de dois nós - o diabo em detalhes