HA do Corosync impedindo o cenário de cérebro dividido

Question

Estou configurando um sistema de teste para auto-aprendizagem sobre balanceamento de carga e alta disponibilidade e estou curioso sobre uma configuração no Corosync e gostaria de saber o que vocês, que têm experiência, têm a dizer.

A coisa que estou pesquisando e aprendendo agora é o quórum de voto do Corosync e como lidar com nós perdidos. Durante uma pequena sessão de pesquisa, encontrei conversas sobre STONITH e cenários de cérebro dividido, onde ambos os nós presumirão que ele é o único sobrevivente, e pensa que é o mestre, tenta permanecer mestre, etc. Este é, obviamente, um cenário indesejado.

Na configuração do Corosync, vi uma configuração específica:

quorum {
        ...
        auto_tie_breaker: 1
        auto_tie_breaker_node: lowest
}

O auto_tie_breaker pode impedir esse cenário de divisão de cérebros ou estou enganado?

Se eu entendi a documentação correta, defini-la como a mais baixa, significa que o nó com o menor nodeide seria o responsável?

nodelist {
          node {
          ring0_addr: primary_private_ip
          name: primary
          nodeid: 1
          }

          node {
          ring0_addr: secondary_private_ip
          name: secondary
          nodeid: 2
          }
}

Claro, estou testando apenas um cluster de dois nós no momento, mas com o objetivo de entender como o processo funciona, para que eu possa configurar com sucesso uma infraestrutura mais confiável no futuro.

Obrigado pela contribuição e orientação e tenha um ótimo dia! :)

    

Answer 1

Você está correto supondo que auto_tie_breaker tentará resolver uma falha de nó em configurações de nó pares (1/1, 1/1/1/1, etc.) "forçando" o cluster a permanecer conectado a o conjunto correto de nós (ou um único nó em dois clusters de nós).

The general behaviour of votequorum allows a simultaneous node failure up to 50% - 1 node, assuming each node has 1 vote.

When ATB is enabled, the cluster can suffer up to 50% of the nodes failing at the same time, in a deterministic fashion. By default the cluster partition, or the set of nodes that are still in contact with the node that has the lowest nodeid will remain quorate. The other nodes will be inquorate. This behaviour can be changed by also specifying

Os votos de quorum para clusters geralmente precisavam ser usados em cenários de n + 1 nós ou com o parâmetro two_node , em que expected_votes tinha que ser definido como 2 e fence de hardware / STONITH tinha que estar ativado.

auto_tie_breaker_node: lowest|highest|<list of node IDs>

'lowest' is the default, 'highest' is similar in that if the current set of nodes contains the highest nodeid then it will remain quorate. Alternatively it is possible to specify a particular node ID or list of node IDs that will be required to maintain quorum. If a (space-separated) list is given, the nodes are evaluated in order, so if the first node is present then it will be used to determine the quorate partition, if that node is not in either half (ie was not in the cluster before the split) then the second node ID will be checked for and so on. ATB is incompatible with quorum devices - if auto_tie_breaker is specified in corosync.conf then the quorum device will be disabled.

Lembre-se: não é um dispositivo STONITH e você não pode usá-lo com a diretiva two_node

two_node: 1

Enables two node cluster operations (default: 0).

The "two node cluster" is a use case that requires special consideration. With a standard two node cluster, each node with a single vote, there are 2 votes in the cluster. Using the simple majority calculation (50% of the votes + 1) to calculate quorum, the quorum would be 2. This means that the both nodes would always have to be alive for the cluster to be quorate and operate.

Enabling two_node: 1, quorum is set artificially to 1

Portanto, o novo método go-to para clusters de nó mesmo sem fence de hardware ou STONITH é auto_tie_breaker .

Em n + 1 clusters, os votos de quorum ainda são bastante confiáveis, mas para o high-profile linux HA, o fence de hardware / STONITH deve permanecer rei.

Como sempre, teste todos os cenários possíveis, como interrupção de rede, falha de hardware, perda de energia, erro de recursos simultâneos, erros de DRBD (se usados), etc. e leia este documento sobre os "novos" recursos do corosync.