Olá, Habr! Apresento a sua atenção uma tradução do artigo por Andrew Beekhof.
Muitas pessoas preferem clusters de dois nós porque parecem conceitualmente mais simples e também são 33% mais baratos que seus equivalentes de três nós. Embora seja perfeitamente possível montar um bom cluster de dois nós, na maioria dos casos, devido a cenários não considerados, tal configuração criará muitos problemas não óbvios.
O primeiro passo para criar qualquer sistema de alta disponibilidade é encontrar e tentar eliminar pontos individuais de falha, muitas vezes abreviados como SPoF (ponto unico de falha).
Vale lembrar que é impossível eliminar todos os possíveis riscos de indisponibilidade de qualquer sistema. Isto decorre do facto de que uma defesa típica contra o risco é introduzir alguma redundância, o que leva ao aumento da complexidade do sistema e ao surgimento de novos pontos de falha. Portanto, inicialmente fazemos um compromisso e focamos em eventos associados a pontos de falha individuais, e não em cadeias de eventos relacionados e, portanto, cada vez menos prováveis.
Dados os compromissos, não procuramos apenas o SPoF, mas também equilibramos riscos e consequências, pelo que a conclusão do que é crítico e do que não é pode diferir para cada implantação.
Nem todos precisam de fornecedores de electricidade alternativos com linhas de energia independentes. Embora a paranóia tenha valido a pena para pelo menos um cliente quando seu monitoramento detectou um transformador com defeito. O cliente fez ligações tentando alertar a companhia de energia até que o transformador defeituoso explodisse.
Um ponto de partida natural é ter mais de um nó no sistema. Entretanto, antes que o sistema possa mover serviços para o nó sobrevivente após uma falha, ele geralmente precisa garantir que os serviços que estão sendo movidos não estejam ativos em outro lugar.
Não há desvantagem em um cluster de dois nós se uma falha resultar em ambos os nós atendendo ao mesmo site estático. No entanto, as coisas mudam se o resultado for que ambas as partes gerenciem independentemente uma fila de trabalhos compartilhada ou forneçam acesso de gravação descoordenado a um banco de dados replicado ou sistema de arquivos compartilhado.
Portanto, para evitar a corrupção de dados como resultado de uma falha em um único nó - contamos com algo chamado "dissociação" (cerca).
O princípio da dissociação
No cerne do princípio da dissociação está a questão: um nó concorrente pode causar corrupção de dados? Caso a corrupção de dados seja um cenário provável, uma boa solução seria isolar o nó das solicitações recebidas e do armazenamento persistente. A abordagem mais comum para a dissociação é desconectar os nós defeituosos.
Existem duas categorias de métodos de dissociação, que chamarei reto и indireto, mas também podem ser chamados ativo и passiva. Os métodos diretos incluem ações por parte dos pares sobreviventes, como a interação com um dispositivo IPMI (Intelligent Platform Management Interface) ou iLO (um mecanismo para gerenciar servidores na ausência de acesso físico a eles), enquanto os métodos indiretos dependem da falha. nó para de alguma forma reconhecer que ele está em um estado não saudável (ou pelo menos impedindo que outros membros se recuperem) e sinalizar sobre a necessidade de desconectar o nó com falha.
Quorum ajuda ao usar métodos diretos e indiretos.
Dissociação direta
No caso de dissociação direta, podemos usar o quorum para evitar corridas de dissociação no caso de falha da rede.
Com o conceito de quorum, há informações suficientes no sistema (mesmo sem conexão com seus pares) para que os nós saibam automaticamente se devem iniciar a dissociação e/ou recuperação.
Sem quórum, ambos os lados de uma rede dividida assumirão, com razão, que o outro lado está morto e procurarão dissociar o outro. Na pior das hipóteses, ambas as partes conseguem encerrar todo o cluster. Um cenário alternativo é um deathmatch, um loop infinito de nós gerando, sem ver seus pares, reiniciando-os e iniciando a recuperação apenas para reinicializar quando seu par seguir a mesma lógica.
O problema com a dissociação é que os dispositivos mais usados ficam indisponíveis devido aos mesmos eventos de falha que queremos direcionar para recuperação. A maioria das placas IPMI e iLO são instaladas nos hosts que controlam e, por padrão, usam a mesma rede, o que faz com que os hosts de destino acreditem que os outros hosts estão offline.
Infelizmente, os recursos operacionais dos dispositivos IPMI e iLo raramente são considerados no momento da compra do equipamento.
Dissociação indireta
O quorum também é importante para gerenciar a dissociação indireta; se feito corretamente, o quorum pode permitir que os sobreviventes assumam que os nós perdidos farão a transição para um estado seguro após um determinado período de tempo.
Com esta configuração, o temporizador de watchdog de hardware é redefinido a cada N segundos se o quorum não for perdido. Se o temporizador (geralmente vários múltiplos de N) expirar, o dispositivo executará um desligamento incorreto (não um desligamento).
Essa abordagem é muito eficaz, mas sem quórum não há informações suficientes no cluster para gerenciá-lo. Não é fácil saber a diferença entre uma interrupção na rede e uma falha no nó peer. A razão pela qual isso é importante é que, sem a capacidade de diferenciar os dois casos, você é forçado a escolher o mesmo comportamento em ambos os casos.
O problema de escolher um modo é que não existe uma ação que maximize a disponibilidade e evite a perda de dados.
- Se você optar por assumir que um nó peer está ativo, mas na verdade falha, o cluster interromperá desnecessariamente os serviços que estariam em execução para compensar a perda de serviços do nó peer com falha.
- Se você decidir assumir que um nó está inativo, mas foi apenas uma falha de rede e de fato o nó remoto está funcional, então, na melhor das hipóteses, você estará se inscrevendo para alguma reconciliação manual futura dos conjuntos de dados resultantes.
Independentemente da heurística usada, é trivial criar uma falha que causará falha em ambos os lados ou fará com que o cluster desligue os nós sobreviventes. Não usar o quorum realmente priva o cluster de uma das ferramentas mais poderosas do seu arsenal.
Se não houver outra alternativa, a melhor abordagem é sacrificar a disponibilidade (aqui o autor refere-se ao teorema CAP). A alta disponibilidade de dados corrompidos não ajuda ninguém, e reconciliar manualmente diferentes conjuntos de dados também não é divertido.
Quorum
Quorum parece ótimo, certo?
A única desvantagem é que para tê-lo em um cluster com N membros, você precisa ter uma conexão entre N/2+1 de seus nós restantes. O que não é possível em um cluster de dois nós após a falha de um nó.
O que, em última análise, nos leva ao problema fundamental com dois nós:
Quorum não faz sentido em clusters de dois nós e sem ele é impossível determinar com segurança o curso de ação que maximiza a disponibilidade e evita a perda de dados
Mesmo num sistema de dois nós conectados por um cabo cruzado, é impossível distinguir definitivamente entre uma interrupção da rede e uma falha do outro nó. Desabilitar uma extremidade (cuja probabilidade é, obviamente, proporcional à distância entre os nós) será suficiente para invalidar qualquer suposição de que a saúde do link é igual à saúde do nó parceiro.
Fazendo um cluster de dois nós funcionar
Às vezes o cliente não pode ou não quer adquirir um terceiro nó, e somos obrigados a procurar uma alternativa.
Opção 1 – Método de dissociação duplicado
O dispositivo iLO ou IPMI de um nó representa um ponto de falha porque, se falhar, os sobreviventes não poderão usá-lo para colocar o nó em um estado seguro. Em um cluster de 3 ou mais nós, podemos mitigar isso calculando o quorum e usando um watchdog de hardware (um mecanismo de dissociação indireta, conforme discutido anteriormente). No caso de dois nós, devemos usar unidades de distribuição de energia de rede (PDUs).
Após uma falha, o sobrevivente primeiro tenta entrar em contato com o dispositivo de dissociação primário (iLO ou IPMI incorporado). Se isso for bem-sucedido, a recuperação continuará normalmente. Somente se o dispositivo iLO/IPMI falhar a PDU será acessada; se o acesso for bem-sucedido, a recuperação poderá continuar.
Certifique-se de colocar a PDU em uma rede diferente daquela do tráfego do cluster, caso contrário, uma única falha de rede bloqueará o acesso a ambos os dispositivos de desassociação e bloqueará a restauração dos serviços.
Aqui você pode perguntar: a PDU é um ponto único de falha? Para a qual a resposta é, claro que é.
Se esse risco for significativo para você, você não está sozinho: conecte ambos os nós a duas PDUs e diga ao software de cluster para usar ambos ao ligar e desligar os nós. O cluster agora permanece ativo se uma PDU morrer e uma segunda falha da outra PDU ou do dispositivo IPMI será necessária para bloquear a recuperação.
Opção 2 – Adicionando um Árbitro
Em alguns cenários, embora o método de dissociação duplicada seja tecnicamente possível, é politicamente difícil. Muitas empresas gostam de ter alguma separação entre administradores e proprietários de aplicativos, e administradores de rede preocupados com a segurança nem sempre ficam entusiasmados em compartilhar configurações de acesso à PDU com qualquer pessoa.
Neste caso, a alternativa recomendada é a criação de um terceiro neutro que possa complementar o cálculo do quórum.
No caso de uma falha, um nó deve ser capaz de ver as ondas de rádio de seu par ou árbitro para restaurar os serviços. O árbitro também inclui uma função de desconexão se ambos os nós puderem ver o árbitro, mas não puderem ver um ao outro.
Esta opção deve ser usada em conjunto com um método de dissociação indireta, como um temporizador de watchdog de hardware, que é configurado para encerrar uma máquina se ela perder a conexão com seu nó peer e árbitro. Assim, um sobrevivente pode razoavelmente assumir que seu nó peer estará em um estado seguro após o temporizador de watchdog de hardware expirar.
A diferença prática entre um árbitro e um terceiro nó é que um árbitro requer muito menos recursos para operar e pode potencialmente servir mais de um cluster.
Opção 3 – Fator humano
A abordagem final é que os sobreviventes continuem executando quaisquer serviços que já estavam executando, mas não iniciem novos até que o problema seja resolvido (restauração da rede, reinicialização do nó) ou uma pessoa assuma a responsabilidade de confirmar manualmente que o outro lado está morto.
Opção de bônus
Eu mencionei que você pode adicionar um terceiro nó?
Duas prateleiras
Para efeitos de argumentação, vamos fingir que o convenci dos méritos do terceiro nó, agora devemos considerar a disposição física dos nós. Se eles estiverem alojados (e alimentados) no mesmo rack, isso também constitui SPoF, e não pode ser resolvido adicionando um segundo rack.
Se isso for surpreendente, considere o que aconteceria se um rack com dois nós falhasse e como o nó sobrevivente diferenciaria isso de uma falha na rede.
A resposta curta é que isso não é possível e, novamente, estamos lidando com todos os problemas no caso dos dois nós. Ou sobrevivente:
- ignora o quorum e tenta iniciar incorretamente a restauração durante interrupções na rede (a capacidade de completar a dissociação é uma história diferente e depende se a PDU está envolvida e se eles compartilham energia com algum dos racks), ou
- respeita o quorum e se desconecta prematuramente quando seu nó par falha
Em qualquer caso, dois racks não são melhores que um, e os nós devem receber fontes de alimentação independentes ou ser distribuídos em 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 querer considerar a recuperação de desastres. O que acontece quando um asteroide atinge o mesmo data center com nossos três nós espalhados por três racks diferentes? Obviamente coisas ruins, mas dependendo das suas necessidades, adicionar um segundo data center pode não ser suficiente.
Se feito corretamente, o segundo data center fornecerá (e razoavelmente) uma cópia atualizada e consistente de seus serviços e seus dados. No entanto, como em cenários de dois nós e dois racks, não há informações suficientes no sistema para garantir a disponibilidade máxima e evitar corrupção (ou discrepâncias no conjunto de dados). Mesmo com três nós (ou racks), distribuí-los em apenas dois data centers deixa o sistema incapaz de tomar a decisão correta de maneira confiável no caso de um evento (agora muito mais provável) que ambas as partes não consigam comunicar.
Isto não significa que uma solução de data center duplo nunca seja adequada. Muitas vezes, as empresas desejam que uma pessoa esteja ciente antes de dar o passo extraordinário de mudar para um data center de backup. Lembre-se de que, se quiser automatizar a interrupção, você precisará de um terceiro data center para que o quorum faça sentido (diretamente ou por meio de um árbitro) ou encontrará uma maneira de desligar todos os dados de maneira confiável. Centro.
Fonte: habr.com