Dotaz: hardware RAID controler s 2x RAID 1

[Dima]

Mohli byste doporucit neajky harwarovy RAID controller na kterem by se dalo udelat 2x RAID 1 (nemusi byt HOT SWAP) s podporou primo v linuxovem jadre a moznosti monitorovani stavu disku pomoci linuxovych nastroju, naprikald smartd.

Diky.

Odpovědi

[d.c.]

Linux na rozdil treba od OpenBSD nema standardni zpusob komunikace s HW RAIDy. Takze pro samotnou komunikaci je obvykle vyzadovan proprietarni program s divokou syntaxi, ktery casto v podporovane distribuci i funguje a nekdy funguje i v nejake jine. Takoveto utility dodava vetsina vyrobcu radicu, casto jsou dostupne primo od dodavatele HW (coz nebyva totez). Vim, ze Areca i LSI je dodavaji (drive prodaval LSI i radice, ktere byly postaveny na architekture MPT, to jiz davno nejde koupit). Byly pokusy nad tim udelat nejakou zastresujici vrstvu, napr. Einarc. SMARTD s tim nesouvisi, jde o komunikaci na jine urovni. Areca ma tu vyhodu, ze radice maji vlastni ethernet a dokazi poslat e-mail se zpravou, kdyz se neco deje.

[Jezus]

Pokud HW raid, tak už řadič, který něco umí a nebude zbytečně zatěžovat CPU. DELL používá controllery PERC. Dnes aktuální řady H200, H300, H700, nebo starší 6/I . Více zde . Monitorování pak přes MegaCli od LSI.

[R]

Na RAID 1 odporucam linuxovy SW RAID. Je to spolahlive, mas to zadarmo, smartd funguje a nepotrebujes ziadne zlozite binarne sracky.

[Dima]

Jaky je vykonostni rozdil mezi hardwarovym a softwarovym RAIDem v konfiguraci RAID 1.

[alkoholik]

Tezko rict. Ale problemy s vykonem HW RAIDu resi v te konferce celkem casto.

[Max]

Osobně si myslím, že bez cache ten rozdíl nebude tak velký. Ovšem pokud má externí řadič cache + zálohu na baterii, tak pak lze celé pole optimalizovat a čtení/zápis cachovat, popř. nastavovat poměry cache pro zápis vs. pro čtení (pokud to řadič umožňuje. Máme Smart Array a tam není problém nastavit třeba všechnu cache jen pro čtení a pro zápis nic).
Teď tu mám třeba server DL380p gen8 s řadičem Smart Array P420, který má 2GiB cache (běžně máme servery, kde má řadič 512MiB cache).
V jistých věcech tedy dojde k navýšení výkonu. Otázkou je, zda v tvém případě také (záleží, jak využité bude pole).
Zdar Max

[R]

Lacnejsie je kupit si 8 GB RAM do serveru, ktory ju v pripade potreby ako cache pouzije.

[j]

Meles nesmysle, HW radic s cache je vykonostne uplne nekde jinde. Navic je ta cache zalohovana, takze neprides o data kdyz se ti srv vypne, narozdil od te RAMky.

[kyytaM]

Naco je dobre mat server s drahym HW RAIDom bez zalozneho napajania?

[d.c.]

Na co je dobre mit *jakykoliv* server bez bezpecneho napajeni?

[Max]

Neříkej, že na 100% věříš UPS, že ti nelže stav baterie, že se server včas ukončí, že UPS jako taková neselže apod.
Zdar Max
PS: vzhledem k dotazu se asi bavíme o nějaké menší firmě, která má i omezené možnosti backupu ...

[kyytaM]

Kvalitny HW RAID radic stoji nasobne viac ako akceptovatelna UPSka.

[Max]

Osobně považuji jako kvalitní/uspokojivý řadič třeba to, co používá HP : Smart Array P420. Tady začíná cena někde u 16000,-. Podívej se na net, kolik stojí nějaký minimální APC Smart-UPS 1500. A to jsou ups bez "Network Management Card 2", která stojí dalších pár klacků. Ta cena je tam srovnatelná s řadičem, zase bych to tedy nepřeháněl .
Zdar Max
PS: o čem se vlastně bavíme? nějak mi to uniká :-/

[j]

UPSka pro server stoji naprosto totez jako radic, navic ja si svych dat narozdil od tebe vazim daleko vic nez nejakych bezcenych papirku, nehlede na to, ze zadna UPSka nezaruci, ze se stihne cache ulozit.

[alkoholik]

A ja ti prozradim, ze ani baterka na radici ti to nezaruci. V serverovne nam 3x za sebou vyrazili "zalohovane" napajeni a data byla v cudu.
Jestli si vazis dat, zalohuj.

[R]

Vykon moze byt "uplne inde" len preto, ze cache je write-back, takze to vlastne ojebava OS. OS si mysli, ze data su na disku, ale v skutocnosti nie su. Potom je tam bateria, ktora by mala zabranit tomu, aby sa tie data pri vypadku stratili. Co v praxi nefunguje na 100 %.

[dustin]

Asi záleží na použití. V mysql na serveru s HW raid SmartArray máme v konfiguraci

innodb_flush_log_at_trx_commit=1

tedy se po každém komitu se flushne log. Nikdy s tím nebyl problém, HW raid bez problémů stíhal. Na devel stroji se sw raid10 (2x4 disky, tedy 8 spindlů) bez šance, musel se použít

innodb_flush_log_at_trx_commit=2

Takže ano, hw raid s baterií umí některé věci podstatně lépe.

Na druhou stranu flexibilita a cena SW raidu má ve spoustě případů (když člověk nepotřebuje hrubý výkon) navrch.

[R]

HW RAID to "stiha", pretoze ziadny flush v skutocnosti nerobi...

[j]

Vyhoda je predevsim v tom, ze se CPU tema diskama vubec nemusi zabejvat. Pokud ten CPu ma tedy neco na praci, krom obsluhy tech disku. S trochu rozumnym radicem pak funguje trebas hotswap disk tak, ze se na nej data zmigrujou driv, nez se primarni disk podela a vubec nijak to neni znat na vykonu pole.

[dustin]

Hm, zápis možná není znát, ale jak zajistíš stejně rychlé čtení, když v zesynchronizovaném stavu to rozkládá požadavky na čtení na oba/všechny disky? Tvrzení "vubec nijak to neni znat na vykonu pole" se mi nějak nezdá...

CPU má obvykle výkonové rezervy na obsluhu SW raidu dost, aspoň se s tím nesetkávám, všechny servery mají aspoň 4 (většinou 8 a víc) jádra. Spíše to víc zatěžuje sběrnice a samozřejmě je tu otázka toho výpadku při přerušení napájení.

[d.c.]

Za poslednich asi tak 13 let, mozna o neco dele, nepamatuji mnoho pripadu, kdy by HW RAID prinesl vyhodu ve vykonu i/o (zvlaste v pripade RAID1. Obavam se, ze zalohovani cache baterii se ponekud precenuje, i kdyz je to jiste skvely napad. Aby bylo ucinne, je nutne vypnout cache disku. O tom, ze baterie radice pochopitelne nechrani pred ztratou dat v cache operacniho systemu (lazy write) neni treba mluvit. Navic vetsina HW RAIDu ma velmi slabe procesory i sbernice a navrh jejich firmware ma rozhodne jine priority nez treba Linuxove jadro.

[R]

Prave rebuild je pruser na HW RAID radicoch. Kedze firmware radica nevie nic o filesysteme a beziacich procesor, nie je mozne nijako rozumne urcit prioritu rebuildu. Aj velke SANy umoznuju len blbe nastavenie low/medium/high.