Olá, Habr! Apresento a vocês a tradução do artigo do autor Andrew Beekhof.
Muitas pessoas preferem clusters com dois nós, pois parecem mais simples conceitualmente e também são 33% mais baratos do que seus irmãos de três nós. Embora seja possível montar um bom cluster com dois nós, na maioria dos casos, devido a cenários não considerados, essa configuração criará muitos problemas não evidentes.
O primeiro passo para criar qualquer sistema de alta disponibilidade é identificar e tentar eliminar os pontos únicos de falha, muitas vezes abreviados como SPoF (ponto único de falha).
É importante lembrar que em qualquer sistema não é possível eliminar todos os riscos de downtime. Isso decorre, pelo menos, do fato de que a proteção típica contra risco envolve a introdução de certa redundância, o que aumenta a complexidade do sistema e cria novos pontos de falha. Portanto, inicialmente, fazemos compromissos e nos concentramos em eventos relacionados a pontos únicos de falha, em vez de cadeias de eventos inter-relacionados e, portanto, cada vez menos prováveis.
Considerando os compromissos, não buscamos apenas SPoF, mas também equilibramos riscos e consequências; como resultado, o que é crítico pode diferir para cada implantação.
Nem todos precisam de fornecedores alternativos de energia com linhas de transmissão independentes. Embora a paranoia tenha se justificado pelo menos para um cliente, quando sua monitoração detectou um transformador defeituoso. O cliente ligou tentando avisar a empresa de energia, até que o transformador defeituoso explodiu.
Um ponto de partida natural é ter mais de um nó no sistema. No entanto, antes que o sistema possa mover serviços para o nó sobrevivente após a falha, em geral, é necessário garantir que os serviços movidos não estejam ativos em outro lugar.
Um cluster de dois nós não tem desvantagens se, como resultado de uma falha, ambos os nós gerenciam o mesmo site web estático. No entanto, tudo muda se, como resultado, ambos os lados gerenciam uma fila de tarefas compartilhada de forma independente ou fornecem acesso de gravação não coordenado a um banco de dados replicado ou a um sistema de arquivos compartilhado.
Portanto, para evitar a corrupção de dados como resultado da falha de um nó - confiamos no que chamamos de «fencing» (cercamento).
O princípio do cercamento
O princípio do cercamento está baseado na questão: um nó concorrente pode causar a corrupção de dados? Se a corrupção de dados for um cenário provável - uma boa solução será isolar o nó tanto de solicitações de entrada quanto de armazenamento persistente. A abordagem mais comum ao cercamento é desconectar nós falhos.
Existem duas categorias de métodos de cercamento que eu chamarei de diretos e indiretos, mas igualmente podem ser chamados de ativos e passivos. Os métodos diretos incluem ações por parte dos nós remanescentes, como interagir com o dispositivo IPMI (Intelligent Platform Management Interface — interface para monitoramento e gerenciamento remoto do estado físico do servidor) ou iLO (meio de gerenciamento de servidores na ausência de acesso físico a eles), enquanto os métodos indiretos dependem do nó falhado para reconhecer de alguma forma que está em estado insalubre (ou, pelo menos, impede que os outros membros se recuperem) e sinalizar sobre a necessidade de desconectar o nó falhado.
O quórum ajuda no uso tanto dos métodos diretos quanto dos indiretos.
Cercamento direto
No caso de cercamento direto, podemos usar o quórum para evitar corridas de cercamento em caso de falha na rede.
Tendo a concepção de quórum, o sistema possui informações suficientes (mesmo sem conexão com seus parceiros) para que os nós saibam automaticamente se devem iniciar o cercamento e/ou recuperação.
Sem quórum, ambas as partes da separação de rede pressupõem justificadamente que a outra parte está inativa e tentarão se desassociar uma da outra. No pior cenário, ambos os lados conseguem desligar todo o cluster. Um cenário alternativo é um 'deathmatch', um ciclo infinito de nós aparecendo, não vendo seus pares, reinicializando-os e iniciando a recuperação apenas para reiniciar quando seu par segue a mesma lógica.
O problema da desassociação é que os dispositivos mais frequentemente utilizados ficam indisponíveis devido aos mesmos eventos de falha que queremos direcionar para a recuperação. A maioria dos cartões IPMI e iLO está instalada em hosts que eles controlam e, por padrão, utilizam a mesma rede, levando os nós alvo a acreditar que os outros nós estão offline.
Infelizmente, as características de operação dos dispositivos IPMI e iLO raramente são consideradas no momento da compra de equipamentos.
Desassociação indireta
O quórum também é importante para gerenciar desassociações indiretas; se tudo for feito corretamente, o quórum pode permitir que os sobreviventes assumam que os nós perdidos, após um certo período, passarão para um estado seguro.
Com essa configuração, o timer do hardware watchdog é reiniciado a cada N segundos, se o quórum não for perdido. Se o timer (geralmente várias vezes N) expirar, o dispositivo executa um desligamento sem graça (não shutdown).
Essa abordagem é muito eficaz, mas sem quórum para gerenciá-la, há informação insuficiente dentro do cluster. Não é fácil distinguir entre a perda de rede e a falha do nó parceiro. A razão pela qual isso é importante é que, sem a capacidade de distinguir entre os dois casos, você é forçado a escolher o mesmo modo de comportamento em ambas as situações.
O problema de escolher um único modo é que não existe um curso de ação que maximize a disponibilidade e previna a perda de dados.
- Se você decidir supor que o nó parceiro está ativo, mas na verdade ocorreu uma falha, o cluster desligará excessivamente serviços que deveriam estar ativos para compensar a perda dos serviços do nó parceiro falhado.
- Se você decidir supor que um nó está inativo, mas foi apenas uma queda de rede e, na verdade, o nó remoto está funcionando, então, no melhor dos casos, você está se inscrevendo para alguma futura verificação manual dos conjuntos de dados resultantes.
Independentemente da heurística que você usa, é trivial criar uma falha que faça ambas as partes funcionarem ou faça o cluster desligar os nós sobreviventes. Não usar o quórum realmente priva o cluster de uma das ferramentas mais poderosas em seu arsenal.
Caso não haja outra alternativa, a melhor abordagem será sacrificar a disponibilidade (aqui o autor se refere ao teorema CAP). Alta disponibilidade de dados corrompidos não ajuda ninguém, e a verificação manual de vários conjuntos de dados também não é agradável.
Quórum
Quórum soa bem, não é?
A única desvantagem é que, para tê-lo em um cluster com N membros, você precisa ter uma conexão entre N / 2 + 1 dos seus nós. O que é impossível em um cluster com dois nós após a falha de um nó.
Isso, em última análise, nos leva ao problema fundamental dos clusters de dois nós:
o quórum não faz sentido em clusters de dois nós, e sem isso é impossível determinar de forma confiável o curso de ação que maximize a disponibilidade e previna a perda de dados.
Mesmo em um sistema de dois nós, conectados por um cabo cruzado, não é possível distinguir definitivamente entre uma queda de rede e a falha de outro nó. A desconexão de uma extremidade (a probabilidade da qual é, sem dúvida, proporcional à distância entre os nós) será suficiente para refutar qualquer suposição de que a operabilidade do canal é 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 comprar um terceiro nó, e somos forçados a buscar uma alternativa.
Opção 1 — Método de duplicação por divisão
O dispositivo iLO ou IPMI do nó representa um ponto de falha, pois, em caso de falha, os nós restantes não podem usá-lo para colocar o nó em um estado seguro. Em um cluster de 3 ou mais nós, podemos mitigar isso calculando o quórum e utilizando o hardware watchdog (mecanismo de desligamento indireto, como discutido anteriormente). No caso de dois nós, devemos usar em vez disso as unidades de distribuição de energia (power distribution units ou PDUs).
Após uma falha, o nó sobrevivente tenta primeiro se conectar ao dispositivo principal de desligamento (iLO ou IPMI incorporado). Se for bem-sucedido, a recuperação continua normalmente. Somente no caso de falha do dispositivo iLO / IPMI é que a PDU é acionada; se a conexão for bem-sucedida, a recuperação pode prosseguir.
Certifique-se de colocar a PDU em uma rede diferente do tráfego do cluster; caso contrário, uma única falha na rede bloqueará o acesso tanto aos dispositivos de desligamento quanto a restauração dos serviços.
Aqui você pode perguntar – o dispositivo PDU não é um único ponto de falha? A resposta é — claro que é.
Se esse risco é significativo para você — você não está sozinho: conecte ambos os nós a duas PDUs e configure o software de cluster para usar ambas ao ligar e desligar os nós. Agora o cluster permanece ativo se uma PDU falhar, e para bloquear a recuperação será necessária uma segunda falha, seja de outra PDU ou do dispositivo IPMI.
Opção 2 — Adição de um árbitro
Em alguns cenários, embora tecnicamente seja possível um método de desligamento duplicado, ele é politicamente complicado. Muitas empresas gostam de ter uma certa separação entre administradores e proprietários de aplicativos, e administradores de rede preocupados com a segurança nem sempre ficam entusiasmados em passar a alguém os parâmetros de acesso à PDU.
Nesse caso, a alternativa recomendada é criar uma terceira parte neutra que possa complementar o cálculo do quórum.
Em caso de falha, o nó deve ser capaz de ver o estado de seu parceiro 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 se veem mutuamente.
Esta opção deve ser usada em conjunto com um método indireto de isolamento, como um timer de watchdog de hardware, que é configurado para desligar a máquina se ela perder a conexão com seu nó parceiro e o árbitro. Assim, o sobrevivente pode presumir com uma confiança suficiente que seu nó parceiro estará em um estado seguro após a expiração do timer de watchdog de hardware.
A diferença prática entre o árbitro e o terceiro nó é que o árbitro requer muito menos recursos para seu funcionamento e, potencialmente, pode servir a mais de um cluster.
Opção 3 - Fator humano
A última abordagem é que os sobreviventes continuem a realizar quaisquer serviços que já estavam realizando, mas não iniciar novos, até que o problema seja resolvido (recuperação da rede, reinicialização do nó) ou que um ser humano assuma a responsabilidade de confirmar manualmente que o outro lado está inativo.
Opção bônus
Eu já mencionei que você pode adicionar um terceiro nó?
Duas estantes
Para fins de argumentação, vamos supor que eu te convença dos méritos de um terceiro nó; agora precisamos considerar a localização física dos nós. Se eles estiverem localizados (e recebendo energia) na mesma estante, isso também representa um SPoF, e uma que não pode ser resolvida apenas adicionando uma segunda estante.
Se isso é surpreendente, pense no que acontecerá se a estante com dois nós falhar e como o nó sobrevivente diferenciará esse caso de uma falha de rede.
A resposta curta: isso é impossível, e novamente lidamos com todos os problemas do caso de dois nós. Ou o sobrevivente:
- ignora o quórum e tenta incorretamente iniciar a recuperação durante as interrupções na rede (a possibilidade de um isolamento é uma história à parte e depende se o PDU está envolvido e se eles compartilham energia com alguma das estantes), ou
- respeita o quórum e desliga prematuramente a si mesmo quando seu nó parceiro falha.
De qualquer forma, duas estantes não são melhores do que uma, e os nós devem ou receber fontes de energia independentes ou ser distribuídos em três (ou mais, dependendo de quantos nós você tem) estantes.
Dois data centers
Neste ponto, leitores que já não estão inclinados ao risco podem considerar a recuperação após uma falha. O que acontece quando um asteroide atinge um datacenter com nós distribuídos em três racks diferentes? É evidente que serão problemas sérios, mas, dependendo das suas necessidades, adicionar um segundo datacenter pode não ser suficiente.
Se tudo for feito corretamente, o segundo datacenter lhe proporciona (e isso é sensato) uma cópia atualizada e consistente dos seus serviços e dados. No entanto, assim como em cenários com dois nós e dois racks, o sistema carece de informações suficientes para garantir alta disponibilidade e evitar danos (ou divergências nos conjuntos de dados). Mesmo com três nós (ou racks), a distribuição apenas em dois datacenters deixa o sistema incapaz de tomar decisões corretas de forma confiável em caso de um evento (agora muito mais provável) que ambas as partes não consigam conectar.
Isso não significa que a solução de dois datacenters nunca é adequada. As empresas frequentemente desejam que alguém esteja ciente antes de tomar uma medida excepcional ao transferir para um datacenter de backup. Apenas tenha em mente que, se você deseja automatizar a falha, precisará de um terceiro datacenter para que o quórum faça sentido (diretamente ou através de um árbitro), ou precisará encontrar uma maneira de desligar todo o datacenter de forma confiável.
Fonte: habr.com
