Come impostare STONITH in un cluster di pacemaker HA Linux attivo / passivo a 2 nodi?

Sto cercando di configurare un cluster Linux-HA attivo / passivo (2 nodi) con corosync e pacemaker per mantenere attivo e funzionante un database PostgreSQL. Funziona tramite DRBD e un service-ip. Se nodo1 fallisce, nodo2 dovrebbe subentrare. Lo stesso se PG viene eseguito su node2 e non riesce. Tutto funziona bene tranne la cosa STONITH.

Tra i nodi c'è una connessione HA dedicata (10.10.10.X), quindi ho la seguente configurazione dell'interfaccia:

eth0            eth1            host
10.10.10.251    172.10.10.1     node1
10.10.10.252    172.10.10.2     node2

Stonith è abilitato e sto testando con un agente ssh per uccidere i nodi.

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 Spettacoli:

============
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 ]

Il problema è: quando taglio la connessione tra le interfacce eth0, uccide entrambi i nodi . Penso che sia un problema con il quorum, perché ci sono solo 2 nodi. Ma non voglio aggiungere un terzo nodo solo per il calcolo del quorum giusto.

Ci sono idee per risolvere questo problema?

Questa è una domanda leggermente più vecchia, ma il problema presentato qui si basa su un'idea sbagliata di come e quando funziona il failover nei cluster, in particolare i cluster a due nodi.

L'essenza è: non è possibile eseguire test di failover disabilitando la comunicazione tra i due nodi. Ciò comporterà esattamente ciò che stai vedendo, uno scenario a cervello diviso con STONITH reciproco aggiuntivo. Se vuoi testare le capacità di scherma, killall -9 corosynclo farà un semplice nodo attivo. Altri modi sono crm node fenceo stonith_admin -F.

Dalla descrizione non del tutto completa del tuo cluster (dov'è l'output di crm configure showe cat /etc/corosync/corosync.conf?) Sembra che tu stia utilizzando gli indirizzi 10.10.10.xx per la messaggistica, cioè la comunicazione Corosync / cluster. Gli indirizzi 172.10.10.xx sono i tuoi indirizzi di rete regolari / di servizio e accedi a un determinato nodo, ad esempio utilizzando SSH, tramite il suo indirizzo 172.10.10.xx. Il DNS sembra anche risolvere un nome host nodo come node1172.10.10.1.

STONITH è configurato per utilizzare SSH, che non è una buona idea in sé, ma probabilmente stai solo testando. Non l'ho usato da solo, ma presumo che l'agente SSH STONITH acceda all'altro nodo ed emetta un comando di arresto, come ssh root@node2 "shutdown -h now"o qualcosa di equivalente.

Ora, cosa succede quando si interrompe la comunicazione del cluster tra i nodi? I nodi non vedono più ogni nodo come vivo e vegeto, perché non c'è più comunicazione tra di loro. Quindi ogni nodo presuppone che sia l'unico sopravvissuto di qualche evento sfortunato e cerca di diventare (o rimanere) il nodo attivo o primario. Questo è lo scenario classico e temuto del cervello diviso .

Parte di questo è assicurarsi che l'altro nodo, ovviamente e presumibilmente fallito, non sia attivo, ed è qui che entra in gioco STONITH. Tieni presente che entrambi i nodi stanno giocando allo stesso gioco: cercando di diventare (o rimanere) attivo e prendere su tutte le risorse del cluster, oltre a sparare all'altro nodo in testa.

Probabilmente puoi indovinare cosa succede ora. node1fa ssh root@node2 "shutdown -h now"e node2fa ssh root@node1 "shutdown -h now". Questo non utilizza la rete di comunicazione del cluster 10.10.10.xx ma la rete di servizio 172.10.10.xx. Dato che entrambi i nodi sono effettivamente vivi e funzionanti, non hanno problemi a inviare comandi o ricevere connessioni SSH, quindi entrambi i nodi si sparano contemporaneamente. Questo uccide entrambi i nodi.

Se non usi STONITH, un cervello diviso potrebbe avere conseguenze anche peggiori, specialmente in caso di DRBD, dove potresti finire con entrambi i nodi che diventano Primari. È probabile che si verifichi una corruzione dei dati e che il cervello diviso debba essere risolto manualmente.

Consiglio di leggere il materiale su http://www.hastexo.com/resources/hints-and-kinks che è scritto e gestito dai ragazzi che hanno contribuito (e continuano a contribuire) una grande parte di ciò che oggi chiamiamo "Linux HA pila".

TL; DR : se si sta tagliando la comunicazione del cluster tra i nodi per testare la configurazione della scherma, si sta facendo male . Usa killall -9 corosync, crm node fenceo stonith_admin -Finvece. La riduzione della comunicazione tra cluster si tradurrà solo in uno scenario a cervello diviso, che può e porterà alla corruzione dei dati.

Potresti provare ad aggiungere auto_tie_breaker: 1nella sezione quorum di /etc/corosync/corosync.conf

Quando ATB è abilitato, il cluster può subire un errore fino al 50% dei nodi contemporaneamente, in modo deterministico. La partizione del cluster o l'insieme di nodi che sono ancora in contatto con il nodo con il nodoid più basso rimarranno quorate. Gli altri nodi saranno interrogati.

Prova a leggere il capitolo Quorum e cluster a due nodi della documentazione di Pacemaker.

Controlla questo per cluster HA usando Pacemaker: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html