RAID

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (Bithibák hatása: pedantéria)
a (Bithibák hatása: pedantéria)
572. sor: 572. sor:
 
* a szerverek vásárlói viszont nagyon is, és őket elrettenti, így a jóval drágább "enterprise" diszkek felé tereli.
 
* a szerverek vásárlói viszont nagyon is, és őket elrettenti, így a jóval drágább "enterprise" diszkek felé tereli.
   
Érdemes lenne megvizsgálni (nagyszámú kísérlettel), hogy 1TB-ot a valóságban desktop diszkekről milyen gyakorisággal tudunk hiba nélkül végigolvasni. A 7,68%-os hibavalószínűség elég nagy ahhoz, hogy könnyen vizsgálható legyen; 14 esetből várhatóan egyszer nem kellene, hogy sikerüljön hiba nélkül végigolvasni az 1TB-ot.
+
Érdemes lenne megvizsgálni (nagyszámú kísérlettel), hogy 1TB-ot a valóságban desktop diszkekről milyen gyakorisággal tudunk hiba nélkül végigolvasni. A (legfeljebb) 7,68%-os hibavalószínűség elég nagy ahhoz, hogy könnyen vizsgálható legyen; 14 esetből várhatóan egyszer nem kellene, hogy sikerüljön hiba nélkül végigolvasni az 1TB-ot, ha a 7,68% nemcsak egy elméleti felső korlát lenne a hibák gyakoriságára, hanem valóban körülbelül ennyi lenne a hiba valószínűsége.
   
 
Az is érdekes kérdés, valóban elhihető-e a 10<sup>-15</sup> szektoros hibaráta; a fenti táblázatból látszik, hogy még 512TB-nál is szinte elhanyagolható lenne a hiba valószínűsége. Ha a 10<sup>-14</sup> bites hibaráta a desktop-diszkeknél igaz, akkor a 10<sup>-15</sup> bites enterprise-hibaráta hihető; jobb, nagyobb redundanciával dolgozó hibajavító kódolással elvileg minden további nélkül elérhető lehet (ugyanakkor számomra az is hihető lenne, hogy a kétfajta diszk egyformán legfeljebb 10<sup>-15</sup> bites rátával hibáz, csak az "enterprise" árkategória vonzóbbá tétele érdekében ír jobb adatot a katalógusba a gyártó). A 10<sup>-15</sup> szektoros hibaráta viszont még ennél is három nagyságrenddel jobb, és így nekem gyanús. Ha valakinek van otthon többszáz terabájtos diszktömbje, legyen olyan kedves és mérje ki. :)
 
Az is érdekes kérdés, valóban elhihető-e a 10<sup>-15</sup> szektoros hibaráta; a fenti táblázatból látszik, hogy még 512TB-nál is szinte elhanyagolható lenne a hiba valószínűsége. Ha a 10<sup>-14</sup> bites hibaráta a desktop-diszkeknél igaz, akkor a 10<sup>-15</sup> bites enterprise-hibaráta hihető; jobb, nagyobb redundanciával dolgozó hibajavító kódolással elvileg minden további nélkül elérhető lehet (ugyanakkor számomra az is hihető lenne, hogy a kétfajta diszk egyformán legfeljebb 10<sup>-15</sup> bites rátával hibáz, csak az "enterprise" árkategória vonzóbbá tétele érdekében ír jobb adatot a katalógusba a gyártó). A 10<sup>-15</sup> szektoros hibaráta viszont még ennél is három nagyságrenddel jobb, és így nekem gyanús. Ha valakinek van otthon többszáz terabájtos diszktömbje, legyen olyan kedves és mérje ki. :)

A lap 2015. március 22., 02:06-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, SAS, ...)
    • 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.

Egy-egy tömb elméleti IOPS-értéke általában a tömböt alkotó diszkek IOPS-értékeinek összege (amit a konkrét elrendezés jelentősen befolyásol; l. lejjebb).

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.
  • IOPS tekintetében közel lineárisan skálázódik (akkor skálázódna lineárisan, ha minden igényt más diszk szolgálna ki, de ezt persze nem tudjuk garantálni).

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.
  • IOPS tekintetében közel lineárisan skálázódik (akkor skálázódna lineárisan, ha minden igényt más diszk szolgálna ki, de ezt persze nem tudjuk garantálni).

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 HP/Compaq Smart Array vezérlőnél pl. a "RAID 1adm" (Advanced Data Mirroring :) nevet kapta a három diszkből álló RAID1.
    • 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 véletlen I/O-t szolgál ki, akkor a RAID1 olvashat gyorsabban, mint a RAID0 (mivel olvashat arról a diszkről, amelyiknek a feje közelebb van a kért adathoz).
  • IOPS tekintetében olvasásra elvileg lineárisan skálázódik (hiszen tényleg kiszolgálhat minden olvasást más diszk);
  • írásra úgy viselkedik, mintha egyetlen diszk lenne (hiszen minden írás mindig minden diszket érint).
  • 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 (számottevő) 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 szektorokat 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.

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.
    • Hátrány: kis olvasásoknál nem adódik össze a diszkek sávszélessége;
    • előny: kis olvasások esetén nagyobb IOPS (hiszen több olvasást is ki tudunk szolgálni egyszerre).
  • 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.
    • Írásokat tekintve legfeljebb annyi IOPS-t tud, amennyit a paritásdiszk.
  • 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 vagy másolatát tárolja aszerint, hogy páros vagy páratlan a paritás).
    • A RAID3 úgy, hogy úgy választjuk meg a csíkméretet, hogy a legkisebb lehetséges olvasás is minden diszket érintsen.
  • n diszk esetén minden diszken minden n-edik blokk paritásblokk, pl. így (left-symmetric parity distribution 5 diszk esetén):
 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ást tekintve az IOPS közel lineárisan skálázódik.
  • Kis olvasás, nagy olvasás, nagy írás gyors; kis írás viszonylag lassú (l. fent).
    • Kis írásoknál kb. negyedelődik a tömb IOPS-értéke.
    • 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 (így az írási műveletek már akkor visszatérhetnek, amikor még csak a cache-ben kerültek rögzítésre, mert áramkimaradás esetén is ki tudjuk írni a cache tartalmát a diszkekre). A cache szépen szerializálhatja a véletlen írásokat, összevárhat többet stb.
  • Pontosan egy diszk eshet ki.
    • Ha kiesett, akkor az olvasás lassú, mert minden "nagy" olvasáshoz minden diszkről olvasni kell.
      • Kis olvasás esetén csak akkor kell minden diszkről olvasni, ha amúgy a kiesett diszkről olvastunk volna.
    • 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 (vagyis a RAID5) 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).
    • Ennek megfelelően kis írásoknál kb. hatodolódik a tömb IOPS-értéke.
  • 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 (megj.: 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. Mekkora 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; emiatt
  • állhat páratlan számú diszkből is, valamint
  • 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 IOPS-alapú méretezés

  • Ha tudjuk, hány IOPS-t kell kiszolgálnunk, és a műveletek mekkora része írás, megbecsülhetjük, összesen hány "IOPS-nyi diszk" kell a tömbünkbe.
  • Például, ha 200 IOPS-t akarunk kiszolgálni, aminek a 30%-a írás, 70%-a olvasás, és RAID6-ot szeretnénk használni, okoskodhatunk az alábbiak szerint:
    • 60 írás/s-hoz 6*60, vagyis 360 "IOPS-nyi diszk" kell (mert a RAID6 kb. hatodolja az írásos IOPS-értéket);
    • 140 olvasás/s-hoz 140 "IOPS-nyi diszk" kell;
    • tehát összesen kb. 500 "IOPS-nyi diszkre" van szükség, ami kb. 8 7200rpm-es, kb. 5 10k rpm-es vagy kb. 4 15k rpm-es diszkkel biztosítható.
      • (Itt természetesen nem vettük figyelembe, hogy használhatunk akkumulátorral ellátott RAID-vezérlőt, amely, ha elegendő cache van rajta, elrejtheti előlünk a RAID6 okozta IOPS-csökkenést.)

7 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/AoE).
    • 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.
      • (Erre a hardveres vezérlők egy része is képes.)
    • Nemigen érdekli, melyik diszket hova dugjuk, amíg megvan mind.
  • Skálázhatóság.
    • Egy tömb diszkjei lehetnek különböző vezérlőkön vagy különböző iSCSI-szervereken (amelyek különböző hálózati interface-eken lógnak), így a sávszélesség később válik szűk keresztmetszetté (bár ez csak igen nagy rendszerek esetében számít).
  • Kiforrottság.
    • 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);
    • ráadásul az elterjedt implementációkat világszerte gépek millióin használják, tehát a hibák aránylag hamar kiderülnek.
  • Nyilvános az adatformátum.
    • Mem 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.)
  • Sebesség.
    • A gép CPU-ja tipikusan sokkal gyorsabban futtatja a RAID5-höz szükséges XORt, mint a RAID-vezérlő mikrokontrollere (a jobb vezérlőkben ugyan valódi CPU van, de akkor sem egy kategória a szerver saját CPU-jával).
    • 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; emellett
    • a mai gépekben jellemzően úgyis sokat unatkozik a CPU, amíg I/O-ra vár.
    • A CPU-magok számával nő(het) a RAID5/RAID6 sebessége (ha többszálú az implementáció).
    • 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 sokkal olcsóbb több RAMot és gyorsabb CPU-t venni, mint gyorsabb RAID-vezérlőt.
    • Ráadásul bizonyos vezérlők csak meghatározott diszkekkel működnek normálisan, és általában nem a legolcsóbbakkal.
  • 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 -- vagy legalábbis minden gyártónak -- 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).
  • Fejlődés.
    • 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 elérhető árú hardveres megvalósítás nem támogatja a RAID6-ot és a RAID10-et (ami nem RAID1+0).
    • Különböző típusú RAID-tömbök egymásba alakíthatósága, új diszkkel való bővíthetősége stb. szintén nem magától értetődő.
  • Megbízhatóság.
    • Ha nincs külön hardveres RAID-vezérlőnk, nem tud elromlani (bár ez csak félig érv, hiszen a diszkeket mindenképpen rá kell dugnunk valamilyen vezérlőre, és az mindeképpen elromolhat -- de az igaz, hogy az egyszerűbb vezérlőben kevesebb dolog tud elromlani).
  • Öngyógyítás.
    • Egy hardveres vezérlő csak akkor veszi észre a hibákat, ha a diszkek jelzik őket. A zfs, ha hibát észlel egy ellenőrző összegben, a tömbön belüli redundancia segítségével gondoskodik arról, hogy az alkalmazáshoz helyes adat jusson el, és a hibás adatot is kijavítja ott, ahol hibás volt (akkor is, ha a diszk nem jelezte a hibát). Ha a hardveres RAID fölött, saját redundancia nélkül csinálunk zfs-t, akkor az ilyen hibák kijavítására már nincs esély.

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.
    • Persze ez a PCIe korában már korántsem számít annyit, mint a 133MB/s-os PCI idejében.
  • A vezérlőn levő akkumulátor segítségével áramszünet esetén (ill. annak elmúltával) is a diszkre írható a cache tartalma.
  • A vezérlőn levő írás-cache segíthet szerializálni a véletlen I/O-t, főként a véletlen szinkron I/O-t. Ez rendkívül fontos előny.
    • Amit az akkumulátorral védett (battery backed) cache-be írtunk, azt tekinthetjük úgy, hogy már a diszken van, tehát a szinkron írások eleve nagyságrendekkel gyorsabbak lehetnek;
    • ráadásul a vezérlő megvárhatja a tényleges diszkreírással, amíg a diszk feje "épp arra jár", így a véletlen I/O-ból, ami az eléséri idő miatt lassú, gyors szekvenciális I/O lesz. Egy 7200rpm-es diszkkel simán elérhetünk 1000 IOPS-t.
    • Erre a szoftveres oldalon is van megoldás: pl. a ZFS-nél használhatunk a szinkron írások gyorsítására egy SSD-t (egyébként az olvasások gyorsítására is), és a bcache, a Facebook által fejlesztett és használt flashcache vagy az ezen alapuló EnhanceIO elvileg az összes linuxos fájlrendszer számára megnyitja ezt a lehetőséget. Az SSD viszont még mindig jóval lassúbb (és főleg kevesebbszer írható felül az élettartama alatt), mint a RAID-vezérlőn levő DRAM; ráadásul az SSD-be írt adatokat idővel újra ki kell onnan olvasni (a rendszerbuszon át) és végül csak kiírni diszkre. A valóságban nagyon is érezhető a különbség egy SSD ZILes és egy BBWC-s vezérlős zfs között.
      • (Egyébként léteznek kifejezetten zfs ZIL-nek (szinkron írásokat gyorsító cache-nek) való, külön táppal ellátott, DRAMot és flash memóriát is tartalmazó PCIe-kártyák. Normális működés közben a gyors DRAMba íródik minden; viszont ha elmegy a táp a PCIe buszon, a kártya a DRAM tartalmát gyorsan átmásolja a flashbe.)
      • Hasonló megoldás tisztán szoftverben, természetesen perszisztencia nélkül: BTIER. Egy több szintből álló háttértár-piramist építhetünk vele, amiben lehet pl. RAM, SSD, 10k rpm-es diszkekből álló RAID-tömb stb.; megpróbálja magától kitalálni, melyik adatot melyik tárolóban érdemes tartani.
    • Megjegyzendő, hogy (főként az olcsó) diszkek írás-cache-e minden esetben kikapcsolandó (pl. a hdparm -W0 /dev/sdX paranccsal), mert aránylag gyakori, hogy a diszkek firmware-je lefagy, majd újraindul (vagy a gép reseteli a diszket, mert nem válaszol), és a firmware közben eldobja a cache tartalmát - amiről az oprendszer azt hitte, hogy már diszkre írta. Ez nyilván nagyon könnyen okozhat adatvesztést.
  • 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. Ezt a RAID-vezérlő elvileg kezelheti elegánsabban.
  • 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 sokáig nem volt ilyen egyszerű (ma a GRUB2-nek köszönhetően már nem nagy varázslat).
  • Ha sok gyors diszk kell, általában nem is tudunk olyan vezérlőt venni, aminek ne lenne RAID-funkciója.
    • Sőt, az is gyakori, hogy a vezérlőnek csak RAID-funkciója van -- tehát a rádugott diszkeket az oprendszer közvetlenül nem is látja, hanem csak azokat a RAID-tömböket, amelyeket szerveztünk belőlük. Ilyenkor, ha egyenként szeretnénk használni a diszkeket, mindegyikből egydiszkes RAID0-"tömböt" kell csinálnunk, ami nem "szép".

8 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. Nem teljesen egyértelmű, hogy az ezekre vonatkozó katalógusadatot hogyan kell értelmezni; a WD Caviar Blacknél és a Seagate Barracuda-nál pl. úgy tűnik, 1014 bitenként, vagyis 11 terabyte-onként várhatóan kb. 1 bit lesz hibás (és így sikertelen lesz az adott bitet tartalmazó szektor olvasása). A Seagate Constellation széria esetében viszont például azt írják, 1015 szektoronként egy lesz olvashatatlan, ami nagyon nem mindegy.
    • Ilyen hiba előfordulhat 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.
    • Nyilván olyan hiba is előfordulhat, amit a diszk még csak nem is észlel; hogy ezek mennyire gyakoriak (ill. remélhetőleg inkább ritkák), arról nem szól a fáma.

8.1 Bithibák hatása

Vizgáljuk meg, milyen valószínűséggel nem tudunk hiba nélkül végigolvasni egy adott kapacitású merevlemezt!

Desktop diszk:

  • Normál üzem esetén minden 1014 (1E14) olvasott bitből legfeljebb egy hibás (ezt állítja a gyártó, amikor azt mondja, hogy "a bithiba-ráta legfeljebb 1E-14").
  • Annak a valószínűsége, hogy egy konkrét elolvasott bit hibás, ezek szerint legfeljebb 1/1E14, vagy 1E-14, vagy 10-14.
  • Annak a valószínűsége, hogy egy konkrét elolvasott bit hibátlan, ebből adódóan legalább 1-10-14.
  • Annak a valószínűsége, hogy n darab bitet hibátlanul el tudunk olvasni, legalább (1-10-14)n.
  • Annak a valószínűsége, hogy n darab bit elolvasása közben hiba lép fel, legfeljebb 1-(1-10-14)n.
  • Ez könnyebben beírható számológépbe a következő alakban: 1-exp(ln(1-1E-14)*n). Fontos, hogy itt n az olvasandó bitek száma.

"Enterprise" diszk:

A fent említett konkrét Seagate Constellation diszk adataiból indulunk ki; nem biztos, hogy minden más "enterprise" típusra ugyanilyen számokat ígér a gyártó.

  • Minden 1015 (1E15) olvasott szektorból legfeljebb egy hibás (ezt állítja a gyártó).
  • Annak a valószínűsége, hogy egy konkrét elolvasott szektor hibás, ezek szerint legfeljebb 1/1E15, vagy 1E-15, vagy 10-15.
  • Annak a valószínűsége, hogy egy konkrét elolvasott szektor hibátlan, ebből adódóan legalább 1-10-15.
  • Annak a valószínűsége, hogy n darab szektort hibátlanul el tudunk olvasni, legalább (1-10-15)n.
  • Annak a valószínűsége, hogy n darab szektor elolvasása közben hiba lép fel, legfeljebb 1-(1-10-15)n.
  • Ez könnyebben beírható számológépbe a következő alakban: 1-exp(ln(1-1E-15)*n). Fontos, hogy itt n az olvasandó szektorok száma.

Számoljuk ki ezt pár konkrét méretre!

Az alábbi táblázatban háromféle diszkkel számolunk: a desktop diszkek 10-14 bitenként hibáznak legfeljebb egyet; az első fajta hipotetikus "enterprise" diszk 10-15 bitenként; a második fajta "enterprise" diszk pedig 10-15 szektoronként. A táblázatban SI prefixeket használtam, tehát 1MB egymillió byte-ot jelent (elvégre a diszkgyártók is így számolnak). A megadott értékek 512 byte-os szektorokra vonatkoznak; 4k-s szektorok esetében állítólag még az itt láthatónál is megbízhatóbbak ezek a diszkek.

desktop enterprise
10-14 bit 10-15 bit 10-15 szektor
1 MB
0,00%
0,00%
0,00000%
100 MB
0,00%
0,00%
0,00000%
1 GB
0,01%
0,00%
0,00000%
200 GB
1,59%
0,16%
0,00004%
500 GB
3,92%
0,40%
0,00010%
1 TB
7,68%
0,80%
0,00020%
2 TB
14,77%
1,59%
0,00039%
3 TB
21,32%
2,37%
0,00059%
4 TB
27,37%
3,15%
0,00078%
5 TB
32,95%
3,92%
0,00098%
6 TB
38,10%
4,68%
0,00117%
7 TB
42,85%
5,44%
0,00137%
8 TB
47,24%
6,19%
0,00156%
9 TB
51,30%
6,94%
0,00176%
10 TB
55,04%
7,68%
0,00195%
11 TB
58,49%
8,42%
0,00215%
12 TB
61,68%
9,15%
0,00234%
13 TB
64,63%
9,87%
0,00254%
14 TB
67,34%
10,59%
0,00273%
15 TB
69,85%
11,30%
0,00293%
16 TB
72,17%
12,01%
0,00312%
17 TB
74,31%
12,71%
0,00332%
18 TB
76,28%
13,40%
0,00351%
19 TB
78,10%
14,09%
0,00371%
20 TB
79,78%
14,77%
0,00390%
21 TB
81,34%
15,45%
0,00410%
22 TB
82,77%
16,13%
0,00429%
23 TB
84,09%
16,79%
0,00449%
24 TB
85,32%
17,46%
0,00468%
25 TB
86,44%
18,11%
0,00488%
26 TB
87,49%
18,77%
0,00507%
27 TB
88,45%
19,41%
0,00527%
28 TB
89,34%
20,05%
0,00546%
29 TB
90,15%
20,69%
0,00566%
30 TB
90,91%
21,32%
0,00585%
31 TB
91,61%
21,95%
0,00605%
32 TB
92,25%
22,57%
0,00624%
48 TB
97,84%
31,87%
0,00937%
64 TB
99,40%
40,05%
0,01249%
80 TB
99,83%
47,24%
0,01561%
96 TB
99,95%
53,58%
0,01873%
112 TB
99,99%
59,15%
0,02186%
128 TB
99,996%
64,06%
0,02498%
256 TB
99,9999999%
87,08%
0,04995%
384 TB
99,999999999995%
95,36%
0,07491%
512 TB
100,00000000000000000000%
98,33%
0,09987%

Látszik, hogy ahogy az adatmennyiség nő, a különbségek óriásivá válnak.

Jogosan merül fel a kérdés: mennyire bízhatunk a katalógusadatokban? Elképzelhetőnek látszik, hogy a gyártók szándékosan aránylag rossz adatokat adnak meg a desktop diszkeknél, mert:

  • többért nem akarnak felelősséget vállalni;
  • a desktop gépek/diszkek vásárlói úgysem nézik ezt az adatot (és egyetlen diszknél úgyis majdnem mindegy);
  • a szerverek vásárlói viszont nagyon is, és őket elrettenti, így a jóval drágább "enterprise" diszkek felé tereli.

Érdemes lenne megvizsgálni (nagyszámú kísérlettel), hogy 1TB-ot a valóságban desktop diszkekről milyen gyakorisággal tudunk hiba nélkül végigolvasni. A (legfeljebb) 7,68%-os hibavalószínűség elég nagy ahhoz, hogy könnyen vizsgálható legyen; 14 esetből várhatóan egyszer nem kellene, hogy sikerüljön hiba nélkül végigolvasni az 1TB-ot, ha a 7,68% nemcsak egy elméleti felső korlát lenne a hibák gyakoriságára, hanem valóban körülbelül ennyi lenne a hiba valószínűsége.

Az is érdekes kérdés, valóban elhihető-e a 10-15 szektoros hibaráta; a fenti táblázatból látszik, hogy még 512TB-nál is szinte elhanyagolható lenne a hiba valószínűsége. Ha a 10-14 bites hibaráta a desktop-diszkeknél igaz, akkor a 10-15 bites enterprise-hibaráta hihető; jobb, nagyobb redundanciával dolgozó hibajavító kódolással elvileg minden további nélkül elérhető lehet (ugyanakkor számomra az is hihető lenne, hogy a kétfajta diszk egyformán legfeljebb 10-15 bites rátával hibáz, csak az "enterprise" árkategória vonzóbbá tétele érdekében ír jobb adatot a katalógusba a gyártó). A 10-15 szektoros hibaráta viszont még ennél is három nagyságrenddel jobb, és így nekem gyanús. Ha valakinek van otthon többszáz terabájtos diszktömbje, legyen olyan kedves és mérje ki. :)

8.2 Bithibák és a RAID

  • A RAID javíthatja az ilyen hibákat, 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 -- állítólag van olyan hardveres RAID5/RAID6-vezérlő, amely olvasáskor is folyamatosan ellenőrzi a paritást, de pl. a linuxos softraid tudtommal nem. Szerencsére -- szintén állítólag -- az ilyen csendes hibák ("silent corruption") ritkák.
  • Példa: 8*1TB desktop 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 42,85% eséllyel nem fog sikerülni, ami nagyon durva.
    • Vagyis elegendően nagy tömbben semmiképpen nem elég az egyszeres redundancia! (Ha olcsó diszkekből építettük, akkor főleg nem.)
    • 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).

8.3 További megfontolások a diszkhibákkal kapcsolatban

  • 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 RAID5-nél (és a RAID6-nál) minden diszk részt vesz a helyreállításban, míg pl. RAID10-nél elegendő hozzá a melegtartalék és az egyik adatdiszk; így a helyreállítás kisebb lassulást eredményez és várhatóan hamarabb be is fejeződik (ritkábban preemptálja más I/O-kérés), ezzel kevesebb időt hagyva arra, hogy közben további diszk essen ki.

8.4 Mérési adatok

  • 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).
      • Ez némileg alátámasztja azt a gyanút, hogy a gyártók hajlamosak trükközni a hibaráta-adatokkal.

9 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)
  • 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 (Sajnos a Sun felvásárlása óta nem elérhető; a lényeg: az operátor rákiáltott a diszkekre, és ettől mérhetően megnőtt a késleltetésük.)
  • 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. :)
  • Calculate IOPS in a storage array

10 Potenciális zh-kérdések

  • Mi a RAIDx? (Ahol x valamilyen konkrét szám.) Mik a tulajdonságai, paraméterei, jellemzői?
  • 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?
  • Vezesse le, mekkora a valószínűsége, hogy egy 4TB-os, 10-14 bithiba-rátájú merevlemez tartalmát nem tudjuk hiba nélkül végigolvasni! Ha nincs számológépe, elég kijelölni a műveleteket.
  • Hogyan befolyásolja a bithibák jelentette veszély a RAID-tömbök tervezését, méretezését?
  • Használhatunk-e mentés (backup) helyett RAID6-ot? Miért?
  • Mi a RAID kontextusában a "write hole"?
  • Miért nem mindegy, hogy RAID0 fölött valósítunk meg RAID1-et, vagy fordítva?
  • Hasonlítsa össze egy azonos számú és típusú diszkből álló RAIDx- és RAIDy-tömb teljesítőképességét olvasás/s és írás/s tekintetében! (x és y konkrét számok)
Személyes eszközök