Dotaz: SAS nebo SATA disky do HW RAIDu

[VSi]

Rozmýšlím, jak postavit úložiště pro Samba server. Na serveru budou uloženy hlavně domovské adresáře uživatelů a Windows profily. Takový profil má cca 15 až 50MB a vyznačuje se tím, že při každém přihlášení na Windows PC se kopíruje ze serveru. Půjde asi o 200 PC, potřebný prostor tak 400 GB. V jednom okamžiku může začít přihlašování třeba z 50 PC naráz.

V současnosti mám na jiném serveru 2×146GB SCSI 10krpm v HW-RAID1, pro asi 100 PC a podobné využití - a už je to dost pomalé. Tenhle RAID má podle hdparm rychlost sekvenčního čtení jen kolem 70MB/s, nicméně při nějakém testu IOP/s co jsem dysi dělal dával skoro dvakrát větší výkon než nový SATA disk. Při popsaném typu zátěže jde ze serveru třeba jen 8MB/s, protože se čtou soubory různě poházené po disku.

O čem uvažuju - server od HP s HW RAID SAS řadičem a BBWC (SmartArray P410 nebo tak něco) +

• RAID5: 4 × SAS disk 147GB, 15krpm, originál HP = cca 34000 Kč, kapacita něco přes 400GB
• RAID10: 8 × SATA 500GB, 7200rpm, Seagate ES nebo WD RE3 = cca 18000 Kč, kapacita 2TB
• RAID5+spare: stejné SATA jako předchozí, kapacita by byla 3TB

Vyšši kapacita u druhé/třetí varianty by se využila, ale tam už nepotřebuju takovou rychlost. Takže k té variantě se SAS disky bych přidal 2 nějaké obyčejné SATA 1TB disky a bylo by to OK.

Je asi jasné, že 4 takové SAS disky v RAID5 dají vyšší výkon než 8×SATA. Dokáže někdo poradit, jak veliký mezi tím asi bude rozdíl pro uvažované použití? Bylo by lepší u SATA disků použít ten RAID5+hot-spare, nebo radši RAID10? Nebo to udělat ještě jinak?

---

---

Odpovědi

[karr]

To za vás nikdo nerozhodne. Záleží také na štěstí, jaké budete mít na komponenty. Mám dobrou zkušenost s hw RAID 6 na řadiči 3ware s šesti SAS disky - podle hdparm testu to je rychlejší (80-100 MB/s) než SCSI (70-75 MB/s), ale je to dost drahé. RAID 6 neumí každý řadič, ale ten pocit bezpečí za to stojí...

[VSi]

Děkuji aspoň za takovou informaci. O RAID6 uvažuju taky, ty HP SmartArray ho umí pokud k nim je baterie na zálohování write-cache, jen je třeba koupit licenční klíč asi za 7000 Kč.

Ty rychlosti jsou pro "celý" RAID nebo pro jednotlivé disky? Zdá se to dost málo, když dnes obyčejný SATA disk dá v hdparm přes 100MB/s.

Ono mi jde i o rozšiřitelnost do budoucna, rozdíl v ceně není až tak zásadní. Do HP serverů jde dát 8, výjimečně 12 3.5" disků, a těch 400GB mi třeba za 2 roky už nemusí stačit. Byla by možnost použít třeba nějaký větší Supermicro case, ale radši bych koupil hotový server.

[karr]

3ware řadič to umí i bez baterky, s baterkou je to asi spolehlivější při výpadku napájení, kdo má peníze na pořádný server, tak mu většinou 2000 kč na baterku nechybí.

Rychlosti jsou pro celé pole, systém jednotlivé disky nevidí. Jednotlivé disky jsou na 3Gbps lajnách (lze volit 1.5 a 3 Gbps). Rychlost je daná nastavením řadiče. Těch 70-400 bylo s vypnutou keší na řadiči. Při zapnutí do módu "inteligent" mi to hodilo 217.90 MB/sec. Asi by z toho člověk vymáčkl i více, záleží na tom, co od toho člověk vyžaduje a co vlastně ten hdparm v tomhle případě vlastně ukazuje.

Je to v supermicro case do raku, pole má dva terrabyte a řadič spolehlivě přestál havárii jednoho z disků, takže si zatím nemohu stěžovat.

Přeji šťastnou ruku při výběru správného železa

[karr]

chybka, 70-100, ne 400

[Miklik]

Ne každý SATA disk je postaven na 7/24 provoz, ale ty od HP snad jsou na 7/24, když jsou do serverů. Já jsem u HP serverů používal SAS/SCSI disky s 15000 otáčkami v RAID 10 (mirror 4 disků ve stripu na dvou kanálech) pro databázi, pro poštu jsem zase měl 8 SATA disků 10000 ot. v RAID5. A chodilo to vcelku dobře. Hodně pomohla na SCSI řadiči cache o velikosti 512MB, ale to spíše pro databázi.

Asi bych tam dal SATA 10000 ot. disky v RAID5, dle mě to stažení těch profilů 50MB x 50PC v jeden čas, bude mít jiná úzká místa v tom serveru a i na těch stanicích.

Nevím jaká je u vás situace, ale snad se ti lidé furt neodhlašují a nepřihlašují.

[svaca]

SATA disky od HP je NORMALNI DISK s HP nalepkou Vetsinou je to treba Western raid edition nebo Seagate ES ... + nalepka HP ... IMHO SATA NEPATRI do serveroveho reseni .. SATA je pouze pro ty co nemaji peniza na SAS (=SCSI)

[VSi]

Pokud bych použil SATA disky, tak výrobcem doporučené pro 24/7 provoz. Tj. Seagate ES/Constellation, nebo Western Digital RE3. Originální disky od HP jsou většinou jen přeznačkované Seagate za nesmyslnou cenu. Je na ně možná lepší záruka, ale ta je pro mě u disků nepodstatná (vracet disk s daty se mi nechce).

SATA 10000 ot. jsem viděl jen WD Raptor/Velociraptor. To by byla možnost místo těch 15krpm SAS, třeba 4×300GB do RAID10. U nich si ale nejsem jist tou spolehlivostí při 24/7 provozu.

Jde o školu, takže na jednom počítači se za den vystřídají třeba 4 lidé. Nejhorší právě je, že vyučovací hodiny začínají najednou, takže se ta zátěž nerozloží.

V současné situaci, jak jsem psal, je úzké místo na serveru. Prostě když probíhá přihlašování na 20 PC naráz, je to znatelně pomalejší než při menším zatížení serveru. V té době se na serveru značně zvedá iowait vytížení CPU.

[svaca]

jen info, pokud ti ten raid jede jen 8MB/s tak mas pravdepodobne vyplou Write cache, coz asi znamena, ze budes mit DEAD batrku na radici ...

Pokud koupis novy radic tak hlavne s baterkou, nebude-li mit baterku, nepujde na nem zapnout WC a budes to mit taky pomale, bacha na to ...

Nekdy jde WC zapnout i bez baterky, ale to se rovna sebevrazde ...

Rozhodne bych sel do SAS, SAS je: nejrychlejsi, nejspolehlivejsi, nejdrazsi

[VSi]

Ne, čtení jede 70MB/s, zápis o něco méně. O vlivu write cache a baterie vím. Jde o starý server s SCSI a řadičem bez baterie který se právě bude brzy nahrazovat.

Těch 8MB/s je tok na Gb síťovce, když z toho RAIDu přes Sambu čte třeba 20PC naráz malé soubory.

[AraxoN]

Podľa mojich skúseností so SAS diskami 10k dosiahneš najmenej dvojnásobok rýchlosti, čo so SATA 7200. So SAS 15k ešte o niečo viac. Tie SAS disky majú ešte veľkú výhodu v tom, že tam je kratší seek time. Takže keď chce 50 používateľov niečo naraz, tak to tie disky rýchlejšie nájdu.

Pri tej prvej možnosti (RAID5 - 4x SAS) môžeš očakávať sekvenčné čítanie nad 330 MB/s (merané cez hdparm -t na troch rôznych serveroch). Pri tej druhej možnosti (RAID10 - 8x SATA) budeš rád keď sa priblížiš ku 150 MB/s. Na tú poslednú možnosť (RAID5+spare - 8x SATA) čo najskôr zabudni. To nebude robiť dobrotu ani čo sa týka výkonu, ani čo sa týka spoľahlivosti.

[dustin]

Na vývojovém serveru používáme SW raid10 z osmi nových rychlých seagatů 500GB 7200.12 po tisícovce za kus a čtení/zápis přes dd přímo na raid (před instalací systému) přes 400MB/s (data nebyla nakešovaná, to jsem si ohlídal). Deska Gigabyte EP45-UD3LR se šesti SATA řadiči, přidány dva levné PCI-e SATA řadiče Sil 3531. Zkoušel jsem i jen jeden řadič PCI-e dual port, ale čtení/zápis na obou discích současně kleslo hluboko pod 100MB/s každý, tak jsem dal řadiče dva.

Trvání naší jedné složitější diskové operace (řádově desítky tisíc symlinků) klesla z 15 minut (2x SCSI320 v HW raidu1 na HP ML330) na cca 4 minuty.

Skříň Akasa Infinity, tři klece po třech diskách, docela pěkně mechanicky vyřešené.

[AraxoN]

To sú hodne zaujímavé výsledky. Hovoria dosť v prospech SW RAID. My máme HW RAID 10 na štyroch diskoch a výkon je síce lepší než výkon jedného samotného disku, ale o dvojnásobku sa určite nedá hovoriť. Ak to SW RAID vytiahne na dvojnásobok (resp. na štvornásobok pri 8 diskoch), tak to je skvelý výsledok za málo peňazí. Dobre vedieť.

[dustin]

To jsou naše čistě praktické zkušenosti. Zatížení CPU je zcela zanedbatelné. Přijde mi, že jde o rozložení zátěže na jednotlivé SATA řadiče, zatímco u HW to jede celé přes jedno zařízení. Ale nevím a asi ani neumím zjistit :)

[svaca]

Pomer cena / vykon je opravdu nadherna, ovsem o spolehlivosti by se dalo polemizovat .. takovy to system NEMA WC zalohovonou baterkou (vzhledem k cene) a nema pred operativni kontrolu pred ctenim a zapisem (proto to taky tak leti) ale nedej boze aby se podelaly dva disky naraz, co v tomto pripade muze byt docela i pravdepodobne ...

[dustin]

Jistě, v tomto případě jsme nehledali rock-solid spolehlivost a dostupnost, ale max. výkon za rozumnou cenu s rozumnou spolehlivostí.

K té baterii - pokud zařízení rovnou při příkazu ukládá (hdd, narozdíl od HW raidu s keší), k čemu by byla baterie dobrá? Při výpadku napájení stejně zůstanou neuložené diskové keše jádra (hdd i HW raid s baterií), tak jaký je rozdíl?

Dva disky naráz se za ty roky, co používáme raid, zatím nikdy nepodělaly (ťuk ťuk).Šance, že to vypadne při podělání dvou disků naráz, je 50% (raid10). Server je každý den kompletně zálohován a neběží na něm aplikace pro klienty, slouží pro naše vývojáře. Když porovnám výkon/spolehlivost/cenu, je to pro nás vhodnější řešení, než proprietární HW raid, se kterým neudělám žádné změny, jak se časem vyvíjejí naše potřeby, narozdíl od flexibilního SW raidu.

[VSi]

S tou cache je to asi tak: write cache mají samotné disky (tzv. drive cache), při výpadku napájení se její obsah ztratí. Jde operativně zapnout / vypnout třeba přes hdparm. Třeba HP na obyčejných SATA discích, co dává do serverů, má upravený firmware, takže je cache implicitně vypnutá (v zájmu spolehlivosti). Pak bývá cache na HW RAIDu, většinou 128MB-1GB.

Pokud má člověk jeden disk / sw raid, drive write cache se obvykle nechává zapnutá, protože bez toho jde výkon zápisu velmi výrazně dolů. Jde pak o filesystem, jak se vyrovná s výpadkem napájení a ztrátou obsahu cache. Nějakým ATA příkazem jde disku říct, aby cache fyzicky zapsal - nazývá se to write barriers. Problém je v tom, že implementace SW RAIDu a hlavně LVM v linuxu barriers nepodporuje, resp. v jádře 2.6.32 nebo tak nějak už by to mělo být vyřešeno, ale jen pro některé druhy RAIDu. Pak taky některé moderní disky pro "zvýšení výkonu" s vyprázdněním cache švindlují, nebo zapisují bloky v jiném pořadí než FS potřebuje.

Třeba ext3 s tím má dost problém, dají se najít testy, kde při použití LVM a pár desítkách vypnutí v průběhu zatížení zápisem se filesystem úplně rozpadne (dojde ke špatnému pořadí zápisu žurnálu a dat). Odolnější by proti tomu měl být EXT4 nebo BTRFS, úplně to asi řeší jen ZFS od Sunu - škoda, že na linuxu asi jen tak nebude.

Takže pro zajištění spolehlivosti u HW RAIDu se drive write cache přímo na discích vypnou, a používá se jen cache na řadiči, která je zálohovaná baterií, a při výpadku napájení se nic nestane. Ten HW RAID si pak navíc může dovolit dělat lepší optimalizace v pořadí zápisu dat na disky.

[svaca]

Hezke vysvetleno .. Moje zkusenost je, ze treba prave IRCH9R nebo IRCH10R, zaply v BIOSu v SW raidu, znamenalo treba pri startu stroje a naslednem vypadku ztraty souboru dulezitych pri bootovani = konec stroje ...

Takze me uz to za to nestoji a odmitam tyto ruzne skladacky. To pole na tom gigabyte je krasne, ale nechtel bych ho mit na starosti a to jen proto, ze s takovym to zelezem mam negativni zkusenosti ... Je to asi ciste o tom, kdo a co si jak udela a pak o te tolaranci. Ovsem dulezite je, aby tu toleranci chapalo i vedeni ...

Na novy poradny raid penize nejsou nikdy, ale rozpadne -li se pole a firma stoji cca hodinu a vic, tak najednou jsou penize vzdy

[Als]

No a zde mate vysvetleno proc to mam 5x drazsi :))

[dustin]

Kvaziraid v biosu mě tedy vůbec nenapadl :)

Je to vše o prioritách. Na páteřní ostrý server do serverhousingu bych to nedal ani náhodou, tam neděláme kompromisy a vysoký výkon a současně spolehlivost jsme si pěkně připlatili. Dovnitř firmy pro vývojáře s tím nemám problém, ani já jako vedení :). Za stejný výkon na značkovém serveru s 16GB FB Dimmy (časem se bude rozšiřovat) a co nejrychlejším rychlým polem alespoň 300GB bychom se pěkně prohnuli. Kdybych nepotřeboval výkon, strčíme tam nesmrtelné HP ML115, na kterých provozujeme ostatní firemní servery.

Domnívám se, že pro potřeby školy, tedy původní dotaz, SW raid ze SATA disků na kvalitním HW stačí, samozřejmě každodenně zálohované a na UPSce. Klidně bych použil levný server od HP se SATA řadiči, ale ten bohužel mívá jen 4 SATA řadiče a na více disků není mechanicky připravený (HP ML115, nvidia čipset, raid10 - 230 MB/s dd spouštěné z livecd). Plánované odstávky se dají dělat odpoledne nebo o víkendu, to není žádný kritický provoz 24/7. Ne každá instituce má stovky tisíc na HW, který za pár let zastará a nedá se s ním pak nic dělat (vysoká spotřeba vzhledem k výkonu, nedostupné náhradní/rozšiřující díly nebo jen přes ebay - např. druhé/upgrade CPU do vyšších řad značkových serverů díky speciálnímu chladiči, rámečky na SAS disky atd.)

[VSi]

Souhlas. Bude to na UPS, denně zálohované na druhý stroj. Když to v případě havárie 1 den nepůjde, zas tak moc se neděje. Více kritické služby, které nepotřebují takový výkon, budou nejspíš na XEN+DRBD clusteru.

Teď tam je nějaký HP ML350, asi 4 roky starý, za celou dobu nebyl problém. Ale má to jen SCSI disky, RAID1 bez baterie, málo paměti, a upgrade prostě nemá smysl. Pak máme nějaké obyčejné HP ML110, a ty jsou taky perfektní.

Takže přišel na řadu upgrade celého serveru, protože se ještě značně zvýší počet PC. Počítám s HW RAIDem, protože za těch cca 10 tisíc se to podle mě vyplatí. HP ho navíc dává do některých serverů za rozumnou cenu (už i do ML110). SW RAID má sice výhodu v možnosti dát disky do jakéhokoliv jiného stroje, ale chtěl jsem mít možnost i SAS disků a tolik obyčejných SATA portů ty servery stejně nemají.

HP má ty originální SAS disky dost drahé, tak o 50% výš než třeba Fujitsu-Siemens, ale ti zas nemají žádný vhodný server, kam by šlo dát dost disků. Chtěl bych aspoň 8 × 3.5" + nějaké volné 5.25", nebo 12 × 3.5". Zajímavé jsou i 2.5" SAS disky (jsou o dost levnější než 3.5" i když jen 10krpm), ale potřeboval bych pak k tomu dát ještě tak 2 velké SATA disky.

Našel jsem informace, že výkon SATA disků ve stripe, rep. RAID 10 asi tak odpovídá polovičnímu počtu SAS 10k dsiků. Proto jsem chtěl znát zkušenosti a těch uvedených 150MB/s s 8 disky v R10 mi přijde docela málo, i když to třeba nevypovídá o výkonu při náhodném čtení.

[dustin]

Stejně mi to není úplně jasné. Ta školní síť přenese takový objem dat pro všechny PC současně žádající svůj profil? Požadované rychlosti by vzhledem k režii smb protokolu zahltily několik gigabitových sítí.

Přijde mi, že pokud je potřeba uspokojit větší počet klientů najednou, bylo by lepší než rychlost řešit schopnost současně číst pro víc klientů. Někde na netu jsem viděl benchmark právě pro SW raid a např. raid1 ma více discích (spindles) měl v tomto ohledu podstatně lepší výsledky než konfigurace, která sice měly větší rychlost, ale při souběhu více požadavků se zadýchaly už při pár požadavcích. Nemohu to najít, ale podobné grafy jsou např. na http://arstechnica.com/civis/viewtopic.php?f=16&t=128870 . Taky pár zajímavých informací a linků viz https://raid.wiki.kernel.org/index.php/Overview#Other_benchmarks_from_2007-2008

[VSi]

Ta sekvenční rychlost mě skutečně vůbec nezajímá. Je mi jedno, jestli to sekvenčně dá 100MB/s nebo 400MB/s. Možná jsem se špatně vyjádřil, ale v pár postech tady někdo popisoval výkonnost jen tou sekvenční rychlostí. Při té zátěži, co popisuju, tak čtení z 2×147GB 10k SCSI v RAID10 dá stěží 10MB/s. Potřebuju tedy co nejlepší výkon pro hodně klientů současně čtoucích soubory ve velikosti pár kB až MB.

Skutečně se mdraid s třeba 4 disky v RAID1 chová tak, že zlepšuje výkon náhodného čtení? Teoreticky mi to dává smysl, je to ale dost neobvyklé nastavení, moc se o něm nepíše.

Byl jsem rozhodnutý pro HW RAID, který by u takovéhle zátěže měl obecně poskytovat vyšší výkon, protože dělá lepší řazení požadavků, read-ahead apod, navíc ta zálohovaná write cache. Výhody HW RAIDu by se zvlášť měly projevit pro SAS disky. Z tohoto pohledu je srovnání HW×SW RAID podle rychlosti sekvenčních operací asi nesmyslné.

V dotazu mi šlo spíš o to, jestli je RAID5 na SAS discích na takovou zátěž obecně vhodný. Jestli je srovnatelné chování X SAS disků v RAIDu a chování dvojnásobného množství SATA disků. Nakonec možná koupím server bez SAS disků, udělám nějaké testy s obyčejnými SATA a když to nebude vyhovovat, koupí se SAS (otázka je, jestli to pak bude lepší). I když to je problematické, protože jde o školu, kupovalo by se to s nějakým dalším HW najednou, protože pak se dá ve výběrovém řízení dosáhnout o dost nižší ceny. Možná se někde půjde domluvit na půjčení těch disků+RAID karty na otestování, uvidím.

[VSi]

Tak tady: http://arstechnica.com/civis/viewtopic.php?f=16&t=128870 kousek za půlkou jsou grafy, ze kterých plyne, že software RAID1 v linuxu pro paralelní čtení drtí vše ostatní. Otázkou je, jestli to nebylo testováno pro čtení několika souvislých souborů. V mém případě se budou číst tísíce souborů různě poházených po disku, takže bude hrát roli seek apod. Navíc úlpně špatný výkon při zápisu taky nemůžu potřebovat - při odhlašování se ta uživatelská data částečně kopírují zpět. I když to by se muselo otestovat, jak přesně to funguje. Asi se nekopíruje zpět všechno, ale probíhá nějaké porovnání. Windows se ale v tomhle chovají dosti divoce.

[dustin]

Tak vezmi nějakou klidně obyč. desku se šesti SATA II porty, šest 500GB seagatů 7200.12 po tisícovce (doporučují se právě kvůli poměru cena/(výkon ve více požadavcích, máme s nimi výborné zkušenosti a když tak je použiješ do pracovních stanic) a vykoušej si na nich raid1. Můžeš začít na 4 a postupně přidávat (parametr --grow v mdadm), dokud nevyčerpáš SATA porty (a pak můžeš pokračovat PCI-e řadiči za pár stovek). Tipnul bych si, že dřív utaháš tu síť, než ten raid. Zápis bude rychlost těch disků, tj. sekvenčně okolo 130MB/s raw data bez zátěže, v reálu přes FS samozřejmě méně. Stejně tam bude významné omezení režie samby po síti. FS bych namontoval s parametry noatime, nodirtime, ať při čtení nic nezapisuje.

SW RAID1 vybírá disk podle toho, který je zrovna volný a má údajně nejblíže k danému sektoru.

[Miklik]

Překvapuje mě, že školství nemá jednoho nebo dva dodavatelé za extra dohodnuté ceny, v tom objemu serverů co se ve školách používá, by se musela dát domluvit i 50% sleva na základní sestavy, které by v 90% vyhovovaly všem.

[dustin]

Myslíš něco jako internet do škol? :) Centrálně řízený nákup v eráru - to opravdu budou "extra dohodnuté ceny", to zcela jistě. :)

[dustin]

Díky za info o write cache disku. Používáme xfs, ale nad raidem. Stroj je na UPSce s řízeným shutdownem.

[Als]

Mam pole MSA-60 s 12x 450GB 15K SAS disky na P800 (512MB WC, 75% pro write) v RAID6 a raw vykon je neco kolem 450MB/s cteni a 250MB/s zapis. Nekde bych jeste mozna mohl najit bonnie testy kde jsem porovnaval XFS a ext3 + drbd.

[svaca]

Krasna jedina vada je, ze te to stalo 4x vic nez kolegu .. mozna 5x

[Als]

No a to to mam dvakrat a ta P800 je k tomu jeste v DL380 s trochou pameti a nejakym tim procesorem :)

[svaca]

mam taky DL380 + P800 + Diskove pole ale 12X SAS 10K + RAID6 a na tom prave xenserver

[Limoto]

A co SSD? Sice asi nejdražší, ale výkon největší...

[frr]

Souhlas Pokud je ta zátěž důsledně read-mostly, tak proč ne Jeden intelí SSD by měl gigovou síť spolehlivě udávit, pokud se to neudáví dřív na Sambě. U SSD zejména bacha na noatime+nodirtime (drobné zápisy BOLÍ), a možná bacha na flow control v Ethernetu. Akorát že 400 GB v rychlých SSD může docela vyluxovat peněženku.

[VSi]

SSD v takové kapacitě jsou skutečně nad finanční možnosti, to už považuji za předimenzované. Pokud nebude třeba vyloženě šetřit, tak 4-5 SAS disků na HW RAIDu (asi RAID5, kdyby to bylo špatné, tak se přidá na 6 disků do RAID 10) bude výkonově bohatě stačit.

V sítí úzké místo podle mě není. Charakter zátěže (náhodné čtení) v současnosti srazí čtení z SCSI 10k disku na méně než 10MB/s.

To řešení s víc SATA disky by nestálo tolik, byla by k dispozici vyšší kapacita, a v případě pozdější výměny špatného disku by to bylo taky levnější. Spolehlivost by byla myslím dostatečná, jen právě nevím, jaký od toho čekat výkon ve srovnání s tím SAS.

Navíc to skutečně není read-mostly, jen při tom zápisu není zátěž tak velká a není takový požadavek na rychlost jako u čtení.

[frr]

Troufnu si nesouhlasit se Sváčou ohledně zálohovací baterky. Jde do značné míry o alibismus výrobců značkových mašin, že uživatelům nedovolí konfiguraci, která je potenciálně nebezpečná. Asi mají svoje zkušenosti se žalobami za ztrátu dat. Sváča se stará o stroje s kriticky důležitými daty. Čili je to někde jinde, než homy ve škole (navíc zálohované). Jak tu kdosi zmínil nezálohované WB buffery na disku a v OS - plně souhlasím. Je fakt, že RAID když má vypnutou WB cache, tak obvykle taky zakáže WB přímo na discích. Nicméně mi prošlo rukama vcelku mnoho Areca-based RAIDů, všechny měly zapnutou WB cache (protože bez ní je jakýkoli RAID prakticky nepoužitelný) a žádný neměl baterku, a nikdo si nestěžoval, že by přišel o data kvůli zapnutému WB při výpadku napájení. Areca s tím cavyky nedělá. Pokud je zálohované napájení, tak když už serveru stejně umře zdroj, tak většinou řešíte spíš zdroj než posledních pár transakcí, které se nedostaly na disky. Zápisové bariéry v žurnálových filesystémech fungují zjevně docela dobře - sice snižují výkon (degradují hloubku TCQ) ale je to pořád lepší, než vypnout writeback úplně. Zejména na read-mostly datech bych dirty writeback vs. výpadek napájení moc neřešil

Proprietárním soft-RAIDům v BIOSu jsem nikdy nevěřil - stížnosti na jejich demenci v kritických situacích slýchám vcelku pravidelně. RAIDový BIOS a ovladače od Intelu nejsou žádný med. Jediný soft-RAIDový BIOS, který trochu za něco stojí, je Adaptec HostRAID - původně na adaptečích U320 SCSI HBA, později i jako OEM modul nad Intel ICH (třeba u některých boardů SuperMicro). Ale pod Linuxem je to stejně nesmysl. Linuxový nativní soft-RAID je za nula peněz opravdu luxusní - výkonný a relativně komfortní. Jasně, nejde bootovat ze strajpovaných RAIDů, ale osobně beztak dávám systém nejradši na oddělený menší mirror, a na RAID10/5/6 dám jenom velký oddíl pro data.

Podle toho, že rozlišujete sekvenční MBps průchodnost od IOps průchodnosti, je vidět, že jste nadprůměrně v obraze Přesně v tom je totiž problém. V reálném nasazení na fileserveru bývá dost jedno, jestli je v RAIDu IOP321 (cca 120-200 MBps), IOP333 (400 MBps), IOP341 nebo IOP348 (600-800 MBps). Posledně jmenované hodnoty platí třeba pro novější Arecy nebo Adaptecy. Solidní soft-RAID (třeba ten Linuxový) na tom bude taky tak nějak. V serveru, na který se dobývá smečka uživatelů, záleží na IOps. Důležité veličiny jsou IOps jednoho disku, počet disků, RAID level (především pro zápis), velikost čteného bloku, velikost a inteligence read-aheadu v RAIDu a v OS.

Třeba běžná Barracuda 7200.10 až .12 umí cca 70-75 IOps při velikosti transakce 64 kB. Tahle hodnota se už pár let nemění, dokonce mezi 7200.10 a 7200.11 mírně klesla. Prostě plotny se točí pořád stejně rychle a hlavy taky nekmitají rychleji, naopak při hustších stopách může ustálení hlavy nad stopou trvat déle. Zas na druhou stranu postupně roste výkon řadičů v elektronice disků a velikost jejich interní cache. U enterprise disků s 10/15k RPM se číslo IOps mezi generacemi možná nepatrně zlepšuje, ale ne o moc. Můj odhad je 110 IOps pro 10k RPM a 130-150 IOps u 15k RPM. Tahle čísla platí pro seek positions generované náhodným generátorem, což je rozumná aproximace smečky uživatelů, kteří se snaží dostat k mrakům drobných souborů. Převrácenou hodnotou IOps je skutečný celkový average seek time

Čím jsem měřil? Znovu si přihřeju polívčičku:

http://www.fccps.cz/download/adv/frr/hdd/hdd.html#hdd

http://www.fccps.cz/download/adv/frr/hddtest-1.0.tgz

Ať už používáte RAID0, 1, 10, 5, 6 atd., při čtení se vždycky rozkládají paralelizovatelné požadavky mezi dostupné diskové mechaniky. Pochopitelně do značné míry "statisticky", tj. nikoli dokonale. Paralelizovatelné = od různých čtoucích vláken (pokud se nepoužívá asynchronní čtení v rámci vlákna, zablokuje se každé vlákno na jediném požadavku). U maličkých souborů se mohou projevovat různé zarovnávací efekty mezi začátkem souborů / FS clusterů / RAID strajpů... Při zápisu se u RAIDu 1 projevuje nutnost zapsat všecko dvakrát, u strajpovaných RAIDů je vedle zápisu parity ještě skryto čertovo kopýtko v nutnosti přednačíst celý stripe set, aby se vůbec nová parita dala spočítat...

Taky je trochu rozdíl mezi čtením a zápisem na úrovni disku - při zápisu může disk uplatnit WB cache, takže má interně ve výsledku hlubší frontu požadavků a může lépe uplatňovat "lokální optimalizace pořadí" (údajně i v rámci jedné otáčky plotny seekuje mezi blízkými stopami). Při čtení v zásadě každý klient čeká na jediný konkrétní seek, a disk řadí jenom jednotlivé klienty mezi sebou. Zajímavé je, že efekt optimalizace řazení při write-back kešování je výraznější u enterprise disků než u desktopových Barracud. Hodně dobré výsledky dává Velociraptor (SATA), ale tam mám zase špatné zkušenosti i reference ohledně dlouhodobé spolehlivosti... není to moc rozsáhlá statistika ale trochu to odradí.

Při čtení je důležitý read-ahead. On to není v Linuxu žádný med ani u parelního čtení sekvenčních souborů - a u drobných souborů je to divoké zejména. Je potřeba, aby kernel přednačítal payload trochu inteligentně "per file", nebo dokonce "per stream". V aktuálních verzích kernelu je toto údajně splněno (posledních pár verzí zpátky na tom jeden člověk dost pracoval). User-space aplikace sice může chování read-ahead algoritmu na otevřeném deskriptoru trochu poštelovat, ale pochybuju, že zrovna Samba tohle dělá - Samba přece neví, jak bude klient konkrétní soubor v budoucnu číst, jestli bude seekovat tam a zpět, nebo bude číst hezky postupně sekvenčně... takže se nakonec uplatní nějaká hrubá heuristika v kernelu.

Ohledně noatime, na jednom starším stroji s kernelem 2.4.34 mi -o noatime zvedlo průchodnost čtení z EXT3 na mirroru ze dvou SATA disků cca na dvojnásobek

Pokud se týče sekvenční průchodnosti linuxového soft-RAIDu, hodně záleží na SATA řadiči. Některé generace ICH se čtyřmi nebo šesti porty SATA se chovají tak, jako kdyby vždycky dva disky byly pohromadě na jednom IDE kanálu (dědictví časů paralelního IDE?) a "dělí se o pásmo", tj. jeden disk jede 100 MBps, ale pokud zatížíte dva sousední disky, tak jedou 100 MBps *dohromady*. Pokud ty dva disky rozhodíte na "nesousední" SATA porty, najednou jedou 100 MBps každý. Pokud potřebujete osadit všecky SATA porty, tak se tomu sdílení třeba nevyhnete. Jedná se samozřejmě o sekvenční MBps - pokud systém visí na IOps (čeká na hlavy až zaseekují), tak se tohle úzké hrdlo neprojeví. Některé ICH se chovají v tomto ohledu líp, pokud je přepnete do AHCI režimu. Naopak jsem ale potkal některé varianty ICH (tuším ICH7 nebo ICH9), kde byl AHCI režim asi o půlku pomalejší oproti režimu "native SATA". U některých variant ICH (ICH5, ICH6) byla šíleně pomalá IDE emulace nad SATA diskem, u jiných není žádný rozdíl mezi "native SATA" režimem a emulovaným IDE... prase aby se v tom vyznalo. Chce to změřit a porovnat. Jedna věc se ale zdá být v benchmarcích vcelku konstantní: on-chip SATA porty Intel ICH pořád ještě vítězí na celé čáře nad integrovanými řadiči konkurence

Barracuda 7200.12 dostala 500 GB na jedinou plotnu, proto má vyšší hustotu záznamu. Pokud se při zdvojení objemu dat na plotnu data zahustí v obou rozměrech rovným dílem, vychází z toho zahuštění stop i zrychlení interního přenosu cca 1.4x (nebo-li, sekvenční přenosová rychlost disku roste dlouhodobě v průměru s odmocninou kapacity). Ono to taky znamená, že s odmocninou kapacity roste doba potřebná pro sekvenční přečtení celého disku Proto postupně roste problém toho druhu, že sice můžete levně pořídit do serveru terabajty diskového prostoru, ale při požadované průchodnosti ve smyslu IOps nemáte šanci se k těm datům dostat. Proto mají enterprise disky menší kapacitu a proto se někdy navíc používá ten nápad, že se z každého disku využije jenom malý kousek (malé mezikruží na plotně) - říká se tomu tuším "short-stroking" - tím se zkrátí radiální rozsah seekování, zlepší účinek lokální optimalizace fronty a teoreticky by se měl zkrátit průměrný seek time / zvednout IOps. Jak už jsem psal výše, u desktopových Barracud to kupodivu moc nefunguje.

Rozdíl v rychlosti (a teoreticky i ve spolehlivosti) není ani tak mezi SATA/SAS, jako spíš mezi desktopovými a enterprise disky. Všimněte si někdy na fotkách odkrytovaných disků třeba u Seagatu, jak malé plotny a jak mohutný magnet mají Cheetahy oproti Barracudám. Takže existující varianta Barracudy se SAS rozhraním nikdy nebude tak rychlá, jako 15k Cheetah - a dost možná ani jako SATA Raptor.

[frr]

BTW, RAID5 přes 8 disků a spolehlivost: bývaly doby, kdy RAID6 ještě neexistoval, a RAID5 přes 8 disků byl v klidu. Taky je fakt, že tehdejší disky bývaly spolehlivější, než třeba první série terových Barracud 7200.10. S těmi jsem postavil pár RAIDů 6 přes 16 disků a pár dvojitých výpadků jsem zažil - v jednom případě odešly krátce po smontování dokonce tři disky, ale jednak se mezitím jeden stačil zrebuildovat, druhak to bylo stejně v laborce, takže na tom nebyla ostrá data...

Pokud máte náladu a čas, zkuste si schválně pro různé počty disků spočítat, co je bezpečnější: jestli RAID10 nebo RAID6 (pro 4 a více disků). Není to moc složitá kombinatorika. Podle mého RAID6 vítězí i při poměrně vysokém počtu disků.

[svaca]

Ty jsi se zase rozepsal

JJ velociraptor nebrat, ale to je dano tim, ze je fakt rychly a ma 10krpm, proste proto je tak nespolehlivy ... Jinak rychlost je prave super na SATA disky, ale kvalita HW pokulhava

Na velkem diskovem poli mam taky z duvodu bezpecnosti nasazeny RAID6 a pohoda ...

BTW k tomu read-ahead, pro read-ahead jsou ruzne volby, jake je z duvodu rychlosti nejlepsi pouzit ?

[frr]

Zrovna read-ahead v Linuxu moc ovlivnit nejde - achilova pata. Dá se šáhnout na block-level read-ahead, ale to je dost k prdu, když nad tím jede nějaký FS, který má drobky metadat promíchané s payloadem (ext3 a snad všechny ostatní), a ty potřebuješ optimalizovat sekvenční průchodnost... Pak jsou nějaké syscally, které se dají poštvat na otevřený file descriptor, a ovlivnit tím chování read-aheadu "per descriptor" - ale to napřed musí aplikace tyhle syscally interně používat, což málokterá dělá. Ach jo... V posledních kernelech by se údajně mělo chování per-file/per-stream read-aheadu trochu zlepšovat. Dělá na tom jeden člověk v žoldu firmy Intel.