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

 ( aspirin | 2011. július 25., hétfő - 9:56 )

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.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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#ZFS_Configuration_Example_.28x4500_with_mirror.29

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

Értem. De egyébként mire jó ez?
Én inkább +1 lemez és raid 5-öt csinálnék. Igaz megy 3 lemezzel is.

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.

rendes kartyaval csinalj raid4dp -t, az gyors es biztonsagos, mindehhez egy centi zfs nem kell.

aztán a nagy biztonságban ne felejts el új kártyát vadászni (nem baj ha már nem gyártják) amikor az tönkremegy, ja és élvezd a driver általi OS-hez kötöttség előnyeit

Normális RAID-kártya az elődjeinek a tömbjeit is fel tudja szedni - tapasztalatból mondom.

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

Egy hw életciklusa max. 3-5 év - legalábbis pécés vonalon - ha meg 10+ évre tervezel, akkor a megbízhatóság/állandóság okán bizony olyan hardvered lesz, amihez így se, meg úgy se fogsz a sarki boltban alkatrészt venni...

... srácok annyival egészíteném ki - a hupon továbbolvastam - hogy ne százé vegyünk hanem kétmillióért, mert az TUTI örökélet!!

lazán kapcsolódik

Valaki indíthatja a gabume.me domain regisztrációját. :)


suckIT szopás minden nap! Perl script 11 millió forintért

ITT kérlek meg, hogy tartsd magadban mindazt, amit az én hozzászólásaimra válaszolnál. Szerintem nem csak engem nem érdekel az agyhiányos böfögésed.

zeller, ahelyett hogy a vérforraló arcátlanságodat (vagy akár a hardverfüggőséged vélt előnyeit) önmagad megvédenéd, most egy másik topikban keresel pajtikat?

mit keresel te a hupon, azt nem értem. ZFS-hez valami?

Három diszkből "többségi szavazással" automatice ki lehet szórni azt, ami hibás - nempécé/nemlinux kategóriában ez természetes dolog... (Hint: megbízhatóság mindenek felett)

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.

Melyik másik raid megoldásban van korlát (csak hogy említed hogy a zfsben nincs)?

ööö... nemtom... de a zfs-ben biztos nincs :) (Mással raid megoldással nem dolgoztam sosem)
<-------
You can't grep on dead trees.

RAID10 ?

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

ja-ja, csak az minimum 4 vinyó, de mint írta, a +1 vinyó megoldható. Teljesítményben szvsz jobb megoldás lenne. A hibatűrés pedig 1, optimális esetben 2.

A raid10-ra +1, fosta már össze nálam magát egy 4 diszkes raid5 tömb. Ebben az esetben a legoptimálisabb a raid10 lenne úgy gondolom. Esetleg még raid6, de mivel 4 diszk van max. úgy ugrana a spare.

Hamár a RAID10 szóba került.
Melyik a jobb megoldás, RAID10 vagy 2xRAID1 és az fölött LVM?

Melyik a jobb autó: a Ferrari vagy a Lamborghini?

Ferrari

Akkor ugy kerdezem, a RAID10 esetleg nyujt sebessegben vagy valamiben plusszot 2db RAID1 + LVM-hez kepest? Mert rugalmassag tekinteteben tuti az LVM-es verzio a jobb.

Biztos vagy benne, hogy ez zfs eseten is igaz?

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)

De csinál stripe-ingot.
lvcreate -i3 ...

Nem tudom mennyire hatékony az MD stripe-hoz képest, de tud ilyet.

... és tényleg! megint okosabb lettem. :)

A RAID10 és felette LVM gyorsabb, mint a 2db RAID1 LVM -el összefűzve, tapasztalatom szerint (iozone -al emlékeim szerint az első eset 12-14%-kal volt gyorsabb, ext3 filerendszerrel)

----
올드보이
http://molnaristvan.eu/

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.

pont ezért kéne nektek a raidz2. dupla paritás.

Igen, de ahhoz több diszk is kell, amire nem nagyon van pénz...

...jó-jó, tudom, én kérdeztem, hogy mit ajánlanátok... :D
<-------
You can't grep on dead trees.

"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.

Raidz2

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.

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.

ZFS-hez nem kell RAID vezérlő.

Jó is a szoftos réd... Pláne i/o-ban :-P A checksum-ot ne a CPU számolgassa már, ha nem muszáj...

nyugodtan terjeszd a hülyeséget, annál hamarabb omlik össze az IT ipar :)

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.

én egyetértek, mindenki vegyen rédkártyát! ha lehet, linux alá! vissza 1995-be!

Nem ezt mondtam, hanem azt, hogy ahol fontos az egyenletes, magas teljesítmény és a megbízható működés, ott bizony a hw-raid jobb választás.

Sajna az Oracle(Sun) erről nem hallott. :(

kulcsszavak: PCI-e, MSI-X, baromisokcoreomvanuresen :)

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...

> egy core csak a checksum-okat számolgatja

:DDDDDDDDDDD

hupexpertized!®

"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...

Nem tudom mit ertesz az atlagos enterprájsz kornyezet alatt, nalunk minden gepben ez van.

(minden gep: sok. Eleg sok.)

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.

A vl nevbol szamomra nem derul ki semmi. Bar biztos a muveletlensegem okan.

Maradjunk a szerintednel:) (de ez innentol elegge off)

Akkor mast tapasztaltunk. Bar az ibm serverraid-ekkel van gond, mert felpuposodik az aksijuk es elgorbitik a kartyat. Szoval megiscsak van vele gond.

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.

raid5-nel azt a borzasztoan szamolasigenyes checksumot XOR-nak hivjak :-)

--
NetBSD - Simplicity is prerequisite for reliability

meg egy blokk írásához egyet beolvasni és kettőt kiírni...

hw raidnek nem kell ilyet csinalnia?

--
NetBSD - Simplicity is prerequisite for reliability

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.

SW RAID-et kell használni HW RAID kártyán, BBU-val. Az a 256 MB pedig ma már inkább 1/2 GB, akksis RAM, vagy flash.


suckIT szopás minden nap! Perl script 11 millió forintért

a BBWC-n kivul latod mas elonyet a HW raidnek?

A ZFS mellett nem. Annak már csak a checksumozása miatt is érdemes abban a rétegben használni a redundanciát.
Az viszont saját (és cimbik) tapasztalat, hogy a BBWC nagyon sokat tud számítani a ZFS-nek (is).


suckIT szopás minden nap! Perl script 11 millió forintért

a, volt egy marek RAID kartyam 256MB rammal, aksi nelkul. Ezeket osztogattam szet
b, volt osszesen ketto darab amibe 512MB ram volt es aksi, ezeket nem osztogattam szet

Egyikre sem modntam, hogy vacsi uj, 2-4 eves darabok. De ingyert szerintem meg igy is jo bolt.

az hogy hw raid gyorsabb-e az vita targya. soft-raid eseten erdekes eset ha rendszerhiba eseten nem sikerul az iras muveletet vegrehajtani ezert a paritas hibas lesz. hw raid-nel ott bbwc.

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.

A szándékot minden estre köszönjük! :)
<-------
You can't grep on dead trees.