Vlákno názorů k článku Cluster na Linuxu: vysoká dostupnost s RHEL a deriváty od Michal Pastrňák - Super článek, jen bych lehce poopravil, že ke...

Super článek, jen bych lehce poopravil, že ke split-brainu může dojít s jakýmkoliv sudým počtem serverů, ne pouze se dvěma. Může se klidně stát, že bude 8 serverů, po 4 na dvou místech a přeruší se mezi nimi síťové spojení, ale zůstane dostupné úložiště (třeba SANka na optice). Toto potom vyřeší quorum, podle kterého se rozhodne, která půlka převezme služby a která se sestřelí.
V tomto případě je dost nebezpečné používat quorum disk na té samé SANce, protože... domyslete si. Obecně, umístění quora je třeba velmi dobře promyslet (disk i server), aby se taková možnost eliminovala a byl bych pro, se tomu někdy příště ještě detailněji věnovat.

Quorum by mela byt NADpolovicni vetsina. Tedy u 8 serveru se jedna o alespon 5 serveru. V pripade 2 serveru jsou to alespon 2. Ke split-brainu dochazi, jen kdyz je povoleno bezet serverum, ktere nejsou soucasti vetsiny. (Bezet = delat modifikace dat, nebo vydavat autoritativni odpovedi jinym dulezitym castem aplikace.) A ted pozor! Pokud se neoveruje kazda operace (nejakym synchronizacnim protokolem), tak jste v neustalem potencialnim split-brainu!

Ostatne mate-li jakoukoli databazi v master-slave replikaci, tak neni dobre automaticky prepinat mastera. Nevidel jsem reseni, ktere by bylo bez race-condition, tedy bez split-brainu. V lepsim pripade po obnove prijdete o cast dat, ktera se zapsala v dobe trvani te race-condition (a budete muset nektereho slave zastrelit a vyreplikovat znovu od nuly), v horsim pripade zjistite ze, v ani jedne kopii nemate data ktera by byla konzistentni z pohledu aplikace (ne vsechny vztahy jdou zapsat jako sql constrainty).

Osobne si myslim, ze na distribuovany beh (a horizontalni skalovani) by mela byt pripravena samotna aplikace. Takze mi v clanku chybi dost podstatna informace: co (jaka aplikace) na tech nodech clusteru pobezi!

Osobne si myslim, ze bud potrebujete HA nebo velka transakcni data, pak potrebujete plnohodnotny databazovy cluster (nikoli bezet databazi v clusteru popsanem v clanku).
Nebo zjistite, ze k vypadku serveru (masteru) prakticky nedochazi, takze je levnejsi prepnout mastera rucne, nez udrzovat cluster.
Nebo zjistite, ze muzete napsat aplikaci tak, aby nebyla transakcni a pouzit nejakou HA netransakcni databazi (objektovou storage). Pak ale zase nepotrebujete v clanku popsany cluster, ale zminenou HA databazi.

Takze pripadu, kdy cluster popsany v clanku prinese vice uzitku nez provoznich nakladu (predevsim v lidskych zdrojich na porozumeni a udrzbu, a na pripadnou opravu chyb zpusobenych automatickym presunem autority podle quora), zase tak moc neni. Mne ted nenapada zadny, takze bych rad o nejakem slysel.

Ano, primárně se cluster řídí nadpoloviční většinou, ale pokud je sudý počet serverů, přidává se samostatné quorum, pomocí kterého se cluster rozhodne, co má běžet. Je to situace celkem běžná, třeba strejný počet stejných serverů ve dvou serverovnách v různých budovách...

Osobně taky nevidím žádný velký reálný přínos popsaného clusteru pro produkci, ale minimálně se na tom dají naučit principy a je to dostupné pro každého, aby si to osahal. Určitě tu budou všichni štěstím bez nohy, když někdo napíše článek o ServiceGuard clusteru, který bude začínat "Připravíme si 2x integrity server, 2x UPS, dvě samostatné napájecí větve, 2x SAN pole (nejlépe SSD), 2x SAN switch, 2x LAN switch (10Gbit) a můžeme začít". Ale co z toho? Autor začal velmi dobře a je vidět, že ví, o čem píše.

Maximálně to tu můžeme vyflejmovat debatou na téma "víc práce, než užitku" vs "mě to tak funguje v produkci bez problémů", ale stejně to k ničemu nepovede. Na některý věci je dobré přijít sám, něco nového se naučit, občas se zpálit a hlavně je potřeba naučit se myslet, předvídat, odhadovat... to chce prostě praxi.

Aha, já jsem nepochopil, že "quorem" v případě sudého počtu nodů myslíte "arbitra". Tedy něco co má hlasovací právo, ale není to plnohodnotný node. Arbitrů může být obecně také libovolné množství, ale více než jeden se používá velmi zřídka.

Co se týče serviceguardu - mne nezajímá jak to chce mít autor naimplementované do detailu, takže takový úvod by nezaujal ani mne. Mne zajímá, jak má rozmyšlená rizika výpadku, co se může ztratit při přepnutí (nemusí mi obhajovat že se to v jeho případě vyplatí, ostatně já si jeho případ stavět nebudu), protože to pak můžu porovnat s jiným řešením, v době kdy teprve uvažuju nad architekturou aplikace.