RAID
A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(bővítés 2007: v0.3) |
(bővítés 2007: v0.9) |
||
5. sor: | 5. sor: | ||
* Sok kis diszk helyett egy nagyot látunk |
* Sok kis diszk helyett egy nagyot látunk |
||
** Ami ráadásul gyorsabb is |
** 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 megbízhatóbb is |
||
*** És jobb esetben működés közben cserélhető |
*** És jobb esetben működés közben cserélhető |
||
− | *** Egy diszk MTFF-je 200000 óra is lehet |
+ | *** 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) |
+ | *** Akkor 100 diszké 2000 óra (kb. két és fél hónap - várhatóan ennyi idő múlva romlik el az első) |
== Megvalósítás típusai == |
== Megvalósítás típusai == |
||
+ | |||
* Hardware |
* Hardware |
||
** Drága vezérlő (ATA, SCSI, ...) |
** Drága vezérlő (ATA, SCSI, ...) |
||
23. sor: | 25. sor: | ||
* (Külső doboz: SAN, NAS) |
* (Külső doboz: SAN, NAS) |
||
− | == RAID szintek == |
+ | == RAID-szintek == |
* Két ortogonális fogalom: |
* Két ortogonális fogalom: |
||
30. sor: | 32. sor: | ||
* Másfelől: 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) |
* Másfelől: 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? |
||
* Csíkozás: |
* Csíkozás: |
||
42. sor: | 46. sor: | ||
*** Koncentráltan |
*** Koncentráltan |
||
*** Szétterítve |
*** Szétterítve |
||
+ | |||
+ | === Ö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. |
||
=== RAID0 === |
=== RAID0 === |
||
+ | |||
+ | (striping) |
||
* Nincs redundancia, csak csíkozás |
* Nincs redundancia, csak csíkozás |
||
49. sor: | 65. sor: | ||
* 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) |
* 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" |
* Egy diszk kiesése után a tömb "használhatatlan" |
||
+ | * Elterjedt. |
||
=== RAID1 === |
=== RAID1 === |
||
+ | |||
+ | (mirroring) |
||
* Az adatokat nem 1, hanem n>1 diszken tároljuk |
* 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 |
* 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 |
* Ha 8 diszkünk van, akkor 4 kapacitása hasznosul |
||
** Bármelyik kieshet, és a tömb még működik |
** 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 |
** 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. |
||
=== RAID2 === |
=== RAID2 === |
||
+ | |||
+ | (memory-style ECC) |
||
* Hamming kódos |
* Hamming kódos |
||
* 4 adatdiszkhez 3 paritásdiszk kell, de a paritásdiszkek száma az adatdiszkek logaritmusával arányos |
* 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 |
* A fenti hétből egy eshet ki, négy kapacitása hasznosul |
||
− | * Nemigen használják |
+ | * Nem használják |
=== RAID3 === |
=== 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 |
* 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 |
* n adatdiszkhez 1 paritásdiszk tartozik |
||
− | * Minden írás minden diszket érint |
+ | * 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 |
* Az olvasásban csak az adatdiszkek vesznek részt |
||
* Pontosan egy diszk eshet ki |
* Pontosan egy diszk eshet ki |
||
76. sor: | 101. sor: | ||
=== RAID4 === |
=== RAID4 === |
||
− | * Mint a RAID3, de nem bitenként használja az egyes diszkeket, hanem blokkonként (striping unit, esetleg stride size). |
+ | (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: |
* 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 |
+ | ** 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 |
** újra kiszámolni a paritást |
||
** kiírni a módosított adatot és az új 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: <tt>1010 1111 1100</tt> paritás: <tt>1001</tt> |
||
+ | *** az <tt>1010</tt> helyére írjuk azt, hogy <tt>1111</tt> |
||
+ | *** az új paritás <tt>1100</tt> lesz, amit megkaphatunk úgy, hogy |
||
+ | **** beolvassuk a másik két adatdiszkről az adatokat és összeXORoljuk az új adatokkal, vagy |
||
+ | **** beolvassuk az <tt>1010</tt>-t és az <tt>1001</tt>-es paritást, |
||
+ | **** XORoljuk a régi adatot (<tt>1010</tt>) az újjal (<tt>1111</tt>); az eredményt (<tt>0101</tt>) pedig XORoljuk az előző paritással (<tt>1001</tt>-gyel) |
||
+ | **** a végeredmény így is, úgy is <tt>1100</tt> (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 |
* Mivel csak egy paritásdiszk van, és azt az összes írás érinti, szűk keresztmetszet lehet |
||
* Itt is pontosan egy diszk eshet ki |
* 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 |
* Nemigen használják |
||
− | ** Akkor lehet jó, ha van több lassú és egy nagyon gyors diszkünk - pl. egy lokális diszk és több hálózati |
+ | ** 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 |
=== RAID5 === |
=== RAID5 === |
||
+ | |||
+ | (block-interleaved distributed parity) |
||
* Mint a RAID4, de a paritás is el van osztva |
* Mint a RAID4, de a paritás is el van osztva |
||
− | ** n diszk esetén minden diszken minden n-edik blokk paritásblokk |
+ | * 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): |
||
+ | <pre> |
||
+ | 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 |
||
+ | ... |
||
+ | </pre> |
||
+ | ** Í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 |
* 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 |
* 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 relatív lassú |
+ | * Kis olvasás, nagy olvasás, nagy írás gyors; kis írás viszonylag lassú (l. fent) |
* Pontosan egy eshet ki |
* Pontosan egy eshet ki |
||
− | * Széles körben elterjedt |
+ | ** 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 |
||
=== RAID6 === |
=== 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 |
* Reed-Solomon |
||
* n+2 diszk kell n diszknyi kapacitáshoz |
* n+2 diszk kell n diszknyi kapacitáshoz |
||
* Bármely két diszk kieshet |
* Bármely két diszk kieshet |
||
− | * Amúgy olyan, mint a RAID5; a kis írás még egy kicsit lassúbb |
+ | * 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 |
* Terjedőben |
||
120. sor: | 167. sor: | ||
* Így aztán lehet az egésznek egy hotspare-je, ami bármelyik diszk kiesése esetén beállhat |
* Így aztán lehet az egésznek egy hotspare-je, ami bármelyik diszk kiesése esetén beállhat |
||
* A Linux kernel [[Software RAID Linux alatt#RAID-szintek|támogatja]] |
* A Linux kernel [[Software RAID Linux alatt#RAID-szintek|támogatja]] |
||
+ | |||
+ | == 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 |
||
== Hardveres vagy szoftveres RAID? == |
== Hardveres vagy szoftveres RAID? == |
||
157. sor: | 210. sor: | ||
* a vezérlőn levő akkumulátor segítségével áramszünet esetén is a diszkre írható a cache tartalma |
* 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 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 |
||
+ | |||
+ | == 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 |
||
== Ajánlott irodalom == |
== Ajánlott irodalom == |
||
163. sor: | 239. sor: | ||
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...). |
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: [http://www-static.cc.gatech.edu/classes/cs4760_98_fall/papers/raidShort.ps "RAID: High-Performance, Reliable Secondary Storage"], ACM Computing Surveys (CSUR), Volume 26, Issue 2 (June 1994), pp. 145-185, ISSN 0360-0300 |
+ | * Peter M. Chen, Edward K. Lee, Garth A. Gibson, Randy H. Katz, David A. Patterson: [http://www-static.cc.gatech.edu/classes/cs4760_98_fall/papers/raid.ps "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? |
** Van benne szép ábra is, nem akar esetleg valaki hasonlót rajzolni nekünk? |
||
− | ** [http://66.249.93.104/search?q=cache:yPLBqrcg6UEJ:www-static.cc.gatech.edu/classes/cs4760_98_fall/papers/raidShort.ps+%22in+recent+years,+interest+in+RAID%22&hl=hu&gl=hu&ct=clnk&cd=1&client=firefox-a Ugyanez a cikk HTML-ként] |
+ | ** 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) |
||
+ | ** [http://66.249.93.104/search?q=cache:yPLBqrcg6UEJ:www-static.cc.gatech.edu/classes/cs4760_98_fall/papers/raidShort.ps A cikk eleje HTML-ként], ábrák nélkül |
||
* Tomka Gergely: [http://gergely.tomka.hu/raidenbd/raidenbd.html RAID és ENBD - gyakorlati útmutató]. Könnyed bevezetés a [[RAID]], az [[Logikai kötetkezelés|LVM]] és az [http://www.it.uc3m.es/~ptb/nbd/ ENBD] (Enhanced Network Block Device) használatába. |
* Tomka Gergely: [http://gergely.tomka.hu/raidenbd/raidenbd.html RAID és ENBD - gyakorlati útmutató]. Könnyed bevezetés a [[RAID]], az [[Logikai kötetkezelés|LVM]] és az [http://www.it.uc3m.es/~ptb/nbd/ ENBD] (Enhanced Network Block Device) használatába. |
||
* [http://linux.yyz.us/why-software-raid.html Why software RAID?] - érvek pro és kontra a hardver-RAID vs. szoftver-RAID vitában. |
* [http://linux.yyz.us/why-software-raid.html Why software RAID?] - érvek pro és kontra a hardver-RAID vs. szoftver-RAID vitában. |
A lap 2007. szeptember 28., 00:29-kori változata
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
- Redundancia (redundancy) a nagyobb megbízhatóság érdekében.
- Másfelől: 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?
- Csíkozá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:
- 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
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 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
- 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)
- 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
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.