zfs over drbd

Linux-haladó

HI!

Azt a kedves feladatott kaptam, hogy csináljak egy erősen hibatűrő levelező szervert. A levelek tárolására a címbeli őrület jutott eszembe. A kérdésem az lenne, hogy van-e valakinek tapasztalata a fenti/hasonló felállásban? Vagy egyáltalán kivitelezhető-e?
Hogy mik az eddigi érveim a ?
A drbd mellett:
- kell valami hálózati tükör.
- benne van a mainline kernelben.
A zfs mellett:
- deduplikáció
- flyon tömörítés

Még egyszer ez csak terv. De azért érdekelne mások véleménye.

Köszi.

  • 3055 megtekintés

( zwei | 2011. 05. 13., p – 09:21 )

"Azt a kedves feladatott kaptam, hogy csináljak egy erősen hibatűrő levelező szervert."

Akkor felejtsd el azt amit a címben említesz.
A zfs linuxon minden, csak nem hibatűrő.

Nem említetted, hogy napi hány millió levelet fogadna , illetve hány száz kilométerre lesz egymástól a két(?) gép (a drbd-ből arra tippelek, legalább kettőt szeretnél.)

"Nem a levél mennyiség a fontos .... De a tömörítés és a duplikáció mentesség nagyon vonzó ígéret."

Sajnos mail szerveren a dedup semmit nem számít.
Az 1000 példányban CC-zett levelek esetén 1000 darab dedup szempontjából különböző (blokk szinten eltérő) levelet fogsz kapni. (Ezt egyébként saját magam is tapasztaltam.)
Csatolmányok esetén sem mérvadó, hacsak nem egy olyan cégről van szó, ahol napjában többször több "vicces" videót is küldözgetnek a munkatársak céges körlevélként.

Duplikált csatolmányok esetén sokkal hasznosabb lenne, ha a egy csatolmány csak egyszer lenne lementve, aztán minden címzettnek csak egy hivatkozást tárolna a mail szerver. (pl. MS Exchange tud ilyet...:) )

Tömörítés már hasznosabb, viszont ha csak pár 100GB-d van, akkor relatíve felesleges, hacsak nem drága FC diszkekkel dolgozol. (Amit kétlek, mert akkor valszeg. nem akarnál drbd-t)
Kb. az egyetlen reális előnyét abban látom, hogy tömörített fájlrendszer esetén a drbd kevesebb adatot küldözgetne hálózaton.

"ahol napjában többször több "vicces" videót"
Na itt pont ez a helyzet. Előszeretettel küldenek széjjel egy videót többször is. De az sem ritka, hogy egy szép xls,pps-t küldenek szét vagy 50 címzettnek. Pont ezért érdekelt a dedup. De ha már itt tartunk akkor hol van értelme?
Mondjuk most azon gondolkozom, tényleg nyomok valami kódot a levelekre hogy számoljon hash-t és meglátom hogy mennyi az ismétlődő levél.

Mondjuk tényleg az elején én is abban gondolkoztam, hogy postfixre kellene valami ilyen cucc de nagyon találtam rá semmit.

"De ha már itt tartunk akkor hol van értelme? "

Szerverek mentése esetén az oprendszerhez tartozó adatoknál.
Pl. linux szerverek mentése esetén a (főleg, ha azonos disztró) 15-30% közötti deduplikációs nyereség van.
Vagy virtualizálás esetén a virtuális szervereket is érdemes dedup-os tárolóra rakni.

( Tyra3l | 2011. 05. 13., p – 09:44 )

dual primary drbd-t nem tudom hogy tudsz-e csinalni zfs-sel (a doksiban nem talaltam ra utalas, csak gfs meg ocfs2):
http://www.drbd.org/users-guide/s-dual-primary-mode.html

ha viszont primary-secondary felallast csinalsz, akkor egyreszt megkapod a drbd sajat nyugjeit (ha erosen konzisztens, akkor lassu az iras mert var a halozatra, ha nem, akkor elveszhet adat failover eseten, ha a mailszerver ugy borul fel, hogy korrumpalja a fajlrendszert, vagy a mailboxokat, az is szepen atreplikalodik etc.).

a zfs amugy jo otlet lenne, tarkapacitasban sokat tudnal sporolni a deduplikacioval, de nem feltetlenul linuxban kellene gondolkozni.

Tyrael

"tarkapacitasban sokat tudnal sporolni a deduplikaciova"
Mail szerver esetén a dedup kevesebb mint 1%-ot hoz. (Mentek mail szervereket deduplikált storage-ra, kb. ez a tapasztalat.)

Tömörített file rendszer már jóval többet spórol.( Leggyengébb tömörítéssel is 30-60%-ot, a levelek tipusától függően.)

"dual primary drbd-t nem tudom hogy tudsz-e csinalni zfs-sel"
Ehhez cluster fs-kell mint pl OCFS2, GFS(2)

"ha viszont primary-secondary felallast csinalsz, akkor egyreszt megkapod a drbd sajat nyugjeit (ha erosen konzisztens, akkor lassu az iras mert var a halozatra, ha nem, akkor elveszhet adat failover eseten, ha a mailszerver ugy borul fel, hogy korrumpalja a fajlrendszert, vagy a mailboxokat, az is szepen atreplikalodik etc.)"
Mindez igaz dual primary esetben is. ;)

Velemenyem szerint mail-ekhez nem szerencses cluster filerendszert hasznalni (nagyon erteni kell az adott clusterfs mukodesehez). Maildir: Nem optimizalt esetben, sok kis file miatt hasznalhatatlan lesz egy ido utan. Mailbox: file lock miatt fogsz szivni.

Azon gondolkodj el, hogy tenyleg kell-e neked "real time" replikacio. Ha nem, egy rsynces megoldas estenkent/orankent hibaturobb lesz mint egy drbd 20 km-eres tavolsagra (drbd-vel interneten keresztul lenne egy par split brain szituaciod, amivel nem szivesen jatszanek egy production-ben levo mail szerveren, ezen felul kurva lassu lenne a sync!)...

Tovabba azon is gondolkodj el, hogy tenyleg kell-e neked az a 20KM-es tavolsag. En speciel jobban preferalom azt a megoldast, hogy legyen egy clustered (drbd+peacemaker/RHCS) az egyik helyen, ami elviszi a levelezest, es legyen egy offsite backupod ami disaster recovery-hez kell...
Ha kell, akkor meg hasznald az smtp-be beleepitett HA-t :) Csinalj ket levelezo szervert a ket telephelyre az egyiket add meg 10-es metrikkel a DNS-be a masikat meg 20-assal. Igy ha Bin Laden fia pont az elso telephelyre celoz, akkor is fog menni a levelezesetek, csak a klienseket kell majd atkonfigolni (remeljuk ok majd a kettes szamu telephelyen ulnek a robbanas idopontjaban) ;)

"Ehhez cluster fs-kell mint pl OCFS2, GFS(2)"
irtam is konkretan hogy a manual csak ezt emliti, de nem ismerem elegge a zfs-t, ugyhogy nem akartam kategorikusan kizarni a lehetoseget.

"Mindez igaz dual primary esetben is. ;)"
nyilvan. viszont most hogy irod, rajottem hogy lemaradt a mondatom masodik fele, szoval primary-sec felallasban megkapod ugyanugy a DRBD nyugjeit, viszont nem fogsz tudni hot spare felallast csinalni, mivel nem engedi a drbd felmountolni a secondary eszkozt meg read-only-ban sem, ergo nem tudod pl. a mailszerver ala odarakni addig a data dirt, meg kell irni hozza a cluster menedzsment reszt, fencinggel, stb.

szoval megkapod a drbd alap hatranyait, de nem lesz teljesitve tole a "kell valami hálózati tükör.", legalabbis nem ugy, ahogy szerintem a kerdezo elkepzelte.

"dual" primary-t szerintem legalabb 3 node-dal van ertelme csinalni, igy mar a quorum miatt elegge jol kizarhato a halozati para miatt splitbrain okozta adatvesztest.

Tyrael

"szoval primary-sec felallasban megkapod ugyanugy a DRBD nyugjeit, viszont nem fogsz tudni hot spare felallast csinalni, mivel nem engedi a drbd felmountolni a secondary eszkozt meg read-only-ban sem, ergo nem tudod pl. a mailszerver ala odarakni addig a data dirt, meg kell irni hozza a cluster menedzsment reszt, fencinggel, stb."

Nem ertem miert mondod... Eppen ez a lanyege a DRBD-nek pri-sec felallasban, hogyha elszall a primary gep, akkor a secondary-bol csinalsz primary-t (cluster sw-vel vagy manualisan az mar rajtad all) es minden mehet tovabb a "masik" szerveren...

igazabol picit elfogult vagyok, ebben az esetben en is valami tobb MX record + mail relay jellegu felallast favorizalnek a celra, ez ezert hangsulyoztam ki, hogy a drbd-vel meg a jarulekos cluster menedzsment cuccok megfelelo beconfiguralasaval ki lehet allakitani egy olyan clustert, amiben ha megborul a rendszer, akkor nemi ido es esetlegesen adatveszes mellett folytathato a tevekenyseg.
amit az esetek eleg jelentos reszeben ugyanakkora SLA-t tud biztositani, mint 2 fuggetlen vas rsync-kel, vagy 1 gep + rendszeres gyakori offsite backup, es visszarakjuk backupbol a cuccot ha gaz van felallas.

Tyrael

Tegyük hozzá, hogy azok nem a DRBD nyűgjei, hanem a replikációs technológia nyűgjei. A DRBD egyébként kihozza a technológiából amit érdemes, szerintem.

A kihalásos node váltás egy rendkívüli esemény, szerintem egy mail szervernél elfogadható, hogy az utolsó pár másodperc már átvett levelei esetleg elvesznek ha lemarad a nagyteljesítményű asszinkron DRBD és hardveresen kihal a primary node. De simán lehet, hogy nincs akkor mail forgalom, hogy ne bírja a szinkron replikációt.

ECC-s memóriával/brand szerverrel többnyire elkerülhető, hogy az egyik node úgy hibásodjon meg, hogy baromságokat írjon a block device-ra. Ezt a lehetőséget elég a katasztófatervbe betenni, hiszen ez azonnal kukázna minden SAN alapú failovert, amire az enterspájzok oly büszkék.

A dual primaryt el kell felejteni, nem kell kísérteni a sorsot ha nem muszáj, sima ext4 fájlrendszert kell használni a DRBD fölött.
A split-brain ilyen távolságnál valós veszély, de ha a pacemaker quorum mellett van redundáns, több csatornás netkapcsolat a két storage között, akkor ez is elég robusztus lesz. A backup mehet a primary node snapshotjáról, rsync-el.

Hálózatilag nem tudom hogy viszonyul egymáshoz a két 20km-re lévő node, de az aktív node hálózati elérhetőségét is biztosítani kell, ami azért nem triviális. Ha egymás mellett lenne a két node egy redundáns netkapcsolattal rendelkező telephelyen és lenne egy offsite backup, biztos kevesebb gondod lenne..

A tömörítéshez sajnos nem tudok hozzászólni, a mai winyóárak mellett ez fel se merült még nálam egy mail szerveren.

Tegyük hozzá, hogy azok nem a DRBD nyűgjei, hanem a replikációs technológia nyűgjei. A DRBD egyébként kihozza a technológiából amit érdemes, szerintem.

igaz, de van azert nehany sajat nyugje a DRBD-nek is (2 nodeos felallasnal split brain, drbd hang).

A kihalásos node váltás egy rendkívüli esemény, szerintem egy mail szervernél elfogadható, hogy az utolsó pár másodperc már átvett levelei esetleg elvesznek ha lemarad a nagyteljesítményű asszinkron DRBD és hardveresen kihal a primary node. De simán lehet, hogy nincs akkor mail forgalom, hogy ne bírja a szinkron replikációt.

es nyilvan fugg a megrendeloi igenyektol is, hogy az integritas vagy a teljesitmeny a fontosabb szempont.

ECC-s memóriával/brand szerverrel többnyire elkerülhető, hogy az egyik node úgy hibásodjon meg, hogy baromságokat írjon a block device-ra. Ezt a lehetőséget elég a katasztófatervbe betenni, hiszen ez azonnal kukázna minden SAN alapú failovert, amire az enterspájzok oly büszkék.

igen, de itt is lassuk be azert, hogy ha device, hanem alkalmazas szinten lenne kezelve a replikacio, akkor jo esetben jobban lokalizalhato az adatvesztes (csak nehany level, vagy mailbox serul), mig ha a block device-on kuszalodik ossze valami, akkor konyen ugorhat az egesz rajta levo fs is.

a tobbivel egyetertek.

Tyrael

ugy kerulod el, hogy tobb mint 2 nodot hasznalsz (vagy a 2 nodeon kivul egy harmadik kulso eroforrast, ahogy mar irtatok)

"dual" primary-t szerintem legalabb 3 node-dal van ertelme csinalni, igy mar a quorum miatt elegge jol kizarhato a halozati para miatt splitbrain okozta adatvesztest.

Tyrael

A split-brain elkerülése igazából a cluster feladata, nem a DRBD-é. Benne csak egy logikus "sanity check" van, ami nem engedi, hogy nyilvánvaló baromságot csináljon a cluster. A DRBD vezérlése (pl pacemaker) pedig már lehet quorum alapú is.

Az alkalmazás szintű replikáció valóban robusztusabb lenne, de kapásból nem tudnék mondani olyan mail szervert, ami tud ilyesmit és eléggé kitesztelt.

( Mico v | 2011. 05. 13., p – 09:45 )

Ezt így ebben a formában gyorsan felejtsd el.

( gabori | 2011. 05. 13., p – 09:55 )

Ok.

Tehát eddig a zfs nagyon rossz helyzetben van. És mi a helyzet a btrfs-el. Tudom az egyik jobb ötletet szülöm a másik után. De inkább mint 1 hetet szívjak vele azt kezdhetem elölről az egészet.
Viszont a drbd-re eddig nem jött semmi komoly panasz. Ez azért lehet, hogy mert az jó vagy azért mert a zfs a főellenség?
Érdekelne még egyéb ötlet is. De a tömörítés nagyon jól jönne mert a wincseszter kapacitás a legszűkebb kereszt metszet. Mivel a gépek adottak.

Egyébként ha megtennétek hogy a véleményetek mellé oda írjátok, hogy tapasztalati úton szereztétek azt megköszönném.

"Ez azért lehet, hogy mert az jó vagy azért mert a zfs a főellenség? "

Drbd még talán...
ZFS linuxon minden, csak nem stabil. Ha simán meg is csinálod, sanszos, hogy pont akkor sz*rik be, mikor a leginkább fáj.

"a wincseszter kapacitás a legszűkebb kereszt metszet. Mivel a gépek adottak."

Ha hibatűrő rendszer kell, akkor alapdolog, hogy hibatűrő vasak kellenek megfelelő kapacitással.
Ha adott gépekből akarsz experimentál szoftverekkel hibatűrő rendszert.... hát sok sikert.

Ha valakinek nincs pénze 4 db 750G-s diszkre, akkor az ne akarjon hibatűrő rendszert.
Ha ennél több levelet kellene kezelni akkor az feltételez egy akkora céget, aki meg simán kiköhögi ennek a többszörösét is.

Ok.

Ebben igazad van. Túlzottan nem akarok ebbe bele menni. De az államigazgatásban a termelő feladatokra nincs pénz. És inkább 10db kellene belőle és itt van bizonyos kötöttség tehát ez a rész milla felett lenne. És ez nem fél bele a "keretbe".

De mindenkit kérek, hogy ezt az irányt zárjuk le.

Értem.
Ez esetben javaslom a FreeBSD vagy OpenSolaris használatát tömörített ZFS-el.
OpenSolaris esetén van dedup-od is, de ez sztem. nem fog sokat hozni.

Drbd helyett napi 2-3 rsync szerintem elég.
Ha megbízható, "real time" tükrözés kell, az sajnos vasfejlesztésbe és pénzbe kerül.

Apropó, milyen sávszélességű és késleltetésű dedikált vonalad van a két gépterem között?

per pillanat van opensolaris production rendszerem. (még akkor lett beállítva, amikor az OpenSol. komolyabbnak számított.)
Aktuális verziójú postfix és társai futnak rajta, illetve egy másik rendszer mentéseit tároljuk rajta. Semmi gond nincs vele, egyenlőre nem indokolt a cseréje. Igaz, csak 1-200 mailbox van rajta, de akkor is prod. Egy adatbázist bankkártya adatokkal én sem raknék rá, de egy kisebb mail szervernek ugyanolyan jó mint bármelyik linux.

Attól, hogy nem "bleeding edge" még nem biztos, hogy szar. Üzemeltetek 8-as Solarist is (trusted). Az sem mai darab, de ma is kb. ugyanaz az elvárás vele szemben, mint amikor jó pár (6-8?) évvel ezelőtt telepítve lett.

logikus érveid nyilván a több évtizedes üzemeltetési gyakorlatodból jönnek... :)

És mi a helyzet a btrfs-el.

Az zfs _csak_ linuxon nevezhető kiforratlannak, a btrfs _mindenhol_ az (bár nem is tudom, létezik-e egyáltalán másra).

Egyesek (itt a fórumlakók közül is) megelégedéssel használják a zfs-t bsd-n, solarison pedig (ha valami elborult ötlettől vezérelve feltétlenül erre vágysz) egyértelmű stabil. Sajnos a solaris politikai okokból kifolyólag a "nem javasolt" kategória.

Én személy szerint tapasztalatokkal nem rendelkező júzernek inkább azt mondanám, hogy maradjon stabil és egyszerű dolgoknál: linux + ext4

Viszont a drbd-re eddig nem jött semmi komoly panasz.

A drbd abban a konfigurációban, amiben megbízható tud lenni, abban kibaszott lassú írásnál, és minél messzebb van egymástól a két site, annál lassabb (tehát 50cm 10gbps madzaggal nem annyira gáz, mint mondjuk egy 20km-es 10mbps linken). A mail szerver tipikusan az a valami, ami sokat (és kicsiket) ír, ergó neki fáj a legjobban a drbd. Egy fájl szervernek, vagy egy keveset változó web szerver alatti területnek akár még jó is lehet.

( zamboriz v | 2011. 05. 13., p – 09:55 )

> hogy csináljak egy erősen hibatűrő levelező szervert.

Kezd azzal, hogy összeírod a céljaidat/követelményeidet. Pld nem mindegy, hogy legfeljebb mekkora időtartama lehet egy HW leállásból adódó teljes kiesésnek. 1 perc, 1 óra, 1 nap, 1 hét, ...? Legfeljebb mekkora időtartama lehet a teljes kiesést követő részleges/csökkent szolgáltatásnak? Stb.

( NagyZ v | 2011. 05. 13., p – 11:36 )

levelek valami HA DBben tarolva FS helyett?

miert, jobb mint a zfs/brtfs + drbd :)

A drbd-nél csak jobb megoldásokat tudok elképzelni :)

kozponti DB siman jo megoldas. akar agyon is lohetik az egyik nodeot...

HA szolgáltatás valami rendes, klasszikus FS felett, és már ki is egyeztünk. :)

Nekem régi vesszőparipám, hogy a relációs adatbázis nem való levelek tárolására (még nem találkoztam rendes blob támogatással bíró relációs adatbáziskezelővel)...

Persze nem látom bizonyítottnak, hogy ne lehetne olyan adatbáziskezelőt írni, aminek nem jelent kihívást a 100 byte - 10 Mbyte tartományon belül bármekkora random objektumok hatékony kezelése, csak valahogy nem látom a versenyzőket.

- Bar nem indokoltad meg, kilotted a drbd-t.

- A klasszikus fs felett hogy kepzelted el? Csak ugy lesznek, vagy mi csinalja a replikaciot? Mindesetre a clusterezett fs-eket kilotted.

- A relacios adatbazisokat kilotted.

- NOSQL-es elerheto (es lehetoleg free) megoldast en nem ismerek, de javaslatot te sem irtal.

A celhw-t (storage) az topic inditoja kilotte azzal, hogy eleve o vetette fel a drbd-t.

Tuljdonkeppen mit javasolsz?

tompos

- Bar nem indokoltad meg, kilotted a drbd-t.

- A klasszikus fs felett hogy kepzelted el? Csak ugy lesznek, vagy mi csinalja a replikaciot? Mindesetre a clusterezett fs-eket kilotted.

Nem replikálunk, azzal nem leszünk előrébb (és ez az indoka a drbd kilövésének). Az aszinkron replikálás ugyanis magában nem elég, az nem ad redundanciát, csak a backupot helyettesíti. A szinkron replikálás meg akkor jó, ha alig van írás, és annak sem számít a teljesítménye. A levelezés, na az nem ilyen. Szerintem.

Tuljdonkeppen mit javasolsz?

Shared diszk + HA. Tudom, túl konvencionális vagyok, hogy a mindenféle tákolmányokat nem tudom értékelni, a bevált (10+ éves) technológiákban hiszek. Én kérek elnézést.

A shared diszk + igazi clusterfs jó dolog, de itt nem látom a hasznát (és nem ingyen van, akár pénzben fizetsz érte, akár mással).

- NOSQL-es elerheto (es lehetoleg free) megoldast en nem ismerek, de javaslatot te sem irtal.

Talán mert én sem ismerem őket. Figyelembe véve, hogy a >10 éve fejlesztgetett mysql milyen BLOB teljesítményt tud, meg a >20 éve fejlesztgetett Oracle milyen BLOB teljesítményt tud, nem várnám, hogy random emberkék friss tákolmányai eget rengetnének, de hátha, majd mások megírják a frankót.

- A relacios adatbazisokat kilotted.

"Persze nem látom bizonyítottnak, hogy ne lehetne olyan adatbáziskezelőt írni, aminek nem jelent kihívást a 100 byte - 10 Mbyte tartományon belül bármekkora random objektumok hatékony kezelése, csak valahogy nem látom a versenyzőket."

Várom a versenyzőket... :)

A topic inditoja sejtetni engedi a peremfelteteleket. A shared diszket o csinalja meg drbd-vel. A drbd jo, ha sok iras van, akkor valoban nem annyira, de sehol nem szerepel, hogy mennyi iras lesz. BTW, a drbd a _nagyon_ sok irasnal nem jo, egyebkent vigan mukodik egy klasszikus es atlagos mailszerver vagy ahhoz hasonlo kornyezetben.
Van mas tapasztalatod? Nekem eddig csak pozitiv.

A shared diszk alatt gondolom storage-ra gondolsz. Azzal hogy biztositod az adatok redundanciajat? A drbd biztositja.

A clusterfs-eknel shared diszk eseten mit ertesz az alatt, hogy nincs ingyen? Mivel kell meg fizetni? Az esetleges teljesitmenyvesztest most szerintem hanyagoljuk, mivel attol meg mukodik, azzal nyilvan tervez az emberunk.

Ha helyzet bizony az, hogy nagyon franko eszkozoket 'takoltak'. Kivancsi lennek, honnan vannak az informacioid, hogy takoltak ezeket, ill. szerinted az oracle-t es a tarsait nem emberek irtak? Nem ertem az ervelesed es legfokeppen arra engedsz kovetkeztetni, hogy informacio es tapasztalat nelkul irsz velemenyt.

Relacios adatbazisokrol pedig annyit, hogy tudtommal pl. a googlemail dbmail-re epul, de ezt csak hallottam, fogalmam nincs, hogy mennyire igaz. Mindenesetre aki nekem mondta, HUP tag.

tompos

A drbd jo, ha sok iras van, akkor valoban nem annyira, de sehol nem szerepel, hogy mennyi iras lesz.

Az nincs sehol, ellenben az van, hogy "levelező szerver", arról meg tudjuk, hogy kb. 50%-ban írás.

BTW, a drbd a _nagyon_ sok irasnal nem jo, egyebkent vigan mukodik egy klasszikus es atlagos mailszerver vagy ahhoz hasonlo kornyezetben.
Van mas tapasztalatod? Nekem eddig csak pozitiv.

Nyilván nem találkoztál még olyan mail szerverrel, ami alatt a diszkek nem bírják a terhelést.

A shared diszk alatt gondolom storage-ra gondolsz. Azzal hogy biztositod az adatok redundanciajat? A drbd biztositja.

Tükrözés. Plain old, mezei, klasszikus tükrözés.
Fogsz két diszket, és mindkettőre kiírod ugyanazt.

A drbd csak szinkron esetben nevezhető redundánsnak, azt ki lehet próbálni. Csak nem értem, hogy minek, ha nélküle is meg lehet csinálni, és még gyorsabb is lesz, plusz egy potenciális adatvesztési lehetőséggel kevesebb.

A clusterfs-eknel shared diszk eseten mit ertesz az alatt, hogy nincs ingyen? Mivel kell meg fizetni? Az esetleges teljesitmenyvesztest most szerintem hanyagoljuk, mivel attol meg mukodik, azzal nyilvan tervez az emberunk.

Stabilitás, komplexitás, ár, ill. ezek kombinációja. Ami ingyen van, ott kérdéses a stabilitás. Pluszban jön a komplexitás növekedése okozta potenciális szopások tárháza, és ez még jobb fajta fizetősöknél is jelen van (láttam én már a crash után nem mountolható VxFS felett anyázó ISP-t).

Fájlon belüli konkurens lockolást pl. nem mindegyik tud, amelyik igen, ott is komoly performanciagondok lehetnek, ha az alkalmazás nem ismeri a konkrét fs típus egyedi lock daemonját, és nem használja annak api-ját (pl. oracle rac + ocfs2).

Ha helyzet bizony az, hogy nagyon franko eszkozoket 'takoltak'. Kivancsi lennek, honnan vannak az informacioid, hogy takoltak ezeket, ill. szerinted az oracle-t es a tarsait nem emberek irtak?

Az oracle alkalmatlan nagy mennyiségű és változatos méretű BLOB-ok kezelésére ("csak" a peformanciával van baj, de azzal nagyon). Ez egyes szám első személyű tapasztalat. Sokat szenvedtünk vele, aztán az maradt, hogy fájlrendszerbe kidobtuk, amit lehetett. Fényévekkel gyorsult ennek hatására pl. egy backup.

A "tákolás" egy általános megfogalmazás a nem-enterprise szintű megoldásokra. Onnan lehet őket felismerni, hogy pl. nem találsz olyan céget, aki használható commercial supportot adna hozzá. Mint pl. a HA cluster, ami nem él túl egy áramszünetet...

Relacios adatbazisokrol pedig annyit, hogy tudtommal pl. a googlemail dbmail-re epul, de ezt csak hallottam, fogalmam nincs, hogy mennyire igaz. Mindenesetre aki nekem mondta, HUP tag.

Az alapján, ami a dbmail weboldalán van, eszembe nem jutna rájuk bízni a levelezésem - nem mintha egyébként szimpatikus lenne a gmail, de ez nyilván teljesen szubjektív.

> Az nincs sehol, ellenben az van, hogy "levelező szerver", arról meg tudjuk, hogy kb. 50%-ban írás.

Lehet ti tudjatok, de mondjatok el ezt a levelezoszervereknek is. Ettol fuggetlenul lehet 90% is, ha az abszolut ertelemben keves.

> Nyilván nem találkoztál még olyan mail szerverrel, ami alatt a diszkek nem bírják a terhelést.

Nyilvan, megfeleloen mereteteztem az ala a stuffot. Ez magaslabda: ezek szerint ezt a lepest te kihagyod:)

> Fogsz két diszket, és mindkettőre kiírod ugyanazt.

Ezt csinalja a drbd. Te milyen eszkozzel csinalod? Olyat irj, amelyiknel nincs SPOF, vagy minimalis van.

> A drbd csak szinkron esetben nevezhető redundánsnak, azt ki lehet próbálni.

Megotortent, mukodik sok eve, a vilagon sokezer rendszeren, eles kornyezetben.

> Csak nem értem, hogy minek, ha nélküle is meg lehet csinálni, és még gyorsabb is lesz, plusz egy potenciális adatvesztési lehetőséggel kevesebb.

Nem lehet megcsinalni (ill. meg lehet, de kizarolaf storage igenybevetelevel), hacsak nem potolod ki a koltsegvetest a sajat zsebedbol. Szegeny ember inkabb okosan cselekszik.

> Ami ingyen van, ott kérdéses a stabilitás

LOL. Ez lehetne az alairasod:)

> A "tákolás" egy általános megfogalmazás a nem-enterprise szintű megoldásokra. Onnan lehet őket felismerni, hogy pl. nem találsz olyan céget, aki használható commercial supportot adna hozzá. Mint pl. a HA cluster, ami nem él túl egy áramszünetet...

Az altalam ismert eszkozok mindegyikere vasarolhato commercial support. Igy elmondhato, hogy nem takolmanyokrol beszeltem.

> Lenyegtelen, hogy mi a szubjektiv velemenyed, ha valoban adatbazisban tarolodjak a leveleket, akkor a gmail megfelelo bizonyitek arra, hogy mukodik. Ez fuggetlen barmelyikunk velemenyetol, hiaba nem valasztana egyikunk sem ezt az utat.

tompos

Lehet ti tudjatok, de mondjatok el ezt a levelezoszervereknek is. Ettol fuggetlenul lehet 90% is, ha az abszolut ertelemben keves.

Persze, 2 levél / óra intenzitásnál a töltőtoll + biorobot is megoldás, valóban. :)

Nyilvan, megfeleloen mereteteztem az ala a stuffot. Ez magaslabda: ezek szerint ezt a lepest te kihagyod:)

Nos, meg volt az tervezve. Csak közben elteltek az évek... a kedves ügyfél pedig úgy gondolta, hogy "ej, ráérünk arra a fejlesztésre még". Hát, egyszercsak a körmére égett a rendszer :)

Ezt csinalja a drbd. Te milyen eszkozzel csinalod? Olyat irj, amelyiknel nincs SPOF, vagy minimalis van.

Nem tudom, csak nekem egyértelmű ennyire? Az oprendszer tud tükrözni, adsz neki két diszket, és csókolom.

Egy pár HBA, egy pár külső SCSI/SAS/FC diszk, vagy ha nagyra lövünk vagy, akkor külső intelligens tárolóeszköz, ami belül mindenhol redundáns és tükrözik magától is (na az akár drága is lehet).
Ha pedig olcsójánost akarunk játszani, egy pár ethernet kártya, egy pár, hálózaton keresztül elérhető, független iSCSI volume (két buta PC, benne iSCSI target SW).

Nem lehet megcsinalni (ill. meg lehet, de kizarolaf storage igenybevetelevel), hacsak nem potolod ki a koltsegvetest a sajat zsebedbol. Szegeny ember inkabb okosan cselekszik.

Ja, értem, a "storage", az már hatalmas kiadási tétel...

Vonjuk le a konzekvenciát: szerinted a drbd arra a problémára ad megoldást, hogy ha annyira mérhetetlenül alacsony az I/O igény, hogy egy mezei buta SATA diszk random write teljesítményének a tört része is elegendő, akkor hogyan építsünk két buta PC-ből és egy-egy buta SATA diszkből valamit, ami nagyon olcsó, és mégis tud "valami" redundanciát.
Egyetértünk, kb. erre elegendő.
Akinek ez elég, használja egészséggel.

Ami ingyen van, ott kérdéses a stabilitás

LOL. Ez lehetne az alairasod:)

Hát akkor meséljél nekem a stabil, kiforrott, évek óta futó cluster fs megoldásokról...

Lenyegtelen, hogy mi a szubjektiv velemenyed, ha valoban adatbazisban tarolodjak a leveleket, akkor a gmail megfelelo bizonyitek arra, hogy mukodik. Ez fuggetlen barmelyikunk velemenyetol, hiaba nem valasztana egyikunk sem ezt az utat.

Nekem a gmail nem bizonyíték arra, hogy ez a koncepció működik.
Nem tudni róla semmit, ez így minden, csak nem bizonyíték. És még a gmail stabil, és adatvesztés-mentességéről sem érzem magam meggyőzve... persze a szolgáltatásért elkért díjhoz képest tényleg stabil, és adatvesztés-mentes.

"pl. a googlemail dbmail-re epul, de ezt csak hallottam, fogalmam nincs, hogy mennyire igaz. "
ok relacios db helyett BigTable-t hasznalnak mindenhol, es a google-nel amugy is nagyon eros a http://en.wikipedia.org/wiki/Not_Invented_Here mentalitas, ebbol kifolyolag nehezen tudnam elkepzelni, hogy a dbmail-t tuningoltak volna fel a gmail-hez.

Tyrael

Az adatbázisok pontosan ugyanazokkal a kihívásokkal néznek szembe mint a DRBD, mivel ők is replikálnak. Ott is lehet szinkron, félszinkron(pl. mysql >=5.5), aszinkron(pl. mysql <5.5), de mindegyiknek ára van, amit a távolság tovább ront.

Jól hangzik, hogy legyen adatbázis/cloud alatta, de ezzel a probléma ugyanaz: hogy lesz az adatbázis nagyteljesítményű, megbízható és hibatűrő? (Most kell valakinek bedobni, hogy: MSSQL - kommentár nélkül :D)

Szerintem nem véletlen, hogy nem igazán van dömping az adatbázis backendel rendelkező mail rendszerekben, nem egyértelmű az előny.

( handler | 2011. 05. 13., p – 11:57 )

Mennyi usert kell kiszolgalni? Azert nem mindegy, hogy 10, 10k, 10M userrol van szo....

( Fisher v | 2011. 05. 13., p – 12:20 )

Érdemes lenne a háromutas drb-n elgondolkozni: http://www.drbd.org/users-guide/s-three-way-repl.html

Lehet egymás mellett két gép szinkron mirrorral, ez viszonylag nem lassú írásra, és egy harmadik, ami messze van, de az már aszinkron módban.

Viszont a drbd nem csodaszer, csak diskhalál ellen véd. Ha maga a levelezőszerver pukkan el, akkor megvannak ugyan az adatok, de minek? Ilyenkor már érdemesebb egy helyi HA clustert összerakni, mondjuk OpenVZ-vel (vagy ami a kedvenced) és a két helyi gép között pattogtatni a futó rendszert ha baj van. És egy távoli masinára is tükrözni, ha esetleg bombát dobnak a szerverteremre.

( zeller | 2011. 05. 13., p – 12:38 )

Ahogy már kérdezték többen: mekkora (darabszám, átlagos méret) napi forgalom, mekkora rendelkezésre állás, meddig kell a szerveren tárolni az adatokat, és megközelítőleg mekkora keret van rá?

( tompos v | 2011. 05. 13., p – 17:22 )

En nem biztos, hogy helyesen ertem, amit irtal.

A cimben zfs over drbd, de utana meg a zfs es a drbd mellett hozol fel erveket. vagy csak magadat gyozkodod?:)

A drbd jo valasztas, a zfs viszont nem.

Ha active/passive modon alkalmazod a drbd-t, akkor nincs clusterezett fs-re szukseged es azt valasztas, ami tetszik. A deduplikacioval es a tomoritessel en itt nem szorakoznek, nem er annyit, mint amennyit veszthetsz vele.

Ha active/active felallast szeretnel hasznalni, akkor pedig vmilyen clusterezett fs-re van szukseged. Pl. ocfs (mas irta, azt hiszem), vagy van meg mas is.

Alternativ lehetoseg, hogy olyan clusterzett fs-t hasznalsz, amihez nem kell shared disk es tud replikalni: pl. glusterfs vagy moosefs.

En a helyedben jo esellyel az active/passive fellalast valasztanam xfs-sel vagy ext4-gyel. Cel HW nelkul ezzel tudod kihozni a legjobb ar/ertek aranyt relativ megfelelo megbizhatosag mellett.

tompos

ui.: A cyrus mintha tudna duplikalt leveleket kezelni, az Xch szinte tuti, persze az gondolom nem jatszik:)
ui2.: Hasznaljanak shared foldereket, a csatolmanyos levelekhez.

( bazso | 2011. 05. 13., p – 17:31 )

Tudom errefelé eretnekség ilyet kérdezni, de MENNYIBŐL? :-)
Vannak komoly technikák,és össze lehet rakni ingyen is (ld a fenti egész thread). Pontos igényre lehet csak pontos választ adni.
A politikailag nem komált solaris nekem két elég távoli (200km) telephely között tart fent aszinkron replikát zfs send/receive párossal stabilan.
"Ingyé" viszont én is az applikációs szintűre szavaznék (kettéirányított levél vagy db forgalom).

Üdv,
BaZso

Szerk: nem a solarist javasolnám fizetősnek :-)

Hja, mert az inode-okat dinamikusan allokálja AFAIK 4MB-os egybefüggő területeken. Ha nincs annyi egybefüggő szabad terület a töredezettség miatt, akkor vége a mesének, nincs új fájl.

Nekem a longterm todo listámba van egy olyan feljegyzés, hogy:
- kernel 2.6.35: OCFS2 allocation reservations, Discontiguous block groups

Talán ez épp erre megoldás. Én közben már megoldottam máshogy a feladatot, egyelőre érdektelenné vált az OCFS2, nem teszteltem.

( mrceeka v | 2011. 05. 14., szo – 15:07 )

Off.
Exchange-nél sokkal jobbat nem találsz a feladatra.
Igaz, üzemeltetni tudni kell azt is és beruházási költsége is lehet.
Ha a beruházási keret is szűkös és értelmesebb üzemeltetői feladványok is akadnak mint a mailserverrel bíbelődni, ráadásul garantált SLA-t szeretnél, akkor Office 365.

Üdv,
mrceeka
On.

( hnsz2002 v | 2011. 05. 14., szo – 15:25 )

Bár már csináltam is ilyet, azt kell mondjam, hogy a kétgépes "cluster" drbd-vel nem igazán jó választás. Nem is igazán cluster, sok vele a nyűg, master-master (aktív-aktív) cluster esetén pedig mégtöbb, és ott van a split brain is, ha nincs szerencséd.
Működik, lehet használni, de... Ha mást nem, legalább egy közös storage-ot érdemes mögéjük tenni, legyen akár freenas, openfiler vagy ami szeretnél.
--
Discover It - Have a lot of fun!

aktív-aktív, vagy aktív-passzív? aktív-passzív még jó is lehet, de aktív-aktívnál volt-e már neked olyan, hogy csak úgy kihúztad az egyiket a konnektorból? Vagy megszakítottál köztük minden kapcsolatot, majd visszakapcsoltad? Az azért nem teljesen egyértelmű két gép esetén, nem is mindig gyógyul magától, és vakarod a fejed, hogy hogy kéne jól megoldani...
--
Discover It - Have a lot of fun!

aktív-aktív, szabályos újraindítás után minden ok, szabálytalannál ha gond van, akkor manuálisan kellhet egykét sort lefuttatni, de olyankor úgyis valami gond van... nem? a cluster miatt a hibátlan fele kiszolgál mindent, amíg a másikat helyre nem állítják. eddig még nem szállt el totál, úgyhogy csak resetelgetéssel kísérletezgettem, de elég jók voltak a tapasztalatok.

Szabályos újraindítás persze, akkor gyakorlatilag kijelentkezik a clusterből, azaz közli a másik géppel, hogy hali elmentem.
De pont ezaz, hogy nemszabályos leállásnál nagyon sokszor előfordul, hogy kézzel kell beletúrni utána kétgépes esetén, mert valami nem állt fel rendesen, nem csipogtak össze, stb.
Igen, a hibátlan fele kiszolgál mindent, egészen addig, amíg mondjuk split brain nem lesz, mindkettő aktív marad, mindkettőn lesznek mondjuk módosítások, mert érkezik mail, töltenek fel fájlt, stb... Na és akkor?
3 vagy többgépes clusterbe ez majdhogynem kizárt hogy előfordul. (Jó, mesterségesen lehet, hogy lehetne olyan helyzetet csinálni, de 99,9%-ban biztos jó lesz)
--
Discover It - Have a lot of fun!

A 3 gépes cluster mivel? Én nem találtam jobb megoldást mint a drbd, ocfs2. Próbáltam aktiv-passziv + reiser + nfs, de lassú volt, és az átálláskor egy szabálytalanul lecsatolt filerendszert kap a másik, ami nem túl jó. Nfs meg lassú is volt. Úgyhogy most ez ami van, eddig bevált, de ha tudsz jobbat, érdekel, nagyon is!

Hát 3 gép alá nem tudsz drbd-t rakni, mivel mint írtam az két gépen működik, se több, se kevesebb :) Az alá már mindenképpen valami dedikált storage kell, hogy az most egy lanon elért cucc lesz, vagy normálisabban mondjuk fc, az már "mindegy". Ocfs2, GFS2 persze jó, és általában ezt szokták használni. A szabálytalan lecsatolással nem tudom mit lehet kezdeni, nfs mount opciókkal és buffer méretekkel lehet mondjuk játszani a sebesség optimalizálás végett.
--
Discover It - Have a lot of fun!