Dotaz: Linux cluster - stonith / fencing

[Odpadlik]

Není tu náhodou někdo kdo rozumí clusterům, konkrétně pacemaker/stonith/fencing? Docela rád bych věděl, proč je třeba u HA clusteru s GFS2 nutno toto konfigurovat...

---

---

Odpovědi

[DarkKnight]

Co udela cluster, kdyz se spojeni prerusi mezi jednotlivymi uzly? Da se predpokladat, ze i kdyz ma node minoritni quorum, tak porad na nej muze nekdo zkusit zapsat, cimz by doslo k nekonzistenci dat (ktera jsou platna, na prvni casti rozpadleho clusteru, nebo na druhe?).

Z tohoto duvodu se prave aplikuje STONITH - pokud nema ta cast rozpadleho clusteru majoritni quorum, zabij ho (neresi problemy, kdy se rozpoji vsechny uzly najednou). To je i duvod, proc se u dvouuzlovych clusteru (velmi pitomy napad - kvuli split-brainu) STONITH vypina.

[Odpadlik]

To je sice pravda, ale v případě HA clusteru je to k ničemu. GFS2 je sdílený FS - tzn tam se předpokládá, že resource užívají oba uzly zároveň. Tj můj dotaz to neodpovídá.

[Lyco]

GFS2 sice může být sdílený FS, ale to ještě neznamená, že je schopný dlouhodobě bezpečného provozu bez spojení mezi jednotlivými uzly. Podle dokumentace to vypadá, že nody které ztratí quorum přestanou pracovat, ale nenašel jsem co to přesně znamená - pokud zůstanou read-only, můžou aplikace vidět zastaralá data, což je problém pokud někdo (klienti aplikací s daty na GFS2 a pod.) vidí data z obou stran clusteru. I pokud by tam tenhle problém nebyl, je tu pořád riziko chyb v programu, v částech kter jsou míň otestované než to co běží v normálním provozu.

Navíc, to že server neodpovídá před timeoutem (a to je obvykle jediná věc kterou o něm ostatní můžou zjistit) neznamená, že nic nedělá. Krom toho, že může prostě pracovat pomalu nebo nedělat nic, může být taky vážně rozbitý a aktivně ničit data. (To jsem reálně viděl, naštěstí v nekritické věci - chyba v kernelu způsobila, že MySQL server spadl, ale před tím do logu zapsal několik MB nulových bytů. Kdyby to byl binlog, tak rozbije repliku.) V případě, že se o něm ví, že neodpovídá, je nejjistější ho prostě zabít.

Obecně, většina distribuovaných systémů předpokládá, že se věci pokazí jen tak, že něco přestane pracovat (fail-stop model): packet se ztratí nebo opozdí, server se restartuje nebo je pomalý. Takové systémy se katastrofálně rozbijí, pokud porucha způsobí něco vážnějšího. STONITH je pragmatické řešení: bylo by příliš složité a pomalé zabezpečit se proti všem typům chyb, tak zkusíme zajistit, že nefunkční server vždycky přestane pracovat, a zajistíme to co nejdřív.

Viz také https://en.wikipedia.org/wiki/Byzantine_fault_tolerance

[DarkKnight]

Ale odpovida. To co pisu neznamena, ze nemuzes zapisovat na oba uzly najednou. Ale pokud dojde k chybe (to je to dulezite) - tj. treba se prerusi konektivita mezi jednim uzlem a zbytkem clusteru, aplikace najednou zacne pracovat se stejnym souborem na kazdem uzlu a problem je na svete. Ktera verze zmeny je ta spravna? Obecne nelze predpokladat, ze jedna je spravna a druha je spatna - proto STONITH jeden uzel zabije (ten, ktery nema majoritni quorum) a je zajistene, ze na ten uzel uz nikdo nezapise.

A znovu pripominam, ze dvouuzlovy cluster nedava pro data-sensitive aplikace (FS, DB, aj.) smysl - neni to HA.

[Odpadlik]

Ale to je přeci běžný problém který se řeší zámkem. Jako rozuměl bych kdyby se v tomto případku STONITH definovalo na dlm démon nutný k provozu GFS či síťovou konektivitu. Ono se to ale řeší přes samotné blokové zařízení:

pcs stonith create iscsi-stonith-device fence_scsi devices=/dev/sdb meta provides=unfencing

... což mi opravdu nedává žádný smysl. Co tento příkaz vlastně udělá? Podotýkám že nezajistí exkluzivní přístup k blokovému zařízení /dev/sdb - tak co tedy zajistí?

[Lyco]

Split-brain v 2nodovém clusteru je problém, který zámkem nelze vyřešit. Buď dojde k deadlocku (když zámek nemá timeout a některý node umře natrvalo), nebo k nekonzistenci dat (pokud je výpadek komunikace - způsobený např. přetížením - delší než timeout zámku, a oba nody zapíšou různá data). Klasický zámek je v reálné (tj. nespolehlivé) síti neřešitelný problém.

Ten iscsi device ve tvém stonithu je pravděpodobně quorum disk. To je takový divný hack - cluster dvou nodů totiž nedokáže při ztrátě spojení mezi nimi rozhodnout, kdo má zůstat naživu, a nody by se vzájemně zabily. Proto oba servery zkusí kontaktovat třetí node - v tomhle případě disk připojený SCSI protokolem - a zamknout ho. SCSI protokol garantuje že uspěje maximálně jeden node, ten se to dozví a zabije ten druhý který zámek nedostal. V podstatě má takový cluster 3 nody, ale jeden z nich slouží jenom k rozhodování "sporů".

K tomuhle účelu se často používá přímo ta sdílená storage na které jsou data, protože nechceme, aby node který ztratil spojení se storagí byl ten, který přežil stonith.

(Tady poznamenávám, že quorum diskům sám moc nerozumím, takže možná jsou detaily špatně.)

[Odpadlik]

No je to skutečně o zámcích, takže máte pravdu:

https://access.redhat.com/solutions/15575