[BSD] Failover cluster dinamikus adatokkal dolgozo webserverhez

[Attila Nagy]

Feczak Szabolcs wrote:
> Ok ez a level mar megjarta a freebsd-questions@ es a freebsd-hackers@
> listakat, ugyhogy elkeseredesemben, hogy senki nem valaszol ide is
> elkuldom. 
Te notórius cross poster spammer :)

> A feladat: ket gep cluster-be allitasa oly modon, hogy
> a ketto kozul barmely kiesik a masik viszonylag zavartalanul
> folytassa a keresek kiszolgalasat. A webszerver Apache,
> a programok php-ben irodtak az adatbazisszerver Postgresql.
> Nem feladat a 100%-os rendelkezesreallas hajszolasa, csupan
> annyi, hogy automatikusan detektalva legyen a hiba es
> a meg jol mukodo fel atvegye a feladatokat, "kozel" (kis - ~1 perc -
> szinkronkulonbseg megengedett) abban az allapotban ahol a masik megallt.
Egyszerű kérdés, számos megközelítés ismert :)

> Olvastam a hup-on a CARP-rol, 5.4-ben mar lesz is, de ahogy a 
> hozzaszolasokat olvastam  a cikk alatt rajottem, hogy nem is biztos
> erre van nekem szuksegem. Ahogy irtak ez csak arra garancia, hogy
> TCP szinten rendbe van-e a dolog, de ha valami alkalmazas szinten
> hasal el, akkor nem fogjak latni a weblapot. Igy a TCP SYN-re
> adott valasz nem kielegito, sokkal inkabb a szolgaltatas ellenorzesere
> iranyulo "pingek" HTTP GET, SQL SELECT ... Ahogy olvastam erre
> a DNS-LB megoldas lehet ...
A DNS alapú failover és load balancer a legtöbb esetben problémás, főleg 
a webszerverek esetében, mivel a browserek nagy ívben tesznek a DNS 
rekord TTL-jére, így ha megváltozik a rekord, a régi szervert fogják 
lekérdezni.

A failover és load balancingra valamilyen hardveres eszközt szokás 
betenni (vagy minimum két PC-t), némelyik hosting szolgáltató tud is 
neked ilyet adni.

Ezzel biztosított, hogy terheléskiegyenlítés és alkalmazás szintű 
(legalábbis az elterjedtebb protokollokra: ftp, smtp, pop, http, stb) 
failover legyen.

Értelemszerűen megoldhatod te is, de ahhoz kell még legalább két gép (ha 
csak nem magukkal a szerverekkel csinálod a failovert és a load 
balancingot).

> A filerendszer adatteruletenek szinkronizalasara
> elso otletem az volt, hogy GEOM-al keszitek egy felemas tukrot,
> azert felemas mert egyik fele lokalis, masik fele nfs. Mint
> kiderult lehet is ilyet csinalni geom_mirror + geom_gate-val,
> de sajnos a szinkron egyiranyu lesz, es olyan "layer"-t senki
> nem tudott ajanlani, amit ket gep meg tud valositani es 
> azt elerve mindket gepben levo tarolon parhuzamosan megtortennek
> az iras muveletek, az olvasas lehet csak egyikrol is.
Tipikusan erre valók a clustering fájlrendszerek. Linuxhoz pld. opengfs, 
lustre, intermezzo használható ilyen célra.

Másik lehetőség, hogy csinálsz RAID-et, de egyszerre csak egy gépen 
húzod fel és ha az meghal, felmountolod és elindítod az alkalmazásokat a 
másikon. Ez kicsit macerásabb és sokkal több a hibalehetőség, mint az 
elsőnél.

> Tulajdonkeppen nem akkora problema ez, hogy egyiranyu a szinkron,
> csak a master kiesese es visszaallitasa utan esetleg kezzel kell
> szinkronizalni. Bar igazabol nem ertem, mivel tudomasom szerint egy
> szamlalo erteke  alapjan dol el, hogy melyik komponens a frissebb, 
> es a magasabb ertekkel rendelkezohoz szinkronizalja a masik osszetevot.
A gmirrorra gondolsz? Ott nem ez a gond, hanem az, hogy az UFS-t 
egyidejű írásra, olvasásra tervezték.
Emiatt már az sem működik, hogy egy RW felmountolt fájlrendszert egy 
másik gépen RO csatolj fel, mert bizonyos metaadatokat a gép memóriában 
tarthat, becache-elhet és ennek a cache-nek a működésére nincs ráhatása 
a másik (RW-s) gépnek.

Csak RO mountolt UFS, csak ez nem hiszem, hogy megoldás neked :)

Egyirányú szinkront csinálhatsz cvsup-pal, rsync-kel, stb, stb.

> Az adatbazist Slony-val probaljuk szinkronban tartani, sajnos
> nem sok szerencsevel jartunk eddig. A Slony listara meg is irtuk,
> hogy minden jonak tunik, kommunikal is a ket node, de megsem
> tortenek update eseten valtozas a masikon. Sajnos onnan sem jott valasz
> par napja ...
Postgres esetében meg lehet még próbálkozni a pgreplicatorral is.

Ha tényleg fontos az adatbázis és pénzed is van rá, használhatsz Linuxot 
és azon Oraclet OCFS-sel. Sajnos ilyen, ezzel egyenértékű, vagy akár azt 
megközelítő megoldásról nem tudok OS adatbáziskezelők tekintetében.

> Ha a fenti harom dolog osszeallna: dns-lb-vel a hibadetektalas es
> valtas, kozos fajlrendszer geom local+nfs, adatbazis szinkron slony-val,
> tulajdonkeppen mukodhetne is a dolog, de sajnos semmi tapasztalatom
> nincs ezekkel, igy elegge akadozva haladnak a dolgok, valamint 
> fogalmam sincs mennyire fog ez mukodni, veszelyezteti-e az adatok
> konzisztenciajat ... es ha igen milyen mertekben (a kieseskor
> elveszett nehany rekord elvesztese toleralhato, ha az adatbazis 
> teljes egeszeben ep marad es a tovabbi uj rekordok rogzulnek).
Minél "fejlebb" mész a failoverbe, annál több hiba lehet. Blokkszinten 
(cluster FS) a konzisztencia kevésbé probléma, alkalmazás szinten 
(rsync, hasonlók), már annál inkább.

> Tudom a jo megoldas az lenne ha venne egy HA hardware switchet, vagy
> berelne ket portot, de ez momentan nem fer bele a koltsegvetesbe,
> viszont azt sem szeretnem, ha ugy menjek pihenni/szorakozni hogy tiszta 
> para barmikor jon egy SMS mehetek dolgozni, vagy rosszabb esetben
> utazhatok Budapestre szervert buheralni. A cel tehat hogy a hiba
> at legyen hidalva, jojjon ertesites, aztan megoldom amint tudom hogy
> visszalljon a normal allapot.
Magát az LB-t és a failovert az "Internet felől" szerintem bízd a 
szolgáltatóra, keress olyat, akinek van ilyen szolgáltatása.

A gépek esetében használhatsz közös diszkdobozt, Linuxszal és valamilyen 
CFS-sel, de itt a DB replikációt és failovert még mindig meg kell 
oldanod (a Postgres és a Mysql sem támogatja a CFS-eket, legjobb 
tudomásom szerint).

Alternatív megoldásként vehetsz egy fájlszerver appliancet, amelyet 
NFS-sel érsz el, vagy ugyanezt a funkcionalitást megoldod saját NFS 
szerverrel és megpróbálod azt minél megbízhatóbbá tenni. Appliance 
esetében később lesz lehetőséged failoverre (megfelelő doboz esetében), 
saját NFS szerver esetében kevésbé (bár ott is bejátszik a CFS, de akkor 
már csinálhatnád a frontendeken is).

-- 
Attila Nagy                                   e-mail: Attila.Nagy at fsn.hu
Adopt a directory on our free software   phone @work: +361 371 3536
server! http://www.fsn.hu/?f=brick             cell.: +3630 306 6758