 Blíží se nám konec našeho miniseriálku a v jednom z posledních dílů se podíváme na "trhače asfaltu". Řeč bude o složených diskových polích RAID0+1, RAID10, RAID50 a RAID60.
Proč trhači asfaltu? Možná si vzpomenete v našem prvním díle (zde) na diskové pole/nepole typu RAID0, neboli stripe set. Tohle pole postrádá důležitou vlastnost - redundanci, ale zato poskytuje enormní výkon. Dokonce tak enormní, že to nedalo spát vývojářům a architektům a vytvořili specifikace polí, která nějakým způsobem využívá vlastnost RAID0.
Začneme polem RAID0+1
Schválně jsem neuvedl zkrácené požadavky, které vedly k tomuto poli, jelikož jsou v podstatě shodné s požadavky na RAID10, ale na rozdíl o poměrně masivně nasazovaného RAID10 jsem RAID0+1 v praxi nikde nepotkal. Výkonostní parametry RAID0+1 a RAID10 jso totiž až do výpadku jednoho z disků shodné.
Co tedy je RAID0+1? Je to pole složené alespoň ze 4 disků (technicky má význam použití právě 4 disků), kdy je nejprve z disků 1+2 a 3+4 vytvořen RAID0 (dvojnásobná kapacita a dvojnásobná propustnost, velmi často subjektivně poloviční latence) a tyto dvě pole jsou pak vzájemně zrcadleny, tedy je na ně aplikován redundantní RAID1.
A první trhač asfaltu je na světě. Plnohodnotné pole má totiž využitelnou kapacitu 50% použité diskové kapacity, propustnost zápisu 2x větší s minimálním nárůstem latence při čekání na nejpomalejší disk, propustnost čtení 4x větší! Zápis je "pouze" dvakrát rychlejší, jelikož se identická data zapisují na oba svazky zároveň, nelze tedy zápis urychlit tolik.
Nevýhody ovšem jsou tři, s tím, že poslední může být při dostatečné paranoie pouze relativní:
1. Při pádu jednoho z disků vám odejte rovnou půlka pole, jelikož druhý disk do páru pro RAID0 použít nelze a spadnete tak na propustnost běžného RAID0 přeživšího páru.
2. V okamžiku spuštění procesu obnovy musí řadič diskového pole (HW nebo SW) odzrcadlit všechna data z živých dvou disků na oba oživené disky. Zkopíruji tedy celou kapacitu pole a vystavím riziku všechna data vysokou zátěží zbylých disků.
3. Přidáním další dvojice disků nezískávám kapacitu, ale redundanci. Klesá mi tedy "výtěžnost kapacity", narůstá mi rychlost čtení, ale kapacita nepřekročí dvojnásobek nejmenší použité kapacity jednoho disku.
Tyto nevýhody jsou podle mého důvodem zanedbatelného využití v praxi.
Požaduji maximální rychlost, ale výpadek dat si nemohu dovolit - RAID10
Tohle pole má myslím nejširší uplatnění v databázových serverech a v dalších aplikacích, požadujících maximální rychlost, ale bez zaplacené ceny rizika výpadku dat. A právě databáze s velikou transakční zátěží musí mít alespoň nějaká úložiště maximálně spolehlivá. Představte si třeba takové měsíční vyúčtování u mobilního operátora. Má miliony účtů, každý z těchto účtů má desítky, stovky ale klidně i tisíce záznamů o hovorech a dalších použitých službách. Každá taková služba se musí ocenit, zaúčtovat a zařadit do detailního výpisu k faktuře. A teď si představte, že tedy uděláte pracně zálohu před takovým cyklem, který běží třeba 2 dny a běží 2x do týdne, aby se všichni zákazníci stihli jednou měsíčně obeslat. Záloha ale taky něco zabere, řekněme, že půl dne. Spustíte běh a v půlce vám spadne jeden disk ve zpracování. Musíte obnovit data, řeknete si možná. No jo, ale co s těmi daty, které od spuštění (celý den běhu) přišly? Zkrátka na tohle spoléhat nejde a vím, že právě mobilní operátoři mají data uložena v reálném čase s redundancí dosahující a přesahující 400% a k tomu ještě počítejte běžné zálohy.
No zpátky k polím: Někomu z vás už určitě došlo, že toto pole je poskládáno obrácenou logikou, než jeho předchozí bratříček. Ano, je to přesně tak. RAID10 potřebuje sudý počet disků, nejméně však 4. Nejprve se podle pořadí disků v poli vytvoří zrcadla RAID1 a ta se potom spojí do stripe setu RAID0 (z toho tedy RAID10, neboli nejprve RAID1 a pak RAID0).
 Tento trhač má tedy vždy 50% využitelné kapacity v porovnání s použitou, čtyřnásobnou rychlost čtení (pokud použijete 4 disky), dvojnásobnou rychlost zápisu (bez ohledu na počet disků) s případným čekáním na nejpomalejší disk. Co je nejdůležitější: V případě pádu jednoho disku mu spadne čtení na trojnásobek základu a zápis zůstává na původní rychlosti! Navíc, pokud si takové pole postavím ze 6, osmi a nebo více disků, kapacita lineárně narůstá a rychlosti také. Představte si tedy výkon enterprise pole o dvou řadičích, na každém 16 SAS disků s rychlostí otáčení 15000 (řadič a disky) a SSD budou tiše závidět, obzvlášť když použijete třeba ty Seagate 600GB a tento trik, kdy využijete jenom nejrychlejší vnější část disku.
Nevýhoda je zjevná, ale podle mých zkušeností s DB serverů relativně marginální: Může vám odejít až polovina disků, ale nehoda se vždycky musí "trefit" do zatím nezasaženého páru.
Mám dost peněz na hodně disků, ale zase chci slušnou výtěžnost kapacity a dobrou bezpečnost dat - RAID50
Po předchozí části už si dovolím popis lehce zkrátit. Většina z vás asi tuší, že RAID50 je kombinace RAID5 a RAID0. Ano, je to přesně tak. Nejmenší počet disků je 6. Disků je vždy třeba sudý počet a využitelná kapacita při N discích, kdy N je sudé číslo je N-2/N. Využitelnost tedy asymptoticky stoupá s počtem disků a začíná na 66%.
Nejběžnější použití jsou i velkých datových skladů, které mají vysokou sekvenční zátěž. Řekněme třeba velká webová farma s mnoha relativně malými soubory a potřebou provozu 24*7: Třeba WAP portál, nebo obrazová banka.
Nevýhody jsou stejné, jako u RAID5 samotného: V okamžiku pádu disku je nutné chybějící data dopočítávat, ale jelikož je většinou tento typ pole řešen pomocí HW řadiče, zpomalení je obyčejně marginální.
Mám dost peněz na hoooodně disků, chci slušnou výtěžnost kapacity a špičkovou bezpečnost dat - RAID60
RAID60 je kombinace RAID6 a RAID0. Nejmenší počet disků je 8. Disků je vždy třeba sudý počet a využitelná kapacita při N discích, kdy N je sudé číslo je N-4/N. Využitelnost tedy asymptoticky stoupá s počtem disků a začíná na 50%.
Nejběžnější použití jsou opět velké datové sklady, ale vzhledem k vyššímu zabezpečení dat pomocí dvojité parity se používá na citlivější data, respektive na data, jejichž ztráta nebo výpadek by byla velmi drahá. Takové pole pak postavíte z mnoha disků (řekněme 12 a více, kdy je využitelnost už slušných 66%), kdy získáte dost slušnou propustnost 10 disků při čtení a 10 disků pro zápis a bezpečnost 2 disků on-line. Takže nejběžnější použití budou transakční úložiště platebních portálů, jejichž výpadek stojí řádově stovky dolarů za minutu na ušlém zisku nebo poškozeném jméně. Opět již jmenovaní telefonní operátoři na B2B kanálech a tak podobně.
Nevýhody jsou stejné, jako u RAID6 samotného: V okamžiku pádu disku je nutné chybějící data dopočítávat, ale zpomalení je opět marginální ze stejných důvodů. Jako v předchozím případě.
A na závěr něco pro opravdu mlsné jazýčky: Tohle pole od IBM se jmenuje DS8700 a umí kapacitu od 1.1TB do 1024TB, on-line šifrování dat na vybraných discích, nacpete do něj jak SATA a SAS tak SSD disky (15k o 7200 otáček), umí se geograficky replikovat s jinou takovou potvorou, takže máte dvě vzdálená datacentra s daty ve dvojím a vícerém vydání on-line, pohání jí až 4 POWER6 IBM CPU s 32-384GB pamětí/diskovou cache a nacpete do ní 16-1024 3.5" disků. Navíc se k tomu lze připojit až 32 servery pomocí optických řadičů. No nekuptet to!
No a to máme z běžných polí všechno, příště se koukneme na způsoby opravy některých polí, aneb padlo to, co s tím?
| AUTOR: Jan Kořínek |
|---|
| V IT jsem už 18 let a z toho jsem posledních 5 let vedl webhostingovou divizi. V tuto chvíli už působím jen jako externí konzultant - specialista na Linux, počítačové sítě a bezpečnost.
A jelikož si od IT odpočívám, otevřeli jsme si se ženou kavárničku. |
|
 "RAID60 (Zdroj: http://upload.wikimedia.org/)")
