Administrace komentářů

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.