LB & HA Cluster

Linux-haladó

Sziasztok!

Szeretnék létrehozni egy terhelés elosztásos, magas rendelkezésre álló fürtöt.

A szervereken névszerver, web, adatbázis, és levelezés fog futni. Körülbelül 4-5 szerver állna rendelkezésemre, és a szervereken Debian Lenny futna, központi tárolási alrendszerrel.

Már nézegettem megoldásokat, de még nem tudtam választani.

Ki mit ajánl?

Üdv,
Ádám

  • 3014 megtekintés

( Batman | 2009. 09. 24., cs – 14:18 )

Szia,

Pár gondolatomat ezzel kapcsolatban szivesen megosztom , remélem lesznek hasznos ötletek, mostanában én is foglalkozom ezzel.
Vegyünk alapnak 3 gépet ,de a szám tetszés szerint növelhető. (Mind három gépen legyen levelezés , web, adatbazis stb..., ezek is tetszés szerint csoportosíthatók)

Én úgy képzelem el a rendszert, hogy egy hálózatban vannak , ez fontos későbbiekben kiderül hogy miért.
Van 3 ugyan olyan Lenny-s szerver ugyan azokkal a konfigokkal. Ahoz, hogy a 3 webszerver képes legyen ugyan azokat a vhostokat kiszolgálni kell valami, közös storage stb.. De szerintem ennek egy másik frappáns megoldása Glusterfs , ez raid over tcp-t ad. Tehát mind a 3 webszerveren ott lesz az összes vhost-od bármelyikhez fordul a kliens ugyan azt adja vissza. Ha egyik mappában változtatnak egy képet az azonnal megjelenik az összes másik szerveren is. Természetesen az apache-ot is szinkronba kell hozni, ha változik valahol a vhost akkor a többin is változzon. Ezt még meg lehet fejelni esetleg azzal, hogy keepalived-vel figyelik egymást a szervereket, ha egyik szerver kiesik , akkor egy másik átveszi az ip-jét virtuál ip-nek. Ezért kell egy halozaban lenniük, így gyakorlatilag pár másodperces kiesés tapasztalható maximum ez egyik szerver kiesésekor. Ehhez az kell, hogy domain-ek körübelül egyenlő számban mutassanak a különböző szerverekre. Van más megoldás is egyik szerverre mutat az összes domain-ed és arra feltenni, egy webproxy-t ami szorja szét a többi szerver közt a kéréseket. Attól függ mennyi domained van és mekkora a sávszéligényük mert ilyenkor minden ezen az egy gépen megy keresztül elöbb utóbb lehet kevés lesz a 100Mbit.

Mail, hasonlóan a fentiekhez 3 gépen ugyan azokkkal a beállításokkal fel van húzva egy postfix , csak a mailroot mappa glusterfs-el van szinkronizálva. A domainekhez, 3 mx rekord van felvéve 10-es priorítással , így a 3 szerver kb egyenlő arányban fogja a leveleket fogadni. Így sose lesz terhelt a levelező szerver, ha egy kiesik másik kettő is lazán viszi majd.

Mysql, célszerü egy mysql clustert létrehozni, master-master replikációval, én minimum 3 noddal csinálnám, és mindig csak az egyikre írnék ha az kiesik akkor térnék át a többire. Én a mysql-proxy-t használom most , igaz nem teljesen tudom arra használni amire akarom, mert még nem kiforrot benne a read-write splitting, de ha kész lesz akkor egy szerverre csak írni fogok másik kettőről csak olvasni így jelentős gyorsulást és biztonságot várok majd az esetleges hibák kivédése miatt.

DNS- itt ugyebár alapból két névszerver van ha egyikkel valami történi a másik még képes kiszolgálni a kéréseket, de akár 3 dns-t is hadrendbe lehet állítani.

Persze most csak vazaltosan írtam le, több helyen még ki lehet egészíteni a konfigot és javítani rajta, de lényeg hogy maga az elképzelés szerintem látható benne.

üdv

Ha sikerülne feltennem 32bites lenny-re akkor használnám elég nagy terhelés alatt de eddig csak 64bites lennyre tudtam beállítani, de ott nincs nagy terhelése de szépen megy.
Szoval ha neked sikerül 32bites lennyn esetleg beüzemelni akkor elmondhatnád a titkot. Fel tenni feltudom össze is jön a kapcsolat de másoláskor az xfs fájlrendszert nem szeretni , ext3 itt is megy. 64bitesnél ext3-at és xfs-t is viszi , csak tudnám miért.

Kérdésed gondolom arra irányul mi is ez:
http://www.gluster.com/community/documentation/index.php/GlusterFS#Intr…

Lényegében amit írtam helyes, két független szervereren képes két mappát szinkronban tartani, ha egyik kiesik majd visszatér helyre állítja a szinkront. Lényegében raid1-et tudsz elérni vele, csak tcp protokoll felett.

Szerintem mind a kettővel elég jól tisztában vagyok.És azzal is tisztában vagyok ,hogy két teljesen különböző megvalósítás más-más eszközökkel, de az elve hasonló és így sokkal szemléletesebb. De természetesen mint mindig a tudásomat szivesen bővítem , így ha leírnád a saját véleményed a topic indító kérdésére , az is hasznos lenne.

"de az elve hasonló és így sokkal szemléletesebb"

Pont ez a lenyege, hogy nem. Az egyetlen kozos pont, hogy mindketto adatokat replikal, semmi mas.

"ha leírnád a saját véleményed a topic indító kérdésére , az is hasznos lenne"

Elore 2 gep haproxy+carp-al, moge johet a tobbi. Webszerver/mailszerver moge teljesen jo a glusterfs+replication, itt (vagy adatbazisban) lehet tartani a session-oket is. Db-nek van a mysql-ndb az ismert limitaciokkal, vagy ki lehet probalni ezt.

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

Szia,

Ezt leírnád vagy kifejtenéd kicsit részletesebben, hogy php-nak hogyan is mondod meg kire írhat és kitől olvashat, ez nagyon érdekelne. Olyan megoldás érdekel , amin a php kodban nem kell valtoztatni, hanem egy a php és az sql közti réteg döntené el, ilyen lenne a mysql-proxy.

üdv

Viszont a master-slave cuccal megint csak ugyanez a baj. Egy webapp olvas es ir is a SQL backendjere, nem nagyon lehet a mukodokepesseg csokkentese nelkul ezt megkerulni. Mittudom en, egy forumon nagyon hulyen nezne ki, ha nem lehetne kommentet irkalni. Viszont a master-slave pont arrol szol, hogy a slave read-only, tehat mindenki a mastert basztatna az irasi keresekkel - SPOF.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Azert ekkora talan megsincs, ugyanis egy ilyen oldalnal akkor is feljon a caching szuksegessege, ha egy geppark van mogotte - egyszeruen azert, mert felesleges mindent nyers erovel kiszolgalni. szerintem egy tizezer c/d rataju oldalnal sem megy el egymillioig a valodi req/d.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( addi | 2009. 09. 24., cs – 14:58 )

Találtam egy másik megoldást is, amivel könnyedén ki lehet vitelezni az egészet: round robin DNS

Állítólag az a hátránya, hogy ha kiesik egy szerver, akkor ugyanúgy küldi neki is a kéréseket, viszont dns, mail, web, ftp minden elosztható vele egyszerűen.

Ezt használja valaki hasonló célokra? Tapasztalatok?

Igen, mi ilyet használunk.

A kieső gépeket ki kell venni a DNS-ből, és akkor nem megy feléjük kérés. Monitorozással és dinamikus DNS-el meglehetősen könnyen összerakható az egész.

Magánvéleményem, hogy a "tökéletes" terheléselosztás és tartalékolás hajszolása teljesen felesleges és a végén a létrhehozott rendszer belső bonyolultsága többe kerül, mint az, ha időnként az egyik kiesett szerver felé mondjuk öt percig hiába mennek a kliens kérések.

Monitorozásra a kialakítástól függően sok mindent lehet használni, pl. nagios-t. Vagy ha szükség van cluster FS-re és ahhoz amúgy is van beépített monitorozás a fencing/stonith miatt, akkor arra is lehet építkezni. (A kettő persze kombinálható is.) És ha a a monitorozás egy node-ot halottnak tekint, akkor már csak azt kell megoldani, hogy meghívjon egy megfelelően paraméterezett "nsupdate"-t :-)

Nálunk eléggé el nem ítélhető módon a GFS miatt csak a GFS cluster saját monitorozási ága van meg, és a fencing hívja az nsupdate-t. Ezért azt külön biztosítani kell, hogy egy sikeresen elinduló node saját magát "visszategye" a DNS-be.
Nagios-al az egész elegánsabb lenne. Előbb-utóbb áttérünk majd arra.

Köszi a választ.

Most épp a RRDNS-t tesztelgetem. Így elsőre elegánsabb megoldásnak tűnik, mint minden szolgáltatást más módszerekkel összekonfigolni. Itt tényleg csak pár scriptet kell megírni, és működhet a dolog web-re, ftp-re, mail-ra.

További kérdés, hogy az adatbázist ez esetben hogyan valósítod meg? Gondolom itt nem mindegyik gépen futtatsz külön adatbázist.

Az ördög persze a részletekben rejlik...

Kérdés, milyen mélységig akarsz tartalékolást, terheléselosztást? Csak a frontend szerverek szintjéig? Akkor ott van single point of failure-ként az egyetlen backend fájlszerver. Ha azt is eliminálni akarod, akkor kell egy cluster fájlrendszer...

A szolgáltatásokat külön-külön kell nézni és kezelni. Az FTP nem probléma. A mail-nek két fele van: az SMTP nem gond, ha nagyon óvatos akarsz lenni, akkor külön SMTP a bejövő leveleknek (MX), és külön a kimenőknek (SMTP relay/SMTP auth a klienseidnek). Utóbbinál lehet játszani az RRDNS-el, hogy a kliensek esetleg ne akadjanak fenn egy kiesett szerveren. De a POP/IMAP-nál szerintem elkerülhetetlen a cluster fs-re való építkezés. (Sajnos a GFS1 nagyon nem szereti a sok fájlt, ezért a Maildir-t pl el kell felejteni :-().

A webnél ha csak statikus fájlok vannak, akkor egyszerű, de gyakorlatilag nem ez a helyzet. Amint a szervereken valami állapotot tárolnod kell, máris el kell felejtened a memóriát, mert a DNS miatt egy kliens akár "körbejárhatja" az összes fronted webszervert. Marad az adatbázis (áttoltuk oda a problémát :-), vagy a közös cluster fs területének használata.

Adatbázisnál szerintem még a legegyszerűbb egy master-master replikáció, nálunk több éve stabilan működik. Home-breed alkalmazásnál meg tudtuk csinálni a következőt: van két read-write master-master backend adatbázis szerver, a frontend szerverek pedig master-slave kapcsolattal replikálják a csak olvasott adatbázisokat, táblákat. Sajna, ha egy master kiesik, akkor a mögötte levő slave-k is kiesnek. (Játszottunk egy picit az automatikus master váltás összehozására a slave-eken, ha több idő lett volna rá, akkor talán összejön. Nem reménytelen dolog, de nem is rocket science.)

Az eredeti felvetésnél névszerver is szerepelt: ahhoz semmi nem kell, a DNS "magától" kezeli a több NS szerver használatát.

"De a POP/IMAP-nál szerintem elkerülhetetlen a cluster fs-re való építkezés."

Néhányan nehezen tudnak azonosulni a gondolattal, de ebben az esetben a cluster fs lesz az SPoF. Egyébként a mail cluster fs-en tárolása nem csak drága, felesleges, de még csak nem is jó.

A megoldás az alkalmazás szintű replikáció. Amit beletehetsz az alkalmazásba, vagy csinálhatod azt, amit én: egy libraryval, amely érti pld. a maildirt, és megoldja a gépek szinkronban tartását.
Szerencsére a maildir ebből a szempontból nagyon jól eltalált rendszer, így egész könnyen lehet split brain tűrő multimaster mail szervereket csinálni, shared nothing architektúrában.

Miért lenne a cluster fs SPoF? Pl. a mi öt gépünkből max kettő eshet ki, és a cluster még mindíg él.

Milyen library-t használsz az alkalmazás szintű replikációhoz? Az hogyan kezeli a splitbrain szituációkat? Hogyan "kötöd be" az alkalmazásokba, ha azok pop/imap szerver, postfix és MUA is (procmail, mutt, alpine)?

Nem állítom, hogy a cluster fs "a" megoldás. Ha van jobb, örömmel hajítom ki.

Vegyük például azt az esetet, amikor a clusterben az egyik géped hardveresen kicsit megszédül. Nem nagyon, csak kicsit. Csak annyira, hogy elszámoljon dolgokat, és szépen összefirkálja oda nem illő adatokkal a shared diszkjeidet. Hopp, a cluster már nem is él, mert elpánikolt az összes tagja.

Hogy ilyen nincs? Dehogynem. :)

Saját libraryt. Úgy kezei a split brain szituációt, hogy minden oldalon rögzíti az ott történteket, és ha elérhető a többi gép, visszajátssza a történéseket. Szerencsére a maildirnél ez jól megy, a fájlnevek egyediek az egész világon.
LD_PRELOAD-dal kötöm be, vagy ha épp nyílt forráskódú, hát inkább hozzálinkelem. :)

A hardveresen kicsit hibás gép ellen az alkalmazás szintű replikáció sem segít: pl. a hibásan legyártott fájljaid a library továbbviszi a többi gépedre és azokon is megjelennek.

Mondjuk a Maildir-nél a create/rename/delete-n kívül mást nagyon nem kell kezelni. :-) Ettől függetlenül érdekes lehet, hogyan oldod meg, ha egy gép mondjuk kiesik fél napra és utána jön vissza? Hogyan kapja meg az addig történt változásokat? Kéri egy másik szervertől timestamp alapján? Meddig emlékszik a tranzakciókra?

Én úgy gondoltam a mailt, hogy NFS-re rátenni a konfigokat, valamint a leveleket tartalmazó könyvtárat. Ez után pedig mindegyik gépre bemountolni őket a megfelelő helyre, és elindítani a szolgáltatást.

A névszervereket pedig külön MX 10, 20, stb. rekordokkal konfigolni.

Ez így működhet?

De, nagyon sokat segít. Ha a kicsit hibás gép csak néhány mailt kefél el, az sokkal kisebb gond, mint ha az egész fájlrendszert elkefélné, olyan szinten, hogy azt később akár fel sem tudod mountolni, illetve a többi gépen lévő sanity check miatt szándékosan, vagy a bitszemét miatt (ez még rosszabb, mert egy kisebb problémából akár egy nagyobb is lehet) véletlenül crashel el az összes géped.
Alkalmazás szinten megvannak a megfelelő absztrakciók, amelyek ezt eleve lehetetlenné teszik (de legalábbis még a fentinél is sokkal-sokkal kisebb valószínűségre csökkentik).

Minden gép a saját magán történt változásokat jegyzi meg a neki beállított gép(ek) felé. A tranzakciók rögzítése, és azok visszajátszása sorrendhelyes, viszont a nagyobb áteresztőképesség érdekében mailboxonként történik (azaz előfordulhat, hogy az egyik gépen A mailboxba hamarabb érkezett meg egy levél, mint B-be, míg a párján ez fordítva van, viszont a mailboxokon belül sorrendi felcserélődés nem lehet).
Amikor egy gép eltűnik egy napra, oda értelemszerűen nem megy levél, nem történik változás. A vele kapcsolatban lévő másik gép(ek) addig írják a tranzakciós logot, és folyamatosan próbálják áttolni a hiányzó gépre.
Amint az visszajön, az áttolás meg tud indulni, és elkezd visszaállni a szinkronitás.

A tranzakciókra a "végtelenségig" emlékszik, ugyanis nincs olyan követelmény, hogy egy gép kiesik, és sosem jön vissza.
Természetesen ha ott elveszne az adat, a másikról -nem a tranzakcionális módszerrel- újra kell szinkronizálni, majd elindítani a tranzakciók feldolgozását.

Ha belevarrsz az url-be egy sessionid-t, akkor apacs frontendeket használva load balancernek, a roundrobin dns nem lesz probléma.
Ezzel a megoldással el lehet jutni odáig, hogyha lerohad az egyik gép, akkor az azon futó sessionok vesznek csak el, a szolgáltatás újraloginolás után ismét igénybe vehető.

A teljes, abszolút üzembiztos elérést meg ilyen tandem kategóriás cucc nélkül szerintem nem lehet elérni. Mert ha elindult egy http request kiszolgálása és közben megborul a vas, akkor az a request biztosan elveszett, tehát valamekkora szolgáltatás kiesés lesz. Ezt a kiesést lehet csökkenteni.

( turdus | 2009. 09. 24., cs – 15:13 )

Nekem az a tapasztalatom, hogy a kettő együtt nem az igazi. Minden professzionális megoldás vagy az egyik, vagy a másik.

Egyébként én a VRRP-t javaslom dns helyett, ez nem load balance-ol, hanem ha, viszont faék egyszerű, és linuxon támogatott. Annyi a lényege, hogy az aktív node mindig elmagyarázza a HA alőtt lévő routernek, hogy neki küldje a SIP-re érkező csomagokat.

Ha tényleg mindkettőt szeretnéd egyszerre, akkor szerintem az osztott rendszerek fele nézelődj.

( addi | 2009. 09. 25., p – 14:40 )

Más ötlet:

VIP-el esetleg nem lehet ügyeskedni?

Az előbb kipróbáltam azt, hogy van 2 gép, az alábbi címekkel:
server1.IP: 192.168.0.101
server1.VIP: 192.168.0.100
server2.IP: 192.168.0.102
server2.VIP: 192.168.0.100

Ráindítottam pinget a 192.168.0.100-ra és utána lelőttem az egyik gépet. Ha azt lőttem le, amelyik válaszolgatott a pingre, akkor természetesen leállt a ping, de 5-10 perc múlva visszajött, automatikusan. Ha a másik gépet lőttem le, akkor értelemszerűen ment tovább a ping, kiesés nélkül.

Gondolom az ARP cache miatt van a jelenség, tehát ha egy másik gépen jött volna be a kérés akkor az kapott volna pinget egyből, hiába állt egy gép.

Erről mit gondoltok?

Tudnál erről egy kicsit bővebben írni?

Ha jól értelmeztem, akkor mondjuk 4 gépet felhúzok azonos rendszert, mindenben azonos konfigot, és beállítom ugyanazt az IP címet a gépekre a CARP protokollt használva. Ebben az esetben egy IP-n lesz elérhető minden a külvilág számára.

Mennyire osztja ez a terheltséget?

A különböző szolgáltatásokhoz mennyire lesz ez használható? (pl.: apache session-ök)

"Tudnál erről egy kicsit bővebben írni?"

carp, vrrp

"Ha jól értelmeztem, akkor mondjuk 4 gépet felhúzok azonos rendszert, mindenben azonos konfigot, és beállítom ugyanazt az IP címet a gépekre a CARP protokollt használva. Ebben az esetben egy IP-n lesz elérhető minden a külvilág számára."

Igyvan.

"Mennyire osztja ez a terheltséget?"

Elvileg tud load-balancing-ot, de gyakorlatban nem erdemes ezzel kuzdeni (pl. carp-nal az arp lb csak subneten belul mukodik, tehat ha a forgalom nagy resze egy helyrol (a routerrol) jon, akkor nemjo; az ip lb-hez meg az osszes carp hostnak latnia kell a forgalmat (pl. hubos halozat)).

"A különböző szolgáltatásokhoz mennyire lesz ez használható?"

Mire gondolsz? Ez csak egy kozos ip-t biztosit, minden mas a te dolgod.
Az viszont szerintem ellenjavallt, hogy kozvetlenul a webszerverekre tegyel carp-ot, ezt inkabb ugy szoktak, hogy a webszerver-farm elott a load-balancert ha-zzak vele.

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

Köszi.

Akkor ez a megoldás, úgy látszik ebben a formában el van vetve. (Úgy akartam, hogy a 4 webszerveren ugyanaz a konfig, és akkor ugyanaz az IP, és osztják egymás között a feladatokat.)

Van még a M$-nek egy Network Load Balancing, NLB nevű megoldása. Ez létezik Linux alá? Vagy ez pont az, csak más néven?

Az rrdns nem igazan terheleseloszto, hanem ahogy esik ugy puffan alapon oszt. Egy load balancer attol load balancer, hogy esetleg kepes kifigyelni a tulterhelt peer-t, es annak addig nem osztani, mig nagyjabol ki nem szolgalja a hozza befutott kereseket - a rrdns ezzel szemben egy buta allat, mindig a soron kovetkezo cimet osztja le. Az ftp nem igazan tudja tulterhelni a gepet, foleg ha az egyes peer-eknek jo nagy memoriajuk van - nagy diskcache -, mert nagyjabol fix terhelest ad le. A mailnal mukodhet a rrdns, mert a level elkuldese utan a kapcsolat azonnal lezarul - nem kell tehat a tovabbiakban fenntartani a kapcsolatot a klienssel, igy nem futhat ki a max kapcsolatszambol, plusz a mailnak nem feltetlen kell azonnal kezbesiteni (nyilvan itt egy olyan frontend rendszert feltetelezek, ami csak fogad, de nem csinal semmit a levellel - az a backend feladata). A db-t meg szerintem ne rrdns-sel oldd meg.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ez nagyon rossz ötlet, egyrészt mert nem csak a kérések, hanem a csomagok is el fognak oszlani, ami azt jelenti, hogy szinkronizálnod kell a két gép között a TCP kapcsolatok állapotát, másrészt, ha két gépről forgalmazol ugyanazon a MAC címen, akkor nem kizárt, hogy a switch viharos sebességgel le fogja vágni a portodat a fenébe (ezt a Cisco-guruk majd megmondják).

Azt javaslom Neked, hogy ne bonyolítsd túl a feladatot, mert több szopásod (és leállásod) lesz vele, mint egyébként. Az SMTP úgy van megtervezve, hogy nyugodtan kibír egy kis leállást, plusz több MX rekordot is fölvehetsz. Storage szinkronizálásra DRBD, Apache, stb failover Heartbeattel, backupolni meg úgyis kell, azt nem úszod meg sehogy sem.

Ha vagánynak érzed magad és load balanced megoldást akarsz, akkor két gépen fellőhetsz egy-egy LVS-t, opcionálisan több IP címmel, Heartbeatelve. A backend gépeket meg ügyesen összerakni.

Egyébként egész konkrétan mit fog ez az egész kiszolgálni?

Gondoltam, hogy ez elég gányolt megoldás így magában, de azért megkérdeztem, mert valaki ajánlotta...

Pár weboldalt fog kiszolgálni, tudom ágyúval verébre, de szeretném egyszer jól megcsinálni, hogy ne kelljen azonnal ugrálni, ha valami gond van...

Ha megcsinálom a HAProxy/Heartbeat-s 2db LB-t, azok osztják a kéréseket a többi gépre. Ebben az esetben az LVS miért kell nekem?

Az LVS ekvivalens a HAproxyval ebben a konstrukcióval, csak abból is kettő kell, különben van single point of failure. Az LVS általnosan TCP load balancer, kapcsolatokat dob tovább a real szervereknek. Ha jól nézem a HAproxy pedig HTTP szintű load balancer.

Ha pusztán az a cél, hogy ne kelljen ugrani, ha baj van, akkor két gép, DRBD, Apache failover és csókolom. Bármi bonyolultabb ennél négyzetesen több munkát és szopást jelent fölhúzni és annyival többet nem nyersz vele (de akár veszthetsz is, mert ha lerohad, mégis csak ugrálnod kell). Ja, és még egy vagon pénzt is kifizetsz.

Természetesen 2db LB-t tennék be.

Tehát ha LVS-el csinálom meg, akkor nem csak az apache látszik egy gépként kifelé (mint HAProxy-s megoldás esetében), hanem az összes TCP-n futó szolgáltatás? (email, ftp)

Gondolom ns1-et és ns2-t érdemes a 2db LB-n futtatni.

( bambano | 2009. 09. 26., szo – 18:21 )

el kellene gondolkodnod, hogy mennyire magas rendelkezésre állást akarsz. ha valódi életnek megfelelőt, akkor azért ott elég sok mozgástér van, mert apróbb kellemetlenséget eltűrnek az userek.

( addi | 2009. 10. 02., p – 20:30 )

Pár előrehaladás van a projektben.

Csináltam egy HA Storage-ot Heartbeat/DRBD/NFS kombóval, ő osztaná a node-oknak a konfigokat.

Játszottam is virtuális környezetben mennyire HA, de azt kell, hogy mondjam, nem igazán megbízható, így első ránézésre... Kb 2 napos tesztelés közben vagy 20 különböző hibaüzenet jött elő, van amikor a DRBD esik szét (split brain, stb), van amikor a Heartbeat nem állítja át az IP-ket, aztán másolás közben kapcsolom le a gépet, akkor az NFS irogat szép üzeneteket a konzolra, szóval nem tudom mennyire lehet ebben megbízni...

Tapasztalatok? Valaki használ éles környezetben HB/DRBD-t?