Dotaz: Rychlost md RAID10 z 12 disků

[Zdeněk Zámečník]

Nemáte někdo zkušenosti s větším sw RAIDem 10 v Linuxu?

Použil jsem disky WD5003ABYX, jeden samotný disk zvládá sekvenční zápis i čtení rychlostí 138MB/s. Postavil jsem z 12 těchto disků RAID10 a z celého pole dostanu rychlosti 309MB/s při zápisu a 775MB/s při čtení.

Testy jsem prováděl takto:

dd if=/dev/zero of=/dev/md1 bs=1M count=10000
hdparm -t /dev/md1

Ty výsledky se mi zdají celkem slabé. Použil jsem řadič Areca ARC-1320-8I, který běží na PCIe 2.0 x8. Všechny disky jsou připojeny přes jeden port tohoto řadiče a ten by měl zvládat rychlosti 6Gbit/s.

Je takto pomalý zápis normální nebo máte nějaký nápad, kde hledat úzké hrdlo? Jestli to chápu dobře, tak md raid by měl v tomto případě stripovat nad šesti zrcadlenými dvojicemi disků, tudíž by se zde mělo teoreticky dosáhnout šestinásobku rychlosti zápisu jednoho disku.

Odpovědi

[Milan Roubal]

no RAID10 znamena, ze zapis se provadi na 2 disky soucasne zatimco cteni jen z jednoho. Tedy zapis musi probihat polovicni rychlosti proti cteni. Pokud pocitame 6GBit/s jako propustnost sbernice, tak pri soucasnem zapisu na 2 disky to dava 3GBit/s pro zapis, coz je 384 MB/s. Pri zapisu 309 MB/s to dava vyuziti pres 80 procent, coz je dost slusne. Pri cteni to vypoctem vychazi na maximum 768 MB/s, tam to vypada ze to jede dokonce nad teoretickem maximu. Urcite by bylo dobre vyzkouset misto RAID10 RAID5, tam by se mela rychlost zapisu vysplhat nekam k tem 700 MB/s pri zapojeni vsech 12 disku.

[Zdeněk Zámečník]

No jo, to mě vůbec nenapadlo nad tím přemýšlet takto... No aspoň budu při příštím nákupu chytřejší. Z RAID5 (RAID6) mám strach, protože ty stroje budou celkem hodně vytížené (zejména jde o provoz db PostgreSQL a MySQL). Každopádně moc díky za dobrou myšlenku.

[Milan Roubal]

Z RAID5 bych strach rozhodne nemel. Jinak je dobre si tu masinu promyslet prave z tohoto pohledu, mozna bude stacit pridat dalsi radic (spise radice), na kazdy z nich povesit nekolik disku. Je potreba, aby disky v RAID1 byly kazdy na jinem radici. Pak se vykon zvedne nekolikanasobne. Jinak doporucuju ten RAID5 alespon vyzkouset, urcite zjistis, ze ten z toho vykonu te masiny neubira temer nic. Druha dulezita vec je, kolik nezavislych linek zvladne zakladni deska, zda se o vykon nebudes delit na nejakem slotu s gigabitovym ethernetem a podobne. Je take dobre zvazit, ktery procesor pak obsluhuje IRQ z ktereho radice, to je dobre rozlozit pres jednotliva jadra.

[Zdeněk Zámečník]

Z RAID5 mám obavy spíše z důvodu možnosti výpadku pouze jednoho disku, což je u většího počtů disků v poli celkem problém. Co jsem různě hledal o RAID6, tak to také není uplně výhra (co se týče rebuildu). Ale asi to zkusím, láká mě už jen snadná rozšířitelnost pole, kterou v linuxu RAID10 stále postrádá.

Další řadič už do toho nedostanu, resp. bych si nepomohl. Ty disky jsou totiž pověšené na SAS2 sběrnici se single expanderem. Konkrétně se jedná o tento case. Jsou to první větší stroje, které jsem dával dohromady, takže je to moje první zkušenost s něčím podobným. Pokud se pletu, tak mne opravte. Ten backplane má sice 3 SAS porty, ale jestli jsem to z dokumentace pochopil správně, tak ty dva jsou pouze na připojení dalších backplanes pro disky a jeden pro řadič. Paradoxně mi při nákupu přišel zapojený tak, že jeden port z řadiče byl zapojený správně a druhý port byl zapojený do portu pro další backplane. Dělalo to potom doslova psí kusy - na řadiči jsem viděl všechny disky dvakrát, ale v instalaci systému někdy dva a někdy žádný.

Reálnou propustnost sběrnice na desce brzy vyzkouším až mi přijdou SFP kabely. Zatím jsem zkoušel protlačit skrz jednu x8 kartu "jen" 10GBit a jelo to naplno (9.91Gbit). Na ty přerušení mrknu. Nikdy jsem s tím nelaboroval, ale google toho našel mraky, takže to snad nebude taková "matika".

Dík

[Xerces]

No v 10 ti taky může bezpečně vypadnout jen jeden.

[Bilbo]

Jo, i když u raidu 10 pokud např. u 4-diskového pole vypadne i druhý disk, tak je 2/3 šance že všechna data přežijí. U raid 5 výpadek dvou disků je vždy smrt pro alespoň část (i když vzhledem k rozvržení stripů na disku a náročnosti rekonstrukce dat ze zbylých kousků spíš pro všechny) dat....

[Heron]

Já bych měl z RAID5 strach právě z důvodů zamýšleného využítí, tedy pro databáze. Přece jen, stránka DB souboru je menší (obvykle 8kB) než je velikost stripu raidu. Tedy při každém zápisu stránky (commitu) je nutné přečíst celý strip a poté zapsat. Což dost brzdí. Pro toto využítí je RAID10 nejlepší volba.

Také by šlo použít rychlý a malý disk pro wal log a raid5 pro databázové soubory. Takto lze obejít popsanou nevýhodu.

[Zdeněk Zámečník]

Možná vás překvapím, u RAID5 jsem naměřil ještě menší rychlost zápisu...

[root@skirrax x86_64]# mdadm --create /dev/md1 --level 5 --raid-devices 12 /dev/sda2 /dev/sdb2 /dev/sdc2 /dev/sdd /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sdh2 /dev/sdi2 /dev/sdj2 /dev/sdk2 /dev/sdl2

[root@skirrax x86_64]# cat /proc/mdstat 
Personalities : [raid1] [raid10] [raid6] [raid5] [raid4] 
md1 : active raid5 sdl2[12] sdk2[10] sdj2[9] sdi2[8] sdh2[7] sdg2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
      214804480 blocks super 1.2 level 5, 512k chunk, algorithm 2 [12/12] [UUUUUUUUUUUU]

[root@skirrax x86_64]# dd if=/dev/zero of=/dev/md1 bs=1M count=10000 
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 82.5009 s, 127 MB/s

[root@skirrax x86_64]# hdparm -t /dev/md1 
/dev/md1:
 Timing buffered disk reads:  2654 MB in  3.00 seconds = 883.84 MB/sec

[Milan Roubal]

Tak tahle rychlost je uz hodne podezrela, ja jsem v masine s 12 IDE disky dosahl na RAID5 rychlost zapisu pres 260 MB/s a to uz pred 10 lety.

Ted bude potreba izolovat co je hlavnim zdrojem problemu. Zkus pustit ten zapisovy test paralelne na vsechny disky s tim, ze nebudou v zadnem RAIDu. Tedy zda je problem spise v sw RAIDu nebo primo v tom radici.

[lertimir]

Tedy proč to tahat přes jeden port?

[sigma]

Ta Areca je SAS řadič s 2 porty, ne? 12 disků bude předpokládám připojeno přes nějaký backplane k jednomu z těch portů. Ten port má 4 linky, každá 6 Gbit/s = 24 Gbit/s = 4 GB/s. Otázka je, jestli expander chip na tom backplane taky umí SAS 6 Gbit/s, pokud ne, tak to dělá 2 GB/s což je pořád daleko od dosažených čísel.

Prvně bych zkusil k dd přidat parametry oflag=direct nebo oflag=sync. Výsledky napoví, jestli je někde něco špatně.

Dejte sem výstup z /proc/mdstat a dumpe2fs toho filesystemu (nebo jiný výpis, kde bude vidět velikost stride toho fs).

Každopádně bych zkusil nastavit HW RAID přímo na tom řadiči, problém může být i v sw raidu. Minimálně ten HW RAID může o dost chytřeji používat write cache, a lépe optimalizovat writeback algorimus. V poslední době jsem dělal různé testy, a už při 4 SATA discích v RAID10 dával mdraid znatelně horší výsledky než HP SmartArray s 256 MB cache.

Na druhou stranu u většího pole s 12 SAS disky v RAID50 taky na HP SmartArray, které dává čtení i zápis přes 850 MB/s, se projevovalo dost zvláštní chování na základě těch parametrů direct/sync - čtení bylo normálně pomalejší než zápis, a až s volbou direct se to srovnalo.

[sigma]

Nějak už mi to nemyslí: 24 Gbit/s = 3 GB/s resp. v případě SAS 3Gb to je 1.5 GB/s.

[sigma]

A tu poznámku s dumpe2fs taky ignorujte, teď koukám že to testujete přímo na /dev/mdX.

[Zdeněk Zámečník]

Ta Areca má dva porty, ale jak píšu výše k tomu backplanu jde připojit jen jeden, jestli jsem pochopil dokumentaci správně. Je tam SAS2 expander, takže skrz to asi víc jak 6Gbit neprotlačím i kdybych se zbláznil, ale možná se pletu.

[root@skirrax x86_64]# dd if=/dev/zero of=/dev/md1 bs=1M count=10000 oflag=direct
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 30.3286 s, 346 MB/s

[root@skirrax x86_64]# dd if=/dev/zero of=/dev/md1 bs=1M count=10000 oflag=sync
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 218 s, 48.1 MB/s

[root@skirrax ~]# cat /proc/mdstat
Personalities : [raid1] [raid10] 
md1 : active raid10 sdl2[11] sdk2[10] sdj2[9] sdi2[8] sdh2[7] sdg2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
      117166080 blocks super 1.2 512K chunks 2 near-copies [12/12] [UUUUUUUUUUUU]

[sigma]

6Gbit znamená kapacita jedné "SAS Lane". Jeden ten port neobsahuje nic jiného, než 4 obyčejné SATA linky + navíc nějaké signalizační vodiče, přes které se řídí třeba failure LEDky. Normálně se dá koupit a použít kabel, co má na jedné straně 4 SATA konektory pro disky a na druhé straně se zapojí do jednoho portu SAS řadiče.

Možná se pletu, ale mnohem pravděpodobnější se mi zdá, že kapacita toho 4-Lane konektoru je 24 Gb/s - už třeba tady: http://en.wikipedia.org/wiki/Serial_attached_SCSI - hned vpravo nahoře.

Těch ~ 350 MB/s je na 12 disků v RAID10 fakt málo. Čekal bych tak 600 až 800 MB/s, podobně jako čtení.

Proč nechcete použít přímo ten HW RAID? Pokud na tom má běžet databáze, tak je to i o dost bezpečnější, resp. při stejné bezpečnosti rychlejší - kvůli efektivnímu využití write cache. Ani nevím, jak je to s přenositelností mdraid pole, když ty disky jedou přes tenhle řadič - jestli ty disky mapuje 1:1, nebo jestli na nich má ještě nějaká svoje metadata.

Kolik má ten řadič vlastní paměti, a máte k němu zálohovací baterku?

[Zdeněk Zámečník]

6Gbit znamená kapacita jedné "SAS Lane"...

Specifikace Areca řadiče říká: Up to 6Gb/s transfer rates per SAS port

[lertimir]

Ale ta Areca má 8 nebo 24 portů, tak bych použil 6 a na každém měl pouze 2 disky. Pak rychlost pole nebude limitována rychlostí linek linky.

[sigma]

To je otázka terminologie PORT vs. LANE, která je možná neustálená. Ten řadič má fyzicky 2 porty, v každém 4 linky. Někdy se ale prodávají od stejného řadiče varianty se SATA konektory, a ty pak mají 8 portů.

Jestliže ten backplane má jeden SAS SFF konektor, tak s tím nejde šachovat na nějakých "6 portů".

Tady si nejsem jistý, ale zdá se mi hodně nepravděpodobné, že ten jeden SAS SFF konektor (port) by celkem přenesl jenom 6 Gb/s. Podle mě to je zmatek pojmů ve specifikaci.

[lertimir]

a mít ve stanici 3 Adapteky každý se 4 SATA porty by tu rychlost zvednout muselo. adaptek tvrdí, že má 3 Gbit/s na každém portu.

[sigma]

A já zas tvrdím, že ten problém s rychlostí na 99% není v tom, že ty disky jsou zapojené na jeden SAS SFF port.

Když vezmu SATA v konzumním segmentu, tak jsme tu měli SATA-I s propustností k jednomu disku 1.5 Gb/s, brzy na to SATA-II s 3 Gb/s, a teď celkem nově SATA-III s 6 Gb/s na jeden disk.

Ta Areca z dotazu má 2 SAS SFF porty. Ale jak už jsem psal, ten jeden port není v podstatě nic jiného, než sdružené 4 obyčejné SATA porty + něco navíc. Pokud bychom uvažovali, že přes jeden SAS SFF port je limit 6 Gb/s, pak to je na jednu linku 1.5 Gb/s, a to je SATA-I resp. těžká historie.

Proto tvrdím, že jeden SAS SFF port na té Areca kartě z dotazu dá celkem 24 Gb/s. Použití 3 4×SATA-II karet by teoretickou maximální propustnost zvýšilo, ale reálný dopad by to nemělo žádný.

Možná je taky nějaká zrada v tom expanderu / backplane (co dělá rozbočení ze SAS SFF / 4 linek na 12/16 disků). Ale to se mi na popsaný problém moc nezdá.

[lertimir]

Argumentaci rozumím, ale myslím, že to tak není. Areca by se jistě pochlubila, když by mohla mít dohromady rychlost 24Gbit/s, ale šalamounsky píše, že na každém portu "up to 6Gbit/s". Navíc pak by se s komunikací nevešla do PCIe. PCIe verze 2 má rychlost 4Gbit/s na linku, takže teoretické maximum průtoku dat na motherboard je 36Gbit/s, což pro pro 8 nebo 24 disku je méně než disky vygenerují.

Nikde jsem nenašel informace, které by potvrdily tu informaci o agregací ze stránky wikipedie. Může být chybná. A čistě z hlediska procesingu: 6Gbit/s znamená, že na tom drátu se jeden bit přenáší na 5 cm délky. Už na téhle rychlosti je problém synchronizace v případě paralelního provozu na více linkách. Na vyšších rychlostech to bude ještě problematičtější.

[Strejda]

Pravdu máte částečně oba. Agregace jako taková tam není ale přes 4x port se dá protlačít 24Gb/s. Ten háček je v tom, že ne k jednomu disku. V tomto případě vedou mezi HBA a expanderem 4 6Gb/s LANE, a na každém z nich může probíhat jedna transakce (tedy max 4 současně), každá na jiný target. Vlastní expander obsahuje "non-blocking switch" přes který se transakce dopraví k cílovému disku. Jednoduše řečeno - HBA v této konfiguraci může pracovat se 4 disky současně. Otázkou je, zda to podporují drivery a firmware (a harware) té Arecy. Tenhle typ neznám ale ty které mají HW RAID to běžně umí.

[sigma]

Jasně. Tady šlo o hledání příčiny problému, kdy pokud by ten 4x port dal jen ~ 700 MB/s, tak to může být limit propustnosti při zápisu.

Problém může být jak v tom expadéru, tak ve spolupráci ovladačů + karty, a možná i v MD vrstvě v linuxu.

Jinak třeba HP u řadiče P410 (dva 4x porty) uvádí:

- Server Interface: x8 5G PCIe 2.0 provides 4GB/s maximum bandwidth

- SAS Speed: x8 6Gb/s SAS provides 4.8GB/s maximum bandwidth -- jednu LANE zároveň uvádí jako 600 MB/s (zřejmě nějaké přenosová režie), pak 600M × 8 = 4.8G.

Je otázka, jestli ty SATA disky mají 6Gb/s rozhraní, nebo jestli to jede na 3Gb/s (SATA-II). A potom jestli ten expandér umí komunikovat s disky na 3Gb/s a s kartou zároveň na 6Gb/s, nebo ne. V nejhorším případě by byla celková propustnost omezená na 1.2GB/s.

[Zdeněk Zámečník]

Zkusil jsem RAID zrušit a spustil zápis na prvních osm disků...každý disk zapisoval rychlostí cca 78MB/s, celkově jsem se podle dstat nedostal přes 625MB/s, což je rovných 5Gbit. První jádro procesoru během testu bylo vytíženo okolo 50%, ostatních 11 na 7%. Avg load byl 9.8 5.23 2.31. Jdu tedy hledat problém v nastavení řadiče...

[Milan Roubal]

Take si myslim ze to bude nastavenim radice. Koukni sem, je tam par zajimavych informaci. Tvoje karta pouziva stejny chip jako tato, ne? Maji tam k tomu jak ovladace, tak dalsi popis. Podle nej je rychlostni limit znacne daleko od tvych hodnot.

[Milan Roubal]

Tady jsou ovladace pro nekolik distribuci, ale ta poznamka o podpore jen 8 disku nevypada prilis povzbudive.

[Zdeněk Zámečník]

V systému (SL6.1) mám distribuční mvsas a na něm jsem celou dobu ten řadič zkoušel. Teď jsem zkompiloval arcsas driver, rebootnul, ale po několikaminutovém čekání při bootu to skončilo na kernel panic, takže tudy cesta nevede.

[Milan Roubal]

Jeste mozna nahlednout sem pro doporucovane zapojeni toho backplane. Pokud by byl k dispozici adekvatni kabel, tak by se dala vyzkouset rychlost toho radice pri primem pripojeni disku bez toho backplane, zda neni problem prave tam.

[Heron]

2 near-copies

Zkuste ještě layout f2 (far 2). Obvykle bývá nejrychlejší.

[sigma]

Takhle mám jedno RAID10 (mdraid) pole s 4 × 500 GB SATA. Chová se mi to tak, že čtení je kolem 420 MB/s (skoro součet co dají všechny disky), ale zápis je cca stejně rychlý jako 1 disk (kolem 100 - 120 MB/s). Ale za vyzkoušení to stojí.

[Zdeněk Zámečník]

Já mám na jiném stroji 8x 500GB SATA v sw RAID10 a zápis mi dá 340MB/s, čtení 380MB/s.

[Zdeněk Zámečník]

Také jsem tuto zmínku našel, ale je to ještě pomalejší:

[root@skirrax x86_64]# cat /proc/mdstat 
Personalities : [raid1] [raid10] 
md1 : active raid10 sdl2[11] sdk2[10] sdj2[9] sdi2[8] sdh2[7] sdg2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
      117166080 blocks super 1.2 512K chunks 2 far-copies [12/12] [UUUUUUUUUUUU]

[root@skirrax x86_64]# dd if=/dev/zero of=/dev/md1 bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 36.5559 s, 287 MB/s

[Zdeněk Zámečník]

Ještě co se týče HW RAIDu, tak nemám rozumný řadič se kterým bych to vyzkoušel, takže tuto možnost bych tak trochu zavrhnul.

Z dřívější doby mám dost smíšené zkušenosti s různými HW řadiči od Dellu a od té doby spíše preferuji SW raid. Uznávám, má to taky své mouchy (absence write cache, bug - odpojení disku při velkém souvislém zápisu někdy způsobí zamrznutí systému), ale pro mne z toho spíše vychází výhody (snadný upgrade pole i za běhu systému, jednotný a spolehlivý dohled nad disky, možnost přečíst data na jakémkoliv řadiči, cena).

[sigma]

No jo, teď koukám, že to je non-RAID řadič. Škoda.

Nějaká RAID Areca nebo i HP SmartArray nejsou v kontextu celé sestavy znatelně dražší. Zvlášť pokud máte těch strojů víc, není problém držet jeden řadič jako rezervu.

Jak už jsem psal, má-li to být databáze na takovémhle HW, tak mi tam sw raid nějak nesedí. Ono při velké zátěži může i filesystem blbou náhodou poškodit ztráta write cache na těch discích při tvrdém výpadku napájení. Možná už je to teda vyřešené, ale tohle býval problém.

[Zdeněk Zámečník]

Přesně tak, je to non-RAID. Holt někdy příště zkusím nějakej HW RAID Areca, nejvíc by se mi líbil non-RAID řadič s cache+baterkou, ale nikde jsem na takový nenarazil.

Konkrétně se jedná o řešení dvou serverů, které se mezi sebou budou replikovat přes drbd a databáze z nich budou zálohovány každou hodinu. Počítám s tím, že budu muset v db nastavit ne uplně bezpečný sync na disk, ale v krajním případě není až taková velká tragédie ztratit data za poslední hodinu. Něco podobného už delší dobu provozuji a zatím se db vždy dokázaly po výpadku vzpamatovat.

[sigma]

Uvidíte, co to udělá, až tam bude DRBD. Předpokládám, že na replikaci máte 10GbE karty, jinak jsou ty rychlosti zápisu stejně jinde než tu řešíme.

I tak je DRBD bez write cache s baterkou celkem odvaha. Podle LINBIT je to přímo nedoporučovaná konfigurace. Zápis každého bloku se totiž musí reflektovat do DRBD bitmapy, což namená seek + sync = bez baterky zásadní zpomalení, hlavně při nesekvenční zátěži. Hodně ale záleží na typu zátěže, na výkonu se to nemusí tolik projevit a nemusí to být problém.

V nejhorším ty karty ještě vyměníte, v celém rozpočtu na ty 2 stroje to podle mě není nijak velká položka (dejme tomu 2 × 10k vč. DPH).

[Zdeněk Zámečník]

Přesně tak, mám tam 2x 10Gbit ethernet. Mám v úmyslu použít v DRBD protocol A nebo B (tzn. asynchronní), protože mě uplně tak moc netrápí ztratit změny za x posledních minut před výpadkem. Takže tak nějak doufám, že to nebude taková tragédie.

Kdysi jsem experimentoval s iSCSI a GFS a byla tam poměrně velká režie právě na zamykání v GFS => nejvíc se bojím filesystému.

Máte pravdu, v krajním případě koupím jiné řadiče. Jen k tomu nesmím dojít až v momentě, kdy to bude v produkci.

[Aleš Kapica]

Tak trošku nechápu. Používám DRBD, spojené dvě síťovky 1GB. Bylo to v pohodě, než se zároveň začalo používat to pole přes sambu jako sdílené úložiště. Teď to dělalo to, že se to občas rozpadne. Myslel jsem, že nestíhá síť, ale nakonec se ukazuje, že úzkým hrdlem je spíš rychlost fyzického HDD. Pořešil jsem to snížením rychlosti pro synchronizaci. Zatím se to jeví uspokojivě.

Jo a používám OCFS2 více viz zde.

[sigma]

Záleží, jaký výkon v zápisu se od toho DRBD svazku čeká. S 2 × 1 GbE se dá dostat na 200 MB/s, což asi pro většinu nasazení stačí. Málo kdy se využije vyšší sekvenční zátěž. Na druhou stranu, pokud mám pole, které zvládá zápis třeba 800 MB/s a specifickou zátež, tak proč tam nedat 10 GbE, čímž se navíc ještě o něco sníží latence té replikační linky.

Rychlost HDD by tedy neměla způsobit rozpad DRBD. Četl jsem kdysi na mailing listu o nějakých problémech s rozpadáváním právě při použití více GbE v trunku s tím, že přechod na 10 GbE to vyřešil. Ale už je to dost dlouho, a chyba může být jinde. LINBIT rozhodně doporučuje použít HW RAID, i kvůli izolaci DRBD od chyb jednotlivých disků.

Co si vzpomínám, tak jste psal, že ty DRBD máte obvykle nad mdraid, a nad tím nějaké virtuály. Pro zajímavost - jak rychle je schopen ten virtuál zapisovat na svůj disk (nad DRBD a mdraid)? Nebo vůbec zápis přímo na DRBD svazek? V mých testech s HW RAID 10 a 10 GbE udělalo DRBD z 300 MB/s zápisu režii cca 10 %.

Jinak tu vaši wiki hodně chválím, je hezké že se dělíte o praktické zkušenosti.

[Aleš Kapica]

Pro virtuály samotné DRBD použité nemám. Díky tomu mě taky to, že se to sem tam rozpadne nevadí.

Virtuály mám na RAID6 zařízeních sestavených z nbd zařízení. Chystám se na to téma zplichtit blogpost, ale nějak není čas. DRBD pole využívám jako sdílený prostor, který je do nich zpropagovaný přes plan9 a virtiofs. V podstatě by ani nemuselo běžet v režimu Primary/Primary, ale hodí se to když testuji nějaké věci.

Pokud jde o rychlosti v samotných virtuálech, tak těžko lze něco měřit, když ten stroj sám o sobě většinou nemá ani těch 10GB (hostitelský stroj má 20GB RAM). Všechna další data jsou na tom DRBD. Jinak čtení z toho DRBD přes p9 do virtuálu (zapisuje se na ten raid6) se pohybuje kolem 28MB/s a naopak obráceně (z raid6 čte a na DRBD zapisuje) je rychlost cca 42MB/s.

[Aleš Kapica]

Bohužel musím vycházet z našich možností, takže fyzické disky jsou sice velké, ale poměrně pomalé - už jsou přeci jenom starší. Moc rád bych vyzkoušel jak by to šlapalo s využitím bcache a SSD disků pro cache blokových zařízení. Bohužel - na experimenty nejsou love. A to cena takového SSD disku je proti ceně jedné 10GbE karty pouhá prkotina.

Taky by to asi bylo výkonově zase o kus jinde, kdyby ty desky měly SATA III ale i tak jsou poměrně slušné. Na to, že jde o téměř tři roky staré obyčejné desktopové desky, které jedou non-stop. Jejich největším nedostatkem je, že nemají možnost mít dublovaný napájecí zdroj.

[Aleš Kapica]

Chystám se na to téma zplichtit blogpost, ale nějak není čas...

Tak jen pro úplnost, že už ten můj blogpost na téma NBD tady je.

[sigma]

Ještě bych dodal, že stejně nejvíc záleží na zátěži, kterou ten stroj bude muset zvládat. Test sekvenčního čtení / zápisu na tom poli pak může být minimálně vypovídající. Jakmile se dostaneme do zátěže náhodným přístupem a ještě s malými bloky, tak můžou vyjít úplně jiné poměry než u sekvenčních testů.

Můžete zkusit ještě tenhle nástroj: http://www.fccps.cz/download/adv/frr/hddtest-1.0.tgz

Dělá test sekvenčního ale i náhodného přístupu + je vidět případné kolísání.

./hddtest -1 -d /dev/md1
./hddtest -2 -d /dev/md1
./hddtest -1 -w -d /dev/md1
./hddtest -2 -w -d /dev/md1

[Zdeněk Zámečník]

Ano, jsem si toho vědom a také jsem z tohoto důvodu nakoupil větší množství "malých" disků. Zkoušel jsem hledat nástroj na nějaké rozumné otestování iops (seeker), ale moc moudrý jsem z těch výsledků nebyl - test na jednom disku mi dal více seeků než na celém RAIDu. Pak jsem zkoušel rychlost sekvenčního čtení/zápisu a narazil jsem na tu podezřele nízkou rychlost zápisu, kvůli které jsem založil tento thread.

[sofokles]

pouzivame iometer.org a tie vysledky z neho by mali byt ok

[Zdeněk Zámečník]

Budu teď pořizovat další server, tak ho koupím s jiným řadičem. Dokázal byste mi někdo poradit vhodný řadič? Koukal jsem např. na ARC-1880ix-12, ale mám pocit, že z něj více jak 6Gbit přes jeden SAS port taky nevyždímu...

[Šangala]

Ne, ale máte jich tam 12

[Zdeněk Zámečník]

To je mi ale platné jako mrtvýmu zimník, jelikož v casu mám SAS expander s jedním portem...

[Šangala]

Ale to není problém řadiče…, tak hold využijete minimálně 4 (možná víc, co já vím jak to funguje, bez detailní specifikace)
Rozdíl mezi řadami je (mimo cache/RAID) až 6Gb/s a až 6Gb/s na každý SAS port, a SAS portů 12 , dle toho co čtu 12 na tři konektory, tedy minimálně 4×6Gb/s , ale že bych to mohl na základě těchto informací tvrdit…

[Strejda]

Tak si otestuj co ten řadič umí - připoj na něj 4 disky na přímo (ne přes expander) a pusť test čtení jednoho sektoru. Postupně nejdřív na jeden disk a pak přidávej další. Pořád i myslím, že problem je v driveru který používá na komunikaci s expanderen jenom jednu LANE...

[Šangala]

Klidně, když mi ho [Ss]trejda koupí

[Zdeněk Zámečník]

Nemám tu žádný kabel miniSAS>SATA a z žádného stroje ho teď ani vyndat nemůžu. Nicméně jsem to dnes zkoušel ve Win7 a výsledky byly úplně stejné. Po delším zvažování jsem došel stejně k názoru, že ten non-RAID řadič byla chyba a rád bych ho tak jako tak vyměnil. Uvažuji nad MegaRAID SAS9260 nebo ARC-1880, přičemž ta Areca mi přijde sympatičtější.

[Zdeněk Zámečník]

Tak jsem nakonec koupil řadiče ARC-1880i včetne BBU. Řadič krásně rozpozná expander a vše funguje velmi dobře. Nicméně zrychlení se tam, kde jsem nejvíce očekával, nekoná:

[root@max ~]# dd if=/dev/zero of=/dev/sda2 bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 24.9443 s, 420 MB/s

[root@max ~]# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   15402 MB in  2.00 seconds = 7713.84 MB/sec
 Timing buffered disk reads:  2516 MB in  3.00 seconds = 838.44 MB/sec

Je tam vidět mírný nárůst rychlosti sekvenčního zápisu, ale ten bych přikládal právě write-back módu řadiče. Problém tedy bude pravděpodobně v expanderu :/