RAID, 2x500 - jaky zvolit?

[jan555]

...

Když si najdeš chvíli na otestování, bude to super, už tenhle 3ware by měl bohatě stačit. (akorát je potřeba benchovat i/o operations, přímo DB, atd. a ne throughput nebo read, ale to je jasné)

My jsme tohle před cca 3-4 lety testovali na snad ideálním prostředí - nějakém malém IBM x-series s integrovaným řadičem s dedikovaným slotem právě na externí RAID (základní přídavná logika ServeRAID s bb cachí asi za 15K) a k tomu 2 sety stejných disků. (takže jsme efektivně eliminovali všechno mimo řadiče) Nepamatuji se už, co to bylo za server, řadič, disky ani Linux, výsledky jsem nearchivoval, takže to není žádný report, spíš jen pro zajímavost. Díky tomu, že jsme měli vlastní lab pro generování multi-user loadu, tak jsme viděli rozdíly opravdu velmi snadno.

Ad ten 1E level - on má různé implementace a např. Adaptec je konzervativní a gain tam moc není (a hlavní výhodou je tak možnost lichého i sudého počtu disků), naopak třeba na IBMce je díky principu zápisu a hlavně čtení možné dosáhnout read performance v úrovni level 0. Nechci to tu sáhodlouze rozepisovat, snadno popis najdeš. S hodně disky, dobrým řadičem a nízkými požadavky na bezpečnost je fakt super výkonný 1E0 (stripe 1E), pokud bys měl řadič a možnost, tak to pro zajímavost zkus. Jinak 1E a 1E0 jsou opravdu dost specifické levely, ne tak 5EE, ten kdo může, tak by měl používat místo level 5 - stejně disků, stejně parity, stejná bezpečnost, vyšší výkon. (jen ho moc řadičů imho ještě pořád neumí)

Ad RAID3 - nerozumím moc té vaší diskuzi ... RAID3 byl odjakživa specifický tím, že je to BYTE-LEVEL. Díky tomu měl také odjakživa nic moc read, slabý write a vyloženě tragický random write a rebuild (a obecně vůbec random operace). To je taky důvod, proč se dávno nepoužívá, tohle co popisujete by imho odpovídalo specifikaci RAID4, která byla dřív než pořádně začala spláchnutá level 5. Máte opravdu v Linuxu něco, co se jmenuje RAID3 a funguje to jinak?

[Petrik]

http://en.wikipedia.org/wiki/Non-sta...EE_and_RAID_6E
To je ono? 5EE tedy podle toho odkazu potrebuje o jeden disk navic a prezije pouze ztratu jedineho disku, takze mi to zrovna jako vyhra nepripada. Navic mi neni jasne, z jakeho duvodu to je rychlejsi... vysvetlis to prosim? dekuji

Jen tak mimochodem: The Linux software RAID code (often called "MD" for "multi-device") is a longstanding feature of the kernel. RAID users appreciate its robustness, configurability, and the fact that it performs well; better performance than that achieved with hardware RAID controllers is not unheard of.
http://lwn.net/Articles/169140/

Jinak 1E a 1E0 jsou opravdu dost specifické levely, ne tak 5EE, ten kdo může, tak by měl používat místo level 5 - stejně disků, stejně parity, stejná bezpečnost, vyšší výkon. (jen ho moc řadičů imho ještě pořád neumí)

[jan555]

http://en.wikipedia.org/wiki/Non-sta...EE_and_RAID_6E
To je ono? 5EE tedy podle toho odkazu potrebuje o jeden disk navic a prezije pouze ztratu jedineho disku, takze mi to zrovna jako vyhra nepripada. Navic mi neni jasne, z jakeho duvodu to je rychlejsi... vysvetlis to prosim? dekuji

To není problém. 5E vylepšil level 5 o integrovaný hot-spare (to je ten - obvykle - jeden dedikovaný disk navíc, který na firemních RAID5 leží vedle v on-line idle), čímž zvýšil pochopitelně výkon (jako jde nahoru každým přidaným diskem do RAID5), než se rozšířil level 5E, byl vylepšený IBMkou na 5EE, který se oproti 5E liší tím, že spare je distribuovaný přes fyzické disky rovnoměrně a nikoliv na konci jako u 5E. Že level 5EE přežije výpadek pouze jednoho disku je zavádějící informace, kterou špatně interpretují sami výrobci. Je to tak, že při výpadku jednoho disku na 5EE přijdete o spare a z 5EE se automaticky stane standardní level 5, který přežije výpadek dalšího jednoho disku. Takže ano, 5EE přežije výpadek pouze jednoho, ale pole s 5EE přežije výpadek dvou, tak je to . (pro reálnou představu je to tak, že RAID5EE z 10 disků disponuje 8/10 celkové kapacity pro data, 1/10 využívá pro paritu a 1/10 pro souměrně distribuovaný spare)

K tomu předešlému postu - mám teď málo času a je to na trošku déle, takže jak se k tomu dostanu (večer/zítra), pokusím se podrobně vysvětlit, co svými úvahami přesně myslím a kam mířím. Bylo by fakt fajn, kdyby to mohl někdo rozdělit a udělat nové téma ...

[Petrik]

V tom odkazu pisi neco jineho:
If one drive fails in a RAID 5E/5EE array then the array is 'compressed' and re-built (re-striped) into a standard RAID 5 array. This process can be very intensive on the drive I/O if the array is made up of less than 10-disks and the process may take several hours depending on the speed of the drives. Once the failed drive is replaced, the array is this time 'decompressed' and re-built (re-stripped) back into a RAID 5E/5EE array. The process may take several hours depending on the speed of the drives. The process can also be very intensive on the drive I/O if the array is made up of less than 10 disks. During the 'compressing' and 'decompressing' stages the array is at risk of a second disk failure as the array is not protected by redundancy during those stages.

Prechod z 5EE na 5 neni ihned a behem toho prechodu neni pole redudantni. Pokud to je pravda, tak bych radeji volil sice pomalejsi, ale spolehlivejsi RAID 6. Kazdopadne tedy beres zpet tvrzeni, ze 5EE potrebuje stejne disku jako 5?
Jinak to co IBM nazyva 1E se v linuxu nazyva 10, ktery navic vyborne skaluje pri velkem I/O zatizeni. Je to v tom odkazu take.

To není problém. 5E vylepšil level 5 o integrovaný hot-spare (to je ten - obvykle - jeden dedikovaný disk navíc, který na firemních RAID5 leží vedle v on-line idle), čímž zvýšil pochopitelně výkon (jako jde nahoru každým přidaným diskem do RAID5), než se rozšířil level 5E, byl vylepšený IBMkou na 5EE, který se oproti 5E liší tím, že spare je distribuovaný přes fyzické disky rovnoměrně a nikoliv na konci jako u 5E. Že level 5EE přežije výpadek pouze jednoho disku je zavádějící informace, kterou špatně interpretují sami výrobci. Je to tak, že při výpadku jednoho disku na 5EE přijdete o spare a z 5EE se automaticky stane standardní level 5, který přežije výpadek dalšího jednoho disku. Takže ano, 5EE přežije výpadek pouze jednoho, ale pole s 5EE přežije výpadek dvou, tak je to . (pro reálnou představu je to tak, že RAID5EE z 10 disků disponuje 8/10 celkové kapacity pro data, 1/10 využívá pro paritu a 1/10 pro souměrně distribuovaný spare)

K tomu předešlému postu - mám teď málo času a je to na trošku déle, takže jak se k tomu dostanu (večer/zítra), pokusím se podrobně vysvětlit, co svými úvahami přesně myslím a kam mířím. Bylo by fakt fajn, kdyby to mohl někdo rozdělit a udělat nové téma ...

[jan555]

Kazdopadne tedy beres zpet tvrzeni, ze 5EE potrebuje stejne disku jako 5?

Ano, potřebuje stejně disků jako level 5 ve funkčně stejné konfiguraci. Při výpadku se chová také stejně jako RAID5 s hot-sparem. Vůbec jsem neuvažoval s tím, že by někdo používal RAID5 s více disky bez alespoň jednoho hot-sparu, ale evidentně jsem se zpletl. Nikde jsem netvrdil, že je něco "hned", na RAID5 zvlášť není "hned" nic.

Jinak to co IBM nazyva 1E se v linuxu nazyva 10, tedy RAID-1 i na lichem poctu disku ktery navic vyborne skaluje pri velkem I/O zatizeni. Je to v tom odkazu take.

Nevím, co se jak nazývá v Linuxu (jakpak je to s tím RAID3?), ale tomuhle už vůbec nerozumím - pokud se v Linuxu nazývá 1E 10, tak jak se proboha nazývá standardní 10? Fakt nechápu, jestli je Linux natolik speciální, že nemůže ani respektovat standardní značení a specifikace a my se tady pak bavíme o něčem, co se jmenuje např. "RAID5", "RAID10", atp. a přitom každý mluvíme o něčem jiném? Jinak hlavní gain u 1E v podání např. IBM je v schopnosti readu a la RAID0, pokud to tak má Linux, tak dobré - většina ostatních řadičů s podporou 1E touhle funkčností neoplývá.

[Petrik]

No vidis a ja jsem zase na mnoha mistech cetl, ze nez provozovat RAID5 se sparem je lepsi RAID6, protoze je proste vyrazne spolehlivejsi. Samozrejmne je take pomalejsi...

RAID3 v linuxu zrejmne neni, ale je to natolik obsolete, ze je to asi jedno. Kdyz jsem mluvil o moznosti udelani pole s dvema raptory ve stripu pro paritni disk, tak jsem mel na mysli RAID4, to jsem se spletl.
Standardni RAID 10 se v linuxu nazyva 1+0 a to z toho duvodu, ze musis opravdu nejdrive udelat dva mirrory a az pak z tech mirroru stripe, tedy pokud se nepletu. Jinak co to presne je najdes v te wikipedii, podle me to je presne totez co 1E.

Ano, potřebuje stejně disků jako level 5 ve funkčně stejné konfiguraci. Při výpadku se chová také stejně jako RAID5 s hot-sparem. Vůbec jsem neuvažoval s tím, že by někdo používal RAID5 s více disky bez alespoň jednoho hot-sparu, ale evidentně jsem se zpletl. Nikde jsem netvrdil, že je něco "hned", na RAID5 zvlášť není "hned" nic.

Nevím, co se jak nazývá v Linuxu (jakpak je to s tím RAID3?), ale tomuhle už vůbec nerozumím - pokud se v Linuxu nazývá 1E 10, tak jak se proboha nazývá standardní 10? Fakt nechápu, jestli je Linux natolik speciální, že nemůže ani respektovat standardní značení a specifikace a my se tady pak bavíme o něčem, co se jmenuje např. "RAID5", "RAID10", atp. a přitom každý mluvíme o něčem jiném? Jinak hlavní gain u 1E v podání např. IBM je v schopnosti readu a la RAID0, pokud to tak má Linux, tak dobré - většina ostatních řadičů s podporou 1E touhle funkčností neoplývá.

[Fox!MURDER]

Když si najdeš chvíli na otestování, bude to super, už tenhle 3ware by měl bohatě stačit. (akorát je potřeba benchovat i/o operations, přímo DB, atd. a ne throughput nebo read, ale to je jasné)

mno uvidime ... budu tu mit dva identicke stroje s identickymi disky ... tak do jednoho ten 3ware zkusim soupnout a do druhyho ne ... snad se ten pulden na to nekde vysetri .... kdyz ne, tak se omlouvam ...

Ad RAID3 - nerozumím moc té vaší diskuzi ... RAID3 byl odjakživa specifický tím, že je to BYTE-LEVEL. Díky tomu měl také odjakživa nic moc read, slabý write a vyloženě tragický random write a rebuild (a obecně vůbec random operace). To je taky důvod, proč se dávno nepoužívá, tohle co popisujete by imho odpovídalo specifikaci RAID4, která byla dřív než pořádně začala spláchnutá level 5. Máte opravdu v Linuxu něco, co se jmenuje RAID3 a funguje to jinak?

http://lists.freebsd.org/pipermail/c...st/030109.html
ono kdyz o tom premejslim z druhy strany, tak to, ze se cte jen z datovych disku je vpodstate vyhoda ... zvlast u mensiho poctu disku ... jde o to, ze pokud z raidu5 chci precist 10 po sobe jdoucich bloku, tak musim bud precist vsechna data vcetne parity, nebo po kazdem cteni jeden z disku seekovat, protoze preskakuju nectenou paritu ... to prvni mi zbytecne zere sbernici, to druhe uz z principu je pomale ...



ad. RAID10/01 ...
mirror stripu se nedela hlavne kvuli tomu, ze by se muselo syncovat cely pole, kdezto pri stripu mirroru se syncuje jen jeden mirror

[jan555]

http://lists.freebsd.org/pipermail/c...st/030109.html
ono kdyz o tom premejslim z druhy strany, tak to, ze se cte jen z datovych disku je vpodstate vyhoda ... zvlast u mensiho poctu disku ... jde o to, ze pokud z raidu5 chci precist 10 po sobe jdoucich bloku, tak musim bud precist vsechna data vcetne parity, nebo po kazdem cteni jeden z disku seekovat, protoze preskakuju nectenou paritu ... to prvni mi zbytecne zere sbernici, to druhe uz z principu je pomale ...

Popravdě těm výsledkům zvlášť a cestě k nim zvlášť dobře nerozumím. RAID3 je prostě v reálu při některých operacích tragicky pomalý, mimoto má vzhledem k principu funkce řádově vyšší nároky na hardware prostředky než snad jakýkoliv single-level RAID. Pokud Petrik uvádí, že mu RAID5 sežere 10-30% procesorového času, tak bych chtěl vidět, co by se stalo v odpovídající konfiguraci s RAID3 ... Jinak fakt pozor na pojmy - tuším, co myslíš "blokem", ale RAID3 není o žádných blocích (to se změnilo evolucí na RAID4 a žádný další už skutečně není tak low-level jako RAID3), RAID3 je opravdu natvrdo byte-level a z toho plyne ta pomalost a šílené nároky na prostředky.

[Fox!MURDER]

Popravdě těm výsledkům zvlášť a cestě k nim zvlášť dobře nerozumím.

jasne, jedna se o synteticky benchmark ... ale zas tak moc v nem nevidim problem ...

RAID3 je prostě v reálu při některých operacích tragicky pomalý, mimoto má vzhledem k principu funkce řádově vyšší nároky na hardware prostředky než snad jakýkoliv single-level RAID.

mno, zas tak tragicky pomaly, podle toho benchmarku, nevypada ...

[jan555]

Tím, že jsem říkal, že tomu moc nerozumím, jsem fakt nechtěl říct, že je to špatně, říkal jsem tím jen, že tomu prostě moc nerozumím . (a pokud bys mi tuhle metodiku mohl v krátkosti osvětlit, budu rád) Linux není můj chleba a z toho, co tam je, neumím vyčíst pro mě potřebné. Nicméně ...

... RAID3 JE tragicky pomalý, proto taky skončil hned, jak mohl a je náročný na hardware, proto ho taky podporovalo jen pár mid-class řadičů, ale většinou až řadiče z nejvyšších kategorií. (stačí si tu režii jen představit ...) Ten princip je jasný a zrovna tohle lze brát snad i jako fakt, tipuji, že je to konstatováno i ve všech overview a elaborátech o RAIDech. Ovšem nemůžu vědět, jestli na Linuxu nefunguje jinak (ale nevypadá to).

[Fox!MURDER]

Tím, že jsem říkal, že tomu moc nerozumím, jsem fakt nechtěl říct, že je to špatně, říkal jsem tím jen, že tomu prostě moc nerozumím . (a pokud bys mi tuhle metodiku mohl v krátkosti osvětlit, budu rád) Linux není můj chleba a z toho, co tam je, neumím vyčíst pro mě potřebné. Nicméně ...

ve zkratce (nekdo mi to v mailinglistu vysvetloval asi 2 roky zpet) tenhle benchmark funguje tak, ze uzivatel si pomoci utility vygeneruje soubor s nahodnymi pristupy na disk a ty pote pomoci jine utility na disku provadi v n procesech paralelne. tim je zajistena jak nahodnost, tak uplna reproducibilita testu ...

This utility can be used to test performance of storage devices.
First, one need to generate file with I/O operations:

# set mediasize=`diskinfo /dev/<device> | awk '{print $3}'`
# set sectorsize=`diskinfo /dev/<device> | awk '{print $2}'`
# raidtest genfile -s $mediasize -S $sectorsize -n 50000

It will generate test which contains 50000 I/O requests with random
size and random offset. Size is a multiple of sectorsize, but less than or
equal to 128kB (maxium size of I/O request). I/O request type (READ or WRITE)
is random as well.
All test data are stored in 'raidtest.data' file in current working directory.

To run test, one should type:

# raidtest test -d /dev/<device> -n 10

This command will read test data from 'raidtest.data' file, run 10 processes
which will be used to send requests to the given device in parallel.
When test is finished you will see statistics:

Bytes per second: <x>
Requests per second: <y>

If you compare performance of two storage devices, use the same data file!

mimochodem, tohle v te dobe jeste taky nebylo k dispozici

-r Use parity component for reading in round-robin fashion.
Without this option the parity component is not used at
all for reading operations when the device is in a com-
plete state. With this option specified random I/O read
operations are even 40% faster, but sequential reads are
slower. One cannot use this option if the -w option is
also specified.

... RAID3 JE tragicky pomalý, proto taky skončil hned, jak mohl a je náročný na hardware, proto ho taky podporovalo jen pár mid-class řadičů, ale většinou až řadiče z nejvyšších kategorií. (stačí si tu režii jen představit ...) Ten princip je jasný a zrovna tohle lze brát snad i jako fakt, tipuji, že je to konstatováno i ve všech overview a elaborátech o RAIDech. Ovšem nemůžu vědět, jestli na Linuxu nefunguje jinak (ale nevypadá to).

erm, nechci byt drzy, ale ponekud se opakujes ... ano, tvrdis ze je tragicky pomaly, mas to podlozene nejakou teorii, ktera mozna je, mozna neni az tak spravna ...

[jan555]

Díky za vysvětlení. Takhle nevidím u toho testu žádný zvláštní problém až na ty lineárně spuštěné procesy. Rozumím tomu správně, že to samé je spuštěno in-time 10x? (takže je to defacto 10 stejných concurrent i/o operací?) To by bylo trošku nestandardní, každopádně bych radši viděl simulaci random i/o operací v mnohem větším počtu userů, v tomhle předpokládám opravdu hodně začaruje cache ...?

erm, nechci byt drzy, ale ponekud se opakujes ...

Drzý nejsi a když budeš chtít být, tak můžeš - však nejsem Tvůj strýček .

ano, tvrdis ze je tragicky pomaly, mas to podlozene nejakou teorii, ktera mozna je, mozna neni az tak spravna ...

Ona to není teorie, mám teď fakt dost málo času na skládání podkladů, pokud si to nechceš najít, tak Ti to na oplátku jak budu mít delší chvilku dodám. A mimo často pochybného read-performance se hlavně připrav na write testy - pokud jsem použil slovo tragický výkon, tak to v případě read operací možná mělo být pouze "špatný" a "tragický" u write - tam padne level 3 kompletně na hubu a může být dokonce i méně výkonný než single-disk(!).