RAID

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.

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ő)

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.