RAID, 2x500 - jaky zvolit?

[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(!).

[Petrik]

Ted me jeste napadl dalsi argument pro linuxovy MD RAID: kdyz uz srovnavame HW vs. SW RAID, je rozhodne ferove srovnavat varianty ktere stoji stejne penize, tedy budto sestavu s HW radicem za 10tis anebo bez nej ale o 10tis drazsi, coz je predevsim u levnejsich serveru pomerne hodne veliky rozdil, takze pak napr. misto RAIDu 5 muzeme nasadit MD RAID 10 (tedy neco podobneho 1E u IBM). Myslim ze je pak nade vsi pochybnost ktere reseni bude rychlejsi, ale i spolehlivejsi.
Pravda ale je, ze napr. vymena vadneho disku za chodu neni u linuxoveho MD RAIDu tak jednoducha, jako u HW, kde staci disk proste vymenit a hotovo, u MD se musi udelat diskove oddily a pomoci jednoho prikazu pridat do pole. Umim si ale predstavit skript ktery toto zvladne.

[Paolo]

Mě napadla jedna naprosto fatální nevýhoda MD RAIDu pod Linuxem oproti HW RAIDu: Server MUSÍ běžet na Linuxu, jinak nelze použít .