Jak skonfigurować STONITH w 2-węzłowym aktywnym / pasywnym klastrze stymulatora HA z linuksem?

Usiłuję skonfigurować aktywny / pasywny (2 węzły) klaster Linux-HA z corosync i rozrusznikiem serca, aby utrzymać bazę danych PostgreSQL. Działa poprzez DRBD i serwis-ip. Jeśli węzeł 1 ulegnie awarii, węzeł 2 powinien przejąć kontrolę. To samo, jeśli PG działa na węźle 2 i kończy się niepowodzeniem. Wszystko działa dobrze oprócz STONITH.

Między węzłami jest dedykowane połączenie HA (10.10.10.X), więc mam następującą konfigurację interfejsu:

eth0            eth1            host
10.10.10.251    172.10.10.1     node1
10.10.10.252    172.10.10.2     node2

Stonith jest włączony i testuję z agentem ssh, aby zabić węzły.

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

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

Problem polega na tym, że kiedy zerwę połączenie między interfejsami eth0, to zabije oba węzły . Myślę, że jest to problem z kworum, ponieważ są tylko 2 węzły. Ale nie chcę dodawać trzeciego węzła tylko do obliczenia odpowiedniego kworum.

Czy są jakieś pomysły na rozwiązanie tego problemu?

Jest to nieco starsze pytanie, ale przedstawiony tutaj problem opiera się na błędnym przekonaniu o tym, jak i kiedy działa przełączanie awaryjne w klastrach, zwłaszcza w klastrach dwuwęzłowych.

Istotą jest: Nie można wykonać testowania awaryjnego, wyłączając komunikację między dwoma węzłami. W ten sposób powstanie dokładnie to, co widzisz, scenariusz podzielonego mózgu z dodatkowym, wzajemnym STONITH. Jeśli chcesz przetestować możliwości ogrodzenia, wystarczy prosty killall -9 corosyncw aktywnym węźle. Inne sposoby to crm node fencelub stonith_admin -F.

Z niepełnego opisu klastra (gdzie jest wyjście crm configure showi cat /etc/corosync/corosync.conf?) Wydaje się, że używasz adresów 10.10.10.xx do przesyłania wiadomości, tj. Komunikacji Corosync / klastra. Adresy 172.10.10.xx są adresami sieci zwykłymi / usługowymi i można uzyskać dostęp do danego węzła, na przykład za pomocą SSH, przez jego adres 172.10.10.xx. DNS wydaje się także rozpoznawać nazwę hosta węzła, taką jak node1172.10.10.1.

Masz STONITH skonfigurowany do korzystania z SSH, co samo w sobie nie jest zbyt dobrym pomysłem, ale prawdopodobnie dopiero testujesz. Sam go nie użyłem, ale zakładam, że agent SSH STONITH loguje się do drugiego węzła i wydaje polecenie zamknięcia, jak ssh root@node2 "shutdown -h now"lub coś podobnego.

Co się stanie, gdy przerwiesz komunikację w klastrze między węzłami? Węzły nie postrzegają już każdego węzła jako żywego i zdrowego, ponieważ między nimi nie ma już komunikacji. Zatem każdy węzeł zakłada, że ​​jest jedynym, który przeżył jakieś niefortunne zdarzenie i próbuje stać się (lub pozostać) węzłem aktywnym lub głównym. To klasyczny i przerażający scenariusz podzielonego mózgu .

Częściowo ma to na celu upewnienie się, że drugi, najwyraźniej i prawdopodobnie uszkodzony węzeł nie działa na dobre, i tam właśnie wkracza STONITH. Pamiętaj, że oba węzły grają teraz w tę samą grę: próbują stać się (lub pozostać) aktywnymi i wziąć nad wszystkimi zasobami klastra, a także strzelaniem do drugiego węzła w głowie.

Prawdopodobnie możesz zgadnąć, co się teraz stanie. node1robi ssh root@node2 "shutdown -h now"i node2robi ssh root@node1 "shutdown -h now". Nie używa to sieci komunikacyjnej klastra 10.10.10.xx, ale sieć usługową 172.10.10.xx. Ponieważ oba węzły w rzeczywistości żyją i mają się dobrze, nie mają problemu z wydawaniem poleceń lub odbieraniem połączeń SSH, więc oba węzły strzelają do siebie w tym samym czasie. To zabija oba węzły.

Jeśli nie użyjesz STONITH, rozszczepiony mózg może mieć jeszcze gorsze konsekwencje, szczególnie w przypadku DRBD, gdzie możesz zakończyć się tym, że oba węzły staną się Pierwotne. Prawdopodobnie nastąpi uszkodzenie danych, a podzielony mózg należy rozwiązać ręcznie.

Polecam przeczytać materiał na http://www.hastexo.com/resources/hints-and-kinks, który jest napisany i utrzymywany przez facetów, którzy przyczynili się (i nadal wnoszą) dużą część tego, co dzisiaj nazywamy „HA Linux stos".

TL; DR : Jeśli odcinasz komunikację klastrową między swoimi węzłami w celu przetestowania konfiguracji ogrodzenia, robisz to źle . Stosowanie killall -9 corosync, crm node fencelub stonith_admin -Fzamiast. Ograniczenie komunikacji w klastrze spowoduje jedynie scenariusz podziału mózgu, co może prowadzić do uszkodzenia danych.

Możesz spróbować dodać auto_tie_breaker: 1do sekcji kworum pliku /etc/corosync/corosync.conf

Gdy ATB jest włączony, klaster może cierpieć do 50% awarii węzłów w tym samym czasie, w deterministyczny sposób. Partycja klastra lub zestaw węzłów, które nadal pozostają w kontakcie z węzłem o najniższym identyfikatorze, pozostaną quorate. Pozostałe węzły zostaną zapytane.

Spróbuj przeczytać rozdział dotyczący kworum i klastrów dwuwęzłowych w dokumentacji stymulatora.

Sprawdź to dla klastra HA za pomocą Pacemaker: http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Clusters_from_Scratch/index.html