Dotaz: HW RAID terminologie (pravy HW, nepravy HW)

[CandySan]

Zdar,

po dlouholetem spokojenem pouzivani md jsem se dostal do situace, ze bych potreboval najit nejaky HW raid radic a ten opakovane po nejakou dobu nakupovat a pouzivat. Narazil jsem na to, ze nejsem schopen rozlisit skutecny hw raid, ktery NEvyuziva hlavni cpu, ale dela vse sam od toho sw radice, ktery je jen coby samostatny radic.

Zde v diskusich, ale i jinde, jsem se docetl o tom, ze existuje tento zasadni rozdil a jedinym voditkem, ktere jsem zatim dokazal pochytit, je cena, ale ani to neni dostatecne spolehlive voditko dokud nebudu znat spravne oznaceni toho skutecne hw raidu. Ani nevim jak se na to ptat dokud to neumim spravne oznacit a spravnym terminem popsat.

Poradite mi pls spravny termin, nebo spravny zpusob jak to uderne popsat pri naslednem hledani vhodneho kandidata?

Diky!

---

---

Odpovědi

[NN]

Asi se ptas na fake raid..

jsem se dostal do situace, ze bych potreboval najit nejaky HW raid radic a ten opakovane po nejakou dobu nakupovat a pouzivat

Proc? Na co?

[CandySan]

Diky! To je hodne zajimave cteni! Potrebuju to pro virtualizacni servery. Dokud tam bylo par virtualek, ktere vykon disku az tak moc nepotrebovaly a virtualkami byly hlavne z duvodu lepsi obsluhy (zalohovani, stehivani ze serveru na server pri upgradech, snapshoty, restart na dalku, kdyz to vytuhlo), tak bylo vse ok... Ted se mi ale zacaly mnozit virtualky, ktere vyzaduji diskovy vykon. Pokud se mi takovych sejde vic, tak roste cas odezvy. Ani nemusi byt ty disky zatizene nejakym vysokym tokem dat, ale odezvy proste rostou

Venoval jsem se tematu a dle ruznych nazoru, ktere jsem na netu obcas nasel, je problem sw raidu v tom, ze se plni fronta pozadavku a to udajne zpusobuje ty delsi odezvy.

Tento clanek to naopak vyvraci. Dokonce uplne! Je jasne, ze nic vyspelejsiho nez md neexistuje a jsem si toho vedom, takze pokud by se ukazalo, ze md neni zdrojem tech potizi, tak bych byl velmi rad!

Obnovenou otazkou tedy je, ze co zpusobuje ty prodluzujici se odezvy..?

Diky moc za ten link!

[petr]

Nic vyspelejsiho nez md neexistuje? Lol. Zfs, btrfs, hw raid. Hw raid je vykonnejsi u vicero raid5/6 poli na jednom stroji, hotswap bez nutnosti pristupu k OS, az ti vypadne jeden disk tak vykonnostny rozdil poznas okamzite.. Zfs pole maji dalsi vyhody ktere s md dosahnes tezko. Podivej se na zapisy, cteni, io obecne, load, jestli mas dostatek ram. Co tam mas za raid? Kolik disku? Kolik ram a jak vyuzitou? Atd... prodluzujici se odezvy muzou mit ruzne zdroje.

[CandySan]

Ano, nektere ficury zfs, nebo btrfs nevyhnutelne nutne potrebuju uz davno a bez nich je kvalita meho zivota vyznamne horsi, ale potrebuju to na linuxu a mam obavu, ze zfs na linuxu neni lety proverena zalezitost a btrfs taky jeste stale neni lety provereny natolik, abych to nasadil plosne na vsech strojich. Takze z techto uvah jsou pro ted vyskrtnuti a zatim pro mne a pro toto vlakno neexistuji v tomto kontextu. Jeste docela nedavno mel btrfs problem treba prave s r5-6 pricemz ne na vsech strojich muzu mit nejaktualnejsi jadro a mam za to, ze tohle jeste stale plati https://btrfs.wiki.kernel.org/index.php/RAID56

Podivam-li se na zapisy a cteni - coz delam kazdou chvili, kdyz resim problem, tak zjistim , ze tam neco zapisuje a neco cte a odpovida to celkem realite. Load se muze v zatezi pohybovat mezi 2 az 2.5 a u viceprocesoroveho stroje to jeste neznamena pretizeni. Pameti mam dostatek. Raid pouzivam md a pocet disku je ruzny na ruznych masinach. Casto jsou to 2 disky v r1 a jinde to byva povicero disku v r5, nebo nekdy v pomalejsim r6.

Uvnitr virtualky muzu spustit kopirovani vetsiho file a lita to krasne, ale potom pri realne praci byvaji stiznosti. Takze si treba nekdy udelam benchmark z vnitrku virtualky a vidim, ze odezvy jsou obcas vyrazne vetsi a ze to obcas muze kolisat. Samozrejme ze se o disk deli vice virtualek a tak jsem dle diskusi na netu dospel k tomu, ze u sw raidu obecne je udajne problem, ktery jsem popisoval vyse. NN poslal dokument, ktery toto zcela popira. Otazkou je, kde je pravda..? Pokud by stale platilo, ze musim volit mezi md a nejakym hw resenim, pak plati ze je to pro mne velka ztrata, protoze hw raid nebude schopen poskytnout to co mi dava md, nebo muze jednou davat zfs a btrfs az se o nich bude vedet, ze uz jsou cela leta bez problemu v provozu a ze je na ne opravdu spoleh. Ale jinak btrfs desne fandim a tesim se na dobu az to budu moct hojne pouzivat.

[SE]

hotswap bez nutnosti pristupu k OS

Přesně, to je na HW RAIDu to nejlepší.

[Jendа]

hotswap bez nutnosti pristupu k OS

…a naopak zápas s vendor-specific utilitami od výrobce. Já nevím, já mám s tímhle dost špatné zkušenosti. Ten jeden příkaz pro výměnu disku v MD mi snad neublíží když mám těch serverů pár, a když bych jich měl stovky, tak to stejně musím řešit nějak jinak.

az ti vypadne jeden disk tak vykonnostny rozdil poznas okamzite

To nechápu - třeba při RAID5 mi rychlost počítání parity na všech strojích podstatně převyšuje rychlost disků.

[CandySan]

Prodlužující odezvy způsobují seeky. Což je principielní charakter HDD. Psal jsem to v jiné diskusi tady. Dedikovaný HW RAID ti pomůže v tom, že má velkou paměť, patrně bateriovou zálohu této paměti, a je schopen tím pádem vůči systému se tvářit jako velký disk a oznámit mu "zapsáno" i když zatím fakticky zapsáno není a drží si to v paměti a v ní optimalizuje pořadí zapsných sektorů a zapíše až bude mít možnost. Bateriová záloha mu dokáže nabrat jistotu, že bude mít dost energie, aby vše z paměti do disků zapsal. Ale pokud budeš potřebovat zapisovat a číst mraky dat přes různé virtuálky a budou rozházené po celém prostoru disku v malých kvantech patrně ucpeš i ten HW raid. Jediné pořádné řešení je přejít na SSD. Pokud se začínáš hltit na odezvách nemyslím, že by ti zfs nebo btrfs pomohl.

[CandySan]

Nojo.. seeky jsou mi jasny, ale mel jsem za to, ze vyznamne bude i to s tim vyuzivanim procesoru v sw raidu. Kdyz koukam na tvuj prispevek, ktery linkujes, tak mi dochazi, ze to musi byt opravdu nejvetsi problem. Podstatne vetsi nez to co resim v tomhle vlaknu a tedy problem z tohoto vlakna je asi nevyznamny. Takze nakonec nezbyva nez prejit na ssd tam, kde to bude nutne a jinde pridat disky, aby jich v r1, nebo r5 bylo vice a bylo alespon cteni rychlejsi.

O baterce v hw raidu vim a vim taky, ze se to musi projevit vyrazne.

Moc diky!

[Jendа]

vyznamne bude i to s tim vyuzivanim procesoru v sw raidu

To bys měl vidět jako nějaký MD kernel thread v htopu.

[j]

... ta zalohovana cache funguje ovsem trochu jinak. Ta baterka tam neni proto, aby se data zapsala, ale proto, aby v te cache zustala i po dobu pripadneho vypadku, a zapsala se az po dalsim startu. Je ale treba kalkulovat s tim, ze je rec o radove maximalne dnech. U tohodle typu HW se nepredpoklada, ze to nekdo bude vypinat na tydny.

Pricemz je to samo jen jeden layer zajisteni, protoze tahle funcionalita se neuplatni, pokud to korektne vypne UPSka.

[Jendа]

Obnovenou otazkou tedy je, ze co zpusobuje ty prodluzujici se odezvy..?

Píšeš o snapshotech - pokud jde o LVM (qcow tím asi bude trpět taky) snapshoty, tak ty se po vytvoření začnou víc a víc zpomalovat (hlavně na rotačních discích extrémně). Oproti tomu snapshoty na úrovni CoW FS (btrfs, ZFS) jsou dost rychlé.

No a pak je tu možnost, že ty disky prostě nestíhají z principu, a pak tomu nepomůže ani svěcená voda ;)

Tento clanek to naopak vyvraci. Dokonce lupne!

Kvalitní HW RAID má jednu výhodu - může si dovolit optimalizovat synchronní zápisy díky tomu, že má baterku pro zálohu cache. Takže ti potvrdí zápis ihned a na disk to zapíše až za chvíli, když se to víc hodí. Teoreticky by tohle mohlo jít emulovat tím, že budeš mít více RAID0 s jedním diskem a nad tím postavíš MD/ZFS/btrfs RAID, ale efektivita využití cache bude nižší.

[CandySan]

LVM snapshoty jsou moc drahy, to vim. Vsechna ta pozorovani jsou ze situace bez jakehokoliv prave existujiciho lvm snapshotu. Na to mam postup jak je vytvorit, udelat zalohu lokalne, aby byla co nejrychlejsi a hned zase zrusit. Do zalohy se to potom taha az nasledne, kdyz uz zadny snapshot neexistuje.

ZFS, nebo btrfs snapshoty jsou presne to co bych jednou rad mel

O baterce vim a uz nejakou dobu kolem toho krouzim.

Diky!

[j]

Kazdej snap (jedno jak delanej) ti zvysuje fragmentaci dat na discich a tudiz prodluzuje odezvy.

A ad btrfs(a spol) a cache. Tady narazis na to, zde defakto rozbijes funkcnost btrfs (a spol). Respektive, prave toho raidu. Nemas pak uz garantovany, ze data jsou odolny proti vypadku X disku, kdyz je na discich trebas vubec zapsany nemas. U HW je to o tom, ze ty radice (s tou zalohovanou cache) mas dva.

Apropos, vykon diskovyho subsystemu se navrhuje primarne na pozadovany IOps. Tudiz by bylo zahodno, kdyby si tazatel zmeril, kolik IO v ramci provozu vznika a z toho jaksi samozrejme vypadne, jaky uloziste potrebuje. Jeden 15k disk da 200(max). Dneska se ale uz 15k disky prakticky nepouzivaj. Protoze SSD je o rady jinde.

[CandySan]

Dobra pripominka! Vymyslim nejake mereni a ukladani IOps a pak z toho budu dodatecne vychazet. Diky!

[radek]

nenapsals to nejdůležitější - kolik do toho chceš vrazit?

Pokud ti server vydělává větší lováče, tak kup klidně diskové pole. Nebudeš muset řešit nějaké vymrdávky, když pak budeš přidávat další server ;)

[radek]

teda tak, ty vymrdávky řešit budeš muset, pokud koupíš něco levnějšího.

[CandySan]

Jo, takovou nejakou predstavu mam uz delsi dobu, ale musel jsem nejprve zvladnout problematiku a az nasledne si muzu vypocitat co potrebuju a co se jeste v me situaci vyplati. Nejak jsem si nikdy neumel predstavit pristup typu "mam na to 200 tacu a tak se vejdu cenove do toho a az pak se uvidi zda to vubec melo nejaky smysl a zda nebudu muset stanovovat opet nejakou hranici toho, kolik do toho chci vrazit a naslepo zkouset dal...". Pokud to dobre chapu, tak jakekoliv diskove pole sestava taky z disku, takze problem je potreba spravne uchopit na urovni tech disku a az pak mi z toho muze vyplynout treba jejich umisteni do samostatneho zarizeni, typ, pocet a nejaka logika nad nimi.