Dotaz: HA cluster 2 serverov

[Ferdo]

Dobry den,

v sucasnosti mam jeden virtualny server. Na server sa historicky nabalovalo vela uloh. nagios, web, python skripty, vela uloh v crontabe, etc...

Vznikla poziadavka vyrobit HA cluster, tj. druhy rovnaky server s master <-> master replikacia.

prosim vedeli by ste mi odporuci akou cestou by som sa mal uberat, co si pozriet, co nastudovat a ako zacat?

Dakujem.

Odpovědi

[dustin]

Ten, kdo požadavek na master-master zadával, tomu rozumí, nebo to jen někde zahlédl z rychlíku?

Cílem je rozdělit zátěž na více serverů, protože to jeden nezvládá (tedy potenciálně master-master), nebo zvýšit spolehlivost při výpadku jednoho serveru (a stačilo by mnohem jednodušší master-slave s handoverem)?

[Ferdo]

Cielom je zvysit spolahlivost pri vypadku jedneho servera kedze je na nom nabalenych mnozstvo roli.

co mate na mysli pod pojmom handover?

[Max]

To znamená režim master-slave s ručním překlopením. Když padne primár, je na adminovi, zda ten primár opraví, nebo nahodí VM v záloze.

Režim master-slave s ručním překlopením nevyžaduje moc režií. Režim master-master je o dost složitější a náročnější.
Nevím, jak je na tom KVM (Hyper-V to neumí), ale třeba vmware to řeší tak, že dělá online replikaci běžící VM na vzdálený storage + replikuje i obsah paměti. Když primár padne, automaticky nahodí VM v záloze, což je otázkou pár sekund.
Toto vyžaduje určité licence a dobře naddimenzovanou síťovou infrastrukturu + navíc to umožňuje jen u VM, které mají myslím max 4x vCPU (možná u novější verze umí více, ale v té max licenci).

Mít storage cluster mezi dvěma lokalitama vyžaduje též dobrou infrastrukturu (a výkonný storage). Musíš zajistit, že do vzdálené lokality ti vedou aspoň dvě trasy dvěma různými směry, protože když ti někdo překopne lajnu, tak asi nechceš, aby se ti na záloze všechno automaticky nahodilo a porušila se ti konzistence replikovaných dat vůču primáru.

Z toho důvodu je nejlepší master-slave řešení. Dva servery, dva storage. Na jednom serveru+storage běží půlka věcí, na druhém druhá půlka. Mezi storage async replikace v nějakých intervalech (třeba co 5min). Když padne jedna strana, nebude fungovat půlka služeb, dokud je ručně nenahodíš na druhé straně. Pokud bude replikace řešena čistě v rámci storage, tak VM budou ve stavu, jako by jsi natvrdo vypnul proud. To v dnešní době přežije všechno.

Pokud ti záleží na minimálním rollbacku dat při překlopení v případě pádu, tak než to všechno řešit drahým řešením a na úrovni VM (což mnohdy nejde, viz limit na vCPU apod.), můžeš to řešit na aplikační úrovni. Tj. mít pro kritické aplikaci dvě VM, jednu v primární lokalitě, druhou v záložní a syncovat data na aplikační úrovni (db sync mezi databázema apod.).

Já na aplikační úrovni syncuju třeba tyto VM/služby : dns, ntp, nginx reverzní proxy servery, aplikační servery (jako např. IIS), oracle databáze atd.
Zdar Max

[dustin]

Tak nějak, díky za follow-up.

Máme master-slave jednodušší o replikaci filesystému přes drbd, takže se nemusí nic syncovat, databáze (mysql, mongodb) se replikují také online jejich vestavěnými replikacemi master-slave. Samozřejmě drbd vyžaduje tlustou linku mezi instancemi, ale mám s ním výborné zkušenosti, spolehlivá technologie.

Handover je spuštěním jednoho skriptu, ale je to ruční, do rizika split-brain se mi nechce, zase tak kritické služby neděláme. Samozřejmě každý má kritéria jinak.

[rpajik]

Pokud to padne hodně natvrdo, tak je dost velká šance, že zrovna mysql v tomhle režimu nebude mít to úložiště konzistentní. Pokud tam bude pouze InnoDb a dáte si hodně pozor jak je to nastavení, tak "jen" přijdete o poslední transakce. Postgresql to většinou zvládne. NoSQL věcem je to v podstatě jedno.

[rpajik]

Hyper-V vzdálenou repliku umí ( tedy asi jen storage a nastavení virtuálu, obsah paměti možná ne ). Failover na ten replica server tam také možný je.

Pokud je více Hyper-V serverů v clusteru a mají společné úložiště, tak při pádu jednoho serveru se to spouští na jiném.

pozn. Nikomu netlačím Hyper-V, to spíš jen pro pořádek.

To řešení kdy jsou 2 servery a na každém běží polovina věcí, je cesta do záhuby. Dává to falešný pocit bezpečí, ale realně se pak snadno stane, že když se všechny služby potkají na jednom serveru, tak tam neni dost výkonu. Člověk si řekne že si tu zátěž ohlídá ... jenže to jsou různé krátké peaky co na grafech vidět moc nejsou ... člověk má dva servery, dle agregovaných grafů oba zatížené na 40% ... a pak se to přeleje všechno na jeden server je smutek. Pokud 2 servery, tak je za mě lepší failover a tu zátěž mít vždy jen na jednom. V případě výkonostního problému klidně na chvilu rozhodit na oba ... ale s vědomím že v tu chvíli redundanci prostě nemám a je třeba to řešit.

Jinak na to aby se to správně přepnulo automaticky bys měl mít vždy někde ještě třetí server - na papíře samozřejmě heartbeat nebo keepalive vše správně zařídí. Ale když na sebe ty servery neuvidí tak je z toho krásný split-brain, protože si oba nahodí služby. Proto je potřeba mít někde třetí server ( klidně bez dat a služeb ), abys měl quorum. Když umře jeden server, tak ten záložní si na sebe převezme služby jen pokud nebude zcela osamocen. Jestli to stačí přehazovat manuálně, tak quorum netřeba řešit.

[Max]

Myslel jsem HA včetně failoveru, to čistě replikace samotné VM/storage bez obsahu ram není. Replikace samotné VM bez obsahu ram není problém snad na žádném virtualizačním řešení. Pokud tam mám ale věci, co mi nabíhají 30min, tak to prostě není ideální. A od toho je právě i replikace ram (Hyper-V opravdu neumí), případně řešit na aplikační úrovni.
Pro eliminaci split brain není ve většině případů potřeba třetí server. Aby na sebe servery viděly, od toho je duplikovaná síťová infrastruktura, případně společný storaže pro quorum disk.
Jinak to, aby si člověk pohlídal, že vše je schopné utáhnout jeden server, je samozřejmost a v dnešní době nejde tak moc o CPU jako spíše o storage a paměť.
Zdar Max

[Aleš Kapica]

Jau.

[Wex]

Celkem dobrý úvod do problematiky je kniha: Designing Data-Intensive Applications

[Ondra Beneš]

Dobry den, na high availability ve smyslu software stacku (bez reseni na urovni hypervisoru jako bylo popsano Hyper-V) se v soucasnosti pouziva corosync+pacemaker. pacemaker je vyspely system pro zajisteni resource managementu, ale i fencingu (pro deaktivaci nodu, ktere nejsou zdrave) a celkove synchronizace clusteru. corosync je pak messaging system, ktery bezi na kazdem z nodu clusteru jako runtime proces a zajistuje heartbeat komunikaci mezi nody.

Mluvilo se tu o Hyper-V, ale nevsiml jsem si jasneho zadani/specifikace, jak by ten HA cluster mel vypadat. Na jakem OS to ma bezet? Jak je poresene sdilene uloziste?

"Cielom je zvysit spolahlivost pri vypadku jedneho servera kedze je na nom nabalenych mnozstvo roli."

=> Toto je presne scenar, ktery by se dal resit pacemakerem. Klasicky failover. Oba stroje za normalnich okolnosti bezi, ale jenom na jednom bezi sluzby (aktivace uloziste, pripojeny filesystem, databaze, jakekoliv aplikace.). V momente, kdy se neco s timto aktivnim nodem (rikejme mu node1) stane, sluzby se na tomto node zastavi a spusti se na do te doby pasivnim nodu (nazveme ho node2).