DRBD + LVM + GFS

Linux-haladó

Nos, összeraktam egy ilyen cuccot:

Két debian 6.0.3 node gép (adattároló), rajtuk raid1-ben két-két vinyó. Cél az lenne, hogy a rajtuk lévő fileokat sok webszerverről el lehessen érni primary-primary módban.

Jelenleg ez a felállás a node-okon:

md0<->pv->vg->lv1->drbd0->gfs2
_______________->lv2->drbd1->gfs2
...stb.

Gondolkodom nagyon ezen:

md0->drbd0<->pv->vg->lv1->gfs2
____________________->lv2->gfs2

Az első esetben minden lv-re kellene egy drbd réteget húzni, amely lehet, hogy az lv-k változtatásakor (vagy törlésekor) macerássa válhat.

A második esetet azért vetettem el, mert jelenleg a két md0 mérete más (partícionálni meg nem akartam őket), és mintha ez utóbbi esetben clvm kellene...azaz a ...locking =3 lenne az lvm configban.

Kérek javaslatot, melyik kezelhetőbb, kevésbé macerás, stabilabb.

(itt már volt szó róla: http://hup.hu/node/73636)

  • 10557 megtekintés

( dap | 2012. 11. 13., k – 23:20 )

Hát, én visszalépnék egyet és megkérdezném, hogy miért kell az aktív-aktív setup ebben az esetben? Az egyszerűséget és a stabilitást ezzel már most kockára tetted, szerintem, a clvm itt már részletkérdés. :)

A terhelésmegosztás mint indok így általánosságban elég gyenge lábakon áll, mert melyk erőforrás az, amit ne tudnál egy gépen belül (vertikálisan) skálázni? 2 diszk helyett tehetsz 4-et, 1 nic helyett tehetsz 2-t. A page cache-t (RAM-ot) több node-dal sem skálázod ha mind kb azonos workloadot kap, mert akkor a page cache minden gépen tükre lesz egymásnak. A CPU pedig a legritkább esetben szűk keresztmetszet fájlkiszolgálásnál.

Ellenben a GFS2-vel lelassítod a fájlok elérését (locking) és az egész komplex setuppal kockára teszed a stabilitást.

Más érv szól az aktív-aktív cluster mellett?

Az egész drbd+parallel fs. szerintem egy nagy taknyolás.

vegyél egy jobb NASt, vagy egy normális redundáns tápos vasat, rakj bele 8-10 diszket raid6-ban, meg pár GB-ramot, és ajánld ki a szervereknek nfs-en.

Tényleg.
Sok jövőbeni szívás és dühös ügyfél megspórolható ezzel.

egyébként meg a 2 db. szervernek látszó tárgy helyett egy darab szerver is elvisz vidáman 200 webtárhelyt. Redundáns táp, 4-6 diszk raid 10ben, BBWC raid adapter 8-16 GB memória, és évekig nincs vele gond. Ilyet már bérelni is lehet nettó 30 körüli havidíjban, hostinggal együtt.

miért pukkanna meg a vas, egy normális redundáns szerverben?

Egy csoffadt 200 tárhelyes webszerver alá bőven elég egy normális minőségű Dell/Hp/akármi brand szerver, redundáns tápokkal.
15+ éve üzemeltetek szervereket, összesen jó pár száz volt, de egy kezemen meg tudom számolni hányszor "pukkant meg a drága vas".
Nem az összegányolt szarokból kell kiindulni, hanem azokból, amikhez 5 év helyszini gart ad a gyártó.
Nincs kockázatmentes üzem, a szakma a kockázatok mérlegeléséről szól. Én egy normális, redundáns brand szerverben kevesebb kockázatot látok, mint egy ilyen drbd-s taknyolásban.

Ha baromi fontos az a 200 webtárhely, és nem megengedhető 8-10 óra kiesés/év kb. 0,05% valószínűséggel, akkor lehet venni belőle kettőt.
Minnél fontosabb az adat, annál inkább költeni kell rá, és nem barkácsolással biztosítani a redundanciát.

+1 - és ami már régóta érik bennem: két gépből minek active-active cluster csinálni? Mivel egy gépnek is el kell vinnie a teljes terhelést (mivel tuti akkor fog megpukkanni, amikor terhelés van rajta, és akkor az amúgy ép gép is magába dől ha nem, így rém sok munkával fel lehet építeni egy olyan recert, ami kb. semmire se jó), ezért csak az élet bonyolódik.

Primitív, egyszerű arcú HA clustert pedig rém könnyen össze lehet hegeszteni, és inkább bíznám arra a fontos cuccokat.

( meroksz | 2012. 11. 14., sze – 08:50 )

Szia

Viszonylag sokat szórakoztunk a cégnél DRBD-vel is és GFS-el is (LVM-el is).

DRBD : master-master felállásban nem tudtuk megbízhatóan özembe állítani. Ha nem volt hiba akkor rendben működött, de ha szimuláltuk az egyik node elhasalását, akkor utána nagy szívások mellet lehetett a split brain-ből kiszedni a rendszer. Jött egy ötlet hogy mi lenne ha 2 felé szednénk a DRBD-t és master-slave megoldásba menne, egyik a node1-en másik a node2-n lenne master. Ez már megbízhatóbb volt de... Megkellet oldani hogy ha az egyik node elhasal a másik automataikusan indítsa el az eddigi slave DRBD-t masterként. ehhet klaszterbe szerveztük a 2 gépet (némi extra bonyolultság) viszont itt meg a qourum kialakulása volt kérdéses, mivel 2 géppel nem lehet töbségi klasztert csinálni. Jött a további ötlet qdisk. ez megoldotta volna a többség megteremtésének problémáját de kellet volna egy külső "storage" ahova a gépek írni tudnak. Lényegényem DRBD-t nem javaslom. A minden hibátlan a dolog működik, de ha beüt a gond akkor eléf sok baj van vele.

GFS: ugyan GFS-t használtunk nem GFS2-t de kegyetlen lassú volt. GFS-t Fiber Channel-el használni egészen jó gondolat, gondolom neked nincs FC kapcsolatod a gépek között (FixMe). Minden file művelet akár csak olvasási megnyitás is a GFS cluster összes node-ját éritő "szavazás" után lehetséges. Sok kicsi file esetén ethernet fölött nagyon lassú lesz a file művelet.

Egy gondolatot megér hogy 1 gépet szanálj ami kellően sok diszkel jó raid szervezéssel van megáldva. Szerintem egy ilyen kiépítés akár még jó is lehet neked. Fontos persze hogy milyen típusú és sebességű a web kiszolgálók felé a kapcsolatod, nagyondd disz teljesítményt nem éri meg tervezni mint amit a háózaton át tudsz pumpálni.

Megfontolandó.

Első eset teszt:
Egyik node-on elkezdtem másolni egy nagyobb filet, majd a másikat kihúztam az áramból.
Egy darabig még ment a másolás az elsőn, majd teljesen behalt a drbd0 device. Ki sem lehet lőni.
Maga a drbd azt mutatja, hogy az egyik uptodate:

srcversion: EE47D8BF18AC166BE219757
0: cs:WFConnection ro:Primary/Unknown ds:UpToDate/DUnknown C r----
ns:630196 nr:1770868 dw:2559076 dr:327008 al:198 bm:38 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:161380

Minden folyamat, ami a drbd0-ra hivatkozik D vagy Z státuszú.
Kíváncsi lennék, hogy lehet a még aktív node-ot kivebnni ebből a elyzetből, újraindítás nélkül.

A nagy gond az, hogy nem vette észre a DRBD a Split Brain állapotot:
(azaz nem jelent meg a logban, hogy "Split-Brain detected")

A kapcsolatmegszakadást ugyan észrevete és át is tette "WFConnection" státuszba a maradék node-ot

--
Nov 14 09:18:07 backup kernel: [175090.108049] block drbd0: peer( Primary -> Unknown ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
Nov 14 09:18:07 backup kernel: [175090.108066] block drbd0: asender terminated
Nov 14 09:18:07 backup kernel: [175090.108072] block drbd0: Terminating drbd0_asender
Nov 14 09:18:13 backup kernel: [175095.609042] block drbd0: md_sync_timer expired! Worker calls drbd_md_sync().
Nov 14 09:18:13 backup kernel: [175095.655635] block drbd0: Creating new current UUID
Nov 14 09:18:13 backup kernel: [175095.682646] block drbd0: Connection closed
Nov 14 09:18:13 backup kernel: [175095.682668] block drbd0: conn( NetworkFailure -> Unconnected )
Nov 14 09:18:13 backup kernel: [175095.682678] block drbd0: receiver terminated
Nov 14 09:18:13 backup kernel: [175095.682683] block drbd0: Restarting drbd0_receiver
Nov 14 09:18:13 backup kernel: [175095.682688] block drbd0: receiver (re)started
Nov 14 09:18:13 backup kernel: [175095.682711] block drbd0: conn( Unconnected -> WFConnection )
Nov 14 10:02:36 backup kernel: [177758.340220] block drbd0: conn( WFConnection -> Disconnecting )
Nov 14 10:02:36 backup kernel: [177758.340261] block drbd0: Discarding network configuration.
Nov 14 10:02:36 backup kernel: [177758.340295] block drbd0: Connection closed
--

... de ezt meg nem tudom egyelőre kezelni, azaz újraindítás nélkül feléleszteni újra a maradék /dev/drbd0-t.
(a másik node maradt kikapcsolva)

Jaja, bocs, rosszul fogalmaztam. Node elhalás történt (bár az igaz, hogy minden kapcsolat megszakadt a node-o kközött - ami ugye a split brain-nél is van, de az egyik node meg is állt.)

Kérdés továbbra is adott, a maradék node-on hogyan tudunk tovább üzemelni ilyen esetben (lehetőleg újraindítás nélkül).

Egyelőre még azt sem tudom, hogy te honnan tudod, hogy jobb? Próbáltad már őket?
Egyelőre a DRBD-t ismerem, de ha valaki alátámasztja érvekkel, hogy van alternatívája a redundáns primary-primary drbd-nek, ami replikálja is a teljes blokkeszközt, nem csak összevonja, akkor kipróbálom

A drbd egy eszköz, arra rakhatsz n+1 féle FS-t. Ha aktív/aktív kell, akkor szűkül a kör - és esik vissza a teljesítmény.
Neked az kell, hogy több helyről rw érj el közösen használt területet. Ezt anno NFS-szerverrel szoktuk volt megoldani. Az nfs-szervert failover clusterben húzod fel két gépre, a kiajánlott diszkterület alá meg raksz szintén aktív/passzív felállásban drbd-t.

Az NFS-en elosztottan éred el, ha kell, ro, ha kell, rw területként (javasolt egyébként szétválasztani az rw és ro területeket). A redundanciát a két gépből failover clusterként összerakott nfs-fürtöd adja, ezeknek a háttértárát (célszerűen a raid1-es md device-okat befűzve a drbd alá) szimpla, mezei aktív/passzív drbd-vel tartva szinkronban.

minden erv, amit az nfs megoldas bonyolultsaga mellett hozol fel, valos lehet, de ebben az esetben egy 3* -os szorzoval a masik megoldasra is igaz.

mit kell kibogaraszni pontosan nfs-nel, amit gfs2-nel majd nem?

felre ne ertsd, miattam viasztablat is hasznalhatsz storage-nek, csak az alapjan amit irtal, imho olyan miatt akarsz nagyon bonyolult setupot, ami ezt nem indokolja.

Szerintem arra gondol wyx, hogy egy esetleges szerver hiba után mikor vissza jönne a hibázó node, de az életben maradt node-ra közben történt írás. Ekkor elő állhat az hogy nem egyeznek meg a node-ok hogyan kellene helyre hozni a dolgot, De ez a könnyebb eset.

Ami nagyobb gond lehet, adott esetben hogy a node[1-2] drbd szinkronba tartáshoz egy dedikált kábelezést használ(teljesen jogos lenne), és ez hibásodik meg. Ebben az esetben node1 is és node2 is életben marad mind a 2-re történhet írás/olvasás. Majd vissza áll a 2 node közötti kapcsolat, és egészen nagy pánikba lesznek a node-ok hogy akkor most mi is a helyes, mit kell szinkelni/módosítani/törölni.

Persze tompos-nak igaza van abban hogy ha nem akarunk automatikus failovert, akkor sok problémát lehet ignorálni, cserébe az admin-nak kell minden hiba után kézzel maszírozni a dolgot. Üzembiztosság/megbízhatóság feláldozása a teljesítményért.

Nem saját bölcsesség de nagyon igaz:
"Legfeljebb 2-t választhatsz:
- megbízható
-gyors
-olcsó"

Tisztázzunk valamit:
- vagy van valamilyen quorum-megoldásod - azaz minimum három független "építőelem" van a rendszerben, amik közül legalább kettő kell a működéshez (pl. két gép és egy külső diszk),
- vagy ha nincs quorum-megoldásod, akkor a "megy a két node és tud egymással beszélgetni" állapotból minden változás teljes leállással és kézi átkonfigurálással jár: megmondod annak a node-nak, akit életben szeretnél hagyni, hogy őneki egyedül is szabad működnie.

Bármilyen más setup adatvesztéshez vezethet, amit nyilván nem szeretnénk.

( djsmiley v | 2012. 11. 15., cs – 21:18 )

Nem akarok ünneprontó lenni, de a GFS szerintem ebben a konstellációban nettó hülyeség, pláne a DRBD-vel kombinálva, ami alapvetően akkor jó ha aktív-passzív megoldást üzemeltetsz, leszámítva speciális eseteket: lásd: kvm live migration 2 node-os környezetben, shared storage nélkül. Itt meg a fencing a probléma, nem is annyira a qourum.

Javaslat: Distributed filesystem mint pl:
IBM GPFS (Hátránya h. RedHat v. Suse kell alá, de megteszi a CentOS is)
Lustre (Hetekig fogsz szívni mire összerakod :))
GlusterFS (Ez baromi jó, userspace és könnyű használni))

Ezekkel a magoldásokkal fs szinten tudsz replikálni, nem kell drbd, egy helyen van minden, még az LVM-et is kihagyhatod tulajdonképpen.

Akik a lockolás miatt aggódnak, azoknak meg üzenem, hogy sanszos h. egy web szerver nem fcntl() lockingot használ, a sima flock() meg gyors clusterben is, csak legyen a gépek közöt normális network, illetve minden fsnek megvan a maga baja (lásd.: GFS-ben is állítgatni kell a max lockok számát cluster szinten).

"Ezekkel a magoldásokkal fs szinten tudsz replikálni"

IBM GPFS-nél hogy van ez a replikáció dolog?
Amikor legutóbb volt vele dolgom akkor shared storage kellett hozzá, ez változott vagy már akkor is tudta az eméített dolgot csak én nem tudok róla?
(ez kb. 2,5 éve volt)
Másrészt ha jól emlékszem a GPFS-hez legalább 3 node kell és elég drága is.

Előre is köszi.

♲♻♲

Jó tudni, köszönöm.
Akkor itt valószínűleg erről van szó:
https://publib.boulder.ibm.com/infocenter/clresctr/vxrx/index.jsp?topic…

Az ilyen hálózaton elosztott fájlrendszerek közül melyik a legmegbízhatóbb / legkiforrottabb ami telesítményben is elfogadható szintet nyújt?
Itt most olyan fájlrendszerekre gondolok mint amit a kolléga is említett fentebb, hogy maga a fájlrendszer oldja meg a node-ok közötti szinkronizálást és egyéb teendőket és nem kell más réteg.
Van ezek között olyan amit aktív-aktív módban is lehet megbízhatóan használni elfogadható teljesítmény mellett?
Most nem extrém esetre gondolok (nagyon sok kis fájl, vagy nagyon nagy fájlok).

♲♻♲

Nem feltétlen kell a GPFS-hez 3 node, de ajánlott (2 qourum-manager is működőképes jó fencinggel). A doksiban arra keress h. tiebreak (ez lehet egy gyenge gép is, nem feltétlen kell neki managernek lenni, lehet úgy konfigurálni h. 2 nagy géped qourum manager és a harmadik csak qourum)
A node-ok belső diszkjeit fel tudod használni, gyakorlatilag shared nothing rendszert lehet belőle építeni, a replikáció pedig a failover groupok között valósul meg. Shared környezetben akár direkt FC-n is, failback ethernettel. Tehát pl. ha minden ok, akkor mindkét szerver írja-olvassa mindkét failover groupot a storage-eiden, path hiba esetén meg megy a dolog úgy is h. network szinten a többi nsd-n keresztül valósul meg a diszkek elérése. Ilyen módon pl. ha elrontasz egy zónázást nem dől össze az fs.
Ez a 3 óta létezik, tehát jó rég óta :) Mondjuk 5 éve biztosan.

Véleményem szerint a legjobb a GPFS, teljesítményben és skálázhatóságban, ha nem az ár az elsődleges szempont, mert processzormagonként van a license, gyakorlatilag CPU unittal számolnak, egy 3 node-os konfig cc 6-800E forintos tétel.

( hrgy84 | 2012. 11. 16., p – 18:25 )

Szerintem eloszor is probald meg atolvasni a clusteringgel kapcsolatos szavak definiciojat, meg hogy pontosan hogyan mukodik egy cluster. Nem kotozkodes, tenyleg ajanlom, mert enelkul nem fogod erteni, hogy mi zajlik a rendszeredben.

Amugy en is amondo vagyok, hogy ide DRBD-t meg GFS-t felesleges rakni. Kell valami olyan FS, ami kepes egyszerre ket gepen leirni ugyanazt az adatot, ilyen talan meg az unionfs is, bar tapasztalatom nincs vele, de minel lightweight-ebb a cucc, annal jobb.

Illetve azt dontsd el, hogy load-balancingot szeretnel, vagy failover clustert. A ketto kozul ugyanis csak es kizarolag az egyik valaszthato.

Ha failover clustert, az az egyszerubb, NFS szerver, kap a 2 gep egy virtualis IP-t, es azt rangatod heartbeat-tel a ket gep kozott. Es szerintem ebben az esetben a nativ DRBD device-ra felhuzni egy FS-t es kesz koszonjuk. Itt eleg lehet egy master-slave felallas.

Load-balancing eseteben pedig szinte biztos, hogy en nem 2 geppel indulnek neki a dolognak, hanem legalabb 3-mal, egy bikaeros geppel mint iSCSI target, es ket NFS node-dal, mindkettovel kiajannlva ugyanazt a targetet. Kesobb az iSCSI target gepet is duplikalni kell, mert SPOF a rendszerben, de tapasztalatbol tudom, hogy ha 2x annyi gepet mondasz, mint amennyit eredetileg terveztek, akkor elhajtanak a verbe, ugyhogy egyelore az 1 iSCSI target az boven eleg lesz, csak az a lenyeg, hogy tenyleg bika legyen. A 2 NFS node lehet gyenge gep is, ok csak az NFS-iSCSI proxy szerepet jatszak, CPU legyen, meg sok mem.

A lenyeg: azok a gepek, amik resztvesznek a tarolasban, direktbe legyenek osszekotve, vagy legfeljebb kulon switchel, tehat olyannal, amin semmilyen mas forgalom nem megy.

Ja, es jobb lenne az MD RAID-et nagyon gyorsan elfelejteni. Nincs bajom vele, csak cluster kornyezetbe eroteljesen nem ajanlott.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

+1. akármennyire erős, ha elhasal, akkor megdöglött minden. Legfeljebb egy normális (dupla vezérlős, vezérlőnként néhány, legalább csigabites lábbal, hogy a multipath+failover megoldás összemadzagolható legyen direktben, azaz switch nélkül) iSCSI storage-ot tudok ott elképzelni (jó kis raid6-tal), előtte két, failover clustert alkotó szerverrel, amik NFS-t adnak a webszervereknek; természetesen ugyanazt az iscsi targetet felváltva magukra húzva - ezzel a drbd-s mókolás is mehet a kukába.

Ha csak az NFS szerverek kulso IP-je (vagyis amire fel vannak konfigolva a gepek) failoverezik, azt viszonylag egyszeru, tul sokat hibazni nem lehet rajta. No persze, roccenes nelkul nem fog menni, de meg igy a legkisebb a kieses.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Szerintem eloszor is probald meg atolvasni a clusteringgel kapcsolatos szavak definiciojat, meg hogy pontosan hogyan mukodik egy cluster. Nem kotozkodes, tenyleg ajanlom, mert enelkul nem fogod erteni, hogy mi zajlik a rendszeredben."
- Tudnál ajánlani jó doksit ehhez?

"Illetve azt dontsd el, hogy load-balancingot szeretnel, vagy failover clustert. A ketto kozul ugyanis csak es kizarolag az egyik valaszthato."
- Általánosságban érted vagy erre az esetre kimondottan? Mindkét válasz esetén a kérdés az, hogy miért.

"Ja, es jobb lenne az MD RAID-et nagyon gyorsan elfelejteni. Nincs bajom vele, csak cluster kornyezetbe eroteljesen nem ajanlott."
- Erről még nem hallottam, úgy tudom, hogy az MD raid egy stabil dolog, amit nagyvállalati környezetben is használnak (ha ez számít bármit is).
- A kérdés szintén, hogy miért.

Előre is köszönöm.

♲♻♲

"- Általánosságban érted vagy erre az esetre kimondottan? Mindkét válasz esetén a kérdés az, hogy miért."

Rossz a kerdesfelteves. Mit szeretnel elerni? Terheleselosztast, vagy magas rendelkezesre allast? Tenyleg nezz utana a szavaknak, a wikipedia meg a google mindig jo kiindulopont. Addig bele sem erdemes kezdeni, amig nem tudod, mire van szukseged.

"- Erről még nem hallottam, úgy tudom, hogy az MD raid egy stabil dolog, amit nagyvállalati környezetben is használnak (ha ez számít bármit is)."

Igen, arrol bootol az operacios rendszer. Esetleg. De adatok ala - foleg olyan helyre, ahol teljesitmeny VAGY magas rendelkezesre allas is kell -, nincs az a nagyvallalati rendszergazda, aki ne uttetne le mindket karjat, minthogy MD RAID-et valasszon. Az MD RAID ugyanis egy szoftveres dolog, annak minden hatulutojevel. Eroforrasigenyes, lassu. Pistikehostingba elmegy, de te nem olyat akarsz epiteni, legalabbis a feladatkiiras alapjan.
Nem tudom, miert odzkodnak emberek hardveres RAID-et venni. Persze, mocskosrohadtkuva draga, de behozza a penzet. Van, ahova jo az MD RAID, kulonosen, ha nem kell az utolso bit/s teljesitmenyt is kicsavarni a gepbol, de ahol kell, oda nem jo, mert felzabalja a gep eroforrasait - reggelire. Es hol van meg az este.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"Rossz a kerdesfelteves. Mit szeretnel elerni? Terheleselosztast, vagy magas rendelkezesre allast? "
- Na most miért is ne szerethetne bárki terheléselosztást és magas rendelkezésre állást elérni egyszerre?

- MD raid esetében itt akkor azt nem tisztáztuk, hogy milyen raid level-ről beszélünk.
- Pl. a topic nyitó raid1-ről beszélt és még mindig nem értem, hogy pl. az MD raid1 miért nem alkalmas cluster környezetben való használatra.

♲♻♲

Szeretni sokmindent lehet. En is szeretnek sok penzt, egy mercit soforrel, egeszseget, vilagbeket... szereny kivansagok. Aztan reggelente mindig hozzaerek a hideg falhoz.
Lehet csinalni olyan terheleseloszto rendszert, aminek magas a rendelkezesre allasa, meg lehet magas rendelkezesreallasu clustert csinalni, csak a ketto nem egeszen ugyanazt a megoldast takarja. A terheleseloszto megoldas ugyanis nem lehet mas, mint aktiv-aktiv cluster, ugyanakkor ha csak a HA a cel, akkor belevaghatunk aktiv-passziv clusterbe is, leven azt sokkal konnyebb megvalositani - ekkor viszont ugrik a terheleselosztas, hiszen a passziv node attol passziv, hogy nem bizgetjuk ot aktivan, jobb esetben nem is tudjuk, hogy letezik.

Az MD RAID-dal elsodleges gond a terhelhetosege. Mivel szoftveres megoldas, igy reszben sosem lesz olyan terheles-turo, mint egy hardveres RAID, masreszrol a reliability tekinteteben is eros hianyossagokkal kuzd, amennyiben elegge fugg a gep eroforrasaitol, mig egy hardveres RAID azert nagyreszt onalloan cselekszik, egy kernel panik peldaul nem vezet implicit a disk write-cache garantalt elvesztesehez.

Persze, lehet hasznalni, mindent lehet hasznalni, egy szal diskkel is lehet clustert csinalni, elvegre a clusternek meg a RAID-nek semmi koze egymashoz. A problema inkabb abban keresendo, hogy amit lehet, azt nem biztos, hogy erdemes is. Ha EN clustert epitenek, eszembe nem jutna egy ennyire kritikus rendszert az MD RAID kenye-kedvere bizni, hanem igenis nem sajnalnam azt a 100-120k-t, amennyivel tobbe kerul az egesz, es tennek bele tisztesseges RAID kartyat. Mert ertekeben sokkal tobbet sporol meg nekem, mint amennyibe kerul.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Akkor vmit nagyon beneztel.

Egy pelda kicsit kifejtosebben:

LSI Logic / Symbios Logic SAS1064ET PCI-Express Fusion-MPT SAS (rev 08)

Van rajta 1 tomb:

ioc0 vol_id 0 type IM, 2 phy, 135 GB, state OPTIMAL, flags ENABLED
ioc0 phy 0 scsi_id 10 SEAGATE ST3146356SS 0006, 136 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 1 SEAGATE ST3300657SS 0008, 279 GB, state ONLINE, flags NONE

A nagyobbik helyett egy kisebb hdd volt korabban, az kiesett, csereltek a nagyobbra.
Mar azt hittuk, szar van a palacsintaban, mert fel nap utan meg mindig degraded volt a tomb. Aztan 15 ora utan helyrejott.

Az MD raid korberohogte volna. Semmi tobbet nem tudok elmondani.

tompos

Nekem olyan tapasztalatom van, hogy MD RAID-rol valtottunk hardveres RAID kotetre, a backup idoablak hossza a felere esett le, ezt megtoldottuk parhuzamositassal, ezzel elfeleztuk, azaz az eredeti negyedere szoritottuk le. Pedig csak egy szar backup volt. A hardvert az Adaptec biztositja.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Te altalanositva irtad. Nem irtal adaptecrol, nem definialtad hogy milyen raid kartyakrol van szo. Igy, altalanositva pedig nem igaz.

Van jopar raid kartya, ami eseten azonos feladat mellett az mdraid valoban rosszabbul teljesit, de messze nem lehet ezt altalanositva kijelenteni.

Sajnos sokszor hiszik az emberek, hogy _barmilyen_ HW raid megvaltas az SW raiddel szemben automatikusan, de ez nem igaz.

tompos

Arra továbbra sem válaszoltál, hogy miért zárja ki egymást a load balancing és a HA.

Használtál már MD raid-et az utóbbi években? A mai modern gépek esetében már nagyon meg kell hajtani a diszkeket, hogy szignifikáns processzorhasználatot generáljon az MD, főleg mirrorozás esetén.
Nem vagyok a linux kernel nagy ismerője, de szerintem a kernel már nem cache-el az MD layer és a block device-ok között, tehát egy crash nem feltétlen jár adatvesztéssel. MD layer fölötti write-cache az bukik, de ez ugyanúgy igaz hwraid esetén is. A journal fs-ek mindig úgy írnak a block device-okra, hogy az mindig konzisztens maradjon. Úgy tudom, hogy a barrier támogatás is megy már MD-n keresztül.

Én is external storage/hwraid párti vagyok, de szerintem sok téves infót összehordassz itt az MD raidről...

Tükör esetén "csak" az írási műveletek által generált i/o műveletek duplázódnak, ez igaz, de pl. egy raid5 esetén három diszknél egy blokk írása az rögtön húz magával egy plusz olvasást és egy plusz írást, ami már i/o-ban, memóriahasználatban és cpu-ban (checksum számolgatása) is jelentkezik.

Utánanéztem, tényleg, 2.6.33 óta van raid[56] barrier [1], 2.6.37 óta pedig váltotta az egész barriert a flush, amit azonnal lekövetett az md/dm is [2 3 4]. Szóval modern kernellel az adatbiztonság már nem érv a hw raid mellett.

> szerintem a kernel már nem cache-el az MD layer és a block device-ok között
Ez így igaz.

"Lehet csinalni olyan terheleseloszto rendszert, aminek magas a rendelkezesre allasa, meg lehet magas rendelkezesreallasu clustert csinalni, csak a ketto nem egeszen ugyanazt a megoldast takarja."
És?

"A terheleseloszto megoldas ugyanis nem lehet mas, mint aktiv-aktiv cluster,"
Simán lehet nekem 10 webkiszolgálóm, amiből 7 aktív 3 meg passzív és vár, hogy a másik 7-ből meghaljon az egyik..

"ugyanakkor ha csak a HA a cel, akkor belevaghatunk aktiv-passziv clusterbe is, leven azt sokkal konnyebb megvalositani - ekkor viszont ugrik a terheleselosztas, hiszen a passziv node attol passziv, hogy nem bizgetjuk ot aktivan, jobb esetben nem is tudjuk, hogy letezik."
És mi van akkor, ha van nekem pl. 4 node-om amiből 2-2 párban HA clustert alkot és a két pár között van terheléselosztás...
Az, hogy mikor mi könnyebb az adott szituációtól, rendszertől függ, egyáltalán nem lehet általánosítani...

Az MD raid-et meg hagyjuk, mert tudom, hogy használnak komoly helyeken MD raid1-et merevlemez tükrözésre illetve más rendszereknél (pl. AIX) is használnak nagy rendelkezésre állású környezetben szoftveres raid1-et.
A szoftveres raid-nek még kimondottan előnyei is vannak a hardware-es raid-el szemben (nyilván hátrányai is), pl. kivehetem és áttehetem egy tök másmilyen gépbe és megy, stb...

Szerk.

♲♻♲

ismét kérdezném: miért nem?

Mert választanod kell a szar performancia és a false sense of security között.
Ha szinkron replikálsz, akkor az megnöveli az írások idejét (minél jobb a diszked, annál durvább lesz a százalékos romlás), ha pedig nem szinkron replikálsz, akkor meg bele van kódolva a rendszeredbe az adatvesztés.

Ez nem indok, egyébként is választanod kell a szar performancia és a false sense of security között. :) Ha nem akarod a writeback cache-ed tartalmát elveszteni, akkor fsync()-elni kell mint állat, ami megöli a teljesítményt -pláne naplózó fájlrendszerrel. Az alkalmazások többsége inkább vállalja az adatvesztést, a juzer meg tolerálja.

Az tény, hogy a DRBD tovább nyitja a teljesítmény és az adatbiztonság közti rést, de megvan az nélküle is, nem ilyen fekete-fehér a dolog.

ez (gondolom) erősen alkalmazásfüggő. TFH van két gép, hw raid vezérlővel. Az eredeti kérdéstől eltérően
ugye kicsit más a felhasználás - ugyanazt az adatterületet nem írja mindkét gép.
"A" gépen fut x virtuális szerver
"B" gépen fut y virtuális szerver

természetesen azzal képben vagyok, hogyha mindkét gépen sok írási művelet van, akkor az kihat jelentősen (azaz összességében kb feleződik - vagy mégrosszabb lesz - az IO sebesség).
Abban az esetben, ha a virtuális gépek keveset írnak, akkor a fenti nem lesz gond. (gondolom)

Főképpen rendelkezése állás miatt gondolom használni így a DRBD-t, azaz a virtuális gépeket lehessen ide-oda pakolni a két fizikai gép között, és leállás nélkül lehessen karbantartani/bővíteni.

Itt is jelentkezne a kockázat?