Melyik RAID levelt ajánlanátok? (zfs)

Merevlemezek, vezérlők

Sziasztok!

Eddig a "szerver"-ünkben zfs mirror-ban ment 3 hdd, ami redundancia szempontjából jó, de így a tárolókapacitást harmadoltuk... :) Egyszer nagyon jól jött a 3-as mirror; az alaplapi memória vezérlő szemetelt, és elég későn derült ki...

Most bővítünk, veszünk 3 nagyobb (160GB -> 1TB) sata hdd-t, ezért érdeklődök, hogy ti mit használnátok? Eddig jól elvoltunk így, 100mbit-en a raid-et úgysem nagyon hajtjuk ki.
Ha érdemes, nem lehetetlen, hogy +1 hdd-t is meg tudunk oldani.

Nem vagyok különösebben nagy guru, az alapvetésekkel nagyjából tisztában vagyok, éppen ezért fordulok a kollektív bölcsességhez :)
A szerver feladatai: levelezés (Squirrelmail + imap), smb megosztás, és úgy kb. ennyi.
Vas: Celeron E3400 @ 2.60GHz, 2GB ram, Gigabyte G31M-ES2L alaplap, alaplapi sata vezérlő.
OS: Solaris 10 (2 külön pata hdd-n)

Köszönöm.

( dj | 2011. 07. 25., h – 10:29 )

Ezt a hármas tükör megoldást nem értem. pl. 1-2-es lemez tükörben, majd a tükör a 3-as lemezzel szintén tükörben? Vagy, hogy?

zfs alatt nincs megkötés, hogy mit hogyan "raidelünk" össze (lehet mirrorokat raidz-be is :))
A mi esetünkben a parancs egyszerű, ld. lentebb a végeredményt: 


 zpool create orl mirror c7d0s4 c7d1s4 c8d0s4

Így egyszerűen nem két, hanem három lába lesz a mirrornak, az adatok három felé mennek. 


[root@...]root/$zpool status -xv
  pool: orl
 state: ONLINE
status: The pool is formatted using an older on-disk format.  The pool can
        still be used, but some features are unavailable.
action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
        pool will no longer be accessible on older software versions.
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        orl         ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            c7d0s4  ONLINE       0     0     0
            c7d1s4  ONLINE       0     0     0
            c8d0s4  ONLINE       0     0     0

errors: No known data errors

Itt is ilyesmit csináltak:
http://www.solarisinternals.com/wiki/index.php/ZFS_Configuration_Guide#…

<-------
You can't grep on dead trees.

1) kiszedsz egy diszket (beszarik, elteszed emlékbe, mentésnek, kölcsönadod a tartalmával együtt valakinek, klónozol belőle egy másik gépet, stb.), és még mindig marad redundáns a rendszered!

2) a raid 5 kurva lassú tud lenni bizonyos körülmények között, és van, akinek ez fáj.

oh oké hát a szavadra komolyan merek alapozni

... akkor emberek, ezt a cross-platform fs-t most kidobjuk és megvesszük százé azt a raid kártyát, hupon esküsznek rá hogy forward-compatible lesz a következő 10-20 évben, és nem is hal ki a termékcsalád, és új adatbusz se jön ki.. röviden: hardverre fogunk dependálni, mert az sose változik

ld. fentebb. (vl+zeller)
Igazából a mi esetünkben praktikus okai is vannak a tripla-redundanciának: egyetemi intézetként pénz hol van, hol nincs... így ha kidől egy hdd, és esetleg nem tudunk újat venni egy darabig, még marad plusz replikánk.
<-------
You can't grep on dead trees.

( tovis v | 2011. 07. 25., h – 13:15 )

RAID10 ?

* Én egy indián vagyok. Minden indián hazudik.

az lvm nem csinál neked raid0-át. ergó ha két raid1-et adsz neki, abból konkatenált raid1 tud csak kijönni a végén. az meg /2 streaming i/o sebességben, és /2 tud lenni random i/o iops-ban, egy darab nem max. méretű volume-ra nézve, sacc/kb.

ha rugalmasságot akarsz volume méret terén, akkor
- 2x raid1, felette 1x raid0, felette lvm (itt minden tükrözve lesz, ebben nincs rugalmasság)
- 2x raid0, felette tükrözés lvm-ből (itt az lvm-ben dönheted el, hogy melyik volume legyen tükrözve, és melyik ne, cserébe redundanciát buksz, mert ha a két raid0 átellenes sarkában levő diszkek kiesnek, akkor az egész rendszered leáll)

( Replaced | 2011. 08. 02., k – 20:41 )

raidz, ha mar zfs, nem?

--
NetBSD - Simplicity is prerequisite for reliability

Anno azért nem raidz lett, mert így egy picit jobb a hibatűrésünk (ld. fentebb az anyagi lehetőségeinkről). A mi esetünkben a sebesség kevésbé érdekes - amennyit kell, annyit tud a rendszer így is, a felhasználó talán pár másodperccel többet vár, míg megjelenik az INBOX-a :)
<-------
You can't grep on dead trees.

( STP | 2011. 08. 03., sze – 01:16 )

"Eddig jól elvoltunk így, 100mbit-en a raid-et úgysem nagyon hajtjuk ki."
Ha a megoldás eddig jó volt, és a feltételek nem változtak, akkor minek változtatni rajta?

...végülis ez lett a megoldás. Plusz 1 hdd nem lett (spórolunk), így maradt a tripla tükör. Így van kis plusz redundanciánk.
Ha jól tudom, olvasásnál elvileg az I/O elosztva jön a 3 hdd-ről, írásnál meg még mindig a 100mbit a szűk keresztmetszet (jó, olvasásnál is... :)), a triple mirror egy diszk-ént viselkedik, ami sata2-nél a mi esetünkben belefér.

<-------
You can't grep on dead trees.

( aspirin v | 2011. 08. 03., sze – 11:01 )

Húha... úgy látom új életre kelt a topic... :)
Mea culpa: a múlt héten nagyon elhavazódtam, és elfelejtkeztem róla. Mindjárt válaszolok mindenkinek - a "project" éppen tegnap-ma zajlik :)

Köszönöm mindenkinek a válaszokat, tanácsokat!
<-------
You can't grep on dead trees.

( battila | 2011. 08. 03., sze – 11:34 )

En a Raid 1+0-at szeretem. 4 diszk + 1 spare.

Mondanam, hogy adok egy Smart Array P400-as vezerlot hozza, de mar szetosztogattam 6-ot es mar csak egy tartalekom van.

RAID esetén, mondjuk egy 3 diszkes raid5-re egy blokk írása hány művelet lesz? Be kell olvasni egy másik blokkot, kiszámolni a checksum-ot, majd kiírni kettő blokkot. Ha van hw-raid, akkor az OS-felől egy darab írási műveletet látsz. Ha szoftos raided van, akkor meg látod mindet, mind terheli a cpu-t, memóriát, rendszerbuszt.

Mert az kell a baromitakarékoshűdejó Java-nak, ugye? Attól, hogy dedikált sávszélességed van minden diszkig (a raid-vezérlőn is megvan ugyanez), attól, hogy egy core csak a checksum-okat számolgatja, attól még a diszk - memória - cpu - memória - diszk útvonalat több adatnak kell végigjárnia - hiába van sok üres mag a proci(k)ban, ha a diszkről a memórába be kell húzni n darab adatblokkot, mielőtt számolni kezdhetsz, és az egy szál írásműveletet n darab, akár párhuzamos írással elvégeznéd. A CPU-mag drága ahhoz, hogy ellenörzőösszegeket számolgasson. Érdekes, ha diszktömbről, diszk-i/o-ról és az ottani checksum-ról, annak számolgatásáról van szó, mindenki jön, hogy "vansokcpumagjóleszaz", miközben pl. egy csigabites/tízcsigás hálókártya esetén természetes igény, hogy a szükséges checksum-ot a kártya intézze...

"A CPU-mag drága ahhoz, hogy ellenörzőösszegeket számolgasson"
Azért a RAID kártya sem olcsó

Egyértelműen felhasználás kérdése, hogy indokolt-e a RAID kártya. Sok előnye van és persze hátrányai is vannak szép számmal, de szerintem ezek valahol már biztos ki lettek vesézve.

Idaig azt hiszem 6-ot osztogattam szet, plussz amit a kollegamnak. Mivel nekem nem kerult penzbe, ezert ennyiert is adtam tovabb.

Ami viszont penzbe kerult, az a sas-sata kabel hozza. Ezzel csatornankent 4 Sata diszket lehet radugni, tehat osszesen 8-at. 1 kabel valami 7 euro volt, a ketto igy 14 (kb 4 ezer forint).

a 10G -s halon a csomagszam (igy a checksumszamolgatas) is joval (nagysagrendekkel) tobb feladat, mint blokkokat manipulalni, checksumolgatni. (FIXME, ha nem, sajnos idom most nincs konkretan megnezni sehol)

plusz, ahogy mar irtak, a diszk - memoria - cpu - memoria - diszk megvan amugy is, csak max a raid vezerlodig.

Csak az nem mindegy, hogy mondjuk egy raid5 tömb esetén egyszer kell adatokat kiböffenteni az eszközre,és a többit majd elintézi saját maga, vagy beolvas-számol-kiír-kiír körök futása van.
A csigabitnél is alapvető dolog, hogy ne a proci számoljon olyanokat, amit lehet másra bízni.

A CPU-mag drága ahhoz, hogy ellenörzőösszegeket számolgasson.

A CPU-mag és a HW RAID kártya ár/teljesítmény faktora alapján egyre inkább nem lesz igaz a fenti állítás (szerintem már most sem az).

Érdekes, ha diszktömbről, diszk-i/o-ról és az ottani checksum-ról, annak számolgatásáról van szó, mindenki jön, hogy "vansokcpumagjóleszaz", miközben pl. egy csigabites/tízcsigás hálókártya esetén természetes igény, hogy a szükséges checksum-ot a kártya intézze...

Ez nem véletlen. A checksum-generáló hálókártya minden szegmensben használható, sőt, az enterprise környezetben van igazán értelme. A HW RAID kártya jellemzően nem működik az átlagos enterprise környezetben, nem véletlen, hogy ezek a PC-be dugható HW RAID kártyák nem készültek FC kivitelben...

Segítek: intelligens, redundáns külső tárolóeszköz, amit több gép használ párhuzamosan, és akár ugyanazt az adatterületet is el tudják érni egyszerre (pl. oracle rac). Ehhez jellemzően szokott párosulni az FC interfész/switch is, természetesen multi-path kivitelben.

Ebben a felállásban nincs igazán helye a gépenként HW RAID kontrollernek...

Azt hiszem nem lattal meg elegendo kornyezetet. Fogalmam sincs, hogy ki vagy, nem is all szandekomban minositeni.

1, az eredeti felallasban localis diszkekrol volt szo. Marpedig barmilyen kornyezeted van a lokalis diszkeket erdmes raiden tartani.
2, enterprise kornyezetben sem minden esetben rakjak az adatokat SAN-ra. A SAN draga, 4 evig uzemeltettem SAN-t, ismerem az arakat.
3, egyetlen egy esetben nem kell raid vezerlo a lokalis gepbe: ha diskless.

Velemenyem szerint a SW raid-del mind a rendszerek epitesekor, mind a hibajavitasakor, tehat uzemelteteskor sokkal tobb a gond, munka.

A kollegaval meg ne vetessunk mar rogton storage boxokat a 3 diszkjehez!

"Azt hiszem nem lattal meg elegendo kornyezetet"

Szerintem sokkal több SAN-os rendszert rakott össze, mint amennyit te eddig láttál összesen. :)

"Velemenyem szerint a SW raid-del mind a rendszerek epitesekor, mind a hibajavitasakor, tehat uzemelteteskor sokkal tobb a gond, munka. "

Tapasztalataim szerint meg nem. Több tucatot csináltam mindkét fajtából, vannak pro és kontra érvek, de egyikről sem lehet kijelenteni, hogy egyértelműen jobb mint a másik.

1, az eredeti felallasban localis diszkekrol volt szo. Marpedig barmilyen kornyezeted van a lokalis diszkeket erdmes raiden tartani.

Bocs, de nem az eredeti kérdésről volt már itt szó, hanem arról, hogy úgy általában a network checksum számolás esetén miért indokolt a cpu-ról lepakolás külön HW-re, míg a storage esetén ugyanezen logika szerint miért nem indokolt a HW RAID kártyákra lepakolás.

Én meg leírtam, hogy azért, mert az igazán nagy rendszereknél a HW RAID kártyák helyett dedikált készülékekbe migrálták ezt a RAID számolást, nem pedig PCI kártyákra. Az csak a középkategóriában (workgroup szerver, kkv szektor) ekkora nagy divat, hogy single gépek dedikált diszkeken tartják az adataikat, és ott tényleg van ennek létjogosultsága (sőt, csak ennek van, szép nagy BBWC-vel megspékelve).

2, enterprise kornyezetben sem minden esetben rakjak az adatokat SAN-ra. A SAN draga, 4 evig uzemeltettem SAN-t, ismerem az arakat.

Nem mindig, persze. De azért az a trend, hogy nagyobb, fontosabb cuccokat nem bíznak single gépekre. Két belsődiszkes gépből pedig nehéz oracle rdbms clustert faragni.

Lehet persze FC helyett két hosztos SAS-t használni (ami azért szívás, mert clusterpáronként külön doboz kell, több hosztot a SAS nem tud), vagy itt vannak az iSCSI-s dobozok is (ott jóval több a flexibilitás), de jellemzően mindegyik verzió arról szól, hogy az intelligens tárolóeszköz HW RAIDel, nem pedig a hoszt.
Shared storage esetén nem lakhat a RAID funkció a hosztokba dugott kártyán, ez alap.

3, egyetlen egy esetben nem kell raid vezerlo a lokalis gepbe: ha diskless.

Egy sima boot diszk tükrözésnél összemérhetőek az előnyök és hátrányok (ergó kétesélyes a mérlegelés eredménye), hogy érdemes-e HW RAID kártyát erre használni. Winfos alá mondjuk elfogadom, hogy kötelező, mert náluk még talán mindig kihívás egy boot diszk tükrözés SW-ből (a 2008 srv már tudja ezt rendesen végre?) De azért egy Solaris 7-8-9-10 lazán megugrotta ezt a feladatot 5-10 évvel ezelőtt is stabilan, a Linuxaimmal se volt sose gondom.

Velemenyem szerint a SW raid-del mind a rendszerek epitesekor, mind a hibajavitasakor, tehat uzemelteteskor sokkal tobb a gond, munka.

Az én tapasztalatom ezzel nem vág egybe. Mindkettővel tudnak szopások lenni, mondjuk tök másmilyenek. Ezért mérlegelendő, hogy melyik szopási eset mekkora valószínűséggel jöhet elő az adott környezetben.

Haaat ahogy visszaneztem mindenki az eredeti kerdest feszegette, hogy erdemes-e? es miert hw-s raid? A checksum szamolgatasa volt talan a fo erv valakinel. Es ennek megtamogatasara hoztak fel a halokartya peldajat. Innen valtottal at az enterprájsz-san, ... iranyvonalra. Ami megvallom oszinten nagyon izgalmas, de mostanaban mas iranyba fordult az erdeklodesem.
De ha valamikor ilyen problemaval kerulok szembe es elakadok, akkor biztos nagyon hasznos lesz az irasod es visszaolvasom.

Egyebkent igazad van, minden ket eselyes: vagy igen, vagy nem.

"Winfos alá mondjuk elfogadom, hogy kötelező, mert náluk még talán mindig kihívás egy boot diszk tükrözés SW-ből (a 2008 srv már tudja ezt rendesen végre?) "

Egy jó ideje már működik.

"De azért egy Solaris 7-8-9-10 lazán megugrotta ezt a feladatot 5-10 évvel ezelőtt is stabilan"

Azért még a 8-asnál is előfordultak hibák. Egyszer egy kihullott raid1 diszket offline cseréltem, és indításkor az üreset tükrözte rá a jóra.

Ha szoftos raided van, akkor meg látod mindet, mind terheli a cpu-t, memóriát, rendszerbuszt.

Vedd észre, hogy egy mai átlagos desktop pc cpu/memória/rendszerbusz kapacitása akkora, hogy ott ez gyakorlatilag nem számít. Valóban, 10-12 évvel ezelőtt, a 600MHz-es P3 idejében ez számított, ma, amikor quad core alatt nem vesz senki szervert, nem igazán.

Semmihez sem kell RAID vezerlo. Hasznaltam mar sw raid-et solaris 8-ban, hasznaltam hpux alatt, hasznaltam linux alatt, hasznaltam 10-es solarison zfs-ben, meg veritasszal is. Lehet RAID vezerlo nelkul elni. De azt sem szabad elfelejteni, hogy ez egy celhardver,amit erre talaltak ki, van rajta 256MB gyorsito. Nem csinaltam sebessegteszteket, meg osszahsonlitasokat, meg grafikonokat, de gyanitom, hogy legalabb eyg picit gyorsabb ez a vezerlo, mint a softveres raid. A masik, meg hogy sokkal kenyelmesebb a hasznalata.

Szerintem az ilyen esetekre találták ki a naplózó fájlrendszereket

"hw raid-nel ott bbwc"
Feltéve, hogy nem pont a kártya szált el. Nem mondanám, hogy otthon vagyok a témában, de szerintem a bbwc nem hiba ellen véd, hanem a plusz hibaforrást próbálja kiküszöbölni, hiszen nagy mennyiségű adatot tart a kártya cache-ben és egy áramszünet/rendszer leállás esetén több MB adat is lehet ami még nem került kiírásra. Ha jól tudom egyes kártyám elem nélkül, nem is engedik használni a memóriát (write back-re)

"Szerintem az ilyen esetekre találták ki a naplózó fájlrendszereket"
A fajlrendszer elkonyveli a naploba hogy az adat sikeresen ki lett irva, valojaban a raid tombre megsem kerult ra az adat, mert hibara futott, a fajlrendszer naploban tovabbra is az szerepel hogy a muvelet sikerult.