RAID
Redundant Array of Inexpensive/Independent Disks. Külön szócikk foglalkozik a szoftveres RAID linuxos megvalósításával.
Tartalomjegyzék |
1 Mire jó?
- Sok kis diszk helyett egy nagyot látunk
- Ami ráadásul gyorsabb is
- A CPU-k sebessége sokkal jobban nőtt, mint a tárolóeszközöké...
- És megbízhatóbb is
- És jobb esetben működés közben cserélhető
- Egy diszk MTTF-je (mean time to failure) 200000 óra (22,8 év) is lehet
- Akkor 100 diszké 2000 óra (kb. két és fél hónap - várhatóan ennyi idő múlva romlik el az első)
- Ami ráadásul gyorsabb is
2 Megvalósítás típusai
- Hardware
- Drága vezérlő (ATA, SCSI, ...)
- SCSI-buszra csatlakoztatható RAID-vezérlő is létezik
- Software
- pl. Linux md
- FreeBSD Vinum(?)
- Windows dynamic disk (?)
- Az XP pro csak RAID0-t tud, a szervertermékek RAID1-et is (woah!)
- Hibrid
- Olcsó alaplapok "RAID"-vezérlői
- (Külső doboz: SAN, NAS)
3 RAID-szintek
- Két ortogonális fogalom:
- Csíkozás (striping) a nagyobb teljesítmény, és
- Lehet finom vagy durva
- Rövidebb sorbanállás független I/O műveletek esetén
- Nagyobb effektív átviteli sebesség egyetlen, több-blokkos I/O művelet esetén
- Csökkenti a megbízhatóságot: 10 diszkből egy várhatóan pontosan tizedannyi idő alatt romlik el, mint egyből egy
- Redundancia (redundancy) a nagyobb megbízhatóság érdekében.
- Milyen hibadetektáló/-javító kódot használ? (általában paritás, ritkábban Hamming vagy Reed-Solomon)
- Hogyan osszuk el a redundáns információt a több diszk között?
- Koncentráltan
- Szétterítve
- Csíkozás (striping) a nagyobb teljesítmény, és
- Alapvetően: nagy, megbízható, gyors - ebből választhatunk kettőt (vagy legalábbis az egyik kicsit mindig háttérbe szorul a másik kettő javára)
- Az összehasonlítás nem egyszerű - miben mérjük a teljesítményt? Tranzakció/s? MB/s? MB/s/EUR? Elérési idő (ms)?
- És utána milyen rendszereket hasonlítsunk össze? Az azonos mértékben redundánsakat? Azonos árúakat? Azonos kapacitásúakat?
3.1 Összefűzés
(linear)
- Nincs RAID-sorszáma
- Egyszerűen egymás mögé rakjuk a diszkeket; az első diszk utolsó blokkja után jön a második diszk első blokkja.
- Nincs benne redundancia.
- A többszálú olvasás és írás szerencsés esetben eloszlik a diszkek között, kevésbé szerencsés esetben nem.
- Nem gyakori.
3.2 RAID0
(striping)
- Nincs redundancia, csak csíkozás
- A legjobb írási sebesség (nem kell kódokat számolgatni és frissíteni)
- A RAID1 tudhat gyorsabban olvasni (több diszken is megvan ugyanaz az adat, tehát olvashatunk arról, amelyik várhatóan a leghamarabb odaér)
- Egy diszk kiesése után a tömb "használhatatlan"
- Elterjedt.
3.3 RAID1
(mirroring)
- Az adatokat nem 1, hanem n>1 diszken tároljuk
- Egyes forrásokban n=2, mások megengednek kettőnél több példányt is
- A tömbhöz tartozhat melegtartalék is (hotspare); erre nem íródnak az adatok, amíg éles diszk ki nem esik
- Ha 8 diszkünk van, akkor 4 kapacitása hasznosul
- Bármelyik kieshet, és a tömb még működik
- Ha szerencsénk van, akár 4 is kieshet, és még működik, de ez már nem garantált
- Nagyon széles körben elterjedt.
3.4 RAID2
(memory-style ECC)
- Hamming kódos
- 4 adatdiszkhez 3 paritásdiszk kell, de a paritásdiszkek száma az adatdiszkek logaritmusával arányos
- A fenti hétből egy eshet ki, négy kapacitása hasznosul
- Nem használják
3.5 RAID3
(bit-interleaved parity)
- A memóriahibákkal ellentétben a diszkek esetében pontosan tudjuk, melyik a rossz, tehát nem kell a Hamming-kód, találhatunk jobbat
- n adatdiszkhez 1 paritásdiszk tartozik
- Bitszintű paritás van, így minden írás minden diszket érint (1. bit - 1. diszk, 2. bit - 2. diszk stb)
- Az olvasásban csak az adatdiszkek vesznek részt
- Pontosan egy diszk eshet ki
- Nemigen használják
3.6 RAID4
(block-interleaved parity)
- Mint a RAID3, de nem bitenként használja az egyes diszkeket, hanem blokkonként ("striping unit", esetleg "stride size").
- Blokkméret alatti olvasási műveletekben csak egy (legfeljebb kettő, ha átlóg) diszk vesz részt
- Blokkméret alatti írási műveleteknél read-modify-write van:
- a többi diszkről is be kell olvasni az adott paritásblokkhoz tartozó adatokat, VAGY
- írás előtt kiolvasni a diszken levő előző adatot és a hozzá tartozó paritást, és
- újra kiszámolni a paritást
- kiírni a módosított adatot és az új paritást
- Példa:
- legyen négy diszkünk, a következő adatokkal: 1010 1111 1100 paritás: 1001
- az 1010 helyére írjuk azt, hogy 1111
- az új paritás 1100 lesz, amit megkaphatunk úgy, hogy
- beolvassuk a másik két adatdiszkről az adatokat és összeXORoljuk az új adatokkal, vagy
- beolvassuk az 1010-t és az 1001-es paritást,
- XORoljuk a régi adatot (1010) az újjal (1111); az eredményt (0101) pedig XORoljuk az előző paritással (1001-gyel)
- a végeredmény így is, úgy is 1100 (ha nem, akkor valami elszámoltam, javítsátok :)
- akárhogy is, legalább négy I/O művelet kell egy kis terjedelmű íráshoz.
- Kivéve, ha cache-ben megvolt a csík többi blokkja vagy az előző paritás
- Mivel csak egy paritásdiszk van, és azt az összes írás érinti, szűk keresztmetszet lehet
- Itt is pontosan egy diszk eshet ki
- Ha kiesett, akkor az olvasás lassú, mert minden olvasáshoz minden diszkről olvasni kell
- A hibás diszket érintő kis íráshoz szintén minden diszkről olvasni kell
- Emiatt fontos, hogy legyen hozzá melegtartalék (hotspare)
- Nemigen használják
- Akkor lehet mégis jó, ha van több lassú és egy nagyon gyors diszkünk - pl. egy lokális diszk és több hálózati
3.7 RAID5
(block-interleaved distributed parity)
- Mint a RAID4, de a paritás is el van osztva
- A RAID1 és a RAID3 tekinthető a RAID5 speciális esetének
- A RAID1 úgy adódik, hogy kétdiszkes RAID5-öt csinálunk (a másik diszk az első inverzét tárolja)
- A RAID3 úgy, hogy úgy választjuk meg a csíkméretet, hogy a legkisebb lehetséges olvasás is minden diszket érintsen
- Emiatt - elméletben - a RAID5 teljesítménye mindenképpen legalább olyan jó, mint a RAID3-é, de ez nem feltétlenül igaz minden konkrét implementációra
- n diszk esetén minden diszken minden n-edik blokk paritásblokk, pl. így (left-symmetric parity distribution):
0 1 2 3 P0 5 6 7 P1 4 10 11 P2 8 9 15 P3 12 13 14 P4 16 17 18 19 ...
- Így szekvenciális olvasáskor minden diszkre sor kerül, mielőtt bármelyikre másodszor is sor kerülne.
- n+1 diszkből itt is n-nek a kapacitását hasznosítjuk
- Minden diszk részt vehet az olvasási műveletek kiszolgálásában
- Kis olvasás, nagy olvasás, nagy írás gyors; kis írás viszonylag lassú (l. fent)
- Pontosan egy eshet ki
- Ha kiesett, akkor az olvasás lassú, mert minden olvasáshoz minden diszkről olvasni kell
- A hibás diszket érintő kis íráshoz szintén minden diszkről olvasni kell
- Emiatt fontos, hogy legyen hozzá melegtartalék (hotspare)
- Nagyon széles körben elterjedt
3.8 RAID6
(P+Q redundancy)
- A paritáson (XOR-on) alapuló redundancia pontosan egy diszk kiesésének túléléséhez elég
- (és csak akkor, ha a diszk úgy romlik el, hogy nem küld adatot - hibás kábel vagy hibás puffermemória esetén rossz adatot küld, és a RAID nem segít)
- az adatok helyreállításához a megmaradt diszkeket egyszer hiba nélkül végig kell tudni olvasni
- reális esély van arra, hogy ez nem fog sikerülni (l. lent)
- Vagyis: jobb hibajavítás kell
- Reed-Solomon
- n+2 diszk kell n diszknyi kapacitáshoz
- Bármely két diszk kieshet
- Amúgy olyan, mint a RAID5; a kis írás még egy kicsit lassúbb (nem 4, hanem 6 I/O művelet)
- Terjedőben
3.9 RAID1+0
- RAID10-nek is hívják, de "van" "valódi" RAID10 is
- Két (vagy több) RAID1 tömböt csíkozással összefűzünk
3.10 RAID0+1
- Mint fent, de két RAID0-tömböt tükrözünk egymásra RAID1-gyel
3.11 RAID1+0 vagy RAID0+1?
Nem mindegy!
- Annak az esélye, hogy egy második diszk kiesése esetén a teljes tömb elszáll, a RAID0+1 esetében (tehát amikor RAID0-ból csinálunk RAID1-et), nagyobb. Pl.:
- legyen 2x8 diszkünk.
- Az a esetben csináljunk ebből két 4-4 diszkből álló RAID0 tömböt, majd ezekből egy RAID1- tömböt (RAID0+1).
- A b esetben legyen 4 db 2-2 diszkből álló RAID1-ünk, és ezekből csináljunk RAID0-t.
- Tegyük fel, hogy egy diszk kiesik.
- Az a esetben az egyik teljes RAID0-tömb összeomlott, a RAID1 féllábú lett.
- A b esetben az egyik RAID1-tömb féllábú lett.
- Tegyük fel, hogy még egy diszk elromlik. Megkora esélyünk van arra, hogy használhatatlanná válik a tömb?
- Az a esetben hét ép diszk van; ezekből négy (az ép RAID1-tömbben levő) kritikus. 4:7 az esélyünk arra, hogy a második hiba katasztrofális lesz.
- A b esetben szintén hét ép diszk van; ebből egy kritikus, az, amely az előbb féllábúvá vált RAID1-tömb másik lába. 1:7 az esélyünk arra, hogy a második hiba katasztrofális lesz.
- Általánosítva: RAID1+0 esetén 1/(n-1) eséllyel katasztrofális a második hiba; RAID0+1 esetén (n/2)/(n-1) eséllyel. A diszkek számának növelésével a két elrendezés közötti különbség egyre nő.
- (Persze ha két tetszőleges diszk kiesését túl kell élni, amúgy is RAID6-ot használunk, hotspare-rel.)
- Egyébként a RAID0+1-hez speciálisan felokosított implementáció hiányában nem elég egy hotspare, míg a RAID1+0-hoz igen, hiszen:
- RAID1+0 esetén két, egy-egy diszkből álló RAID1 tömbünk van
- lehet egy további diszkünk, ami a két tömb közös hotspare-je
- bármelyik diszk kiesése esetén a féllábúvá vált RAID1-tömbbe berakhatjuk ezt a diszket és rámásolhatjuk a tömb másik feléről az adatokat
- Viszont: RAID0-ban nem értelmezett a hotspare fogalma, hiszen nincs redundancia, nincs honnan odamásolni az adatokat az új diszkre
- tehát ha két RAID0-tömbből csinálunk RAID1-tömböt, és kiesik egy diszk, attól a RAID1 féllábú lesz, és egy hotspare RAID0-tömbbel (vagy a kiesett RAID0-tömbbel legalább megegyező méretű egyetlen diszkkel) tudnánk helyettesíteni a kiesett RAID0-tömböt.
- Egy speciális, okos implementáció persze tudhatja, hogy a kiesett diszken levő adatok a RAID1-hez tartozó másik RAID0-tömb egyik részében is megvannak, de alapértelmezés szerint a teljes RAID0-tömb kiesik, ha az egyik fele kiesik. A RAID0 és a RAID1 két különböző logikai szinten van megvalósítva, ezért a RAID1 számára az a két RAID0-tömb, amiből felépül, két általános blokk-eszköz, fekete doboz, ismert belső struktúra nékül.
- Ezért a RAID1-ben meglevő redundanciát felhasználva nem tudjuk helyreállítani a kiesett RAID0-tömböt, viszont megtehetjük, hogy
- eldobjuk a hibás RAID0-tömböt
- a megmaradt jó diszkből és a spare-ből csinálunk egy új RAID0-t
- ezt hozzáadjuk a féllábú RAID1-ünkhöz
- így az új RAID0-ra rámásolhatók a másikon levő adatok, csak, mivel két diszknyit kell másolni, valószínűleg tovább fog tartani
- bár nem kétszer annyi ideig, hiszen a RAID0-ról gyorsabban olvasunk és írni is gyorsabban írunk rá, mint egyetlen diszkről/-re
- viszont több I/O sávszélesség kell
- és nagyobb valószínűséggel futunk rá kijavítatlan bithibára, mert nem egy, hanem két diszket kell hibátlanul végigolvasnunk a helyreállításhoz
- (az új RAID0-tömb nem fogja tudni, hogy "a fele már jó")
- Összefoglalva: RAID1 over RAID0 esetén jóval bonyolultabb az egydiszkes melegtartalék kezelése és nagyobb az esély a tartalék szinkronizálása közbeni adatvesztésre bithiba miatt.
A Solaris SVM nem tud RAID0 over RAID1-et létrehozni, csak RAID1 over RAID0-át, viszont az így létrehozott tömb mégis RAID0 over RAID1-ként fog működni, ha a diszkek egyformák. Ez nem vicc, a Sun hivatalos dokumentációja írja ezt, bár most hirtelen csak egy sunos blogban találtam meg. Akit érdekelnek az implementáció részletei, olvassa el.
3.12 RAID10 vagy RAID 1e
- Elvileg egy RAID1+0-jellegű hibrid megoldás
- Egy komplex tömb, nem két egymásra épített
- Állhat páratlan számú diszkből is
- Így aztán lehet az egésznek egy hotspare-je, ami bármelyik diszk kiesése esetén beállhat
- A Linux kernel támogatja
4 További trükkök
- Ha úgyis van hotspare, ami nem csinál semmit, miért ne használjuk valamire azt is?
- Distributed sparing
- Főleg akkor van értelme, ha viszonylag sok a tartalék-diszk az éleshez képest
5 Hardveres vagy szoftveres RAID?
A (nyílt) szoftveres megvalósítás mellett szól:
- rugalmasság
- Különböző vezérlőkön lógó diszkek is lehetnek egy tömbben;
- sőt, egy RAID-tömb állhat teljesen különböző technológiákat használó eszközökből (pl. USB-s flash drive+SATA diszk+network block device/iSCSI)
- segít csökkenteni a kritikus pontok (SPoF) számát - pl. egy tömb minden diszkje lehet másik vezérlőn, vagy akár másik városban
- partíciókból is építhető tömb, nemcsak diszkekből
- nemigen érdekli, melyik diszket hova dugjuk, amíg megvan mind
- a RAID-vezérlők firmware-je gyakran hibás, de a frissítés nehézkes és a hibák nehezen derülnek ki
- a szoftveres megoldásnál viszonylag egyszerű a hibakeresés (van forráskód, amit el lehet olvasni)
- nyilvános az adatformátum
- nem kell mindig ugyanolyan vezérlőt venni
- a diszkek szabadon mozgathatók egyik gépből a másikba)
- egy RAID1 tömb minden diszkje külön-külön is használható más-más gépben
- (hardware raid esetén még gyártó két vezérlője közötti mozgatás esetén is szükség lehet dump-restore ciklusra)
- van olyan hardveres RAID-megoldás is, pl. az Areca, aminek az adatformátuma nyilvános, de kérdés, mire megyünk ezzel a gyakorlatban - ha valaki tudja, írja ide
- A gép CPU-ja tipikusan sokkal gyorsabban futtatja a RAID5-höz szükséges XORt, mint a RAID-vezérlő mikrokontrollere
- Persze ez egyben hátrány is, hiszen ezt is a CPU-nak kell csinálnia
- Viszont CPU-t egyszerűbb upgrade-elni, mint RAID-vezérlőt
- A CPU-magok számával nő a RAID5 sebessége
- Tehát: nem igaz, hogy egy hardveres RAID szükségszerűen gyorsabb lenne, mint egy - mondjuk azonos árfekvésű - szoftveres megoldás
- költséghatékonyság: általában olcsóbb több RAMot és gyorsabb CPU-t venni, mint gyorsabb RAID-vezérlőt
- termék-életciklus: régi RAID-vezérlőhöz többnyire nincs támogatás, firmware-frissítés stb. (sőt, esetleg már a gyártó sincs meg)
- egységes felhasználói interfész (amúgy minden RAID-vezérlőnek más)
- naplózás, hibakezelés szintén különbözhet, nemcsak a tömbök összerakásához használt eszköz
- pl. hardveres RAID esetén nem magától értetődő, hogy a syslogban megjelenik minden hiba (pedig ez segít a diszkhalál előrejelzésében)
- a RAID-vezérlő funkcióinak halmaza adott; a szoftver-RAID fejlődik, anélkül, hogy hardvert cserélnénk
- funkcionalitás: a legtöbb hardveres megvalósítás nem támogatja a RAID6-ot és a RAID10-et (ami nem RAID1+0)
A hardveres megvalósítás mellett szól:
- a softraid jobban terheli a rendszerbuszt
- RAID1-nél azért, mert több példányban kell a buszra küldeni minden írást
- RAID5-nél azért, mert a paritást is át kell tolni a memóriából a diszkre
- a vezérlőn levő akkumulátor segítségével áramszünet esetén is a diszkre írható a cache tartalma
- a PC-hardver bizonyos típusú hibákra nincs jól felkészítve, úgyhogy ha egy diszk bedöglik, lefagyhat a gép, és oda a rendelkezésreállás
- a hardveres RAID-vezérlőhöz lehet színes-szagos konfigurációs program, akár linuxos is - ha szeretjük az ilyesmit, ezt akár előnynek is felfoghatjuk
- vagy persze hátránynak, mivel természetesen nem szabványos, csak az adott gyártó termékeivel, esetleg csak bizonyos termékeivel működik
6 Az ellen nem véd
... és egyéb problémák
- Emberi mulasztás ("rm -rf * /*")
- Vezérlőhiba
- Szoftverhiba
- Hirtelen rendszerleállás esetén félbeszakadhat írási művelet - hibás lesz a paritás
- P+Q redundancia esetén mindkét paritás érvénytelen lesz, mintha két diszk is kiesett volna
- Ennek elkerülésére naplózást lehet használni (vezérlő megoldhatja elemes RAMban, softRAID csak diszken)
- Piszkos tömb indításakor újra kell számolni a paritást (jó esetben tudjuk, melyik adatok paritását)
- A diszk által észlelt, de nem javítható bithibák
- 10^14 bitenként, vagyis 11 terabyte-onként várhatóan kb. 1 ilyen van
- Pl. a lemez öregedése, külső mágneses hatások vagy ilyesmi miatt
- Ezt a RAID amúgy javítja, de ha már nem redundáns a tömb, egy ilyen miatt esetleg nem helyerállítható
- Irodalmi példa: egy 100GB-os degradált tömb esetén 0,8% eséllyel veszítünk adatot
- A diszk monitorozása (pl. S.M.A.R.T.) segíthet előrejelezni a diszkhalált, úgyhogy még időben berakhatunk hotspare-t (ha nem lett volna eleve)
- A diszkhibák gyakran korreláltak
- Pl. mert környezeti hatások okozzák őket (tűz, földrengés, meteorbecsapódás, Armageddon; vagy akár csak táphiba, bekapcsolás...)
- A diszkek a várható élettartamuk elején és vége felé nagyobb eséllyel hibásodnak meg (kádgörbe)
- Típushibák által érintett diszkek is romolhatnak el közel egyszerre
- Vagyis alapesetben is reális esély van arra, hogy az egyik diszk hibáját viszonylag hamar követi egy másik diszk hibája
7 Ajánlott irodalom
Az itt fel nem sorolt irodalommal bánjatok óvatosan! RAID-ügyben sok a makacs mítosz és téveszme. Könnyű önellentmondást tartalmazó ismeretterjesztő cikket találni (pl. kijelenti, hogy a hardveres RAID mindenképpen gyorsabb bármilyen szoftvermegoldásnál, majd kiméri, hogy vannak konkrét esetek, amikor a softraid a gyorsabb...).
- Peter M. Chen, Edward K. Lee, Garth A. Gibson, Randy H. Katz, David A. Patterson: "RAID: High-Performance, Reliable Secondary Storage", ACM Computing Surveys (CSUR), Volume 26, Issue 2 (June 1994), pp. 145-185, ISSN 0360-0300
- Van benne szép ábra is, nem akar esetleg valaki hasonlót rajzolni nekünk?
- Nagyon jó, alapos cikk; az elején van egy jó összefoglaló a RAIDek működéséről, aztán megbízhatóságmodellezés, RAID-implementáció-tervezés, esettanulmányok, kitűnő irodalomjegyzék ...
- (csak sajnos kicsit régi)
- A cikk eleje HTML-ként, ábrák nélkül
- Tomka Gergely: RAID és ENBD - gyakorlati útmutató. Könnyed bevezetés a RAID, az LVM és az ENBD (Enhanced Network Block Device) használatába.
- Why software RAID? - érvek pro és kontra a hardver-RAID vs. szoftver-RAID vitában.
- RAID Classifications - egy jó összeállítás az egyes RAID-szintekről, ábrákkal.
- Why is RAID 1+0 better than RAID 0+1?