RAID

A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2009. január 1., 14:28-kor történt szerkesztése után volt.

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

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
  • 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/€? 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
      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.

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 (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

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 a PC-be való diszkeknél
    • Pl. a lemez öregedése, külső mágneses hatások 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ú.
    • 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.)
    • Képlet az adatvesztés valószínűségére: (1-10^(hibátlanul_olvasandó_byteszám*8*log(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)
    • 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...).

Személyes eszközök