STONITH – když se oba nody HA clusteru nedohodnout a musí se vzájemně sestřelit

STONITH je mechanismus k řešení sporů ohledně přístupu ke zdrojům/službám clusteru. V rámci clusteru se musí vždy jednotlivé uzly dohodnout kde která služba poběží – tzv. fencing. Pokud se uzly dohodnou, vše je v pořádku. Když se náhodou nedohodnou, přijde ke slovu STONITH – sestřelení protějšího uzlu, který danou službu zadržuje a nechce vydat.

Konkrétní případ:

Při konfiguraci NFS clusteru jsem nastavil všechny potřebné služby – spouštění DRDB, LVM, Filesystem, IP adresy pro NFS a NFS samotné. DRBD je v režimu primary/slave = služba může běžet pouze na jednom z uzlů clusteru. Při studeném startu clusteru vše naběhlo správně a fungovalo, ovšem při migraci služby mezi uzly clusteru vždy nastala situace, že stávající aktivní uzel nechtěl uvolnit souborový systém aby se odmountoval a proto nešlo přehodit DRBD na druhý uzel. Cluster to vyřešil jednoduše – několikrát zkusil zda umount projde a když zjistil, že ne tak odstřelil porouchaný uzel (ten který nechtěl uvolnit filesystem).

Cluster po odstřelení vadného uzlu mohl správně nahodit DRDB, LVM, přimountovat souborový systém, nahodit IP a nfsd a vše bylo v pořádku. Tedy dokud jsem nechtěl zase přemigrovat služby zpátky po naběhnutí odstřeleného uzlu – vše se opakovalo.

STONITH mechanismus v tomto případě “řešil” situaci rozbitého skriptu pro nfs. Závadu jsem vyřešil – opravil jsem rozbitý skript pro ovládání NFS. Skript pro ovládání NFS totiž při ukončení nechal běžet některé procesy a ty neuvolnily souborový systém. Na tom všem to selhávalo.

Má konfigurace STONITH je následující:

Servery a jejich management rozhraní přístupné po síti přes IPMI:

• server: node0.domain.tld, IPMI: 179.100.1.72
• server: node1.domain.tld, IPMI: 179.100.1.70

V management rozhraní každého serveru jsem vytvořil uživatele “stonith” s právy pro restart serveru.
Přes program crmadmin jsem v konfiguraci CRM vytvořil 2x stonith resource – vždy pro daný server. Pomocí pravidel (location) jsem každý resource umístil na protější uzel – tak aby služba pro restart barzini.klenot.eu běžela na uzlu tommasino a naopak.

primitive stonith-node1 stonith:external/ipmi \
        params hostname="node1.domain.tld" ipaddr="179.100.1.70"\
                      userid="stonith" passwd="HESLO" interface="lan"
primitive stonith-node0 stonith:external/ipmi \
        params hostname="node0.domain.tld" ipaddr="179.100.1.72"\
                      userid="stonith" passwd="HESLO" interface="lan"
location loc-stonith-node1 stonith-node1 \
        rule $id="loc-stonith-node1-rule" -inf: #uname ne node0.domain.tld
location loc-stonith-node0 stonith-node0 \
        rule $id="loc-stonith-node0-rule" -inf: #uname ne node1.domain.tld

Postup úpravy konfigurace clusteru

Nejdříve si vypíšu dostupné stonith moduly:

[root@barzini ~]# crm ra list stonith
apcmaster               apcsmart                baytech
bladehpi                cyclades                external/drac5
external/hmchttp        external/ibmrsa         external/ibmrsa-telnet
external/ipmi           external/kdumpcheck     external/rackpdu
external/riloe          external/sbd            external/ssh
external/vmware         external/xen0           external/xen0-ha
ibmhmc                  ipmilan                 meatware
null                    nw_rpc100s              rcd_serial
rps10                   ssh                     suicide
wti_nps                 

Protože mám dostupné IPMI na serverech přes lokální síť, použiju external/ipmi modul. Možnosti konfigurace modulu zjistím následujícím příkazem:

[root@barzini ~]# crm ra meta external/ipmi stonith
IPMI STONITH external device (stonith:external/ipmi)

IPMI-based host reset

Parameters (* denotes required, [] the default):

hostname (string): Hostname
    The name of the host to be managed by this STONITH device

ipaddr (string): IP Address
    The IP address of the STONITH device

userid (string): Login
    The username used for logging in to the STONITH device

passwd (string): Password
    The password used for logging in to the STONITH device

interface (string): IPMI interface
    IPMI interface to use, such as "lan" or "lanplus"

Operations' defaults (advisory minimum):

    start    timeout=15
    stop     timeout=15
    status   timeout=15
    monitor  timeout=15 interval=15

Spustím tedy konfiguraci a napíši potřebné “příkazy” pro vytvoření stonith zařízení, výsledek mohu ověřovat příkazem “show”, který vypíše aktuální stav. Konfiguraci potvrdím příkazem “commit” a protože pracuji na živé konfiguraci běžícího clusteru, budou okamžitě nově vytvořená zařízení stonith spuštěna na správných uzlech clusteru:

[root@barzini ~]# crm configure
crm(live)configure# primitive stonith...
...
...
crm(live)configure# commit

Na závěr by bylo vhodné STONITH otestovat – pro základní test stačí na jednom z uzlů násilně zabít heartbeat pomocí “pkill -9 heartbeat”.

Další témata