Redundáns webszerver - Hogyan?

Hálózatok általános

Sziasztok!

Adott két szerver, ami két külön szerverteremben van. Azt kellene megoldani valahogy, hogy ha az egyik szerver kiesik, a másik a helyébe álljon. (Pár perc kiesés lehet maximum). A szerverekről weboldalak és levelezések futnak. Az is kérdés hogy hogyan lehetne szinkronizálni a szerverek között.
Bármilyen megoldás jó, amihez nincs szükség jelentős plusz kiadásra. A szervereket CPanel kezelőfelület fogja kezelni, jó lenne ha ezt is átvenné a második szerver, de nem követelmény.

A probléma az, hogy a szolgáltatások nem csak AB-ba írnak, így a merevlemezt is szinkronizálni kell valahogy rendesen. Hogyan?
Tudom, ez így nagyon barkács, de mégis kellene valami megoldás.Ötlet?

  • 6844 megtekintés

( fn26 | 2010. 09. 21., k – 18:34 )

Hi,

biztos kapsz sok jo megoldast. En csak annyit irok, hogy a drbd a merevlemez szinkronizalasra jo lehet. En mondjuk kb. 3 eve hasznaltam, de nem volt eleg stabil, vagy legalabbis nekem nem tunt annak, viszont azota fejlodhetett.

Ahogy én csináltam meg:

- két vas, rajtuk virtualizált masina
- a virtualizált környezet drbd-vel szinkronban
- NINCS automata átállás. Mi alapján döntöd el, hogy át kell-e állni?
- a DNS külső szolgáltatónál, nem a clusteren, attól független, webes felületen lehet módosítani a rekordokat.

Értem.

http://en.wikipedia.org/wiki/Split-brain_%28Computing%29

Ezt én csak úgy tudtam megkerülni, hogy egyrészt 2 ethernet link van a gépek között, az egyik crosslink kábel, illetve van egy soros portos HB is. De ez egy demo clsuter, csak arra szolgál, hogy lehessen vele vakítani.

Nagyon be lehet szopni azzal, hogy ha van egy kétlábas clustered, egymástól jó messze, a nagy routeren és a üvegkábel hegyen is túl, a switchek által övezett gépteremben, ahol legalább évente egyszer van karbantartás és olyankor az egy másodperctől a 10 percig terjedő forgalomkiesés.

Ha ilyenkor az alvó node-od azt látja, hogy az élő fele hirtelen eltűnik, és ettől megijedve azonnal magára rántja a szolgáltatás IP címét, akkor:

- ugyanaz az IP cím két gépen lesz, ami vicces ugyan, de nem túl egészséges
- a szolgáltatásod két helyen fog futni, és nincs aki eldöntse, hogy melyik a jó változat (pláne ha sok ügyfél matat rajta, és az egyik az egyiken módosít, a másik a másikon)
- amint helyreáll a kapcsolat, a clustered érzékeli a split-brain-t (remélhetőleg, eheh), és ilyenkor változatos módon reagálnak, a leállástól kezdve az ötletszerű adatmegsemmisítésig
- a kenyér mindig a vajas felére esik, a cluster mindig a failed node-ról próbál helyreállni

A split_brain-ra az egyik, alkalmazott megoldás, az IP hálózattól független quorum eszköz használata.
Pl. egy storage diszk, amit mindkét szerver scsi-n, vagy FC-n keresztül elér.
Ha split brain szitu adódik, akkor mindkét szerver megpróbál egy scsi rezervációt rárakni a diszkre, és amelyiknek először sikerül, az nyert.
A másik látja, hogy már foglalt a diszk, és .... (álltalában elabortál, hogy még véletlenül se próbálja a közös adatokat ő is módosítani.)

csak éppen az eredeti feladatkiírásra egyébként nem létezik occsó és jó megoldás...
Lehet tákolni, de folyamatos adatszinkront dedikált min. 1Gbites link nélkül nem lehet csinálni.
Automatikus szolgáltatás fail-overt "majd a hostok figyelik egymást" alapon baromság csinálni.

Ebben az esetben legjobb amit lehet tenni, az, hogy időnként valamivel (pl. rsync) szinkronba hozni a távoli szervert az élessel, meg egy jó monitorozó, sms-küldő megoldással minimalizálni a kézi átálláshoz szükséges időt.

Pont 2 napja kerdeztem ra, akkor ezt a megoldast kaptam. Nekem ez jonak tunik, rugalmasan lehet jatszani a sulyokkal es elotte a prioritassal. Jelen esetben mondjuk en ugy allitanam be a helyedben, hogy a fogepnek adnek mondjuk 66% solyt, a kicsinek 34%- ot (azonos prioritassal), es akkor lenne nemi load balancingod is. Ha ez nem tetszik, akkor A fogepnek nagyobb prioritast, es ennyi. Celnak elvileg mindketto megfelel. Mondjuk nem tudom, hogy honnan tudja a DNS, hogy az egyik gep nem elerheto, de vagy holnap, vagy csutortokon csinalok errol tesztet. Ha erdekel, megirom.

Semmit, mar nem foglalkozom ilyesmivel :- ), ezert is irtam, hogy anno nem volt stabil, de lentebb mas is irta ugyanezt. Talan alkalmazas szintjen lenne jo megoldani, ha nem drbd. Tfh. csak valami egyszerubb oldalrol van szo, ami csak kepeket ir a vinyora, vagy filekat (na ezzel sokat mondtam :- ) ), a masik gepen meg valami figyeli, hogy mi jott, es percenkent athuzza. Na most ha valami HA- ban vannak, akkor mindketton mindketto :- ). Passz, biztos van jobb megoldas is.

aktiv-passziv-ban eleg jol mukodott nekunk, split-brainre nagyon kell vigyazni, nehogy mindket nodeon felhuzd aktivba, mert az adatvesztes.

viszont lattam hallottam egyket megmagyarazhatatlan mysql hang-rol, amiben az egyetlen kozos az volt, hogy drbd volt alatta.

milyen configgal milyen problema volt nalatok?

Tyrael

( asd | 2010. 09. 21., k – 19:00 )

gondolom ne kelljen konfiguralni, legyen egyszeru, ingyenes es mukodjon magatol....

ez az amit nem kapsz, ha HA-t akarsz hasznalni.

kezdesnek jobb, ha a cpanelt most rogton el is felejted...

( Mtommy | 2010. 09. 21., k – 19:03 )

Fájl replikálásra: drbd
Menedzsmentre: Pacemaker

Egy lanon lévő gépek esetében ez nekem működik.
Neked még kérdéses lesz a két eltérő publikus ip cím közti váltás

( uid_16401 | 2010. 09. 21., k – 19:19 )

Lehet hogy lehúrrognak majd, de nem egyszerűbb egy megbízható szervertermet találni pl. Dataplex és egy normális masinát berakni, normális rendszerrel? Hosszútávon lehet hogy egyszerűbb mint két vasat hdedikálni ugyan arra feladatra...

Azt gondolom sejted hogy a 99,5% után minden egyes emelkedés nagyságrenddel növeli a ráfordítást mind időben, mind technikában. Szerintem itthon igen szűk az a közönség, akinek egy rendes szerverteremben elhelyezett rendes szerver (tehát redundás táp és normális storage) rendelkezésre állása kevés ÉS hajlandó kifizetni a helyi és a földrajzi redundanciát.

Ha nektek megéri a ráfordítást akkor hajrá, de rendesen megcsinálni néhány perces kieséssel nem lesz egyszerű megcsinálni két különböző helyen levő gép között. Az alap megoldás pedig eleve DNS kókányolást igényel, amivel meg más esetben lehet magatokat tökön lőni.

Több szolgáltató ad földrajzilag is szeparált hostingot. Persze ezzel meg az a baj, hogy ha annál az egy szolgáltatónál van általános probléma, akkor hiába van nekik két külön kerületben a cucc, ha egyszerre dől meg mindkettő.

Jó megoldást csak akkor lehet adni - szerintem - ha pontosan ismeri valaki a feltételeket és a lehetőségeket. Addig csak azt lehet tudni, hogy néha jobb az egy, de rettentő megbízható szerver, más esetben meg jobb a kettő (vagy esetleg húsz) gépes cluster (felhő?).

Igen, azt olvastad gondolom a hozzászólásomban, hogy a ráfordítás... :) Lehet különféle szolgáltatókat vagy azoknak a különféle szolgáltatását is használni van sok módszer, de nem lesz olcsó. A különféle ISP-knél elhelyezett gépeknél az IP váltás viszont már nem olyan egyszerű, tehát igencsak ki kell találni a dolgot.

Viszont ha belegondolsz, a Dataplex eves szinten 99.999%-os rendelkezesreallast garantal, ez evente max. 5 perc kieses. Ez kb. pont annyi ido, mint ami egy dns failoverhez minimalisan szukseges, tehat sokat nem nyersz vele (meg akkor sem, ha ezt az 5 9-est nem az internetkapcsolatra garantalja), viszont noveled a rendszer komplexitasat.

Jakubovics jol mondja, alapvetoen 3 lehetoseged van: vagy veszel rendes, redundans tapos-ventillatoros-diszkes-memorias gepet, es berakod rendes hostingba, vagy ha ez keves, kiepitesz tobbszazmillioert egy rendes multisite infrastrukturat, vagy berled valakitol, akinek mar van: pl. amazon aws.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Ilyesmit minden szolgáltató garantál és be is tartja, ha szerencséje van. Ha nincs szerencséje, akkor egy csomó ügyfele ráébred a valóságra. A VH-ban is állandóan a szünetmentes betápon rugóznak az ügyfelek, de amikor egy útburkolat alatti közmű javítása okán a markoló felrántotta az üvegkábeleket, akkor bizony az 5 perc kissé 48 óra lett. Senki nem kapott kompenzációt. Ez pár évvel ezelőtt volt. Azóta is az összes terem garantál mindenféle, százhoz közeli rendelkezésreállást. Garantálni könnyű. Én a helyükben a 100%-ot is bevállalnám, a papír/monitor elbírja ezt a számot is.

a trükk az, hogy a dataplex csak a környezeti jellemzőkre (van áram, megy a klíma, őrség van, stb) garantál rendes rendelkezésre állást, a távközlést neked kell intézni általad válaszott isp-vel. vannak isp-k, akik oda betelepültek, így tőlük szolgáltatást venni annyi, hogy kihúznak egy optikát a dataplexen belül.

viszont ha teljesíti a küldetést a kábelkereső gép, az nem a dataplexes szerződésed hatásköre, hanem az isp-sed. így lehet egy nagyon jó rendelkezésre állású környezetet elrontani, mert a dataplex szerintem fogja tartani az általa ígért dolgokra az általa ígért sla-t, csak ez neked meg a te ügyfelednek mindegy, ha mégsem látja a weblapodat.

tudok olyan isp-t, aki a saját hálózati határain belül bevállalja a 100%-ot...:)

Öööö...
Dataneum-ban 99.999%-t vállalnak szintén. Két, egymástól független betáp (külön irány), irányonként redundáns áramellátás, szünetmentes és generátor.
A klímára szintén N+2 redundancia. El tudom képzelni, h áram és hűtés van folyamatosan (ha redundáns tápos a géped).

Az adatátvitel szintén többszörösen redundáns optika ÉS mikró (utóbbit nem mondom, h nem lehet megállítani, de elvágni sem...)

Az a helyzet, hogy az internet egy sokszereplős játszótér, ezért nagyon garantálni semmit sem lehet...
Másrészt vannak szolgáltatók aki redundáns hálózattal vannak jelen a Dataplex és Dataneum (nem a VH) területén, úgy hogy az "ötkilences" rendelkezésreállást gond nélkül összejöhet 1-2db kiszolgálóval és egy jól megépített adattárolóval.

"Az a baj, hogy a garantált az nem az összejöhet kategória, hanem a biztos."

Nincs az a ISP aki a saját eszközein túlra garantálna valamit is, azaz pl. a 99,999% az utolsó saját switchportig értendő... Addig meg biztosan összejön, és akkor a te rendelkezésre állásod is biztosított az inyternyetre. Azt hogy 3rd party felhordóhálózat besz@rt, és ezért Pistike számára elérhetetlen vagy, azért meg fájjon más feje pl. Pistiké.

Nem igazán csak marketing értékű. Disaster recovery célból elég sok helyen használnak másodlagos site-okat, ahova a kritikus rendszereket általában dedikált 2-4Gbit-es vonalakon folyamatosan tükrözik. Egy ilyen, valóban jó megoldás a több tíz, de inkább százmilliós árkategóriában mozog. Pár ilyen cluster építésében részt vettem én is, és egy jól özerakott környezetben kb 3-10 perc alatt átkapcsolható egy több tucat TB-os adatbázis és alkalmazás üzemeltetése egy másik földrajzi helyen levő gépterembe.

Szerintem nem az a kérdés, h ki mit garantál, hanem ki mit térít vissza ha mégsem.
Ha fizetsz havi 50e-t a 99.999% SLA-ért (1 hó=43200perc azaz 1.15HUF/perc) de óránként (munkaidőben) 100 000Ft a kiesés, akkor sovány vigasz, ha 1 óra kiesés után visszatérítik a havidíjat...

Nem mondtam, hogy nem felel meg nekik. A kérdés inkább az, hogy mi történik, ha mondjuk 2 óra hosszat kiesik?

Arra akartam célozni, hogy minden esetben meg kell nézni, hogy a magasabb redundancia (jelen esetben duplikáció - avagy vésztartalék - másik site-ra) megéri-e a befektetést. (Azaz az elképzelhető kiesés vesztesége, vagy a redundancia ára a nagyobb összeg)

Számomra olyan hihetetlenek tűnik, hogy pl. a szolgáltatófüggetlen Dataplexben, megbízható eszközökkel és normálisan, szakszerűen kialakított infrastruktúrával megvalósítható redundancia és rendelkezésre állási szint nem elegendő egy adoot feladatra, de olyan valakit bíznak meg vele, akinek itt kell tanácsot kérnie.

Ne értsetek félre szép dolog, ha az ember tanulni akar és ez egy szakmai portál, ami alkalmas is lehet erre. Nem is a kérdezőt szeretném kritizálni, inkább a megbízóját. Ez a sokadik hasonló "nagyigényű" téma itt a hup-on, ahol a valóságban is 100%-ot elérő rendelkezésre állást szeretne valaki "összebarkácsolni", de a leggyengébb láncszem szokás szerint még mindig az ember. Vagy csak én érezném így, helytelenül?!

Mondjuk, azért ez nem ennyire egyszerű :)

Nem a 100%-os rendelkezésre állásra hajtunk, hanem rendkívül olcsón akarunk összehozni egy viszonylag nagy rendelkezésre állású valamit.

Magyarul: Olcsóbbra jön ki két olcsó szervert üzemeltetni két olcsó szerverteremben, (ha össze tudjuk hangolni őket) mint egy korrektet egy korrekt szerverteremben...

"Magyarul: Olcsóbbra jön ki két olcsó szervert üzemeltetni két olcsó szerverteremben, (ha össze tudjuk hangolni őket) mint egy korrektet egy korrekt szerverteremben..."

Epp csak a rendelkezesreallasa nem lesz jobb. Sot.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Ez sajnos nem egyértelmű. Saját összeszerelésű pc, rendszeresen több mint egyéves uptime-al, ilyenem van, nem is egy.

És láttam brand gépet is hasraesni (anno amikor valami superdome-ot toltak be a pannonhoz, eheh, azt hiszem eleinte csoda volt ha egy napig ment dőlés nélkül), mindenféle gyártótól.

De tény, hogy ha lehet, én is inkább veszek "rendes" vasat.

Nem is elsodlegesen a PC miatt, hanem a penz, eszkozok, es szakertelem nelkuli clusterezes miatt. Ha akar egyszer is kezzel kell osszelegozni az adatokat egy jol fejlett split-brain utan, akkor mar a 2 9-es is teljesithetetlen alom marad. :)

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Egyébként mi futna a szervereken? Tehát mi az ami miatt nem fér bele az hogy mondjuk ha meghal az egyik (teljesen mindegy mi miatt, de most tekintsünk el attól hogy a szolgáltatónak megy el az uplinkje), akkor a másikat fogod beviszed, backupról visszatöltöd az adatokat és megy minden tovább.

Igazad van. Viszont a clusternek, a földrajzilag is szeparált megoldásoknak marketingértéke van.

Ugye ilyenkor legalább két gépet kell venni. Ha csak egy gépet kellene, akkor 2x annyi pénzt lehetne rákölteni, azaz lehetne plusz egy tápot venni bele, plusz egy hálókártyát, plusz memóriát, plusz hot- és cold swap diskeket, de ez nem hangzik olyan jól :D

( KAMI911 v | 2010. 09. 21., k – 19:43 )

HW lodabalancer, vagy 4 géppel.
2 gép ami:
LB (ldirectord) HA (pacemaker),
2 gép ami:
(Apache, Mysql, pl multi masteres megoldás)

CPanel az mibe dolgozik? Mysql?

Fájlrendszerre DRBD-t lehet, de nekem nem vált be...

Szerintem ennyi indulásnak elég lesz :oP

KAMI | 神
--
Támogatás | OxygenOffice | Fordításaim és SeaMonkey

( Tyra3l | 2010. 09. 22., sze – 15:05 )

az en ket centem.
attol fuggoen, hogy mit jelent a kulon szerverterem lehet hogy lehet az IP cimek mozgatasaval jatszani failoverre, lehet hogy nem.
nemreg raktam ossze egy 2 gepes kis clustert, ott pacemaker+corosync alapokon indultam el eloszor, de a vegen manualis failover lett belole.
van a 2 gepnek 1-1 sajat ip-je, illetve van egy VIP ip, amit barmelyik gep felvehet, erre old fel a domainnev, ergo ahol van eppen az IP, az a gep kapja a forgalmat.
mysql szinkron Master-Master megoldas lett (semmi csicsa, vagy toolkit, szimplan csak keresztbe van replikalva a ket szerver)
fajlrendszer szinten meg a pacemaker-es nekifutasban felhuztam aktiv-aktiv drbd+ocfs2 kombot, de ott is para volt a splitbrain, szoval ehelyett is egy sokkal fapadosabb unison-os megoldas lett.

a feladat inkabb a rendelkezesreallast kovetelte meg, ha esetleg a fajlrendszer vagy a DB kozott megall a szinkronizacio, az nem akkora para, mint ha megallna az oldal, es mivel viszonylag ritkan valtozik, hogy melyik szerver kapja a terhelest (a 2. gep tenyleg csak meleg tartalek), ezert itt ez megengedheto volt.

a te esetedben viszont ha az IP failover nem jatszik, akkor csak a dns marad.
felvenni a domaint alacsony ttl-el az elsodleges (vagy ha load balance is kell, nemcsak failover, akkor round robin-nal mindket gepre) IP-re, fajlrendszer szinkronban aktiv-passziv drbd(ha mindket gepnek kell terhelest kapjon, akkor esetleg aktiv-aktiv+valamilyen cluster fs, de ez ket geppel eleg nagy szopas+kockazat (nincs egyertelmu quorum)), esetleg rsync/unison.
adatbazis szinkronra vagy drbd (ez csak es kizarolag aktiv/passzivban lehet eletkepes), vagy ha mindketto gep kap terhelest, akkor Master Master replikacio.

Tyrael

A két gép annyira két külön szerver teremben van, hogy két országban van.

A második szerver itt is csak tartalék, ideális esetben csak az első szerver van terhelve. Fájl módosulás sajnos mindkét szerveren lehet, mert az oldalak működés közben mysql-t és fájlrendszert is írnak.

A két gép normálisan felszerelt, tehát redundás táp, raidelt merevlemez, stb megvan, csak az a baj, hogy időnként a szervertermek maguk meghalnak. Magyarországi szerverterem eleve nem játszik, backup 2. szerverre mindenhogyan szükség van, tehát olcsóbb lenne ezt beállítani tartaléknak, mint valami méregdrága szerverterembe költözni.

(Sajnos a törvényi különbségek miatt a szerver nem lehet Mo-n és nem lehet elérhető a szolgáltatás Mo-ról. )

DRBD-vel foglalkoztam régebben. Manualt végig olvasva kitűnt számomra: Úgy tervezték, hogy a két gép között külön dedikált legalább 100 megabites kapcsolat van. Ha ez nem áll, akkor a sok írás nagyon lelassítja a rendszert. Ha pl. csak akkor ír a lemezre, ha a másik géphez elért az adat, akkor az nagyon lassú lehet (WAN-on keresztül). Ha a masteren kiírja az adatokat és azután küldi a replikált gépre, akkor a sebesség megmarad, de adatvesztéssel járhat.

Esetleg egy jó virtuális gép nem jöhet szóba? Pl. itthon is ad a t* olyan virtuális gépet, amelyikre 99,95%-t garantálnak, ilyen biztos van külföldön is.

A DRBD háromféle protokollt tud használni a gépek között, A, B és C-t. A C protokoll az, ami (ha jól emlékszem), ami viszonylag aszinkron, azaz lassabb linken átküldve se fogja meg a rendszert. Persze ennek hátránya, hogy ha terhelés alatt van a rendszer, folyamatosan ír, és közben elkakukkol, akkor bizony van esély egy beteg fájlrendszerre.

Viszont valamit valamiért, occsóért csinálni HA-t, az bizony kompromisszumokkal jár, különösen ha a feltételek olyanok, hogy két országban van a cluster két lábacskája.

szerintem nem...
részlet a /etc/drbd.conf-ból:
# transfer protocol to use.
# C: write IO is reported as completed, if we know it has
# reached _both_ local and remote DISK.
# * for critical transactional data.
# B: write IO is reported as completed, if it has reached
# local DISK and remote buffer cache.
# * for most cases.
# A: write IO is reported as completed, if it has reached
# local DISK and local tcp send buffer. (see also sndbuf-size)
# * for high latency networks

itt mar a halozati latency is para, imho csak valami asyncron szinkronizacio jatszhat(vagy nagyon durvan buksz a teljesitmenyen), ami viszont azt jelenti, hogy lehet elveszett adat/tranzakcio.
ha ez nem para, akkor db replikacio, plusz valami rsync alapu fajlrendszer szinkronizacio megfelelo lehet.

Tyrael

( miloska | 2010. 09. 22., sze – 19:31 )

Mi alapjan ki/mi donti el, hogy mikor van failover?

( battila | 2010. 10. 04., h – 11:32 )

Az egyetlen eset, amikor nem fogod tudni megoldani, ha az ip kotodik az egyik szerverteremhez.
pl.: kulonbozo szolgaltatoknal van, vagy az egyik halozat a 10.1.0.0/16 a masik meg a 10.2.0.0/16, ...

Ezeket nezd meg, a tobbi mar megoldott: drdb, hearbeat, xen, rsync, iscsi, ...

( asd | 2010. 10. 12., k – 17:41 )

jah, split brain szitu eleve bele van agyazva a kerdesbe, mint peremfeltetel.

helyes valasz: nincs jo megoldas

A jo megoldas azzal kezdodik, hogy redundans heartbeat-et teszel a gepek koze, utana megnyilik nehany lehetoseged.

asd

stonith-rol olvastal fentebb?
ha fizikailag le tudja loni egy direkt killswitchen keresztul a magat gyoztesnek tarto gep splitbrain eseten, akkor az lehet egy mukodo megoldas.
legroszabb ami tortenhet, hogy splitbrain-nel egyszerre lovik ki egymast, de az meg belefer a "fail secure" megkozelitesbe.

ha meg tobb mint 2 geped van, akkor meg a quorum miatt mar jobban kezelheto a kiesett gepek felderitese, illetve a kieso gep sem fogja azt hinni magarol, hogy neki kellene vinni tovabb barmilyen szolgaltatast.

Tyrael

http://en.wikipedia.org/wiki/STONITH
fencing megoldastol fuggoen tobb megoldas is lehet, az egyik az lehet az, hogy fizikailag aromtalanitani tudjak egymast a gepek, ez esetben ha split brain van, akkor vagy mindket gep kilovi a masikat, es nem tortent baj, a leallastol eltekintve, vagy a passziv lesz a gyorsabb, es lekapcsolja az elhullott aktivat, es viszi tovabb a szolgaltatast szepen.

a masik megoldas, amit szoktak hasznalni, az valamilyen storage-en van a futashoz szukseges eroforras, es aki meg tudja szerezni az exclusive lockot, az a nyertes.

amugy btw. a dedikalt heartbeat link meg rosszabb is lehet, mint ha csak 1 laba van a halozatnak, mert ha ugyanaz a halozat felelos a HB-ert es a kiszolgalasert is, akkor halozati hiba eseten a split brain nem okoz problemat, mert hiaba hiszi magarol a halozatrol leszakadt gep, hogy o az aktiv, nem kaphat forgalmat, igy nem tud galibat csinalni, mig ha van kulon halozat a heartbeat-nek meg mondjuk a DRBD-nek, akkor siman elofordulhat, hogy split-brain miatt felveszi a passziv gep is a VIP ip-t es ezzel csinal egy IP utkozest, mert a publikus labon meg kilat mindket gep.

Tyrael

Tyrael

Igen, ezért írtam azt amit.

Megjegyzem a STONITH-ot nem a HB helyett használják, hanem mellette.

Akkor tételesen:

"vagy mindket gep kilovi a masikat, es nem tortent baj, a leallastol eltekintve"

Butaság. Ha mindkét gép kilövi egymást, a cluster elvesztette a létjogosultságát.

"..ha ugyanaz a halozat felelos a HB-ert es a kiszolgalasert is, akkor halozati hiba eseten a split brain nem okoz problemat"

Hatalmas nagy tömény baromság, a mondat többi részével egyetemben.

Közös erőforrással rendelkező HA storage-ok esetén a dedikált, redundáns HB nem megkerülhető. Illetve igen, de akkor nincs értelme HA-ról beszélni.

"Megjegyzem a STONITH-ot nem a HB helyett használják, hanem mellette."
valo igaz, mint szoftver valoban kell ala HB vagy OpenAIS, de magat a fencing-et(amire probaltam a STONITH-os linkel is utalni) meg lehet oldani mas modon is, persze a monitorozast mindenkepp meg kell oldani, szoval valami HB jellegu megoldas igyis, ugyis kelleni fog.

"Butaság. Ha mindkét gép kilövi egymást, a cluster elvesztette a létjogosultságát."

lehet, de attol ez meg igy mukodik/elofordulhat, lasd Stonith Deathmatch:
http://www.ourobengr.com/ha
persze megfelelo konfiguracioval, es halozati szintu redundanciaval ennek az eselye csokkentheto.

2 nodos kornyezetben sajnos nem tudsz quorumot hasznalni (no-quorum-policy=ignore), innentol kezdve pedig elofordulhat, hogy split brain eseten nem tudjak kiloni egymast a node-ok (mert azt is halozaton keresztul csinalna a STONITH agent), vagy ha fizikailag le tudjak egymast loni (mondjuk irtal egy agentet, amivel soros porton keresztul mondjuk meg tudod szakitani a masik gep tapellatasat), akkor elofordulhat hogy split-brain-nel keresztbe kilovik egymast.

velemenyem szerint 2 gepes felallasnal inkabb alljon meg mindket gep kis esellyel, mint hogy egyszerre tegye magat aktivba mindketto, es tegye korrupta mondjuk a DRBD-n keresztul a mysql particiot.

"Hatalmas nagy tömény baromság, a mondat többi részével egyetemben."
device-tol fugg, de pl. drbd-nel ha nem kap egyszerre mindket node olyan forgalmat, amit muszaj megorizni, akkor annyi tortenik, hogy miutan visszajon a halozat, eszlelik egymast a nodeok, hogy mindketto aktiv, mindketto ledobja magat passzivba, neked meg kezzel el kell dontened, hogy melyik node verziojat szeretned megtartani.
http://www.drbd.org/users-guide/s-resolve-split-brain.html
ha egyszerre csak az egyik node kapott mondjuk mysql-tol irast, akkor meguszod az adatvesztest, ha egy tobb halozatos clusterben volt split-brain-ed, es bar nem lattak egymast a nodeok, de kaptak forgalmat, mert mindketten felhuztak a VIP ip-t, akkor rabasztal.

"Közös erőforrással rendelkező HA storage-ok esetén a dedikált, redundáns HB nem megkerülhető. Illetve igen, de akkor nincs értelme HA-ról beszélni."

nekem az a velemenyem, hogy 2 gepes HA clustert csak akkor eri meg csinalni, ha vagy van valami storage, amivel megoldhato, hogy egyszerre csak 1 node tudjon futni, ezaltal megkerulni a split-brain szituaciokat, vagy ha a split-brain eseten nem fordulhat elo hogy egyszerre ket gep kap forgalmat, amit szerintem egyszeru megoldani egy halozattal, mind kettovel.

de ird le te is a sajat tapasztalataidat, csak ne meruljon ki annyiban, hogy baromsag.

Tyrael

lehet, de attol ez meg igy mukodik/elofordulhat, lasd Stonith Deathmatch:
http://www.ourobengr.com/ha
persze megfelelo konfiguracioval, es halozati szintu redundanciaval ennek az eselye csokkentheto.

Így működik, elő is fordulhat, és nem is jó ez így semmire se.

"Rendes" világban az van, hogy van shared storage, van storage fencing, amit periodikusan frissít az a gép, aki egyedül maradt. Ha nem tudja, akkor nyom egy hard resetet. Ebben a konfigurációban NEM fordulhat elő, hogy állva marad mindkét gép egyedül, egymást nem látva. Az lehet, hogy mindkettő nyom egy resetet, de "rendes" számítógépek "rendes" oprendszerekkel be szoktak ilyenkor bootolni, és majd szépen eldöntik, kinél van a quorum, és szépen megy tovább a rendszer arról a gépről. Ez "kapcsoljuk le a másik a tápját", ez ilyen pécés-olcsójánosos megoldás. És "rendes" helyeken a szerver oprendszer irányából amúgy sem engedik elérni a menedzsment hálót, ahol is le lehetne kapcsolni a tápot.

Rendes" világban az van, hogy van shared storage, van storage fencing, amit periodikusan frissít az a gép, aki egyedül maradt.

ok, de 2 gepes node-dal, amik ket kulon szerver teremben vannak, es nincs kozos storage-uk sajnos nem ez a helyzet. szerintem is olcsojanos dolog, de ez volt az eredeti szituacio, amit a kerdezo feldobott.

Az lehet, hogy mindkettő nyom egy resetet, de "rendes" számítógépek "rendes" oprendszerekkel be szoktak ilyenkor bootolni, és majd szépen eldöntik, kinél van a quorum, és szépen megy tovább a rendszer arról a gépről.

igen, ha tobb mint 2 geped van, vagy van storage, amit lehet szemaforkent hasznalni, akkor ez tok jol mukodik, de ez a topic illetve az en hozzaszolasom is a 2 gepes felallasrol szolt.

Ez "kapcsoljuk le a másik a tápját", ez ilyen pécés-olcsójánosos megoldás. És "rendes" helyeken a szerver oprendszer irányából amúgy sem engedik elérni a menedzsment hálót, ahol is le lehetne kapcsolni a tápot.

hasonlo okok miatt en sem ilos megoldasra gondoltam, hanem valami ilyesmire:
http://www.baytech.net/products/showprod.php?prod=RPC10E-20
de ez valoban barkacs, raadasul ha 2 gepteremben kell lennie a ket szervernek, akkor nem is kivitelezheto.

Tyrael

ok, de 2 gepes node-dal, amik ket kulon szerver teremben vannak, es nincs kozos storage-uk sajnos nem ez a helyzet. szerintem is olcsojanos dolog, de ez volt az eredeti szituacio, amit a kerdezo feldobott.

2 node, no shared storage => no quorum.

Ebből a legjobb, amit lehet építeni, az egy aktív - standby rendszer, ahol halál esetén manuális adminisztrátori beavatkozással lehet előléptetni a standby rendszert aktívvá, ráadásul ha abszolút zéró elvesztett tranzakcióval elégszünk csak meg, akkor minden tranzakcióírásnak szinkron kell lennie a standby tárterületre, ami azért húzósan nagy latency-t tud jelenteni.

A legjobb alatt azt kell érteni, hogy _elméletileg_ is ki van zárva, hogy ennél jobbat (pl. automatikus átállás) tudjál csinálni, előre bekódolt adatvesztés nélkül.

A probléma az, hogy a szolgáltatások nem csak AB-ba írnak, így a merevlemezt is szinkronizálni kell valahogy rendesen. Hogyan?

amugy en nem javaslom az LVS-t ketgepes felallasban, plane nem akkor ha, ahogy a topicnyito irta, foldrajzilag elosztott kornyezetbe.

ott mar eleg nagy latency-je lenne a drbd-nek is, ergo megintcsak vagy nem varod meg, mig fizikailag vegrehajtja a tavoli gep is az irast(es bukod a konzisztenciat), vagy a szolgaltatas az ido jelentos idejeben a halozati ping-pongra fogsz varni.

ps: ettol fuggetlenul ha megis maradni kellene az eredeti szituacional (2 gepes felallas, kulon gepterem, webalkalmazas, mysql+filerendszer szinkron), akkor en a kovetkezot csinalnam:

- round robin dns a 2 public IP-re
- mysql master-master
- webalkalmazas local mysql-t hasznalja
- fajlokat elso korben valami rsynces/unisonos megoldassal szinkronizalnam, de nekiallnek atirni a webalkalmazast, hogy hasznaljon valami kozos storage-et (amazon S3, vagy akar a local mysql).

Tyrael

Tyrael

a szo amit keresel a muszaj

A probléma az, hogy a szolgáltatások nem csak AB-ba írnak, így a merevlemezt is szinkronizálni kell valahogy rendesen. Hogyan?

a fajlrendszer szinkron miatt kerult elo a DRBD, de vannak sokan akik Primary/Secondary modban MySQL-t is uzemeltetnek vele.
konzisztencia szempontbol ha jol van uzemeltetve (nincsenek elrontott init scriptek, nincs split brain), akkor konzisztencia szempontjabol jobb tud lenni mint az master-master replikacio, amit MMM illetve maatkit elotti idokben elegge bator dolog volt uzemeltetni (bonyolul provisioning, nehezen ellenoriztetheo konzisztencia, key clashing, etc.).

ketgepes LVS-sel onmagaban nincs problema, csak a split-brain-nel, es vannak olyan szolgaltatasok, amik erre erzekenyebbek, ott ildomos legalabb 3 node-ot rakni a clusterbe, es akkor a quorum miatt mar kissebb a riziko, de ez fentebb szerintem mar tul is lett targyalva, esetleg olvass vissza kicsit.

Tyrael

Mindíg csak az egyik gépre történhez írás és ha A gép kiesik, akkor jön a B gép. Elvben pedig ha A gép visszajött, akkor a MySQL "felköveti" a változásokat.

Azért írtam, hogy elvben, mert amikor legutóbb ilyet csináltam akkor eléggé eseti jellegű volt a felkövetés.

Használom, teljesen jól működik. A gép B gép mastere, B gép meg A nak. Az id offseteket kell jól beállítani, hogy ne akarjon a kettő ugyanolyan id-ju rekordot lerakni, de amúgy jó teljesen.

Az meg, hogy több helyre ír vagy sem, alkalmazs kérdése, ha úgy van megírva tudja ezt kezelni, ha nem, akkor nem.

arrol erdemes tudni, hogy az autoincrementes utkozeseket ugyan tok jol lehet szabalyozni, de ha nem autoincrementes PRIMARY/UNIQUE kulcsod van, akkor Master-Master-nel elofordulhat key-clashing.
ha egyszerre csak egy aktiv Mastered van (csak egy kap egy idoben forgalmat), akkor eleg kicsi az eselye, mivel csak a failover idejen fordulhat elo, ott meg bevallalhato egy minimalis inkonzisztencia (amit majd csak akkor veszel eszre, amikor visszaengeded a faulty node-ot, es ha van inkonzisztencia, ott elofordulhat, hogy meg is fog allni a replikacio) a rendelkezesreallas oltaran.

de persze nagyon alkalmazasfuggo, ahol kell a garantalt konzisztencia, meg akkor is, ha uzemszunettel jar, akkor storage/drbd cold-spare felallassal.

Tyrael

vl kolléga lentebb már kifejtette, hogy normális világban van shared storage. Shared storage-ot akár occsón is meg lehet csinálni, linux+iSCSI target alapon, amit dedikált storage hálózaton ki lehet adni a hostoknak.
Egy valamire való HA clusterben az általad felvázolt hiba nem fordulhat elő. Egy olyan "cluster", amiben split-brain esetén bármelyik node aktiválhat, vagy írhat közös erőforrást, az használhatatlan, max. az LA (Low Availibility) névre pályázhat.

Saját gyakorlati tapasztalatom 2 géptermes clusterekkel jelen esetben nem túl nagy segítség, mert feltételez (1-4 gigabites)FC kapcsolatot, dedikált redundáns HB linket a két gépterem között, mindkét oldalon (FC) storage eszközöket, illetve jól működő cluster szoftvert.

Egyébként te is leírtad, hogy kb. mi a topic feltételeinek megfelelő megoldás. Bár, ha olyan az a webes alkalmazás, hogy fájlokat is generál ill. töröl (pl. egy publikus fotógaléria), akkor az kicsit bonyolítja a dolgot.

úgy értem, ha 2 nodeos HA (mint High Availability == magas rendelkezésre állás) clustert akar valaki, akkor ennek egy "normális" világban vannak műszaki követelményei, úgymint shared storage.
Ha ezek az elvárások nem teljesülnek, úgy célszerűbb más megoldás után nézni.
Lehet tákolni, de akkor meg ne beszéljünk már HA-ról, meg clusterről, meg failoverről, mert nem az....

.

Node mivan, ha megis mukodik?

Persze, kompromisszumok itt is vannak. Lehetnek megoldasok, ahol a te megoldasodra irja vki, hogy nem _az_.

Mashogy megkozelitve a dolgot csak hogy ertsd, ezzel a hozzaallassal leallna a fejlodes, nem lennenek takolasok, igy nem szuletnenek uj megoldasok. Szerintem definicio szerint hujeseg elvetni.

Ugy velem, mindig az ar/ertek viszony hatarozza meg, mi mihez kepest HA (high = ?, aviability = ?).
Lehet csinalni akar shared storage nelkul is ilyet csinalni, ha a peremfeltetelek megengedik.

tompos

ui.: Egy kicsit elkanyarodtam a tematol, nem biztos, hogy szorosan illeszkedik erre a topic-ra.

"Ugy velem, mindig az ar/ertek viszony hatarozza meg, mi mihez kepest HA "

Nem. A magas rendelkezésre állás nem relatív. Ennyi erővel egy 5 éves, raid1-be rakott ide diszkekkel összerakott asztali PC is hívható HA-nak, mondjuk egy bad sectoros döglődő diszkkel rendelkező XT-hez képest..

"ezzel a hozzaallassal leallna a fejlodes, nem lennenek takolasok, igy nem szuletnenek uj megoldasok"

Azért ne becsüljük le a mérnöki tervezést sem, ha már fejlődésről, és új megoldásokról esik szó... :)

"Persze, kompromisszumok itt is vannak."

Igen. A gyurmából épített vár dekoratív, és lehet, hogy még bástyája is van, de ne csodálkozzunk, ha az első ágyúlövésre szétfröccsen....:)

Hmmm, dedikalt FC, ami elvisz mondjuk 15km-re?

Elvisz az az FC még 70-150km-re is simán... pl. van két olyan telephelye a Matávnak Bp-n, amik között 56km volt a távolság, FC-to-FC mérve (nyilván légvonalban kevesebb lenne, csak a drótok össze-vissza mennek), gyönyörű szépen megy rajta a távoli storage elérése.

Az iSCSI biztos jo, bar eddig en csak Gb [dedikalt] osszekottetessel lattam ajanlva, ami nem feltetlen realis 2 szolgaltato kozott...

Nade ha nincs sávszélességed, akkor az adatokat egyáltalán hogyan szeretnéd átjuttatni egyik telephelyről a másikra? Teleportálással? Vagy furgonban, mágnesszalagon? Csak én érzem, hogy a lehetetlen akarod holnapra?

Az iSCSI-nak egyáltalán nem kell dedikált csatorna, persze, ennek az az ára, hogy disk latency-ben annyit kapsz, amit a vonalad tud.

Mellesleg, az 1Gbps, az nem egy nagy sávszélesség, ha a CPU és a diszkek közötti utat nézzük. Azért manapság egy jobb SATA diszk ki tud streamingben ennyit hajtani, egy 10-20 diszkes RAID tömb meg ennek a többszörösét is meg tudja tölteni, hanem random I/O-ról van szó.