dinamikus raid

Szoval a cel az lenne, hogy olyan nas eszkozt tudjak kesziteni ami tud:
- kulonbozo meretu lemezeket kezelni
- elviseljen 1 lemez elveszteset adatvesztes nelkul (max 4. lemez)
- el tudja viselni ha lecserelek egy lemezt nagyobbra, detektalja es hasznat veszi a nagyobb particionak.
- minel jobban kihasznalja a lemezek kapacitasat.

Szoval keresgeltem egy darabig de nem sok mindent talaltam a linuxos softraid 10-rol es, hogy hogyan kezeli a kulonbozo
meretu lemezeket. Szoval igyekesztem mindent elrejteni a driverek szempontjabol kovetkezes kepen elegge idiota elmeleti megoldas szuletett:

Minden lemezt LVM segitsegevel felosztjuk 500Gs (vagy nagyobb/kisebb annyira nem lenyeges) szeletekre. 2 Lemez eseten
raid1-et 3+ lemez eseten raid5-be kotjuk. Ezek fogjak kepezni a nagy kotet alapjat. Ezt a raidet ugy kell kialakitani a
lemezeken, hogy egyik raid kotetnek se legyen 1-nel tobb eleme ugyanazon a lemezen. Ezeket az elso szintu raid eszkozoket
aztan raid0-ba kotjuk.

Mivel LVM-et hasznalunk amikor uj lemez erkezik "konyu" atrendezni ha jol ertelmezem az LVM lenyeget.

Ha egy lemez kiesik akkor elmeletileg meg mindig nem kellene adatot veszteni.

Nem tudom, hogy ez mit jelent adatatvitel/cpu hasznalat/orultseg/kivitelezhetoseg szempontjabol de gondolom majd ti megmondjatok:)

Amit meg nem tudok, hogy a raid1->raid5 konverziot, hogy kellene ertelmesen megoldani amikor 2 lemezrol 3 lemezre valt
az ember. De ezen majd gondolkozok, ha ezen otletem miatt nem dobaltok meg tojassal vagy eppen ami kezbe akad:)

( cabal v | 2010. 08. 25., sze – 16:12 )

Mindenképpen magadnak akarod csinálni? Mert ha nem, akkor választhatsz innen is. Ezek pl. tudnak RAID level migrationt és RAID expansiont is. (Legalábbis a leírásuk szerint.)

"A +1 az a proletárlájk."

( hrgy84 | 2010. 08. 25., sze – 16:16 )

O, a 3. pont egy kicsit el van rugaszkodva a valosagtol, meg igy mindentol. A lemezcsere meg okes, de a RAID eseteben nem (vagy csak nagyon ganyolosan) lehet megoldani, hogy kulonbozo meretu lemezparokbol tukrot vagy stripe-t csinaljon, eppen a RAID tulajdonsagaibol kifolyolag: tukor eseteben nem lehet nagyobb a raid kotet mint a paros legkissebb eleme, hiszen akkor lennenek olyan adatok, amik nincsenek tukrozve. Raid0 eseten pedig megint ugyanez van, lennenek olyan adatok, amik csak az egyik lemezrol jonnek. Ez igy hulyeseg.

Azt meg lehet csinalni, hogy tobb raid1-et csinalsz, es ezeket kotod lvm-be. Ha cserelsz, akkor ugyanakkora mereture cserelsz. Elvben meg lehet azt csinalni, hogy a raid tomb alatt mindket lemezt kicsereled nagyobbra, es akkor elmeletileg nagyobb tud lenni a raid tomb, max mdadm-mal kell valamit varazsolni, hogy lassa a nagyobb meretet. De altalanos ervenyu szabaly, hogy barmilyen raid-et csak egyforma lemezekbol allitunk ossze, ezt nem tudod megkerulni, ez a technologia lenyegebol fakad.

Ami az LVM-es megoldasodat illeti, en azt mondom, ezt igy NE. Tul azon, hogy baromi lassu lesz, meg raadasul instabil is lesz, mert az LVM koteteket nem igazan erre talaltak ki. Maga a linuxos LVM is tud mirroringot, esetleg azon a vonalon elindulhatsz, de a most felvazolt tervet surgosen ejtsd el a kuka felett.
-- 


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

de ha van 2 500Gigas lemezed meg 1 1Terrasod akkor tudnal 1 Terrat hasznalni. Ha hozzaloksz egy masik 2 Terrasat akkor mar rogton 2 terrat tudnal hasznalni. Aztan ha lecsereled az egyik 500Gigast mondjuk egy 1.5 Terrasra akkor megint tudnal hasznalni belole mondjuk ugy 2.5 Terrat ha raid1-et hasznalsz az elso szinten. De akkor mar lehetne raid5 is az elso szinten es akkor rogton jobban josz ki. Majd holnap/hetvegen osszeutok valamit aztan tesztelgetek. Kar, hogy csak laptop vinyok allnak most rendelkezesre.

Erdemes megnezni itt: http://www.drobo.com/resources/drobocalculator.php

1.) "Terras" lemez nem létezik. :)

2.) A linkelt drobo calculator-ba ha bedobálod a lemezeket, akkor az "JBOD"-szerűen összefűzött lemeztömb-méreteket mutat.

Ebbe gondolj bele:

"de ha van 2 500Gigas lemezed meg 1 1Terrasod akkor tudnal 1 Terrat hasznalni."
Hogy lesz ebből RAID?
Mit tükrözöl mire?
Később írod, hogy "raid1". Hogy fog ebből összeállni bármilyen raid1??

Egyébként ezt a funkcionalitást meg lehet csinálni zfs -sel, ahogy leírtam.
Csinálsz egy nagy pool -t az összes lemezből, aztán beállítod, hogy pl. copies=2. Ez azt jelenti, hogy minden fájlról két példánít tart a zfs, transzparensen, két külön eszközön.
De ez nem raid, viszont az általad elvárt funkcionalitást nyújtja.
(Lehet zfs-sel RAID-et is csinálni egyébként, de nem így, hogy 2db 500 gigás + 1 db terás lemezből csinálsz egy 1 TB-os RAID1 tömböt...)

1) de azert erted mit akarok mondani nemde:P

2) Az lehet de elviseli az egyik lemez elveszteset adatvesztes nelkul.

Mint emlitettem az eredeti hozzaszolasban ebbol raid ugy lesz, hogy felosztod szeletekre, majd a szeletkbol raidet csinalsz, majd ezt raid0-val vagy LVM-el osszefuzod. Szoval igy...

A ZFS az lehetseges megoldasnak tunik csak annyi a problema, hogy ott ugye 1+1 redundancia van -> felezodik az elerheto tarhely. De ennek utanna kell olvasni, szoval most egy darabig researching:)

"1) de azert erted mit akarok mondani nemde:P"

Ja, a Földdel akarsz valamit kezdeni, de nem jöttem még rá, hogy mit. :P

"2) Az lehet de elviseli az egyik lemez elveszteset adatvesztes nelkul."

Ha JBOD-szerűen vannak összefűzve, akkor a fenti kijelentés nem igaz.

"A ZFS az lehetseges megoldasnak tunik csak annyi a problema, hogy ott ugye 1+1 redundancia van -> felezodik az elerheto tarhely."
Mégis, hogy akarod megoldani egy lemez elvesztését úgy, hogy az adatok csak egy példányban léteznek?
(Van egyébként raidz és raidz2 paritásos móka is, raidz esetében egy lemeznyivel kevesebb tárhelyed lesz, raidz2 esetén pedig két lemeznyivel lesz kevesebb. Pont, mind RAID5 és RAID6 esetén. Viszont raidz/2 -t nem tudsz bővíteni, RAID5/6-ot pedig igen.)

De mindegyik kicsit ki kell cserélni nagyra, hogy a tömb kaapcitása is megnöjjön.

Az egesz lenyege az lenne, hogy ezt ne kelljen csinalni. Ez elsodlegesen otthoni hasznaltra kell amire egy JBOD is tokeletes lenne csak akkor nincs "kenyelmes" lemezcserelgetes es para van ha lemezt vesztunk....

( trey | 2010. 08. 25., sze – 17:28 )

"Szoval a cel az lenne, hogy olyan nas eszkozt tudjak kesziteni ami tud:"

tltr

Ha Linux alapú storage kell egyszerűen, akkor OpenFiler. Többet is használok élesben ultragagyi hardverekből összerakva, VMware ESX-szel. Működik. Hogy neked megfelel-e, azt le tudod ellenőrizni:

http://www.openfiler.com/

--
trey @ gépház

( blajo | 2010. 08. 25., sze – 22:06 )

Mivel csak utaltal ra, hogy Linuxot szeretnel, erdemes megemliteni a zfs-t freebsd vagy opensolaris (R.I.P.) alatt...

zfs +1.

Csinál egy nagy pool -t (nem raid), és beállítja, hogy copies=2.
Aztán gyakorlatilag van egy RAID1 szerű valamilye, igaz nem RAID1, de a lényeget tekintve felfoghatjuk annak is.
Aztán fog tudni lmezeket ki-be rakosgatni, különböző méretűeket is akár.

http://docs.sun.com/app/docs/doc/816-5166/zfs-1m?l=en&n=1&a=view:
copies=1 | 2 | 3
.. The copies are stored on different disks, if possible. ...Changing this property only affects newly-written data.

Szoval egyaltalan nem garantalt, hogy azt fogja csinalni amit kell, es nem ir semmit arrol, hogy mi van akkor ha kicserelek egy lemezt nagyobbra akkor majd o elkezd masolgatni mar felirt adatokat. Gyanitom, hogy nem fogja megtenni.