~12 TB szinkronizálása: drbd van, valami jobb megoldás?

Ubuntu Linux

Sziasztok,

a következő problémánk van. Adott két szerver gép, sok winyóval. Elsődleges, másodlagos felállásban. A gépeken lévő adatok szinkronitását drbd-vel tartjuk fent. De probléma, hálózati leszakadás, újraindítás esetén inkonzisztens a partíció és nulláról kezdi az adatok másolását. Nem is lenne baj, ha egy gigáról beszélnénk, de közel 12 TB átmásolásáról beszélünk. (sok csillió millió pici fájl) A szűk keresztmetszet nem is hálózat, inkább a wincsik olvasási sebessége úgy, hogy közben az elsődlegesen terhelés is van.

Olyan megoldást keresünk akár drbd-vel, akár máshogy, hogy ha az előbb említett "bajok" előjönnek, akkor mindig az utolsó állapottól folytassa a másolást és ne a nulláról. De ha van itt drbd szakértő akkor figyelek :)

Köszi!

  • 11343 megtekintés

( Elbandi v | 2013. 05. 14., k – 02:12 )

valami parameterrel lehet allitani hogy mekkora legyen a buffer amiben tarolja hogy mik valtoztak amig a masik fele off-on volt. azt vedd nagyobbra

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

Bocs h beleokiskodok, de ez nem igy van. A DRBD automatikusan a resource low level device-anak merete alapjan kalkulalja a metadata meretet, nincs beleszolasod. Meg a szamitasi keplet is benne van a manualban h leessen tervezni az "elveszett" disk spaceel.
En inkabb arra gyanakodnek ebben az esetben h valami bovli cluster megoldassal uzemeltetik a rendszert, ami node failure eseten kvazi invalidalja a kiesett slave-et, hiszen a drbd a meta adat reszt pont a megvaltozott blokkok nyilvantartasa hasznalja.
Ismerni kellene a konfigot es a kornyezetet, az h drbd az edeskeves. Most akkor pacemamer v RHCS v meg netan heartbeat. Nem egy heartbeatv2 clustert lattam mostanaban is, ami kifejezetten szar az elobb emlitett megoldasokkal hasonlitva.

Activity Log idezet: If a temporarily failed node that was in active mode at the time of failure is synchronized, only those hot extents highlighted in the AL need to be synchronized, rather than the full device. This drastically reduces synchronization time after an active node crash.

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

( deep | 2013. 05. 14., k – 06:39 )

ha más megoldások is szóba jöhetnek akkor 2 gép esetén Glusterfs.

drbd sux

Nehéz őket beállítani és üzemeltetni. A GPFS ebből a szempontból kivétel, vele a legfőbb bajom, hogy nem olcsó, így mi csak kivételes esetekben tudjuk használni és mint ilyen, kis szigeteket alkot a rendszereinkben, miközben tetemes tudás kell a profi üzemeltetéséhez, szóval nem valami gazdaságos. Persze egy nagyvállalati struktúrában ez nyilván nem probléma.

OCFS2-vel az utolsó élményem 2.6.32-nél az volt, hogy 30%-os telítettségnél betelt, nem lehetett új fájlt létrehozni, mert a töredezettség miatt nem tudott 4MB egybefüggő területet lefoglalni az inode clusernek és game over. Ráadásul ezt még monitorozni se lehetett, a semmiből csapott le [1]. Emiatt aztán ő sem került soha production-be felénk. A GFS2 akkoriban fényévekkel előrébb járt, valószínűleg ez még most is igaz, de komplexebb architektúra kell neki.

Mindenesetre a shared-disk architektúrát érdemesebb elkerülni ha a teljesítményt skálázni kell, mert az nem lesz egyszerű és/vagy olcsó. Mi mára szerencsére megszabadultunk tűlük.

Nagyon mas megoldasod nincsen. Ha egyszer akarod tarolni az adatot es mondjuk shared storage-en, akkor ezek vannak. Ezek kozul pedig a GFS2 a legmegfelelobb. Ha nem csak HA-ra tervezel, hanem distributed megoldast is akarsz, akkor pedig a gluster jo valasztas. Ha nincs mas, csak ket szerver shared storage nelkul akkor en probalnam az eroforrasaimat szetszedni. Pl 2 drbd, az egyik az egyik node-on master a masik a masikon. Pl az egyik node a web szerver, a masik az sql es egymasnak replikai. Ebben az esetben k fontos a jo fencing, meg a plusz quorum, hiszen nincsen 3. Node-od h ha egy kiesik akkor dontesre vigye a kerdest h ki halt meg. Erre talaltak ki a qdisk-et.

Azért az elég másra van kitalálva, meg vannak vele gondok (security, scalablity).
Egy NFS-nél a replikáció is elég macera, ha distributed megoldást szeretne. Ha distributed megoldás, akkor meg GPFS cnfs-én kívül túl sok ötletem nincs, az NFS egyszerre két szerverről nekem nem értelmezhető fogalom, persze lehet tákolni DRBD+VIP+NFS kombót, de az megint olyan... sz*r :)

Szerintem van létjogosultsága annak a felállásnak is, hogy: shared-disk + local fs (pl. ext4) + nfs és az egész egy aktív-passzív clusterbe. Persze a teljesítmény így másképp alakul mint cluster fájlrendszerrel, de lehet vele tervezni. Előnye, hogy pehelysúlyú és széles körben ismert eszközökre épít.

Bár az egymondatos "nem akarom ugyan azt az adatot 2x tárolni" rendszerspecifikáció alapján nem lehet messzemenő ajánlásokat tenni, csak sötétben lövöldözünk a fogalmakkal. :)

(BTW: a DRBD+VIP+NFS nálam teljesen sztenderd és jól működik.)

Azért shared storage esetén szerintem luxus nem "kiélvezni" a shared FS előnyeit, ha az alkalmazásban meg lehet valósítani annak normális használatát. Ez főleg akkor igaz ha CPU és nem IO intenzív a task amiről beszélünk (tipkus PHP futtatásra gondolok :))

Tényleg vaktában lövöldözünk, de egész jól összerakjuk az "Egy elképzelt HA rendszer felállítása" című thread-et :)

Ezt a security reszt kifejtened?
A skalazhatosagnal meg mit akar it varialni, 2 node-ja van. Ha meg tobb lesz, megnagyobbat fog szivni a gfs-sel.

Ja, ha mar ott tartunk, h ami nem gpfs, akkor minden szar. He, topiknyito, bele se kezdjel.

tompos

ui.: Ha nem kell posix kompatibilis fs, akkor megneznem a mongodb-t es a mogilefs-t.

ui.: Ezelbol a felinformaciot bedobos topikokbol vhogy mindig eltunnek a topiknyitok.

Krb nélkül az nfs az egy authentikációs rémálom, krb-vel meg konfigurációs rémálom. Lehet választani.
2 node-ja van, de nem mindegy h. mennyire szívás bővíteni hosszabb távon, bár lehet én vagyok túl előre gondolkodó típus.
Ami nem GPFS az nem szar, csak az ő cnfs implementációjuk az valóban jó, lehet ennek ellent mondani, de tök felesleges. Két szerverre meg még csak nem is olyan horror. Aztán ha valami nem jó, akkor lehet csesztetni a nagy kék supportját h. miért nem úgy megy ahogy, teljesen más, mint egy FOSS cuccokból építkező valami, de ezt gondolom te is belátod.

u.i.: a mongodb k. jó ötlet
u.i.2: ha túlnő rajtuk a feladat, akkor inkább minden marad a régiben, amíg megy megy alapon.

> Krb nélkül az nfs az egy authentikációs rémálom, krb-vel meg konfigurációs rémálom. Lehet választani.

Az esetek kicsiny szazalekaban van authentikaciora szukseg. Mashogy kifejezve meg legtobbszor VM-ek ala kell, vagy ilyesmi, akkor meg minek?
Vagy epp szarnak az authentikacio-ra, mert mas okbol nincs ra szukseg.

> 2 node-ja van, de nem mindegy h. mennyire szívás bővíteni hosszabb távon, bár lehet én vagyok túl előre gondolkodó típus.

Igen, te vagy. Tobbnyire koegyszeru rendszerekrol van szo, egyszeruen nem kifizetodo semmi nagyobban gondolkodni. Ha meg a megvasarolasra lenne is penz, fizetni kell hozza az uzemeltetest, a frissiteseket, a vendor lockint, az OS-t, meg meg kitudja mit.

A koegyszeru, 20 eve rendszerint mukodo strukturabol meg lenne egy gpfs-es complex rendszer, aminek mas a celkozonsege.

> lehet csesztetni a nagy kék supportját h. miért nem úgy megy ahogy, teljesen más, mint egy FOSS cuccokból építkező valami

Nem ismerem konkretan az IBM supportjat, de nagyon rossz tapasztalatom van minden helyzetben, amikor a a ket kapcsolatban levo fel merete (pl. dolgozok szama, arbevetel) ugy 50-100%-nal jobban elter. Azaz a nagyceg eroszeretettel szopatja a kisceget, mint a torkosborz. Ebben az esetben tobbnyire szerencsetlen gazda ugyanugy a FOSS kozosseghez fordul.

> ha túlnő rajtuk a feladat, akkor inkább minden marad a régiben, amíg megy megy alapon.

Arra celoztam, h az emberek feltuno modon meg egy kerdest sem tudnak feltenni, vmint tobbnyire elvi szinten bunkosagnak tartom, ha felteszi vki a kerdest, aztan otthagyja a levegoben logni.
Persze a gyakorlatban ezer oka lehet, ami felmenti ez alol.

Krb nélkül az nfs az egy authentikációs rémálom, krb-vel meg konfigurációs rémálom. Lehet választani.

Szerverekről beszélünk, minek ott authentikálni? Az esetek döntő többségében tökéletesen megfelelő az a megoldás, hogy az egymást NFS-en látó gépek egységes userid namespace-t használnak (ez implicite azt is jelenti, hogy aki az egyiken adminisztrátor, az a másikon is az), az meg tűzfalszabályokkal tökéletesen megoldható, hogy aki nem root az egyik gépen, az ne tudja az NFS szolgáltatást IP szinten elérni, azaz ne tudja megkerülni a policyt.

A mongodb jó is lenne, ha csak doksik lennének a tömbön. De van rajta minden: txt (csilliárd sok), avi, mp3, mpeg, kazettás magnó, walkman :O
RAID6 van, de thruput is kell. Az IO-ról már nem is beszélek.

A tipikus Murphy, olyankor kezd elhasalni több vas több különböző helyen amikor azt hiszed, hogy most akkor ezt rendbe rakhatod.

Felejtsd el, nagyo nehéz összehozni, és sok adatnál probléma esetén elfogadhatatlan ideig fsckzik, közben nem tudod, hogy lesz-e még valaha belőle valami. Mindez persze csak akkor fog kiderülni, amikor nagy gáz van, mert amikor minden ok, akkor amúgy nincs vele baj. Saját lemez formátuma van, amit katasztrófa esetén az életben nem recoveryzel.

A glusternek sok baja van, de annyi mindenképp előnye, hogy egy rendes feilerendszeren, rendes fileok vannak, és nagy a baj, akkor egy példány még mindig van egyből.

GPFS, AFS nem valami nagy mutatvány, nem értem miért dolgozzon vele akinek 7 anyja van :)
GPFS drága, de teljesen jó, a failure group-okkal pont ezt tudja, ráadásul Posix kompatibilis egészen az fcntl() részig.

Jelen esetben egy jó cluster sw-vel maradnék a drbd + extX megoldásnál, nagyon muszáj szituban mennék a Gluster felé.
Ceph még beta, de baromi jó lesz ha kiforrja magát, bár azt inkább virtuális rendszerek alá tudom elképzelni (pl. Proxmox)

( f0xhu v | 2013. 05. 14., k – 07:07 )

2 node esetén a drbd tud meglepetést okozni (split brain). Én tennék fölé egy rendesebb cluster megoldást (pl. Pacemaker), rendes quorum-mal, ami minden esetben segít eldönteni, ki a master és ki a slave.

--
A gyors gondolat többet ér, mint a gyors mozdulat.

( tompos v | 2013. 05. 14., k – 09:05 )

Vmit elkefelsz, incerementalisan kell szinkronizalnia.
Mibol gondolod, h nem ugy teszi?

tompos

+1. Teletömött Thumper (bruttó 48TB) volt a passzív oldal, és egy rakás másik masina tolta rá az adatokat drbd-n. Az aktív oldalon sw-es raid tükörre (md) lett drbd device húzva, a passzívon meg egy megfelelő méretű lv-re került a drbd eszköz. Pöcc-röff, egy újabb gép alá drbd-zett tárhelyet csinálni nem sokkal tartott tovább, mint ezt a hozzászólást megírni :)

( mrmartin v | 2013. 05. 14., k – 09:09 )

DRBD helyett CEPH esetleg, és mondjuk 3 vagy 5 node?

( saabi v | 2013. 05. 14., k – 10:10 )

Tudom, naív vagyok, de 12TB alá nem érné meg inkább egy shared storage-t alkalmazni? Vagy túl messze vannak a node-ok egymástól? Vagy alacsony a költségvetés?

Ave, Saabi.

A szexre, de most koncentráljunk a te problémádra!
Jelenleg, ha jól értettelek, akkor van két géped, mindegyiken local storage és ezek között drbd-vel tükrözöd az adatokat. Én ennyi adatnál inkább egy intelligens storage-t használnék (pl. HP 3Par), amely maga gondoskodik a redundáns tárolásról és amelyet a cluster tagjai egyszerre érnek el (iSCSI, Fiber Channel). Természetesen megoldható hogy tárolóból is kettőt használsz, amelyek közt lehet host oldalon és lehet storage oldalon gondoskodni az adatszinkronról.
A HP Serviceguard for Linux referencia konfigurációi közt található egy olyan, ahol a cluster tagjai legfeljebb 100Km távolságra találhatóak egymástól. Mindkét site-on van egy-egy 3Par tároló, melyek közt az adatszinkronról egy host oldali tükrözés gondoskodik. Minden gép csatlakozik minden tárolóhoz. A gépkiesésről a cluster software, a tároló kiesésről pedig a tükrözés gondoskodik. Márminthogy a fentiek ne okozzanak problémát.
Nem állítom, hogy a fenti megoldás a lehető legolcsóbb.

Ave, Saabi.

Vendor lock-in normális cluster software-t használni? LOL! Ezzel az erővel egy RHEL vagy SLES OS is vendor lock-in! :-(
Amit meg a storage-ekről írtam, nyilván nem csak HP tárolókkal igazak, csak én nem ismerek mást. Amúgy a 12 TByte adatból mertem feltételezni, hogy nem egy "Jézus-szíve Bt." kategóriájú cégről van szó. Bár tény, hogy a négy terás SATA diskek korában egy microserverben ( HP Proliant MicroServer :-P ) is lehet ekkora tárkapacitás. Redundánsan!
Hmm... akkor két tömött microserver iSCSI-n, host oldalon tükrözve, na? A cluster software meg tetszőleges.

Ave, Saabi.

Nagyon sok filenál azért tud lassú lenni az rsync, mert a filerendszer sok adatot olvas (rossz esetben random összevissza helyekről) a file adatok miatt. De ezt a cp nek is meg kell csinálnia, tehát szerintem a cp semmilyen esetben nem lehet jobb az rsyncnél. Ha meg az inplace stb. az rsync kihagy egy csomó filet, és a nagy fileokat is csak részben másolja át, akkor hogy lenne gyorsabb a cp?

( uid_18079 | 2013. 05. 15., sze – 13:16 )

Troll: 6 merevlemez és egy gördeszka?

( banyek | 2013. 11. 08., p – 12:28 )

Initial sync eseten nezd meg az A es B protcolt

( Fisher v | 2013. 11. 08., p – 12:42 )

Log nélkül csak találgatni lehet, régi drbd verziókban volt ilyesmi race condition.

( freeoli v | 2013. 11. 08., p – 12:59 )

Hány fájl található a rendszerben?