RAID

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (RAID10 (más néven RAID 1E): raid1e)
(RAID-szintek: a csíkozás az elérési időt nem javítja)
40. sor: 40. sor:
   
 
* Két ortogonális fogalom:
 
* Két ortogonális fogalom:
** [http://www.pcguide.com/ref/hdd/perf/raid/concepts/perfStripe-c.html Csíkozás] (striping) a nagyobb teljesítmény érdekében.
+
** [http://www.pcguide.com/ref/hdd/perf/raid/concepts/perfStripe-c.html Csíkozás] (striping) a nagyobb átviteli sebesség érdekében.
 
*** Csíkszélesség (stripe width): hány független diszkre íródnak ki a logikailag folytonos adatok (a paritásdiszk(ek)et természetesen nem számítva).
 
*** Csíkszélesség (stripe width): hány független diszkre íródnak ki a logikailag folytonos adatok (a paritásdiszk(ek)et természetesen nem számítva).
 
*** Csíkméret (stripe size): mekkora folytonos adatblokkok kerülnek egy-egy diszkre a csíkozás során.
 
*** Csíkméret (stripe size): mekkora folytonos adatblokkok kerülnek egy-egy diszkre a csíkozás során.
46. sor: 46. sor:
 
**** Kis csíkméret: nagyobb effektív átviteli sebesség egyetlen, több-blokkos I/O művelet esetén, mivel több diszkről olvasunk egyszerre; cserébe ezeket a diszkeket közben nem használhatjuk másra.
 
**** Kis csíkméret: nagyobb effektív átviteli sebesség egyetlen, több-blokkos I/O művelet esetén, mivel több diszkről olvasunk egyszerre; cserébe ezeket a diszkeket közben nem használhatjuk másra.
 
**** Optimális érték: alkalmazásfüggő; általában csak méréssel lehet megállapítani.
 
**** Optimális érték: alkalmazásfüggő; általában csak méréssel lehet megállapítani.
*** Csökkenti a megbízhatóságot: 10 diszkből egy várhatóan pontosan tizedannyi idő alatt romlik el, mint egyből egy
+
**** Egy csíkozott, redundanciamentes tömb elérési idő szempontjából nem jobb, mint egyetlen diszk, hiszen minden adat pontosan egy helyen van meg, vagyis mindenképpen azzal az egy konkrét diszkkel kell "odaseekelni", amelyiken az adat van. Ez nagyon súlyos hátrány! Mindig gondoljunk arra, hogy igaz ugyan, hogy a lineáris írás és olvasás sebessége növekszik diszkek számával, az elérési idő azonban állandó marad, és többszálú véletlen I/O esetén ez fog dominálni, nem az írás és az olvasás időigénye. Ökölszabály: legyen minden adatból annyi független diszken példány, ahány szálon olvasni szeretnénk majd a fájlrendszert (a többszálú véletlen írás persze így is lassú lesz, hiszen minden adatból minden példányt felül kell írni).
  +
*** A csíkozás 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. Fajtái:
 
** Redundancia (redundancy) a nagyobb megbízhatóság érdekében. Fajtái:
 
*** Több azonos másolat (tükrözés, mirroring);
 
*** Több azonos másolat (tükrözés, mirroring);

A lap 2010. november 23., 16:38-kori változata

Redundant Array of Inexpensive/Independent Disks. Olyan megoldás, amely n fizikai merevlemezből m logikai merevlemezt csinál úgy, hogy az adatokat szétteríti több fizikai diszkre a gyorsabb (párhuzamos) írás és olvasás érdekében és/vagy redundánsan tárolja őket, hogy ha a fizikai diszkek valamely hányada kiesik, a logikai diszkeken tárolt adatok továbbra is rendelkezésre álljanak.

Külön szócikk foglalkozik a szoftveres RAID linuxos megvalósításával.

Tartalomjegyzék

1 Mire jó?

  • Például: 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é századennyi, 2000 óra (kb. két és fél hónap - várhatóan ennyi idő múlva romlik el az első)

Megjegyzés: a 22,8 év akkor lenne igaz, ha a megbízhatósági "teknőgörbének" folyamatosan a vízszintes szakaszában tartózkodnánk, ami anyagfáradás és egyebek miatt valószínűleg nem teljesül. Emiatt egy konkrét 200000 órás MTTF-ű diszk esetében nem érdemes arra számítani, hogy valóban 22,8 évig fog működni, de az ergodicitás miatt, ha sok ilyen diszkünk van, akkor a hasznos élettartamuk lejárta előtt kollektíven úgy viselkednek, mintha mindegyik várhatóan 22,8 év múlva romlana el először. Más szavakkal: egy diszk ugyan várhatóan nem 22,8 év múlva romlik el (mert ennél hamarabb ér véget az élettartamának az a szakasza, amelyben úgy viselkedik, mintha 22,8 év múlva romlana el :), de 100 diszk közül az első várhatóan igenis kb. két és fél hónap után romlik el, ami olyan, mintha egyenként mindegyik várhatóan 22,8 év múlva romlana el. Akit ez részletesebben érdekel, vegye fel a Megbízhatóságmodellezés c. tárgyat, vagy olvassa el a tárgy jegyzetét.

Tehát, még egyszer: a diszkekhez megadott megbízhatósági adatokkal akkor tudunk értelmesen számolni, ha "sok" diszkünk van; és ha komolyan vesszük a rendelkezésre állást, nem szabad megfeledkeznünk a többi rendszerkomponens megbízhatóságáról sem.

2 Kapcsolódó fogalmak

  • MAID: Massive Array of Idle Disks (olyan RAID-tömb, amiben nagyon ritkán használt adatok vannak, így az idő nagy részében a diszkek nagy része nem is kell, hogy forogjon).
  • SLED: Single Large Expensive Drive (a RAID ellentéte :).
  • JBOD: Just a Bunch Of Disks (ha több diszkünk van és ezeket külön diszkként is kezeljük).

3 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 hivatalosan csak RAID0-t tud, a szervertermékek RAID1-et és RAID5-öt is (woah!)
  • Hibrid
    • Olcsó alaplapok "RAID"-vezérlői (Linux alatti neve: dm-raid)
  • (Külső doboz: SAN, NAS)

4 RAID-szintek

  • Két ortogonális fogalom:
    • Csíkozás (striping) a nagyobb átviteli sebesség érdekében.
      • Csíkszélesség (stripe width): hány független diszkre íródnak ki a logikailag folytonos adatok (a paritásdiszk(ek)et természetesen nem számítva).
      • Csíkméret (stripe size): mekkora folytonos adatblokkok kerülnek egy-egy diszkre a csíkozás során.
        • Nagy csíkméret: rövidebb sorbanállás független I/O műveletek esetén (egymástól függetlenül kiszolgálható több kérés).
        • Kis csíkméret: nagyobb effektív átviteli sebesség egyetlen, több-blokkos I/O művelet esetén, mivel több diszkről olvasunk egyszerre; cserébe ezeket a diszkeket közben nem használhatjuk másra.
        • Optimális érték: alkalmazásfüggő; általában csak méréssel lehet megállapítani.
        • Egy csíkozott, redundanciamentes tömb elérési idő szempontjából nem jobb, mint egyetlen diszk, hiszen minden adat pontosan egy helyen van meg, vagyis mindenképpen azzal az egy konkrét diszkkel kell "odaseekelni", amelyiken az adat van. Ez nagyon súlyos hátrány! Mindig gondoljunk arra, hogy igaz ugyan, hogy a lineáris írás és olvasás sebessége növekszik diszkek számával, az elérési idő azonban állandó marad, és többszálú véletlen I/O esetén ez fog dominálni, nem az írás és az olvasás időigénye. Ökölszabály: legyen minden adatból annyi független diszken példány, ahány szálon olvasni szeretnénk majd a fájlrendszert (a többszálú véletlen írás persze így is lassú lesz, hiszen minden adatból minden példányt felül kell írni).
      • A csíkozás 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. Fajtái:
      • Több azonos másolat (tükrözés, mirroring);
      • hibajavító kódolás:
        • paritás, vagy
        • többszörös paritás, vagy
        • Reed-Solomon (esetleg kódrövidítéssel);
        • elvi lehetőség a Hamming-kód.
      • Hogyan osszuk el a redundáns információt a több diszk között?
        • Koncentráltan (dedikált paritásdiszk vagy dedikált tükör-diszk); vagy
        • szétterítve (csíkozott paritás, csíkozott tükrözés).
  • Alapvetően: nagy, megbízható, gyors, olcsó -- ebből választhatunk kettőt (vagy legalábbis kettő kicsit mindig háttérbe szorul a másik kettő javára).
    • A gyors diszkek magas fordulatszámúak vagy SSD-k, ezek viszont se nem nagyok, se nem olcsók;
    • ha lassú diszkekből akarunk gyors tömböt, akkor sok kell, ami szintén drága, másrészt nem megbízható;
    • ha megbízhatóságot akarunk, ahhoz redundancia kell, ami drágít, lassít, és helyet foglal.
  • "Melyik a legjobb RAID?" Az összehasonlítás nem egyszerű - miben mérjük a teljesítményt? Tranzakció/s? MB/s? MB/s/€? 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?

A Wikipédia kapcsolódó szócikkében van egy hasznos táblázatos összefoglaló az egyes RAID-szintek jelentéséről és tulajdonságairól; a Standard RAID Levels szócikk pedig az itteni vázlatnál részletesebben írja le őket. Az itt közölt vázlat elolvasása nem elegendő a téma mélyebb megértéséhez, viszont a Wikipédia anyagát átemelni vagy átdolgozni értelmetlen lenne. (A mélyebb' megértéshez a Wikipédia sem elegendő, de az előadáson való részvételt ebben a konkrét esetben majdnem helyettesíti.)

Az alábbiakban legyen B a bruttó kapacitás (a tömbben található fizikai diszkek kapacitásának összege), N a nettó kapacitás (a tömb, mint logikai diszk, tárolókapacitása). Minden RAID-szinthez meghatározható az N/B hányados, amely a tárolási hatékonyságot jellemzi.

4.1 Összefűzés

(linear)

  • Nincs RAID-sorszáma, valójában nem is RAID.
  • Erre a megoldásra is használják a JBOD rövidítést, de mi ne tegyük.
  • 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 nettó kapacitás nyilván megegyezik a bruttó kapacitással (N/B = 1).
  • 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.

4.2 RAID0

(striping)

  • Paraméterei: diszkek száma, csíkméret (ekkora blokkonként írunk az egyes diszkekre).
  • Nincs redundancia, csak csíkozás (vagyis szigorúan véve ez sem RAID, mert nem redundáns).
  • A nettó kapacitás nyilván megegyezik a bruttó kapacitással (N/B = 1).
  • A legjobb írási sebesség:
    • nem kell kódokat számolgatni és frissíteni;
    • csak egy példányban kell átvinni az adatokat a memória és a diszkek között;
    • az összes diszk írhat egyszerre.
  • 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".
  • A megbízhatóság n diszk esetén egy diszk megbízhatóságának n-ed része.
  • Elterjedt.

4.3 RAID1

(mirroring)

  • Paraméterei: diszkek száma.
  • 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 (és az is előfordul, hogy a kettőnél több diszkből álló RAID1-et RAID1E-nek vagy RAID1e-nek nevezik, ami zavart okoz, mert a "RAID10"-et is hívják így időnként).
    • A nettó kapacitás nyilván a bruttó kapacitás n-ed része (N/B = 1/n).
  • A tömbhöz tartozhat melegtartalék is (hotspare); erre nem íródnak az adatok, amíg aktív ("éles") diszk ki nem esik.
  • Ha többszálú I/O-t szolgál ki, akkor a RAID1 olvashat gyorsabban, mint a RAID0.
  • Nagyon széles körben elterjedt.

Ha n elég nagy, akkor olvasáskor akár többségi szavazással is eldönthetjük, melyik adatot tekintjük érvényesnek. Hogy ennek van-e értelme, az a hibamodelltől függ: ha számítunk átállítódásos hibára vagy inkonzisztens írásra (amikor a tömb diszkjeinek csak egy részén fejeződik be egy írási művelet), akkor ez a megoldás lehet jó (bár természetesen lassú).

Az írás atomiságával kapcsolatos, itt csak felületesen érintett problémáról szintén olvashatunk a Wikipédián (és persze a Wikipédia által hivatkozott cikkekben).

  • Elvileg azt is megtehetjük, hogy úgy készítünk biztonsági mentést (vagy akár úgy klónozunk egy rendszert), hogy egy RAID1-tömbből ideiglenesen kivesszük az egyik diszket, lementjük/lemásoljuk, majd visszatesszük (vagy ezt a diszket magát tekintjük innentől mentésnek/klónnak, és a tömbbe egy újat teszünk).
  • Ha visszatesszük a korábban kiszedett diszket a tömbbe, a RAID-megvalósítás kifinomultságán múlik, hogy újra az összes adatot rá kell-e írnia a visszarakott diszkre, vagy csak azokat az adatokat, ami a kivétele óta megváltoztak.
    • Van olyan rendszer, ami eleve azért tartalmaz három diszket, hogy amikor az egyiket kivesszük (nem feltétlenül fizikailag) és lementjük, akkor is redundáns maradjon a tömb.

4.4 RAID2

(memory-style ECC)

  • Hamming-kódot használ hibajavításra.
  • 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 (tehát 7 diszk esetén N/B = 4/7).
  • Az adatok bitenként vannak szétterítve az adatdiszkek között; a Hamming-kód négybites bitcsoportokhoz rendel hétbites hibajavító kódot.
  • Az összes diszk író-olvasó feje egyszerre mozog.
  • Viszonylag gyors szekvenciális olvasást tesz lehetővé, mivel az összes adatdiszk egyszerre olvas.
    • A paritásdiszkek nem tudnak részt venni az I/O-ban, csak hibajavításkor, viszont mindig célszerű a teljes kódot beolvasni, nemcsak az adatbiteket, hogy az adatok integritását ellenőrizhessük. Ez nem vezet (releváns) teljesítménycsökkenéshez, hiszen a paritásdiszkeket amúgy sem használnánk másra, a paritásszámítás pedig minden bizonnyal több nagyságrenddel gyorsabb, mint a diszkről való olvasás.
      • A paritás kiolvasása csak akkor vezethet lassuláshoz, ha a rendszerbusz a szűk keresztmetszet.
  • A Hamming-kód egy átállítódásos hibát tud észlelni és javítani (az egyszerű paritásos rendszerek az ilyen hibát csak észlelni tudják, javítani nem).
  • Merevlemezekhez nemigen használják, mivel ott inkább a törléses hiba a gyakori (a hibás szektrokat egyáltalán nem tudjuk elolvasni, nem hibás adatot olvasunk belőlük).
    • Állítólag maguk a merevlemezek, belül, Hamming-kódon alapuló hibajavítást használnak.
    • SSD-knél lehetne releváns, de talán célszerűbb, ha maga a meghajtó belül használ Hamming-kódot (esetleg paritásbittel kiegészítve, tehát 8 biten 4 bitet tárolva). (Amíg az SSD-ennyire drágák, aligha akar az ember mindjárt hét-nyolc darabot venni...)

4.5 RAID3

(bit-interleaved parity)

  • A memóriahibákkal ellentétben a diszkek esetében általában pontosan tudjuk, melyik a rossz, tehát nem kell a Hamming-kód, találhatunk hatékonyabbat.
  • n adatdiszkhez 1 paritásdiszk tartozik.
  • Bitszintű vagy byte-szintű paritás van, így minden írás minden diszket érint (1. bit vagy byte - 1. diszk, 2. bit vagy byte - 2. diszk stb.).
  • Az olvasásban csak az adatdiszkek vesznek részt.
    • Ráadásul, mivel egy adott adat minden diszken "ugyanott" van, a tömb nem tud egyszerre több olvasást kiszolgálni (minden olvasáshoz minden adatdiszkre szükség van).
    • Nyilván kiolvashatjuk és ellenőrizhetjük a paritást is, de ettől nem lesz gyorsabb az olvasás.
    • Ebből adódóan a RAID3-tömb elérési ideje semmivel sem jobb, mint egyetlen diszké, a sávszélessége viszont annyiszorosa egyetlen diszkének, ahány adatdiszkünk van.
    • Emiatt olyan alkalmazásokhoz jó lehet, amelyek szinte kizárólag szekvenciálisan írnak vagy olvasnak, nagy sávszélességet igényelnek és meglehetősen állandó elérési időt; ilyen például a videorögzítés és -lejátszás.
  • Pontosan egy diszk eshet ki.
  • N/B = (n-1)/n (ahol n a diszkek száma).
  • Nemigen használják.

4.6 RAID4

(block-interleaved parity)

  • Mint a RAID3, de nem bitenként vagy bájtonké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:
    • 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, majd
    • 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 valamit 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ő adat és 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.
  • N/B = (n-1)/n (ahol n a diszkek száma).
    • 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.
  • Olyan megoldás is van/volt, ami a RAID4-et kettős paritásossá egészíti ki; ebben az esetben két diszk kiesését vészeli át a tömb, de még lassúbb a kis írás.

4.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):
    • Így szekvenciális olvasáskor minden diszkre sor kerül, mielőtt bármelyikre másodszor is sor kerülne.
 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
...
  • 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).
    • Nagyon szerencsétlen esetben (sok, véletlenszerű kis írás esetén) a RAID5 akár egy nagyságrenddel is lassúbb lehet, mint az ugyanazokból a diszkekből épített RAID0.
    • Ez különösen adatbázisoknál okozhat problémát; a gondot csökkenti/megszünteti, ha megbízható (pl. akkumulátorral védett) write-back cache-ünk van, és így áramkimaradás esetén is ki tudjuk írni a cache tartalmát a diszkekre.
  • 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).
  • Gond lehet, ha írás közben megy el az áram (vagy fagy le a gép), és inkonzisztenssé válik a paritás az adatokkal. Ha ezután esik ki egy diszk, rossz paritás alapján rekonstruáljuk a tartalmát, ami nehezen észlelhető adattorzuláshoz vezet - ráadásul valószínűleg csak jóval később vesszük észre. Nem teljesen intuitív okokból ezt a problémát "write hole"-nak nevezik.
  • Elvileg akárhány diszkből építhető RAID5-tömb, a valóságban viszont tíznél többől nem valószínű, hogy jó ötlet (l. lejjebb).
  • Nagyon széles körben elterjedt.

4.8 RAID6

  • 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.
  • Például:
    • P+Q (paritás és az adatok lineárisan visszacsatolt shiftregiszterrel shiftelt verziójának paritása), vagy gyakran
    • kettős paritás (minden adatblokk két független paritásblokkhoz járul hozzá).
  • n+2 diszk kell n diszknyi kapacitáshoz (N/B=(n-2)/n).
  • 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.
  • Olyan megoldás is van/volt, ami a RAID4-et egészíti ki kettős paritásossá.
  • A RAID6-ot is lehet továbbragozni, háromszoros paritással (így további teljesítménycsökkenés árán három diszk kiesését éli túl).

4.9 Egymásba ágyazott RAID-szintek

Miért is ne építhetnénk RAID-tömböket más RAID-tömbökből? ("Yo dawg...")

Mivel a szabványosnak tekinthető RAID-szintek mindegyikének egyjegyű száma van, az egymásba ágyazott megoldásokat számozhatjuk úgy, hogy egyszerűen egymás után írjuk az egymásra épített RAID-szintek számát. Tehát a RAID50 pl. RAID5-tömbök összefűzése csíkozással (néhány szerző pluszjelet tesz a két szám közé, tehát pl. RAID50 helyett RAID5+0-t ír).

4.9.1 RAID1+0

  • RAID10-nek is hívják, de "van" "valódi" RAID10 is; l. Software RAID Linux alatt
  • Két (vagy több) RAID1 tömböt csíkozással összefűzünk.
  • 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.

4.9.2 RAID0+1

  • Mint fent, de két RAID0-tömböt tükrözünk egymásra RAID1-gyel

4.9.3 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
      1. eldobjuk a hibás RAID0-tömböt
      2. a megmaradt jó diszkből és a spare-ből csinálunk egy új RAID0-t
      3. 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.

4.9.4 RAID10

  • Elvileg egy RAID1+0-jellegű hibrid megoldás.
  • Egyetlen 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 üzembe állhat.
  • A Linux kernel támogatja.
  • Ezt is hívják néha RAID1e-nek, mint a kettőnél több diszkből álló RAID1-et, úgyhogy ezt az elnevezést kerüljük.

L. még: Non-standard RAID levels a Wikipédián.

4.9.5 RAID100

  • RAID10-tömbök fölött megvalósított RAID0.
  • Akkor használják, ha nagyon sok diszket kell egyetlen tömbbe összefogni:
    • az egy-egy hardveres RAID-vezérlőn lógó diszkekből RAID10-es tömböket csinálnak, majd
    • az egyes vezérlők tömbjeiből egy szoftveres RAID0-tömböt.

4.9.6 RAID50

  • RAID5-tömbök fölött megvalósított RAID0.

4.9.7 RAID51

  • RAID5-tömbök fölött megvalósított RAID1.

4.9.8 RAID60

  • RAID6-tömbök fölött megvalósított RAID0.

4.9.9 RAID61

  • RAID6-tömbök fölött megvalósított RAID1.

5 További trükkök

  • Ha úgyis van hotspare, ami nem csinál semmit, miért ne használjuk valamire azt is?
    • Distributed sparing (RAID5E, RAID5EE, RAID6E)

L. még: Non-standard RAID levels a Wikipédián.

6 Hardveres vagy szoftveres RAID?

Egyáltalán nem eldöntött kérdés; hogy egy adott helyzetben mi a jobb, az -- mint annyi minden az életben -- az igényektől és a(z anyagi/emberi) lehetőségektől függ.

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 (zárt forrású firmware esetén, de ez a gyakoribb)
    • ezzel szemben nyílt forráskódú 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 azonos gyártó két vezérlője közötti mozgatás esetén is gyakran szükség van 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
  • 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
    • viszont szerencsés esetben jól skálázódik sokezer gépre és vezérlőre
  • a hardveres megvalósítás szemrebbenés nélkül bootol RAID5-ről vagy RAID6-ról; a linuxos softraid esetében ez nem ilyen egyszerű
  • ha sok gyors diszk kell, általában nem is tudunk olyan vezérlőt venni, aminek ne lenne RAID-funkciója

7 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, így 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
    • 1014 bitenként, vagyis 11 terabyte-onként várhatóan kb. 1 ilyen van a PC-be való diszkeknél
    • Pl. a lemez öregedése, külső mágneses hatások, kozmikus háttérsugárzás, napfolttevékenység, népfelkelés, atomháború vagy ilyesmi miatt
    • Ezt a RAID amúgy javíthatja, de ha már nem redundáns a tömb, egy ilyen miatt esetleg nem helyerállítható
      • Persze ha a diszk nem jelzi, hogy nem sikerült az olvasás, csak hibás adatot ad vissza, akkor a RAID erről csak akkor szerez tudomást, ha eleve redundánsan olvas mindent, ami viszont lassú - szerencsére ez nagyon ritka.
    • Példa: egy 100GB-os degradált tömb esetén 0,88% eséllyel veszítünk adatot
    • 1TB-nál ez már 8,42%!
      • 8*1TB diszkből álló RAID5 tömbnél, ha 1 diszk kiesik, 7TB-ot kell tudni hibátlanul végigolvasni; a bithibák miatt ez már 45,98% eséllyel nem fog sikerülni, ami nagyon durva.
      • Pár további konkrét érték: 200GB - 1,74%; 500GB - 4,30%; 2TB - 16,13%; 16TB - 75,52%; 32TB - 94,00%; 64TB - 99,64%.
    • Vagyis elegendően nagy tömbben semmiképpen nem elég az egyszeres redundancia! (Ha olcsó diszkekből építettük.)
      • A drága diszkeknél a specifikáció szerint általában 1015 bitenként találkozunk egy ilyen nem javítható bithibával; számomra kérdéses, hogy mérésekkel alátámasztható-e ez a nagyságrendi különbség (amit mondjuk jobb, nagyobb redundanciával dolgozó hibajavító kódolással elvileg minden további nélkül elérhetnek a gyártók; a kérdés tehát az, hogy megteszik-e ezt valóban?).
    • Képlet az adatvesztés valószínűségére: (1-e(hibátlanul_olvasandó_byteszám*8*ln(1-(1/bithiba_ráta))))
    • 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 v. teknőgö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
  • Ha elegendően sok elegendően nagy diszk van egy tömbben, akkor egy meghibásodás után a következő meghibásodásig várható idő kisebb lehet (vagy legalábbis azonos nagyságrendbe eshet), mint a melegtartalék aktiválásához szükséges idő.
    • Ha nincs is melegtartalék, akkor a helyreállításhoz szükséges időhöz hozzá kell adni a diszkcsere idejét is, ami így még könnyebben megközelítheti a következő meghibásodásig várható időt.
    • Már csak emiatt sem érdemes irdatlanul nagy RAID5-tömböt építeni.
  • A CERN-nél (amúgy egy honfitársunk által) végzett kísérlet eredménye alapján mondható, hogy a vártnál lényegesen gyakoribbak az átállítódásos hibák.
    • 3000 gépen futtattak, több héten át, egy olyan programot, ami minden második órában megabájtonként, az egyes blokkok között 1-1 másodpercet várva kiírt pár GB adatot, majd ugyanilyen lassan visszaolvasta és ellenőrizte.
    • 3 hét alatt 152 esetben találtak olyan hibát, amit a hardveres RAID nem jelzett.
    • Ha ezt felszorozzuk, valami olyasmi jön ki, hogy durván 10 TB-ra jut egy ilyen hiba (több helyen is olvastam a kísérletről, és egymásnak némileg ellentmondó számokat közöltek, úgyhogy pluszmínusz egy-két nagyságrend is belefér). Ez a 10TB-os érték látszólag összhangban van a lemezgyártók 10-14-es adatával, azzal a különbséggel, hogy az elvileg az észlelhető, de nem javítható hibák gyakoriságára vonatkozna, ezek pedig nem észlelt hibák voltak, ha ennek az opensolarisos prezentációnak hinni lehet. Ugyanakkor nem is csak a diszkeken keletkeztek:
    • A teljes rendszerek (kábelekkel, vezérlőkkel, memóriával stb. együtt) kb. 3*10-7-es bájthibarátával dolgoztak, ami szánalmasan rossz: azt jelenti, hogy kb. 28MB-ra jut egy hiba. Ezt a rossz eredményt lehet, hogy az magyarázza, hogy a kísérletben szereplő WD diszkek firmware-je hibás volt (a hiba pedig a felhasznált 3ware RAID-vezérlőkkel pont előjött). A kísérlet után emiatt a diszkek firmware-jét frissítették is, de úgy tudom, a kísérletet nem ismételték meg.
    • A diszkek megfigyelt bithibarátái jóval (kb. 60%-kal) alacsonyabbak voltak a specifikációban megadottnál; viszont
    • a bad sectorok gyakorisága nem tért el jelentősen az olcsó és a drága diszkek között (az opensolarisos prezentáció szerint 8-20TB-onként van egy).

8 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?
  • Egy vicces videó arról, mennyire érzékenyek a merevlemezek a rázkódásra
  • Egy rossz példa: The PC Guide - azzal együtt, hogy a RAID2-nél például hivatkoztam rá, ezen a konkrét oldalon butaságot ír: szerinte tükrözős RAID csak páros számú diszkből építhető, "for obvious reasons". Ezt csak azért emelem ki, nehogy abból, hogy korábban idéztem, valaki arra következtessen, hogy minden részével egyetértek. :)

9 Potenciális zh-kérdések

  • Mi a RAID kontextusában a distributed sparing?
  • Mi szól a szoftveres ill. hardveres RAID ellen ill. mellett?
  • A RAID0, a RAID1, a RAID5, a RAID6, a RAID10, a „RAID1 over RAID0” és a „RAID0 over RAID1” elrendezés közül melyikhez lehet értelmesen hozzáadni egy darab hotspare-t? (Tegyük fel, hogy a RAIDx over RAIDy esetében az egymás fölött megvalósított RAID-tömbök nem tudnak egymásról.) Válaszát indokolja!
  • Milyen esetben lehet érdemes RAID4-et használni?
Személyes eszközök