Failover cluster - közös storage nélkül

Microsoft Windows

Sziasztok,

Adott 2 db, viszonylag combosabb kiépítésű Dell PowerEdge R520-s szerver, belső PERC RAID vezérlőkkel, közös storage nélkül.

Szoftveres oldalon (hypervisor-nak) 2 db Server 2012 R2 Standard vagy free ESXi 5.5.

4.0-s ESXi-eken levő gépeket kellene migrálni, de mivel a Server 2012 Standard már tartalmazza a Failover Clustert és a HyperV már SMB 3.0-n is képes tárolni, elgondolkodtam azon, hogy ezt vajon magas rendelkezésre állással, shared storage nélkül meg lehetne oldani.

Van valakinek ilyen irányú tapasztalata?

  • 15447 megtekintés

( _ventura_ v | 2014. 05. 08., cs – 08:37 )

Linux + drbd vel megoldható. Nem tudom a vmware/windows támogat-e hasonlót.

Fedora 20, Thinkpad x220

( freeoli v | 2014. 05. 08., cs – 09:06 )

A Windows 2012 R2 lesz a jó megoldás Neked.

( Zs | 2014. 05. 08., cs – 10:25 )

Magas rendelkezésre állás shared storage nélkül meglehetőst érdekes elképzelés. Hogyan is venné át a kieső node szolgáltatását a működő node, ha a kieső node-on futó guest adatai nem shared storage-n vannak meg? A már emlegetett drbd erre alkalmas eszköz lehet, pláne hogy tud master-master módban is gurulni - viszont a vmware saját kernelt használ. Nem mondom, hogy lehetetlen hackelni hozzá drbd modult, de annyira azért nem is lesz egyszerű.
Ami működő megoldást én erre láttam, az egy két gépes ProxMox cluster volt: egy viszonylag kis saját kötet, majd drbd-n a "nagy" lvm. Itt ha egy guest létre jött, akkor az akár live migration módon is gyorsan áttehető volt a két gép között, mert csak a konfig + memória adatoknak kellett átkerülnie egyik node-ról a másikra és máris futott tovább a guest, szinte csuklás nélkül.
Ahol ez a felállás macera tud lenni, az az, amikor emergency poweroff van mindkét node-on. Ilyenkor a drbd-n lévő adatok egyik fele az egyik node-on érvényes, a másik fele meg a másikon, mert ugye amelyik guest az egyik node-on fut, ott az az érvényes adat, ami esetleg nem ért át a másik node-ra, viszont a másik node-on futó guest adata a másik node-on érvényes és esetleg nem ért át az egyik node-ra. Ilyenkor van szívás, mert mindkét helyen fel kell hozni standalone-ban a drbd-t, majd ahol kevesebb a mentendő adat, ott lementeni az érvényesnek tekintett adatokat. Ezek után jöhet az összeszinkronizálás úgy, hogy ahonnan mentettünk, az a kiesett node, oda kell mindent visszahozni a másikról - majd ha ez megvan, akkor a mentett területet vissza kell állítani, hogy mégis az itt érvényes jusson vissza még a másik gépre is. Ez ellen úgy lehet védekezni, hogy nem egy, hanem két drbd kötet készül: az egyiken az egyik node guest-jei vannak, a másikon a másik node guestjei. Ilyen esetben nem kell mentegetni, mert az elso drbd kötetet úgy kell szinkronba hozni, hogy a node1 az érvényes és a node2 a kiesett tag, a második kötetet meg pont fordítva: a node2 az érvényes, a node1-et kell szinkronizálni. Persze ennek is ára van: az egy közös nagy tárterület szétesik két kisebbre, így ha kell egy nagyobb terület, akkor azt esetleg egy helyről nem tudjuk kiszakítani, ha viszont két helyről kell merítenünk, akkor pont az előbb leírt előnyt veszítettük el, illetve a másik fele, hogy ha később a terhelés elosztás alapján az jön ki, hogy pl. a guest3-at mégis inkább a node1-re kéne tenni, akkor megint probléma lesz abból, hogy a drbd2-n lévő lvm2-n van az adata. Szóval azért ez sem tökéletes megoldás...

"Magas rendelkezésre állás shared storage nélkül meglehetőst érdekes elképzelés. Hogyan is venné át a kieső node szolgáltatását a működő node, ha a kieső node-on futó guest adatai nem shared storage-n vannak meg?"

Nyilván úgy, ha (konzisztensen) tükrözve vannak az adatok mindkét node-on.

Köszönöm a kimerítő választ!

az uj proxmoxban mar van ceph tamogatas is: a proxmox node-ok a master (*), osd meg lehet kulso gep de akar sajat maguk is.
szvsz a split brain annyira nem veszes: hacsak nem vagy olyan marha, hogy egy vm-et ket helyen is elinditasz, a ceph monitor majd megoldja a szinkronba hozast, hogy melyik chunkot kell hova masolnia.

* itt is kell a paratlan szamu gep a szavazashoz, de meglehet csinalni hogy ket gep futtatja a vmeket tobbi gep csak a szavazasban vesz reszt.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

valszin neki van gyakorlati tapasztalata... te hogy allsz ezzel?

ha az a gep hal el, amin a ceph-mon fut, akkor mit csinalsz? persze, azt is tukrozod, es majd elinditod a masik oldalon, igaz? ha meg nem, akkor 2 monitort _nem_ ajanlott futtatni, egy jo kis split-brain utan bucsut inthetsz (legalabb) a delta alatt letrejott adatoknak.

( freeoli v | 2014. 05. 08., cs – 11:24 )

De mit akarsz igazából? Mi az minek redundáns elérhetőséget kell biztosítani?

( palotti | 2014. 05. 08., cs – 11:33 )

DRBD jó megoldás, ha nem ragaszkodsz esxi vagy hyperv-hez nézd meg a ganeti-t: linux-kvm-drbd-livemigration. Stabil, van scriptelhető parancssoros interface, és csili-vili webes felület(kis kézimunkát igényel a telepítése).

--
Kis problémából egy kis munkával nagy problémát lehet gyártani. Ha valami müxik ne b***tasd :)
Uriember az, aki nem beszél a Windows-ról, pedig tudna...

( mrceeka v | 2014. 05. 08., cs – 11:33 )

Hello,

Ezt érdemes elolvasni: http://aka.ms/hup-hvsmb
Amit szeretnél, ahhoz kevés a két host: az SMB3 cluster nem lehet azonos hardveren a Hyper-V host clusterrel.
Egyébként 2 szerverrel mit oldasz meg vele? El tudnád mondani, hogy minek nőne a rendelkezésre állása ettől és hogyan?

Üdv,
Marci

( janoszen v | 2014. 05. 08., cs – 12:54 )

Teljesen mindegy, milyen technologiat hasznalsz, nekem a kovetkezo a tapasztalatom:

Nem javaslom, hogy 2 gepbol kozos storage nelkuli clustert epits. Miert? Mert ket gep eseten nem tud tobbsegi szavazat arrol kialakulni, hogy kie a kozos eroforras (ezt hivjak quorumnak), ergo eloallhat, amit split brainnek hivunk, hogy a ket gep mindegyike nem tud a masikrol semmit es azt gondolja, hogy o a master. Ez IP cimek eseten meg kevesbe kritikus, mivel ott max nem mukodik a szolgaltatas, de adat eseten inkonzisztencia fog fellepni, amit nem fogsz tudni egykonnyen osszefesulni.

A masik amivel ismerkedj meg ezzel kapcsolatban, az a STONITH, avagy lojuk fejbe a hibas node-ot. Ezt legtobbszor a hibas node remote management konzoljan vagy egy dedikalt STONITH-device-on keresztul mukodik, azonban ez szinten csak minimum 3 gep eseten tud mukodni, mivel 2 gep eseten egymast fogjak leloni, szerencsetlen esetben egyszerre.

Elgondolkozhatsz azon, hogy bevonsz egy harmadik cluster membert, pl a default gatewayt, de azt tartsd szem elott, hogy a halozati eszkozok elsodleges feladata nem az, hogy pingre valaszoljanak, igy terhelt CPU eseten siman hiheted azt, hogy meghalt, holott csak dolgozik. Ezen felul eloallhat az az allapot, hogy mindket gep latja a gatewayt, de egymast nem, innentol kezdve megint split brain allapotban vagy.

Ezek sajnos alapigazgasok a cluster epitessel kapcsolatban es nem is tudod athagni: amit nem tudsz, azt nem tudod, a masik node attol hogy elerhetetlen, siman mukodhet es generalhat adatot. Ha ket gepbol epitesz barmilyen kozos adattal rendelkezo clustert, eroteljesen haladsz abba az iranyba, hogy a rendelkezesre allasod alacsonyabb legyen, nem pedig magasabb.

Aki mast allit, az vagy nem latott meg eleg clustert osszeborulni, vagy tud valamit amit en nem es ossza meg velem.

Csakhogy én meg azt kérdeztem, hogy Windows-on splitbrain esetén mi következhet be, ami olyan sérülést okoz a szolgáltatás adataiban, hogy visszatoltest tesz szükségessé. Erre kértem példát, mert hirtelen nem jut eszembe ilyen eset.

Rövidebben: Mi történhet Windowson spb esetén, hogy adatot kell visszatolteni?

Üdv,
Marci

Hopp ezt a kérdést nem értem. Megpróbálom megfogalmazni:
-az érdekel, hogy egy VM cluster erőforrásként automatikusan el tud-e indulni a másik hoston egy nem tervezett failover esetén?
-vagy az, hogy két standalone (nem cluster) host közti Hyper-V Replica esetén automatizálható-e a site failover?

Üdv,
Marci

Alapból a site failover egy kézzel indított folyamat.
Mivel az indítást megteheted scriptből is, így megvalósítható az automatizálás is.
Olvasnivaló: http://blogs.technet.com/b/keithmayer/archive/2012/10/05/automate-disas…
A Te környezeted esetében én személyesen győződnék meg az adott vas tényleges haláláról, indíthatatlanságáról, zárnám ki a véletlen elindulását és végezném el a site failovert.

Üdv,
Marci

A hardveres STONITH 2 géppel is megoldás a split-brainre. Annak igen kicsi az esélye, hogy egyszerre lőjjék ki egymást, hiszen ha az egyik picit is előbb áll meg, akkor nincs aki a másikat kilőjje, megakad a folyamat.

A redundáns kommunikáció és a hardveres STONITH ami 2 géppel nagyon fontos, ha az megvan, akkor szerintem okés a dolog.

Igen? Nekem anno amikor kezdtem a 2. probalkozasra sikerult olyat eloideznem hogy egymast lovoldozte ki a ket gep. Probald meg a ketto kozott kihuzni a halokabelt, esetleg egy kis packet losst betenni, ne adj isten szetterhelni a gepeket CPU-ban vagy IO-ban, kivancsi vagyok, meddig tartod fenn az allitasodat. Nyilvan nem akkor fog eloallni, amikor laborkorulmenyek kozott vadi uj kabelekkel vadi uj vasat tesztelsz, hanem mondjuk 2 ev mulva amikor valaki a Te geped folotti gepet rackeli ki es veletlenul sikerul meglazitani a mar elgyalazott kabelt.

Hát nyilván fejre lehet állítani ezt is, ahogy a quorum-os clustert is, egyik sem véd minden hiba ellen. Vannak 2 node-os és quorumos DRBD clustereim is, volt már mindenféle zűrzavar itt is ott is, nem mondanám, hogy a quorum silver bullet. Inkább a redundáns heartbeat és a jól beállított STONITH a lényeges.

Azért csendben megsúgom, hogy bírtak már emberek értelmes cluster szoftvert írni, aminek nincsenek ilyen dolgai, hogy "egyik sem véd minden hiba ellen".

Az az elvárás szerintem abszolút reális, hogy bármilyen egyszeres hiba ellen védett legyen a cluster (azaz bármilyen egy darab alkatrész megdöglik, bármilyen kábel elpusztul, bármelyik betáp megmurdel), a szolgáltatás menjen tovább. Az is elvárás, hogy semmilyen esetben (többszörös hiba esetén) se lehessen split-brain, azaz inkább álljon le mindkét node, minthogy párhuzamosan menjenek egymás mellett.

Egy korrekt, külső diszkes SCSI3 rezerválásos quorum abszolút korrektül képes ezt a funkciót ellátni.

Emberi hiba..? Vagy 1% network pkt loss, 10% IO teljesítmény csökkenés egy diszk miatt - mind okozhatja az alkalmazás bizonyos mértékű leállását, ami végsősoron a HA, a cluster kudarca lesz.

A HA soha nem fekete-fehér, bizonyos szkenáriókra felkészülsz és bízol abban, hogy a többi nem üt be..

Varj, nem azt mondta, hogy az alkalmazas nem allhat le. Azt mondta, hogy ha hiba van, inkabb legyen egy komplett leallas, minthogy a hibas rendszer tovabbra is mukodni akarjon.

Egy cluster eseteben fontosabb az integritas, mint az elerhetoseg (rendelkezesreallas).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Harmadik cluster member nem feltetlenul csak annyit jelent, hogy pingre valaszol, lehet quorum-al biro de szolgaltatasban nem reszt vevo node is. Vagyis adatot nem szinkronizal, nem tudja atvenni a szolgaltatast, de quorum szavasban tud segiteni a masik 2 node-nak hogy meglegyen az egyertelmu tobbseg. Erre pedig nem kell nagy eroforras, akar elferhet egy masik gepen is ami egyeb feladatot lat el.

Nem építettem még semmilyen clustert, még csak ötlet szintjén merült fel. Jókat mondasz, de nekem az a bajom, hogy a közös storage egy SPOF. Lehet venni nagyon jó rendelkezésre állású és redundanciát is tudó storage-et, de az jó drága. Ha nem nagyon kritikus dologról van szó, akkor még akár a manuális failover is teljesen jó lehet, és nincs split brain probléma.

--

EGYETÉRTEK.

Sajnos az eszetlenül konfigurált, szétszállt clustermegoldásokból felállás sokkal több időt vett már el az életemből mint a manual failover.
És a legtöbbször nincs is rá szükség, szükségtelenül bonyolítja az üzemeltetést, roppant kellemetlen problémákat generálva (pl. spb effektus).

Nem kell, hogy hajnali kettő legyen ahhoz, hogy probléma legyen egy átállás levezénylése.

Bőven akad olyan elfoglaltság az ember életében, amikor alkalmatlan ilyennel foglalkozni. Persze 1 ember nem ember, de főleg "egyszerűbb" környezetek esetén azért nem ritkán előfordul, hogy nincs kompetens helyettesítő és mindenki bízik abban, hogy remélhetőleg nem történik semmi a távollét/elérhetetlenség alatt...

Akár az is jobb megoldás lehet, hogy a két vas közül az egyik hidegen pihen, gond esetén a vinyókat kvázi bárki át tudja tenni.

Senkit nem erdekel az, hogy hanyszor allt le valami. Egy cluster eseteben ha valamibol csak egy van, az SPOF, mert ha egyszer elszall akarmiert, nincs potlasa neki. Es ez nem feltetlen az adott cucc hibaja lehet, ha pl. elszakad a monitoring gep halozati kabele, az is lehet hiba, holott maga a monitoring rendszer granitszilardsaguan fut tovabb a romok felett.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

J, a monitoring se csodamegoldas, nekem volt mar egy csomoszor, hogy notifikalt, de eppen akkor se tudtam volna erte barmit tenni, ha akartam volna. Egy rendszerben legyen mar annyi automatizmus, hogy legalabb onmukodoen osszeomlik, nem kell meg nekem is besegitenem neki.

Raadasul manualis failovernel a rendszergazda valik SPOF-fe, mert ha barmiert nincs internete, akkor bizony senki nem fog failovert csinalni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Sőt. Csináltam democlustert két barebone-ból, meg külön kis switch, soros kábel HB, miegyéb, aktív-passzív felállásban, drbd, miegyéb. Azzal demóztuk, hogy milyen, ha a cluster egyik lábából kirántom a delejt. Mókának, tapasztalatnak jó volt.

Az éles rendszernél maradtam a kézi failovernél, részben a földrajzi távolság miatt, részben pedig azért, mert felkacagtam, amikor kiszámoltam, hogy hány óra egy év egy százaléka.

mivel 2 gep eseten egymast fogjak leloni, szerencsetlen esetben egyszerre.

Ez nem akkora probléma, mivel meglepő módon egy HA cluster software-nek nem a szolgáltatás nyújtása az elsődleges feladata, hanem az adatok integritásának megőrzése, a brainsplit helyzet előállásának megakadályozása. Ha másképp nem megy, akkor inkább álljon le minden. Legfeljebb az üzemeltetők elkezdenek gondolkozni némi plusz redundancia előállításán.
BTW, tapasztalatom szerint egy quorum server praktikusabb bír lenni mint egy shared storage-n kialakított lock disk. Egy quorum server jellegéből adódóan garantálja, hogy az a server maradjon talpon, amelynek a hálózati kapcsolatai működnek.

Ave, Saabi.

( bognarattila | 2014. 05. 10., szo – 10:56 )

- replikálsz egyik vasról a másikra, ekkor RPO praktikusan a replikációs gyakoriság, az RTO annyi, amennyi idő alatt el tudod indítani a replikát
- szoftveres közös tár, stormagic.com ("olcsóbb"), VMware vSAN (mérettől függően olcsóbb lehet ennél egy fizikai redundáns tároló) vagy egyéb hasonló megoldások

Ha "nagy" tároló terhelésed van, akkor biztosan mélyebben zsebbe kell nyúlni (ha GbE nem elegendő).

Persze igaz az, hogy jobb egy fizikai redundáns tároló és/vagy 3 csomópont, de általában a pénzen múlnak a dolgok és lehet kompromisszumot kötni: nem nulla a kavarodás esélye, de azért kellően alacsony, hogy annak a kockázatát be lehessen vállalni (nyilván megfelelő konfigurációval, két switch is alap a vasak mellé, esetleg a vasakat közvetlenül is célszerű összekötni).

Persze mindettől függetlenül nem árt valami normális mentés megfelelő helyre, javaslom a Veeam Backup and Replicationt, ezzel replikálni is tudsz egyébként.

( NagyZ v | 2014. 05. 11., v – 04:27 )

vegyel egy NAS-t/epits valami shared storaget. fillerekbol ossze lehet rakni ha csak tarhely kell, es meg az is jobb megoldas, mint 2 gepbol ganyolni valamit.

nem ertem 2 geppel es az ingyenes esxi-vel mit akarsz csinalni amugy. vmotion nincs, dvs nincs, drs nincs, vcenter nincs...