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

11

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

Entre os nós é 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 eu estou testando com um ssh-agent 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 cortar a conexão entre as interfaces eth0, ele mata ambos os nós . Eu acho que é um problema com o quorum, porque existem apenas 2 nós. Mas eu não quero adicionar um terceiro nó apenas para o cálculo do quórum certo.

Existe alguma ideia para resolver este problema?

    
por MMore 19.03.2012 / 11:22

4 respostas

20

Esta é uma questão um pouco mais antiga, mas o problema apresentado aqui é baseado em um equívoco sobre como e quando o failover em clusters, especialmente em clusters de dois nós, funciona.

A essência é: Você não pode fazer o teste de failover desabilitando a comunicação entre os dois nós. Isso resultará exatamente no que você está vendo, um cenário de divisão de cérebro com STONITH adicional e mútuo. Se você quiser testar os recursos de proteção, um simples killall -9 corosync no nó ativo será suficiente. Outras formas são crm node fence ou stonith_admin -F .

A partir da descrição não muito completa do cluster (onde está a saída de crm configure show e cat /etc/corosync/corosync.conf ?), parece que você está usando os endereços 10.10.10.xx para mensagens, ou seja, a comunicação do 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 node1 para 172.10.10.1.

Você configurou o STONITH para usar o SSH, o que não é uma boa ideia em si, mas provavelmente você está apenas testando. Eu mesmo nã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" ou algo equivalente.

Agora, o que acontece quando você corta a comunicação do cluster entre os nós? Os nós não veem mais cada nó como vivo e bem, 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. Este é o clássico e temido cenário de cérebro dividido .

Parte disso é certificar-se de que o outro nó, obviamente e presumivelmente falhado, esteja desativado para sempre, e é aí que entra o STONITH. Lembre-se de que ambos agora estão jogando o mesmo jogo: tentando se tornar (ou permanecer) ativo e assumir todos os recursos do cluster, bem como filmar o outro nó na cabeça.

Você provavelmente pode adivinhar o que acontece agora. node1 faz ssh root@node2 "shutdown -h now" e node2 faz 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 ambos os nós estão vivos e funcionando bem, eles não têm problema ao emitir comandos ou receber conexões SSH, portanto, os dois nós disparam um ao outro ao mesmo tempo. Isso mata os dois nós.

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

Eu recomendo a leitura do material no link que é escrito e mantido pelos caras que contribuíram (e ainda contribuem) um grande pedaço do que hoje chamamos de "pilha HA do Linux".

TL; DR : Se você está cortando a comunicação do cluster entre seus nós para testar sua configuração de proteção, você está fazendo errado . Use killall -9 corosync , crm node fence ou stonith_admin -F . Cortar a comunicação do cluster só resultará em um cenário de cérebro dividido, o que pode e irá levar à corrupção de dados.

    
por 17.08.2012 / 01:26
2

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

When ATB is enabled, the cluster can suffer up to 50% of the nodes failing at the same time, in a deterministic fashion. 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.

    
por 18.02.2018 / 00:15
0

Tente ler os clusters de quorum e de dois nós capítulo da documentação do marcapasso.

    
por 19.03.2012 / 13:59
0

Verifique se há cluster de alta disponibilidade usando o marca-passo: link

    
por 20.04.2017 / 19:38