Srovnání výkonu HW a SW RAID pole (diskuse)

[Freud]

Uz jsem nekoliksetrat obnovoval jak SW, tak HW raidove pole, nejcasteji 1, 10, 5 a 6 a tech par procentik udajne rychlejsiho HW pole (vetsinou ty sakra drahe) u mne nikdy nevykoupi obtiznost a castou nemoznost poskladat HW pole po vaznejsi havarii. Se SW raidem se daji delat takova silena kouzla a pole se da casto zrekonstruovat i kdyz jsou disky jednou hlavickou v kosi.

[Foo Bar]

A jak do SW pole přidáte baterkou zálohovanou cache?

[Jary]

UPS nestačí proč?

[Foo Bar]

Vám ještě nikdy neshořel zdroj v serveru/počítači? A když tam jsou dva, tak vám při tom vzal i ten druhý zdroj? Nebo chyba v jádře, která způsobí pád jádra v půlce zápisu? Nebo telehouse, který i přesto, že běží na UPSkách, tak vypnul třetině zákazníků napájení?

Prostě pokud máte data, kterých si opravdu vážíte, tak musíte každý zápis fsyncovat, tj. nepoužívat cache v operačním systému. A ve chvíli, kdy fsyncujete, tak potřebujete kvůli výkonu write cache na řadiči a tu u slušných řadičů nezapnete, pokud ji nemáte zálohovanou baterkou.

Jasně, že pokud máte RAID kvůli rychlosti stahování warezu, tak klidně může být na SW raidu. Stejně tak systém může být v klidu na swraidu. Ale původní autor píše, že by se databáze měly dávat na HW raid kvůli rychlosti, což je jenom část pravdy. Ta důležitější část je o tom, že si u HW raidu můžete být jistí, že po fsyncu data jsou zapsána a zapsána budou a nemusíte přitom přijít o výkon.

Další opomenutý fakt je ten, že autor nikde nepíše o tom, že by na SATA discích v konfiguraci SW raidu vypnul cache na discích, což standardně HW raidové řadiče dělají, právě z důvodů toho, aby byly schopni říct, že zápis opravdu proběhl.

Osobně se zajímám o tuto problematiku jen v rámci práce a rozhodně si nepřipadám v této oblasti jako odborník, ale přijde mi, že když se autor chlubí tím, jak se nezabývá souborovými systému, tak by článek nemusel být takhle strašně odfláknutý .

[atan]

A HW raid je jako neznicitelny?

[Foo Bar]

To jsem netvrdil.

Chtěl jsem ti jen říct, že rozhodování mezi SW a HW raidem by nemělo být (jen) na základě rozdílu ve výkonu.

[Michal Fecko]

... sranda začíána keď HW raid po záruke odíde - a teraz babo raď - čo s dátami - jasna voľba SW RAID... koľko dát sa môže stratiť z cache pri SW raide? 16 - 32M ? A koľko keď odíde HW RAID?

[Maverick]

Já jsem s havárií po záruce neměl vážný problém, i když mě maličko zatrnulo.

Sehnání nového (kompatibilního) řadiče pro IBM x345 mě trvalo cca 8 hod. včetně dopravy Obnova pole proběhla bez nejmenších komplikací.

A taky jsem zjistil, že s takovým problémem si servicemani značkových výrobců poradí (alespoň PCNet a IBM).

[Michal Ludvig]

Z mych zkusenosti mnohem vic zalezi jestli jde o SATA nebo SCSI/FC disky. Nevim jak moc se lisi vlastni HW disku mezi SATA a SCSI, ale fakt je ze pri velkych zatezich SATA disky nestihaji. I kdyz se vyrobci levnych serveru snazi tvrdit opak. Mozna to bude tim ze v SCSI je vsechno od radice az pres elektroniku az po HW disku "jen o kousek" vyladenejsi, ale ve vysledku to ma na vykon vyznamny vliv.

[Foo Bar]

Dneska spíš už SAS než SCSI, ale jinak s vámi souhlasím.

[Qaxi]

Ono jde o to na co to pole používáte ...

Pokud na něm máte /home tak ho potřebujete pole veliké, rychlost disků neni až tak důležitá (já vím, já vím ...) protože účel toho FS je aby na něm data ležela a sem tam je někdo přečetl/zapsal ... takže proč ne SATA v nějaké cfg. která umožní výměnu vadného disku za chodu ... ( mluvím např. o 5 TB /home )

Pokud na něm, ale běží DB tak to pole bude mít jiné potřeby - velikost většinou nebude třeba v řádu TB ale musí mít pekelně rychlé čtení a rychlý konzistentní zápis ... no a tady je jasné místo pro FC/SAS

[springer]

pro oblast raid-problematiky plati 1. Kasprzakova veta:

na veskere otazky typu ... - 'mam pouzit HW nebo SW raid' zni odpoved: vy chcete sw-raid!

[Yenya]

To ze jsem rekl? Zajimave.

Ale koneckoncu co uz, pravda to je.

Jeste tady nezaznel muj oblibeny argument, ze HW RAID ma nejakych kdyz dobre pul gigabajtu cache, u ktere navic OS nemuze ovlivnit ktere operace jsou fakt casove kriticke a ktere ne, zatimco SW RAID ma typicky nekolik gigabajtu RAM pocitace pro ruzne optimalizace a preskladavani pozadavku.

-Yenya, http://www.fi.muni.cz/~kas/blog/

[cz_motyl]

verim, ze tento link docela pekne naznacuje rozdily: HW versus SW raid

[Michal Fecko]

verim, ze tento link docela pekne naznacuje rozdily: HW versus SW raid

njn, SW RAID, HW RAID a tadaaaaa HP HW RAID - ten je najsamlepsi

[Let_Me_Be]

Mne to cele prijde trochu na hlavu. Kdyz si koupim HW raid tak urcite pro RAID 6 a ten proste nejde (resp. jde, ale vykonove je to uplne mimo) provozovat softwarove.

[Let_Me_Be]

Ted koukam ze tam testuji i ten RAID 6, od kdy je v jadre implementace Raid 6?

[trekker.dk]

Mám ten pocit, že je tam už několik let.

[Mti.]

No nekde byt musi. To ze to nenabizi instalator debianu (mam to na 4.0) pri instalaci je jedna vec, to ze to pak jeho jadro (bez uprav) zdatne zvlada je vec druha. Mam to tak ve dvou strojich a (zatim?) bez problemu. (6x1TB seagati disky ; nepozaduji vykon ale misto, merit jsem to nejak moc nezkousel).

[Kvakor]

.. tak urcite pro RAID 6 a ten proste nejde (resp. jde, ale vykonove je to uplne mimo) provozovat softwarove.

Proc by nemel jit? Je spousta pripadu, kdy je naprosta vetsina pristupu k disku jenom cteni (kde zadne zdrzeni neni, cte se primo) a zapisuje se jen zridka (nova data atd.). Pak nemusi vadit, ze je vypocet dvou opravnych kodu o dost slozitejsi nez proste XORovani u RAIDu 5.

A samozdreme ze RAID 6 je v Linuxu uz nejakou dobu, ale zatim neni standardni soucasti jadra.

[trekker.dk]

Ale je: Device Drivers - Multiple devices driver support (RAID and LVM) - RAID support - RAID-4/RAID-5/RAID-6 mode (CONFIG_MD_RAID456)

[mobi]

Běženě provozuji SW RAID6 (4 disky SATA) s XFS pro Sambu a pod Vmware a žadný problém s výkonem jsem neshledal...

[Let_Me_Be]

Jak moc to vytezuje procesor?

[mobi]

Za běžného života serveru v podstatě neznatelně.Ale na databázový stroj bych to nedal. Jinak - C2D,965,4GB RAM,Intel 1Gb NIC, Samba cca 30 uživatelů, na tom Vmware server s Win2008 jako TS + x dalších vývojových serverů.

md3 : active raid6 sda5[0] sdd5[3] sdc5[2] sdb5[1]
      616735104 blocks level 6, 64k chunk, algorithm 2 [4/4] [UUUU]
      
md2 : active raid1 sdc2[0] sdd2[1]
      4096448 blocks [2/2] [UU]
      
md0 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1]
      104320 blocks [4/4] [UUUU]
      
md1 : active raid1 sda2[0] sdb2[1]
      4096448 blocks [2/2] [UU]

md3 /home a Vmaware md2 swap md1 / md0 /boot

krom /boot vše xfs

2.6.24 / raid6: using algorithm sse2x4 (5484 MB/s)

Za plného provozu:

hdparm -Tt /dev/md3
/dev/md3:
 Timing cached reads:   2238 MB in  2.00 seconds = 1118.94 MB/sec
 Timing buffered disk reads:  256 MB in  3.22 seconds =  79.62 MB/sec

[Krtko]

Domaci RAID1 mi dava 65MB/sec

[mobi]

Ano, psal jsem při zátěži, pri testech před spuštěním cca 130MB/sec.

[Let_Me_Be]

Premyslel jsem nad pouzitim pro pracovni statnici (s tim ze nad tim chci pouzivat sifrovani), takze vytizeni procesoru je hodne dulezite.

[Petr Tomášek]

Tak si říkám, že úplně ideální RAID by byl HW RADI, který má na disku data ve formátu linuxového SW RADIU ;) Nechcete někdo něco takového postavit?

[Max]

To jsem si říkal také, už když se tady začali hádat, co je lepší ... :D
Zdar Max

[Kvakor]

On by uplne stacil normalmni radic, ktery by mel na sobe velky buffer (nejlepe realizovany nejakou pameti ve slotu) a krome ridiciho procesoru jeste nejaky jednoucelovy procesor na pocitani kontrolnich souctu v onom bufferu (Promisaci tomu na svych radicihc rikaji "RAID accelerator"). Takove zarizeni by melo vyhody jak HW RAIDu (vlastne je to skoro HW RAID), tak SW RAIDU (moznost volby formatu ukladani na disk atd.). Skoda ze zatim ty existujici (treba ty od Promise) zatim maji v Linuxu podporu jen na urovni obycejneho radice/fakeraidu.

[Yenya]

A cemu presne by toto melo pomoct?

Cim mene cache pameti radic ma, tim lepsi kontrolu ma OS nad poradim pozadavku a tim lepsi je odezva systemu (znamy problem drivejsi verze driveru pro 3ware, kde si nadefinovali TCQ frontu o hloubce 1024, pricemz fronta I/O scheduleru byla 512, a tedy I/O scheduler se nikdy nedostal poradne ke slovu).

Podobne - kdyz se podivate na rychlost vypoctu kontrolniho souctu u RAID-5 nebo 6 (vypisuje kernel pri bootu), tak i pro relativne stare pocitace je to nekolik GB/s, pricemz 8-diskove pole pri beznem (= nahodnem) pristupu udela tak do 50 MB/s provozu (pri sekvencnim pak maximalne o jeden rad vic, ale kdo vubec takovy typ provozu ma). Cili ani HW-akcelerovany vypocet kontrolniho souctu nijak zvlast nepomuze.

-Yenya, http://www.fi.muni.cz/~kas/blog/