Gerenciamento de quedas de energia e isolamento de rede em um cluster HA

Quais são os diferentes cenários em caso de isolamento de rede num cluster?

Uma única rede

Quando existe um isolamento de rede, o comportamento predefinido é:

• à medida que heartbeats são perdidos para cada nó, cada nó vai para ALONE e executa a aplicação com o seu endereço IP virtual (execução dupla da aplicação que modifica os seus dados locais),
• quando o isolamento é reparado, um nó ALONE é forçado a parar e a resincronizar os seus dados a partir do outro nó,
• no final, o cluster é PRIM-SECOND (ou SECOND-PRIM, de acordo com a deteção de endereço IP virtual duplicado feita pelo Windows).

Duas redes com uma rede de replicação dedicada

Quando existe isolamento de rede, o comportamento com uma rede de replicação dedicada é:

• uma rede de replicação dedicada é implementada numa rede privada,
• Heartbeats na rede de produção são perdidas (rede isolada),
• Heartbeats na rede de replicação estão a funcionar (não é uma rede isolada),
• o cluster permanece no estado PRIM/SECOND.

Uma única rede e um checker split-brain

Quando existe um isolamento de rede, o comportamento com um checker split-brain é:

• um checker split-brain foi configurado com o endereço IP de um testemunha (normalmente um router),
• o checker split-brain funciona quando um servidor passa de PRIM para ALONE ou de SECOND para ALONE,
• em caso de isolamento de rede, antes de ir para ALONE, ambos os nós testam o endereço IP,
• o nó que consegue aceder ao endereço IP vai para ALONE, o outro vai para WAIT,
• Quando o isolamento é reparado, o nó WAIT resincroniza os seus dados e torna-se SECOND.

Nota: Se a testemunha estiver inativa ou desconectada, ambos os nós entram em WAIT e a aplicação deixa de funcionar. É por isso que deve escolher uma testemunha robusta, como um router.

Quais são os diferentes cenários em caso de queda de energia em um cluster?

Falha de energia no nó primário

Quando uma queda de energia interrompe apenas o funcionamento do nó primário:

• Há um failover automático no nó secundário, que fica isolado e reinicia a aplicação.
• Quando o nó 1 é reiniciado, ele se torna SEDOND após a ressincronização dos dados replicados.
• Os papéis de primário e secundário podem ser trocados por um administrador, se necessário.

Falha de energia no nó secundário

Quando uma queda de energia interrompe apenas o nó secundário:

• Não há failover, o nó primário fica isolado e a aplicação continua sua execução no nó 1.
• Quando o nó 2 é reiniciado, ele se torna SEDOND após a ressincronização dos dados replicados.

Queda geral de energia - caso 1

Quando uma queda de energia interrompe o funcionamento de ambos os nós, o comportamento padrão é:

• ambos os nós entram em estado de PARADA,
• Quando o nó 1 é reiniciado, ele não entra no estado ALONE e não reinicia o aplicativo porque não sabe se possui os dados atualizados. Portanto, ele entra no estado WAIT, aguardando a reinicialização do outro nó.
• Quando o nó 2 é reiniciado, ambos os nós retornam aos seus estados PRIM/SECOND anteriores.

Queda geral de energia - caso 2

Quando uma queda de energia interrompe ambos os nós, o comportamento com syncdelta é o seguinte:

• O parâmetro syncdelta está configurado, por exemplo, para 10 minutos, o que significa que o início de um nó é aceito mesmo que seus dados estejam 10 minutos atrasados em relação à última sincronização.
• Quando o nó 1 é reiniciado, ele entra no modo ALONE e reinicia o aplicativo, desde que a reinicialização seja feita em até 10 minutos após a falha de energia.
• Quando o nó 2 é reiniciado, ele se torna o SEGUNDO após a ressincronização dos dados replicados.
• Observação: se o nó 2 for reiniciado primeiro, ele se tornará o único nó em execução e o nó 1 se tornará o segundo nó em execução ao iniciar.

🔍 Explore o SafeKit

Encontre informações sobre as funcionalidades, arquiteturas, vídeos, documentação e a versão de teste gratuita do SafeKit.