Como configurar o STONITH em um cluster de marcapasso HA ativo / passivo de 2 nós?

Estou tentando configurar um cluster Linux / HA ativo / passivo (2 nós) com corosync e pacemaker para manter um banco de dados PostgreSQL em funcionamento. Funciona via DRBD e um IP de serviço. Se o nó1 falhar, o nó2 deverá assumir o controle. O mesmo se o PG for executado no nó2 e falhar. Tudo funciona bem, exceto a coisa STONITH.

Entre os nós há uma conexão HA dedicada (10.10.10.X), então eu tenho a seguinte configuração de interface:

eth0            eth1            host
10.10.10.251    172.10.10.1     node1
10.10.10.252    172.10.10.2     node2

O Stonith está ativado e estou testando com um agente ssh para matar nós.

crm configure property stonith-enabled=true
crm configure property stonith-action=poweroff
crm configure rsc_defaults resource-stickiness=100
crm configure property no-quorum-policy=ignore

crm configure primitive stonith_postgres stonith:external/ssh \
                params hostlist="node1 node2"
crm configure clone fencing_postgres stonith_postgres

crm_mon -1 mostra:

============
Last updated: Mon Mar 19 15:21:11 2012
Stack: openais
Current DC: node2 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
4 Resources configured.
============

Online: [ node2 node1 ]

Full list of resources:

 Master/Slave Set: ms_drbd_postgres
     Masters: [ node1 ]
     Slaves: [ node2 ]
 Resource Group: postgres
     fs_postgres        (ocf::heartbeat:Filesystem):    Started node1
     virtual_ip_postgres        (ocf::heartbeat:IPaddr2):       Started node1
     postgresql (ocf::heartbeat:pgsql): Started node1
 Clone Set: fencing_postgres
     Started: [ node2 node1 ]

O problema é: quando eu corto a conexão entre as interfaces eth0, ele mata os dois nós . Eu acho que é um problema com o quorum, porque existem apenas 2 nós. Mas não quero adicionar um terceiro nó apenas para o cálculo do quorum certo.

Há alguma idéia para resolver esse problema?

Essa é uma pergunta um pouco mais antiga, mas o problema aqui apresentado baseia-se em um equívoco sobre como e quando o failover em clusters, especialmente clusters de dois nós, funciona.

A essência é: você não pode fazer o teste de failover desativando a comunicação entre os dois nós. Fazer isso resultará exatamente no que você está vendo, num cenário de cérebro dividido com STONITH adicional e mútuo. Se você quiser testar os recursos de esgrima, será necessário um simples killall -9 corosyncnó ativo. Outras maneiras são crm node fenceou stonith_admin -F.

A partir da descrição não muito completa do seu cluster (onde está a saída crm configure showe cat /etc/corosync/corosync.conf?), Parece que você está usando os endereços 10.10.10.xx para mensagens, ou seja, comunicação Corosync / cluster. Os endereços 172.10.10.xx são seus endereços de rede regulares / de serviço e você acessaria um determinado nó, por exemplo, usando SSH, por seu endereço 172.10.10.xx. O DNS também parece resolver um nome de host do nó como node1172.10.10.1.

Você configurou o STONITH para usar o SSH, o que não é uma boa ideia, mas provavelmente está apenas testando. Eu não o usei, mas presumo que o agente SSH STONITH efetue login no outro nó e emita um comando de desligamento, como ssh root@node2 "shutdown -h now"algo equivalente.

Agora, o que acontece quando você reduz a comunicação de cluster entre os nós? Os nós não veem mais cada nó como ativo e bom, porque não há mais comunicação entre eles. Assim, cada nó assume que é o único sobrevivente de algum evento infeliz e tenta se tornar (ou permanecer) o nó ativo ou primário. Esse é o cenário clássico e temido do cérebro dividido .

Parte disso é garantir que o outro nó, obviamente e presumivelmente com falha, esteja inoperante definitivamente, e é aí que entra o STONITH. Lembre-se de que os dois nós estão jogando o mesmo jogo: tentando se tornar (ou permanecer) ativo e tomar sobre todos os recursos do cluster, além de fotografar o outro nó na cabeça.

Você provavelmente pode adivinhar o que acontece agora. node1faz ssh root@node2 "shutdown -h now"e node2faz ssh root@node1 "shutdown -h now". Isso não usa a rede de comunicação do cluster 10.10.10.xx, mas a rede de serviço 172.10.10.xx. Como os dois nós estão de fato vivos e bem, eles não têm problemas ao emitir comandos ou ao receber conexões SSH; portanto, os dois nós disparam um no outro ao mesmo tempo. Isso mata os dois nós.

Se você não usar STONITH, um cérebro dividido pode ter consequências ainda piores, especialmente no caso de DRBD, onde você pode acabar com os dois nós se tornando Primários. É provável que ocorra corrupção de dados e o cérebro dividido deve ser resolvido manualmente.

Eu recomendo a leitura do material em http://www.hastexo.com/resources/hints-and-kinks, que é escrito e mantido pelos caras que contribuíram (e ainda contribuem) com uma grande parte do que hoje chamamos de "o Linux HA pilha".

TL; DR : se você estiver cortando a comunicação de cluster entre os nós para testar sua configuração de esgrima, estará fazendo errado . Use ou killall -9 corosync, em vez disso. Cortar a comunicação do cluster resultará apenas em um cenário de cérebro dividido, o que pode e levará à corrupção de dados.crm node fencestonith_admin -F

Você pode tentar adicionar auto_tie_breaker: 1na seção de quorum do /etc/corosync/corosync.conf

Quando o ATB está ativado, o cluster pode sofrer até 50% dos nós com falha ao mesmo tempo, de maneira determinística. A partição do cluster ou o conjunto de nós que ainda estão em contato com o nó com o ID do nó mais baixo permanecerá quorado. Os outros nós serão consultados.

Tente ler o capítulo Quorum e clusters de dois nós da documentação do pacemaker.

Verifique isso no cluster de alta disponibilidade usando o Pacemaker: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html