Názor k článku Cluster na Linuxu: vysoká dostupnost s RHEL a deriváty od jen_ftr - sanlock bohužel není zdaleka totéž. 1 - nejde o...

sanlock bohužel není zdaleka totéž.

1 - nejde o ochranu dat aplikace, to je druhotný efekt. Aplikace do fencingu nemá co mluvit, to musí být v režii clusteru. Jde o quorum, tedy o pomoc v rozhodnutí v krizové situaci, kdy jeden nebo více nodů nemá spojení na ostatní nody clusteru, kdo má "mít pravdu" ohledně stavu a konfigurace clusteru jako takového. Druhá strana sama sebe prohlásí za nepoužitelnou, aby zůstala jen jedna autorita, a ukončí se, aby nedošlo ke konfliktům. Dokonce má odmítnout nabootovat systém, dokud nevidí vítěze arbitráže a nemůže od něj dostat aktuální konfiguraci a povolení připojit se do clusteru. A to už sanlock+watchdog nevyřeší.

Mimochodem, aplikační data jsou lépe chráněna proto, že se nod, který "prohrál" arbitráž sám zahaltuje s flushem cache, místo aby ho někdo jiný zastavil vypnutím uprostřed rozepsaných metadat. Druhotný efekt.

2 - plést do toho watchdog není moc šťastné. Quorum device (ať disk nebo síťové) není nutné ani žádoucí kontaktovat až dokud nenastane potřeba. Vůbec nejde o pravidelné proby na quorum device, nemá to přeci suplovat cluster interconnect. Proč riskovat pád části clusteru kvůli momentální nemožnosti kontaktovat quorum device, což může být zcela záměrné nebo to může být opomenutí jinak neovlivňující provoz (maintenance odlehlé části sítě v jiné lokalitě, migrace na jiné disky...)

3 - SCSI3 rezervace například nepotřebuje vůbec žádný prostor na disku, nespotřebuje žádné IO. Pokud máte viditelný jakýkoli LUN ze všech nodů clusteru, může být quorum device právě on, ať je na něm cokoli. Aplikace to vůbec nepozná. Za zkušenosti mohu říci, že SCSI rezervace je zatím asi nejspolehlivější metoda, ačkoli má taky mouchy (co třeba když máte cluster i data na dvou serverech a dvou polích ve dvou serverovnách).

Nakonec mám trochu osobní mentální potíž s výrazem "asi by šlo" v kontextu něčeho, na co vsázím stabilitu provozu a své klidné spaní. Jak píšete "Asi by tudíž šlo propojit corosync a sanlock na úrovni aplikace". Ano, asi by šlo. Ovšem "asi by šlo" je dost slabé vyjádření. Lze také říci "vendore, asi by šlo dodělat standardní fencing přes quorum devices a podporu v systému místo STONITH". Asi by šlo dát aplikaci za balancer nebo využít aplikační cluster. Asi by šlo ji i přepsat.

"Asi" je slovo, které v produkčním projektu nemá co dělat, a právě množtví těch "asi by šlo" záležitostí v podobně základních věcech jako fencing je to, co mi na téhle implementaci poněkud vadí. Nevadí to pro relativně malé nebo osobní projekty. Ale například RedHat má přeci vyšší ambice než tvrdit, že by něco "asi šlo" udělat v implementaci na úrovni konkurence z roku 2003 (SUN cluster v2, a kdo to viděl potvrdí, že to bylo také "něco"). Vlastně lépe řešený fencing mělo i DECovské ASE v polovině devadesátých let. Vsadí si někdo na "asi by šlo" když mu určitě jde o mnoho?

Opravdu nechci nějak bořit nebo shazovat téma článku. Naopak, jako úvod do clusterování je to pěkná sumarizace a dává to smysl. Zkusíte tohle, pro menší prostředí si vystačíte, a víte, po čem se ptát dál. Jen je třeba i vědět, že to má svá úskalí a není to vrchol snažení.