Názory k článku Cluster na Linuxu: vysoká dostupnost s RHEL a deriváty
-
MP (neregistrovaný)
Dodal bych 2 veci:
1] odkazy na redhat stranky, ktere jsou pristupne jen po prihlaseni, jsou osemetne. Nejsem si jist, zda nektere nevyzaduji zaplacenou podporu.
2] hodilo by se upozorneni, ze fencing ze zdraveho node na neodpovidajici ma vice problematickych stavu. Napr. pokud totiz ten node neodpovida ani na standardni komunikaci, tak ho proste neodstrelite. Na to by se muselo pouzit but:
a] fencing primo na urovni neodpovidajiciho node - napr. Proxmox takto resi vypadnuty stroj z clusteru, ze se sam zrestartuje (obcas to pri aktualizaci zaboli :-) )
b] externi fencing - tam je to zase komplikovanejsi z toho duvodu, ze ilo/idrac atd. jsou mnohdy v oddelene siti, protoze jejich zabezpeceni je deravejsi nez standardni linux. -
Díky za reakci.
1. Ano, odkazy na dokumentaci Red Hat v rámci access.redhat.com/solutions a access.redhat.com/articles jsou většinou dostupné po přihlášení, a to nejčastěji znamená mít placenou podporu (kromě Developer programu). Proto se snažím koncept, na který odkazuju těmito články, dostatečně vysvětlit. Samozřejmě tyto odkazy obsahují mnohem víc informací než moje shrnutí -- proto na ně taky odkazuju. Ty odkazy nejsou pro pochopení tohoto článku nutné, je to jen rozšíření.
2. Ve virtuálním prostředí si nemyslím, že tento problém existuje -- pokud zdravý node pošle hypervizoru pokyn k fencingu - rebootu neodpovídajícího nodu a pokud je vše správně nakonfigurováno, pak hypervisor fencing provede nezávisle na stavu neodpovídajícího nodu. Ten může klidně být i vypnutý.
V případě fyzických mašin se používá externí fencing, jak píšete v bodě 2b.
2a. Tzv. self-reboot je funkcionalita zahrnutá ve fencingu pomocí SBD -- storage-based death. Tam se k rebootu využívá tzv. watchdog device
Using SBD with Pacemaker
https://access.redhat.com/articles/2212861https://www.kernel.org/doc/Documentation/watchdog/watchdog-api.txt
2b. Ano, proto je externí fencing pomocí out-of-band management karet zpravidla na jiné síti -- aby se signál k rebootu neodpovídajícího node ke kartě dostal. Pokud jde o bezpečnost, jiní jsou rozhodně povolanější než já, aby se k tomu vyjádřili.
-
hefo (neregistrovaný)
Pri HP-UXe (ServiceGuard) to bolo riesene sposobom a) - ak node zistil, ze odpoveda menej ako polovica clustra, vykonal sa TOC (nieco ako tvrdy hardverovy reset z vytvorenim memory dumpu). A z tohto dovodu aj dvojnodovy cluster pouzival este treti element - bud samostatny quorum server alebo quorum disk, dostupny cez fibre channel z oboch nodov, ktory urcoval, ktory je aktivny node a s jeho zapocitanim sa dala urcit nadpolovicna vacsina clustra.
-
Adam KaliszStříbrný podporovatelDíky, právě na to téma dopisuji bakalářku, rozhodně se to hodí na utřídění myšlenek/ reflexi.
-
FTR (neregistrovaný)
Dobrý článek, ovšem přidal bych jedno varování:
Linuxový cluster tak, jako ho má pohromadě RedHat a další je bohužel stále ještě nedovařený a nedoporučil bych ho právě u služeb, které *musí* běžet a visí vám na nich podstatné finance. Vícekrát jsem na něm viděl ztrátu informace o konfiguraci clusteru nebo hůře, ztrátu dat při splitbrain nebo i "běžné" relokaci, což jsem na jiných clusterech (veritas, Oracle SC, HACMP, ServiceGuard) nikdy neviděl - a šlo o zcela korektní patchované instalace.
O něčem vypovídá i fakt, že podobné situace se vyskytují i na připravených labech.
Jeden z důvodů je právě nepřítomnost toho, co je v článku uvedeno jako "druhořadá" metoda fencingu, tedy např SCSI rezervace, a reálně prakticky jediná podporovaná volba je STONITH (a komerčně podporované je jen tvrdé vypnutí druhého nodu remote power switchem).
STONITH má zásadní problémy
- race condition (servery se mohou zastřelit navzájem, zvlášť pokud používáte KVM agenty, a pak leží všechno)
- žádný sync nebo nějaké podobé řešení nacachovaných filesystem (meta) dat, a tedy větší riziko ztráty.
- Nod, který nemá co dělat (a tedy je vlastně méně provozně důležitý) má větší pravděpodobnost, že "vystřelí dřív". Když se taky nudí a celé dny si jen hraje s bouchačkou...
- problém se zvětšuje s počtem nodů v clusteru.Ostatní clustering řešení fencing řeší kombinací externí autority a mechanismu v kernelu jednotlivých nodů. Při splitbrain nody clusteru zkusí kontaktovat autoritu a umístit na ni svůj zámek. Operace je atomická a z definice může vyhrát jen jeden. Ten je pak master clusteru a ostatní, kteří zjistí, že už je zamčeno se musí s vlastníkem quora zkontaktovat. Pokud nod není v této situaci schopen kontaktu s quorem ani s vlastníkem quora automaticky sám sebe zastaví (kernel panic/dump/halt).
Tento fencing bývá primárně SCSI2 nebo SCSI 3 rezervace, nebo nějaký jednoduchý síťový server třeba i v jiné lokalitě, který akceptuje spojení od nodů clusteru a čeká na zámek od prvního, kdo ho bude chtít.
Na skutečný support fencingu tohoto typu, hlavně na SCSI rezervace a podporu "sebevraždy" čekáme léta jak na smilování a je skutečně smutné, že to zřejmě "není priorita", asi proto, že více se řeší aplikační clustery a horizontální škálování, než old-school HA.Pochopitelně se pak řeší "quorum matematika", tedy jestli pozůstalí mají dost "hlasů", aby cluster sám sebe považoval za provozuschopného nebo bude vyžadovat lidskou intervenci, ale to už je asi na článek.
Neberte to prosím jako shazování článku nebo autora, je to jen varování před přílišným optimismem vedoucím k neopatrnosti. Použití uvedeného clusteru prostě jen vyžaduje větší péči a kontingenční plány "co když" - a především důsledné a časté zálohy, ze kterých si musíte být jisti, že obnovíte v požadovaném čase komplet celý cluster. Trochu to jde proti smyslu clusteru, když se obáváte s ním manipulovat a musíte si každou operaci nějak jistit, ale v malém prostředí se s tím dá žít.
-
MarSik (neregistrovaný)
RHV například používá sanlock [1], který vypadá přesně jako to co popisujete. lockspace je na sdíleném disku a pří nedostupnosti lockspace dojde k rebootu aplikace nebo celého nodu (přes watchdog).
Sanlock jinak běží jako lokální služba na každém nodu a aplikace si říkají o zámky (a jsou svázané s jejich životností). Asi by tudíž šlo propojit corosync a sanlock na úrovni aplikace, která vlastní daná chráněná data.
[1] přímo i přes livbirt / qemu, vic je toho v manpage: https://pagure.io/sanlock
-
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í.
-
MarSik (neregistrovaný)
> 1 - nejde o ochranu dat aplikace, to je druhotný efekt.
Jak u které aplikace. Databázový server je typicky služba, kde jde primárně o data a samotný stroj není tak důležitý (to samé virtuální počítače a ochrana proti double-mount disků).
Aplikace bez dat a s vedlejšími efekty je pak zase příklad vaší strany mince a situace kam se sanlock úplně nehodí.
> 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...)V případě sanlocku a jím hlídaných dat se obvykle jedná o jeden a ten samý storage server (nebo cluster). Takže delší nedostupnost jednoho znamená nedostupnost obou. Navíc ztráta spojení s daty znamená i ztrátu možnosti je poškodit. Poškození zápisem starších dat po znovuobnovení spojení právě vyřeší lokální sanlock fencingem aplikace nebo celého nodu přes lokální kernel watchdog (což je jen mechanizmus specifický pro linux a ochrana proti pádu lokálního sanlock daemona).
> Aplikace do fencingu nemá co mluvit, to musí být v režii clusteru.
Ale to samozřejmě platí i pro ten aktivní přístup. Aplikace se nemůže neukončit, když řídící logika clusteru zavelí (a je jedno jestli to je corosync nebo sanlock).
> 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.Samozřejmě chápu, že u old-school HA existuje i informace o počtu nodů a arbitr není za běžného provozu potřeba. Jak se ovšem takový cluster vyrovná se ztrátou poloviny +1 nodů? (např. pád celého jednoho datacentra). V tu chvíli jsou zbývající nody v menšině a možná vidí arbitra. Předpokládám, že je pak potřeba ruční zásah, narozdíl od aktivně udržovaného zámku.
Oba dva přístupy (quorum + arbitr pro nerozhodný stav vs. aktivní zámek) mají svoje sady problémů a hodí se na malinko jiné typy aplikací. A rozhodně neplatí stejná pravidla pro umístění HA arbitra (někde mimo) a sanlock lockspace (co nejblíže datům), proto se ty přístupy nedají takto jednoduše porovnat.
-
Jako jsem psal níže, sanlock a SCSI3 rezervace (nebo síťový arbitr) pro účely quora neřeší to samé a mají různý účel. Právě proto je nelogické je porovnávat a rozhodně nemůžete argumentovat tím, že byste řešil quorum a následky získání/ztráty quora jednotlivých nodů clusteru sanlockem - Umím si představit, jak bych to celé napodobil, ale není to rozhodně integrální součást tohoto clusteru, bude to můj dodělek. To je vše.
-
MarSik (neregistrovaný)
Nejsme ve sporu, tvrdím to samé. To typické použití se liší.
Nicméně sanlock samozřejmě interně synchronizaci nodů a split-brainy řeší taky. Je tam na koncensus použitý PAXOS co si vzpomínám. Aplikace a data už jsou odstíněna od té komplexity a jen si udržují zámek, takže quorum nemusí řešit.
-
jk (neregistrovaný)
Nevidím tu nic, co by SCSI fencing řešil a STONITH to nedělal také nebo lépe.
- race condition: bez kvóra se nefencuje, fencuje se z kontroleru (tj. jeden stroj). Není to náhodná palba všech na všechny při ztrátě tokenu. Nejdřív quorum a pak střílení nezúčastněných ;). Nevidím, kde by tam mohla vzniknout race condition.
- žádný sync. SCSI reservace taky žádný sync neposkytují nebo ho přímo znemožňují. Takový sync si musí dělat filesystem a aplikace (žurnály třeba, datasync po write...). STONITH tady přispívá zajištěním, že po fencu už k neočekávanému zápisu nedojde (mašina je vypnutá).
- node, co nemá co dělat se akorát dříve připojí do nového ringu po ztrátě tokenu. Je pravděpodobnější, že tam bude. Obecné principy ale zůstanou a není nic jako "hrát si s bouchačkou". Pořád musí udělat kvórum a postupovat skrz stejnou logiku.
- problém se s počtem výrazně nezvětšuje. Ta logika funguje pořád stejně. Leda by se ty nody během formování nového ringu (membership) pořád připojovaly a náhodně odpojovaly (a způsobovaly by tak restart toho cyklu).
STONITH > SCSI fencing any time :)
Samozřejmě se rád dozvím, pokud něco z toho není pravda :).
-
Asi mluvíme o něčem jiném, zkusím to lépe zformulovat. SCSI rezervace není metoda provedení fencingu, je to prostředek dodávající metodě podklad k rozhodování. Metoda samotná je STONITH versus "ukončení běhu sebou samým".
Neboli nod ukončí sám sebe, pokud je ve stavu vyžadujícím quorum a quorum ztratil. Standardní případ, 2 nody plus 1 hlas quorum device. Splitbrain, jeden získá zámek na quorum device (nemá nic společného s clusterovými disky pro aplikaci), a tedy má 2 hlasy, druhý má jen sebe, ztratil quorum, ukončuje se. Ale protože ho nikdo nevypnul vypínačem, tak má všechna systémova metadata *svých* disků, včetně systémových, včetně služeb, které byly "jeho", korektně uložena nebo odrolována (systemová, nikoli aplikační). A máte také crash dump, logy v konzoli, nevidíte tam jen "mlčení jehňátek".
Méně standardní případ, 5 nodu, quorum device 4 hlasy, rozpad na 1, 2 a 2. Kterákoli skupina získá device přežívá, ostatní samy sebe ukončí.
Ukončené nody se do clusteru nemohou připojit ani utvořit vlastní, dokud neuvidí na ostatní, protože prostě nemohou získat quorum.Při splitbrain se můžete spolehnout jen na jedno, a to že vám nefunguje síť. Jak chcete v takovém stavu zaručit, že vůbec jste schopen STONITH provést?
STONITH > SCSI fencing nedává tedy smysl ani this time ani any time :-). Porovnavejte STONITH s metodou "ukončuje se každý sám".
Také nelze míchat SCSI rezervaci quorum device (a psal jsem, že to je jen jedna z možných metod) se zamykáním aplikačních disků, což je oddělená záležitost, i kdyby využívala podobný mechanismus. Překvapivě je sync normálně možný :-). A znovu, netýká se aplikace, můj problém se STONITH je notorická nespolehlivost právě při splitbrain, který má řešit, v logu mlčení jehňátek a ztráta dat nebo rozpad konfigurace clusteru s pravděpodobností 1:6 (vlastní statistika, zkuste vlastních dvacet HA testů pod zátěží, porovnáme data :-).
- ad race condition: vše záleží na metodě určení quora. A bohužel jsem vzájemnou střelbu viděl a řešil, takže si nejsem tak jist, že není možná. Poku je tento bug už vyřešen, jsem rád a odškrtněte si to, ale pořád to neřeší problém se sítí při splitbrain ani větší riziko ztráty dat při opakovaném vypínání napájení.
-
MarSik (neregistrovaný)
Hlavní problém nastane pokud dojde ke ztrátě spojení mezi částí clusteru a kontrolerem. Pokud je IPMI dostupné, tak se nic neděje a fencing to vyřeší.. ale například hodně serverů co jsem viděl používá na IPMI a na síť stejný kabel... a kdo pak odstřelí ten server, když je nedostupné i IPMI?
Pokud to dobře chápu, tak SCSI rezervace je jen arbitr pro případ, že se dvě oddělené části clusteru musí _autonomně_ (bez kontroleru) rozhodnout jestli spáchají sebevraždu nebo ne. Ten kdo se první dostane k arbitrovi vyhrál a zůstane v provozu.
-
Ano, tak by se to dalo formulovat. Nebo lépe, vyhraje ten, kdo nahrabe víc hlasů. Hlas má od quorum device (to může mít víc hlasů dle potřeby) a od každého, na koho vidí po interconnectech a kdo mu tudíž svůj hlas "dá". Má-li většinu, on a jeho "bratři v quoru" žijí dál. Zbytek nodů se sám odstřelí.
Ten problém s IPMI je přesně příklad té potíže. Osobně mi vadí i to vypínání, které pokládám za komplikaci, ale to jistě může být osobní preference, byť k ní mám praktické důvody. Nemusíte mít navíc jen stejný kabel, můžete běžet přes stejné switche apod. Je toho hodně, co se mohlo pokazit, STONITH prostě přidává krok navíc výměnou za sporné benefity, můj názor na to asi nemá smysl opakovat.
-
Dobrý den, díky za komentář a omlouvám se za pozdní reakci.
K pár bodům:
Vícekrát jsem na něm viděl ztrátu informace o konfiguraci clusteru nebo hůře, ztrátu dat při splitbrain nebo i "běžné" relokaci
===> Tohle by mě zajímalo. Byl otevřen case na Red Hat podporu? Co Vám tam řekli? Split brain je poměrně těžko dosažitelný stav, pokud je cluster správně konfigurován (viz níže)
O něčem vypovídá i fakt, že podobné situace se vyskytují i na připravených labech.
===> Nejsem si jistý, kam tím směřujete. Můžete to prosím říct jinak?
"druhořadá" metoda fencingu, tedy např SCSI rezervace
===> Druhořadá proto, že stejně musíme zajistit reboot nodu. Jinak pokud storage SCSI 3 rezervace podporuje, a fence device je správně nastavena, pak SCSI fencing zpravidla účinně a okamžitě zamezí danému nodu přistupovat k datům
STONITH má zásadní problémy
- race condition (servery se mohou zastřelit navzájem, zvlášť pokud používáte KVM agenty, a pak leží všechno)===> Z tohoto důvodu se používá parametr delay na jedné z fence devices. Pokud by měla nastat situace, kdy se oba nody chtějí fencnout zároveň (ve stejnou chvíli), jedna bude fencovat dříve než ta druhá -- a split brain nenastane
- žádný sync nebo nějaké podobé řešení nacachovaných filesystem (meta) dat, a tedy větší riziko ztráty.
===> Toto pozjíšťuji, nedokážu teď odpovědět
- Nod, který nemá co dělat (a tedy je vlastně méně provozně důležitý) má větší pravděpodobnost, že "vystřelí dřív". Když se taky nudí a celé dny si jen hraje s bouchačkou...
===> Ńetuším, co tím chcete říct... Zkuste znovu jinými slovy prosím
- problém se zvětšuje s počtem nodů v clusteru.
===> Který problém? Předpokládám, že se odvoláváte na to "vystřelení"?
Ostatní clustering řešení fencing řeší kombinací externí autority a mechanismu v kernelu jednotlivých nodů
===> Externí autorita může být quorum disk (quorum device od 7.4) a mechanismus v kernelu je využíván při SBD -- storage based death (sbd poison-pill fencing via block-device).
https://access.redhat.com/articles/2943361
Asi bychom potřebovali probrat konrétní situace a udělat RCA na základě logů a daných konfigurací.
Díky, jsou to připomínky k věci.
-
Kristian Feldsam (neregistrovaný)
Ja chcem iba doplnit info ohladom site pro corosync. Pouziti jenom bondingu/teamingu sa nedoporucuje, pretoze pri prepinani interfacu muze dojit k latenci a node nemusi odpovedet vcas. Idealne je pouzit dva privatni okruhy a oba definovat v corosync configu. Su to takzvane ringy. Ja osobne pouzivam teaming + vyhradenu dedikovanu sit pro corosync. V corosync konfigu je pak dedikova sit jako hlavni ring a teaming shared sit jako backup ring. Taktiez co sa tyka Centosu 7, tak treba vyhradne pouzit verzi 7.3+, pretoze do verze 7.2 vratane centos obsahoval staru zabugovanu verzi libqb. Ta sposobovala pravidelny cluster hung a crash. Pokial to opravili a vydali novu verzi v centosu 7.3 som musel pouzivat backportnute balicky z fedory.
-
Díky za odpověď.
K latenci při přepínání síťovek: Je možno otestovat a nastavit o to větší token.
Mít dva ringy (neboli Redundant ring protocol -- RRP) je ale určitě dobrá alternativa, ale omezuje nás jejich použití na active passive cluster. DLM (distributed lock manager) a tím pádem CLVM (clustered LVM) s RRP není podporované.
CLVM má na starosti aktivaci VG na všech nodech clusteru a závisí na DLM.
-
Díky za odpověď.
K latenci při přepínání síťovek: Je možno otestovat a nastavit o to větší token.
Mít dva ringy (neboli Redundant ring protocol -- RRP) je ale určitě dobrá alternativa, ale omezuje nás jejich použití na active passive cluster. DLM (distributed lock manager) a tím pádem CLVM (clustered LVM) s RRP není podporované.
CLVM má na starosti aktivaci VG na všech nodech clusteru a závisí na DLM.
-
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.
-
vjur (neregistrovaný)
> bych lehce poopravil, že ke split-brainu může dojít s jakýmkoliv sudým počtem serverů
a ja bych lehce poopravil, ze obecne ke split-brainu muze dojit u jakehokoli distribuovanovaneho systemu, kde se voli master/leader/primary owner, nezavisle na poctu nodu (pochpitelne predpokladam n>1), ale v zavislosti na algoritmu, podle ktereho se voli master/leader/primary owner, tj. ze split-brain je obecny termin, ktery obecne nijak nesouvisi s poctem nodu v clusteru :-)
-
MarSik (neregistrovaný)
V běžných řešeních nijak. oVirt interně používá sanlock. HA pro management je pak zajištěno self hosted enginem, který je opět chráněn sanlockem.
Nad pacemakerem se uvažovalo, ale má příliš vysoké nároky na latenci sítě a podporuje v základu jen 16 nodů (na další už musí být extender topologie iirc). Nicméně nějaké pokusy byly a dají se vygooglit (třeba linbit).
-
To neřeš, s MSCS mám aktuální zkušenost, kdy ani MS premier support nebyl schopnej vyřešit problém a zcela klasicky udělali z bugu fičuru. Ono to totiž funguje SKVĚLE, ale pouze s jedním strojem a cokoliv víc je v podstatě nepodporovanej experiment debilního zákazníka, kterej si od toho něco sliboval.
-
Já mám také s MSCS "aktuální zkušenost". Běží mi pěkných pár HA clusterů (většinou active/active), většina z nich už pár let, a jsou zcela bez problémů. Co můžete vidět jako více překvapivé: všechny jsem je pohodlně nastavil z GUI, a nenapsal jsem u toho ani řádku skriptu, protože to prostě nebylo potřeba.
-
GUI je obecně platná výhoda nebo nezbytnost?
Nebo jste, pokud prostě netrollíte, chtěl sdělit světu, že systémy nespravujete sám, znáte je jen z manažerského pohledu - jinak byste totiž nenapsal "zcela bez problémů"? Nebo že nejste schopen ani práce v PowerShellu? Že nejste nejen schopen držet se tématu a něco užitečného k němu napsat, ale ani nejste schopen si o něm nejprve nastudovat alespoň tolik, abyste věděl, že i non-MS clusteringy mají GUI a že psaní skriptů není nezbytná podmínka? Že vůbec nemáte ponětí o dalších alternativách ani o tom, že uvedený clustering postavíte i z non-RedHat zdrojů?
Z vašich příspěvků jsem bohužel jiné informace odvodit nedokázal, pokud napíšete něco k věci a užitečného, rád si názor opravím.Topic je clustering na linuxu nebo aspoň clustering jako takového, nikoli získání seznamu toho, o čem který přispěvatel nic neví nebo to neumí, ale zato na to má ideologicky správný názor.
Pokud chcete vědět, odkud pramení názor zjevně rozšířený ve zdejší komunitě, že windows admini a příznivci jsou banda idiotů, kteří neumí, co není v GUI jako next-next-finish, tak přesně od vašeho stylu trollingu. Argument žádný, znalost alternativ stěží chabá, ale ideologie silná. Pokud byste znalosti měl, psal byste k věci. Pokud tedy nemáte nějakou poruchu.
A co mi vadí nejvíce, vzájemně se tím lidé jako Vy a Linux nazis (a obojí je stejné) utvrzujete v tom, že idiotský trolling, ignorování nevhodných faktů, ideologie, urážky a VELKÁ PISMENA kdykoli nahradí znalosti, argumenty, myšlení i etiku.
Podobní nazis na jakékoli téma se většinou rekrutují z řad lidí, co chabou znalost problematiky nahrazují kategorickými prohlášeními "jak by to mělo být ideologicky správně" a trollingem. Nikdy od nich neuvidíte nic konkrétního k věci, nikdy nevysvětlují, nedokazují, nepoužijí korektní argumenty a už vůbec nikdy neuznají chybu, neznalost nebo omyl, nikdy nekorigují ani nevysvětlují své stanovisko, vždy jen výkřiky, ideologie a argumentační fauly. Je na Vás, jako co chcete vypadat, čeho dosáhnout a jak se prezentujete. Děkuji.
-
Ad systémy nespravujete sám, znáte je jen z manažerského pohledu, jinak byste totiž nenapsal "zcela bez problémů" - dobře nasazený a stabilizovaný systém běží bez problémů. Občasný reboot po patchování, občas warning že někde dochází místo, ale jinak nebývá moc důvod, aby věci neběžely stejně dobře jako první den v produkci. Incidenty jsou většinou (i když samozřejmě ne výhradně) způsobené vnějšími zásahy, nejčastěji špatným change managementem.
Ad nejste schopen ani práce v PowerShellu - jsem schopný pracovat v PowerShellu, ale v daných případech k tomu jaksi nebyl důvod.
Ad nejste nejen schopen držet se tématu - naopak se tématu držím celkem dobře. Reaguji totiž na to co je popsané v článku. Konkrétně na neplacenou reklamu Red Hatu, ve kterém ovšem vidím, že si člověk snad ušoupe prsty psaním něčeho, co na MSCS prostě a jednoduše naklikám. BTW je fakt vtipné když vy mluvíte o nedržení se tématu... a velká část vašeho příspěvku je úplně mimo téma. Nic proti, to co píšete na téma volně navazuje. Ale těžko pak můžete totéž někomu vyčítat.
Ad i non-MS clusteringy mají GUI a že psaní skriptů není nezbytná podmínka - opakuji: reaguji na to co je popsané v článku. Hrozně se vám nelíbí, že vytahuji MSCS, a přitom vytahujete jiné clustery a jejich GUI. Tak si vyberte, co vlastně chcete.
Ad vůbec nemáte ponětí o dalších alternativách ani o tom, že uvedený clustering postavíte i z non-RedHat zdrojů - samozřejmě vím, že clustering od Red Hatu a MS nejsou jediné alternativy. Před lety jsem párkrát jsem použil Sun Cluster a na AIXu HACMP, viděl jsem zběžně HP ServiceGuard. Koncepty HA clusteru všude více-méně stejné.
Ad Z vašich příspěvků jsem bohužel jiné informace odvodit nedokázal - předpokládám že k tomu abych ohodnotil postup popsaný v článku slovy "názorná ilustrace, jaké komplikace si člověk ušetří, když použije MSCS" snad nemusím zároveň posílat CV :)
Ad odkud pramení názor zjevně rozšířený ve zdejší komunitě, že windows admini a příznivci jsou banda idiotů, kteří neumí, co není v GUI jako next-next-finish - ale to tak snad ani nemusíte zmiňovat. Každý má iluze o sobě a své skupince. Admini klasických Unixů považují linuxové adminy za děti co si na pískovišti hrají na profesionály. Linuxoví admini si myslí o Win adminech, že jsou to klikači co umí jen next/next/finish. Win admini si o unixových adminech myslí, že používají děrné štítky a terminál, a místo učení principů se memorují syntaxi příkazů. Programátoři si adminech myslí, že jsou to nedoukové, kteří se nějak dokázali naučit pár příkazů a/nebo "pokročilých" manévrů myší. Admini si o programátorech myslí, že jsou banda nechopných lemplů, kteří mají v popisu práce sabotovat práci adminů. Mohli bychom o tom mluvit hodiny, a není to k ničemu. Rád bych si myslel, že tyhle stereotypy můžeme přenechat těm méně bystrým v každé skupince, protože na naší úrovni mentální kapacity takové žabomyší války jaksi nejsou relevantní.
Ad vzájemně se tím lidé jako Vy a Linux nazis (a obojí je stejné) utvrzujete v tom, že idiotský trolling, ignorování nevhodných faktů, ideologie, urážky a VELKÁ PISMENA kdykoli nahradí znalosti, argumenty, myšlení i etiku - v podstatě souhlas, ale nevidím se ve skupinách, které popisujete. Pokud jde o velká písmena, tak možná jde o poruchu, jak jste zmiňoval v předchozím odstavci: N2KOMU SE ZASEKNULA KL8VESA SHIFT :)
Ad "jak by to mělo být ideologicky správně" - nevím jestli je můj názor "ideologicky správně". Za mě je ve firmách spousta systémů, které by měly mít high availability. HA clustery sice řadu situací v principu neřeší, ale to je na jiné povídání. To že se málo používají je dané mimo jiné nedostatkem znalostí na straně adminů, komplikovanou konfigurací a administrací clusteru. V případě Windows odvedl MS spoustu práce, snaží se to adminům ulehčit - a zjevně je to pořád málo. No a námi diskutovaný článek ukazuje konfiguraci clusteru způsobem, který patří někam do dřevních dob. To je za mě vše.
-
Článek má název: "Cluster na Linuxu: vysoká dostupnost s RHEL a deriváty". Jakým způsobem je off-topic například Veritas Cluster Suite nebo HP ServiceGuard? Obojí na Linuxu a na RHEL+derivátech běží a je supportované, což při Vámi deklarovaných zkušenostech přeci musíte vědět, i to, jak se to ovládá a jak to funguje v praxi.
A naopak, jakým způsobem je in-topic MSCS, které na jakémkoli Linuxu ani ničem Unix-like neběží?
Reklama na RedHat - to je právě část té neznalosti. Na to, co je v článku, RedHat vůbec nepotřebujete.
Se zkušenostmi, které tvrdíte, že máte, to opět musíte vědět.Tož se nedivte, že bez ohledu na Vaši dlouhou obhajobu to vypadá na jednu ze dvou variant: buď víte, a pak jste troll, nebo nevíte (co plyne z druhé varianty si doplní každý dle svého).
Bohužel opět nemáte nic k věci, GUI jste uvedl jako killer-feature do diskuse Vy, a kvalitu implementace MS clusteru dokazujete opakovanim tvrzeni "typu MSCS je lepší" bez jediného slova k topicu. Třeba aspoň o fencingu. Ačkoli vlatně ten je dle vás off-topic, s clusteringem nemá zřejmě nic společného :-).
-
Ad Veritas Cluster Suite nebo HP ServiceGuard na RHEL a derivátech - upřímně jsem Linux v produkci už dlouhá léta neviděl. V HA clusteru jsem viděl Linux jen jednou. Konkrétně SLES, který se během toho týdne, kdy jsem to měl možnost pozorovat, dostal asi 3x do split-brain stavu se ztrátou dat. Naštěstí to nebyl můj problém.
Ad jakým způsobem je in-topic MSCS - a jakým způsobem se k článku "Cluster na Linuxu: vysoká dostupnost s RHEL a deriváty" váže vaše povídání o trollingu, ideologii, VELK7CH P9SMENECH, urážkách a nevím co ještě? Aha.
Ad Reklama na RedHat; Na to, co je v článku, RedHat vůbec nepotřebujete - článek je komplet psaný pracovníkem Red Hatu o Red Hatu. Pokud se ty samé balíčky dají použít na systému který s RH nemá nic společného (nevím a je mi to celkem jedno), tak tedy není technicky důvod do toho Red Hat vůbec tahat, a článek je pak ještě drsnější reklama, než pokud jde o RH-only řešení.
Ad opět nemáte nic k věci - k věci mám to co jsem psal od začátku: HA cluster je poměrně potřebná funkcionalita, a tahle reklama na Red Hat mi připadá spíš jako reklama na rukavice, aby si člověk neošoupal prsty na klávesnici. MSCS je v tomhle ohledu výrazně lepší. O dalších kvalitách MSCS (ani o jiných HA clusterech) jsem se nijak nevyjadřoval, s výjimkou reakce na údajnou nespolehlivost MSCS. A za to, že jsem si "dovolil" pohanět konfiguraci produktu od RH, jsem se od vás dozvěděl, že trollím, systémy nespravuju a nerozumím jim, nejsem schopen ani práce v PowerShellu, neumím se držet tématu, nevím že existují i non-MS clustery s GUI, nemám ponětí o alternativách, nemám žádné argumenty, nepíšu k věci atd. Takže se vás zeptám: připadáte si v pořádku? Já si "dovolím" prohlásit, že popsaný způsob konfigurace je nešťastný a MSCS to zvládá lépe. Vy na mě v reakci vylijete kýbl špíny založený na vašich dohadech a odhadech, místo abyste se držel tématu, a ještě si hrajete na mravokárce. Za mě je to z vaší strany dost chucpe. Vašimi slovy: Je na Vás, jako co chcete vypadat, čeho dosáhnout a jak se prezentujete.
-
Už se smiř s tím, že jsi tu za blbečka. Oháníš se reklamou na RH a u toho děláš reklamu na MS. Víš ty co? Tak nám napiš nějakej seriál o MSCS, ať je taky nějaká sranda... a třeba se dozvím, proč se jeden z našich wokeních clusterů 3x měsíčně rozpadá a není schopnej se opět dát do kupy bez restartu všech nodů. A neví to ani ten tvůj pošahanej support, kterej doporučil reinstal všeho, po kterým se děje přesně to samý. Ty tvoje slavný klikátka už jsou tak proklikaný, že už prostě není kam klikat a posledním doporučením premiere supportu je neprovozovat ten cluster, než "se" to nějak vyřeší. A čeká se na to, až to vyřeší japonci Onoseto a Samoseto - už skoro 3 měsíce.
-
Ad Už se smiř s tím, že jsi tu za blbečka - táhněte do hajzlu, sprosté hovado. Hint: když porušujete body číslo 1 a 2 pravidel pro diskutující, dočkáte se stejného zacházení.
Ad Tak nám napiš nějakej seriál o MSCS, ať je taky nějaká sranda - na to asi root platí moc málo
Ad proč se jeden z našich wokeních clusterů 3x měsíčně rozpadá a není schopnej se opět dát do kupy bez restartu všech nodů - proč myslíte že zrovna já budu uklízet váš bordel? Jestli neumíte administrovat systém, nebo máte technický problém a neumíte provést troubleshooting, tak je to váš boj, ne můj. Máte k dispozici všechno od logů až po checked build a debugger, tak dělejte svojí práci. Pokud ovšem není vaší kvalifikací jen to, že umíte "pokročile klikat myší".
Ad Oháníš se reklamou na RH a u toho děláš reklamu na MS - jistě, když upozorním že jiný produkt řeší nějakou problematiku lépe, tak je to jasná reklama :D. Vezměte si prášek.
-
Kecy...
blabla...
aha... a to nejsou schopní opravit ani "experti" z MS, za jejichž služby platíme ročně dost vysokou částku, to už tak nějak ignoruješ... ale jo, je vidět, že jsi z MS.
Tak nám to dokaž, že to ten MS šmejd řeší lépe. Nejlépe objektivním článkem/seriálem, obsahujícím podložená fakta a srovnání a ne debilní výkřiky někoho, kdo považuje GUI za killer feature.
-
Ad to nejsou schopní opravit ani "experti" z MS, za jejichž služby platíme ročně dost vysokou částku, to už tak nějak ignoruješ - to je opět váš boj, ne můj
Ad ale jo, je vidět, že jsi z MS - IMHO LOL
Ad Tak nám to dokaž, že to ten MS šmejd řeší lépe - psal jsem, že MSCS řeší lépe konfiguraci, protože místo aby si člověk ušoupal ruce, tak prostě cluster nakliká. Nevyjadřoval jsem se k dalším vlastnostem MSCS, ani jiných řešení, vyjma konstatování že mi běží pěkných pár MSCS zcela bez problému (jo ještě a že jsem z bezpečné vzdálenosti pozoroval opakovaný "výbuch" clusteru na SLES). A upřímně nevidím důvod vám něco dokazovat, nebo psát článek/seriál pro root.
Ad debilní výkřiky někoho, kdo považuje GUI za killer feature - zatím tu křičíte akorát vy, míru debility nechť posoudí laskavý čtenář. GUI samozřejmě je killer feature, protože konfiguraci clusteru zrychluje a usnadňuje. Čím snadněji se clustery konfigurují a administrují, tím víc se mohou nasazovat. Chápu že jestli žijete ve světe, kde se výraz "uživatelská přívětivost" považuje za neslušný výraz, tak to můžete vidět trochu jinak.
-
blablabla...
support, který je v komunitě řádově kvalitnější, než oficiální od MS asi není dostatečně zásadní...
aha... to je ta krásná výhoda windows obecně... prostě tam ty wokýnka jsou, i když nejsou vůbec potřeba, takže chtě nechtě tam prostě běží grafický stack s celým cirkusem okolo. Komplexnější konfigurace čehokoliv klikátkama znamená, že buď nejde nastavit všechno a pak si to můžu lovit v tom lepším případě po různých souborech, v tom horším v registrech, navíc většinou s neúplnou dokumentací, nebo to nastavit všechno jde, ale za cenu takovýho chaosu v různých okýnkách a meníčkách, že zlatej texťák, kterej se dá grepnout a kterej navíc může, na rozdíl od okýnka, který se má vejít na obrazovku, obsahovat libovolný komentáře a příklady. Ano, klikátka jsou killer feature, ale velmi často v tom smyslu, že zabíjí vlastní produkt
-
Ad support, který je v komunitě řádově kvalitnější, než oficiální od MS - tak si nekupujte support od MS, a kupte si ho od někoho jiného. Nebo místo toho používejte "komunitní podporu", uvidíte, co vám na to zaměstnavatel řekne :)
Ad prostě tam ty wokýnka jsou, i když nejsou vůbec potřeba, takže chtě nechtě tam prostě běží grafický stack s celým cirkusem okolo - ten grafický stack běží prakticky když máte přihlášenou session. Pokud ho nechcete vůbec, tak můžete použít Server Core (BTW už minimálně 8 let), a správu provádět pomocí UI nainstalovaného na jiném stroji.
Ad Komplexnější konfigurace čehokoliv klikátkama - jenže velká většina konfigurace se dá zvládnout daleko rychleji a komfortněji těmi "klikátky". Na ten zbytek je PowerShell, případně ruční editace konfigurace.
Ad buď nejde nastavit všechno a pak si to můžu lovit v tom lepším případě po různých souborech, v tom horším v registrech - ano, v nejhorším případě na tom budete stejně jako na Unixech. Ve většině případů ovšem ne. Jak jsem psal, u žádného clusteru na MSCS jsem nemusel napsat ani řádku skriptu, a nebylo nutné editovat ani jeden konfigurák.
Ad zlatej texťák, kterej se dá grepnout a kterej navíc může... obsahovat libovolný komentáře a příklady - komentované konfiguráky jsou mizerná náhražka administračního UI. Unixová filosofie je prý "do one thing and do it well". Takže smícháme úložiště konfigurace, konfigurační interface, dokumentaci a examples do jednoho souboru, v jednom z cca deseti rozšířených formátů konfiguráků, a celé to budeme editovat v textovém editoru. Wow... totiž jenom au :/
Všimněte si, že serióznější unixový SW (třeba Oracle nebo Veritas Cluster) se také snaží mít UI. A můžete se pochlubit, kdy jste si naposledy ručně editoval konfiguráky KMailu nebo OpenOffice. Že nikdy, a vždy jste radši použil UI? No jistě, protože je to daleko rychlejší a pohodlnější. -
Díky za reakci. Pokud Vám to připadá jako reklama na Red Hat, pak je mi to líto. Rozhodně tak článek (ani celý seriál) není myšlen a pokud se odkazuju na dokumentaci Red Hat, pak proto, že prostě velice dobře vysvětluje konceptu, o kterých ve článku mluvím. Jak už zaznělo níže, Red Hat linux k tomuto seriálu ani nepotřebujete.
O Microsoftím clusteringu nevím vůbec nic, píšu jen o tom, s čím se setkávám v práci.
A když už tady mluvíme o reklamě, nemyslíte, že zrovna Váš příspěvek se dá považovat za reklamu na produkt Microsoftu? :)
ČLÁNKY DO MAILU