Software RAID Linux alatt

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(Potenciális zh-kérdések hozzáadva)
a (→‎RAID-szintek: 3.4 óta a RAID10 korlátozottan bővíthető)
 
(2 szerkesztő 15 közbeeső változata nincs mutatva)
1. sor: 1. sor:
−
Linux alatt két programcsomag hivatott a szoftveres RAID kezelésére: a raidtools2 és az mdadm.
 +
Linux alatt két programcsomag hivatott a szoftveres [[RAID]] kezelésére: a raidtools2 és az mdadm.
 
Mi most csak az mdadm-mal foglalkozunk, mert a raidtools2 kihalófélben van: ha valaki akarja, házi feladatként bemutathatja.
  
Mi most csak az mdadm-mal foglalkozunk, mert a raidtools2 kihalófélben van: ha valaki akarja, házi feladatként bemutathatja.
   
−
== RAID-tömbök ==
 +
== [[RAID]]-tömbök ==
   
−
Linux alatt a RAID-tömböknek is lehet szuperblokkja; ez a tömböt alkotó blockdevice végén található, és a tömb automatikus összerakásához nyújt segítséget.
 +
Linux alatt a [[RAID]]-tömböknek is lehet szuperblokkja; ez a tömböt alkotó blockdevice végén (vagy elején) található, és a tömb (automatikus) összerakásához nyújt segítséget.
−
Ebből adódóan a RAID-tömbök tetszőleges mélységben egymásba ágyazhatók (vagyis olyan elrendezésben csinálunk RAID0 fölött RAID1-et vagy fordítva, ahogyan jól esik).
 +
Ebből adódóan a [[RAID]]-tömbök tetszőleges mélységben egymásba ágyazhatók (vagyis olyan elrendezésben csinálunk [[RAID#RAID0|RAID0]] fölött [[RAID#RAID1|RAID1]]-et vagy fordítva, ahogyan jólesik).
   
−
A /dev/md* eszközökön keresztül érhetjük el a RAID-tömbjeinket, miután "elindítottuk" őket (l. később). (md="multiple devices")
 +
Többféle szuperblokk-verzió van, az alábbi előnyökkel/hátrányokkal:
   
−
=== RAID-szintek ===
 +
* 0.90:
  +
** a kernel össze tudja rakni a tömböket boot közben;
  +
** nem hordozható architektúrák között;
  +
** az eszköz végén van (4k hosszú, és az eszköz utolsó előtti teljes 64k-s blokkjának az elején van);
  +
** előfordulhat, hogy egy diszk és a rajta levő utolsó partíció RAID-szuperblokkja ugyanoda esik;
  +
** legfeljebb 28 elemű tömböket támogat.
   
−
A Linux a következő RAID-szinteket támogatja:
 +
* 1.[012]:
  +
** csak userspace-ből rakhatók össze a tömbök;
  +
*** vagyis ha RAIDről akarunk bootolni, initrd vagy initramfs kell;
  +
*** (a GRUB2 elvileg bootol RAIDről, de ez csak annyit jelent, hogy be tudja tölteni a kernelt és az initrd-t; ha a rootfs RAIDen van, a kernel nem tudja önállóan összerakni);
  +
** lehet az eszköz elején és végén is;
  +
** többszáz tömbelemet támogat.
  +
  +
A szuperblokk nem minden konfigurációhoz szükséges (de a redundánsokhoz speciális esetektől eltekintve igen).
  +
  +
A 2.6.28-as kernel óta a meta-adatokat kezelheti egy tömbtől független, userspace processz is (így elvileg akármilyen metaadat-formátum támogatható). A kernel maga a saját formátumain kívül csak az Intel Matrix Storage Manager és a SNIA által szabványosított "Disk Data Format" metaadat-formátumát támogatja.
  +
  +
A /dev/md* eszközökön keresztül érhetjük el a RAID-tömbjeinket, miután "elindítottuk" őket (l. később). (md="multiple device")
  +
  +
Amúgy az mdadm kezelte régebben az ún. multipath konfigurációkat is (amikor redundáns útvonalak vannak a gép és a háttértár között), de ezzel itt nem foglalkozunk.
  +
  +
=== [[RAID]]-szintek ===
  +
  +
A Linux a következő [[RAID#RAID szintek|RAID-szintek]]et támogatja:
   
 
* LINEAR: csak összefűzi az eszközöket, nincs se csíkozás, se redundancia; cserébe bővíthető.
  
* LINEAR: csak összefűzi az eszközöket, nincs se csíkozás, se redundancia; cserébe bővíthető.
−
* RAID0: csíkozás. Ha nem egyforma nagyok az eszközök, akkor is az összes helyet használhatjuk, legfeljebb a végére nem lesz annyíra csíkos.
 +
* [[RAID#RAID0|RAID0]]: csíkozás. Ha nem egyforma nagyok az eszközök, akkor is az összes helyet használhatjuk, legfeljebb a végére nem lesz annyíra csíkos.
 
** Egy csík (stripe) itt egy valamennyi fizikai eszközre kiterjedő, logikailag folytonos blokkcsoportot jelent.
  
** Egy csík (stripe) itt egy valamennyi fizikai eszközre kiterjedő, logikailag folytonos blokkcsoportot jelent.
−
** Jelenleg nem bővíthető.
 +
** Az egy diszkre eső csíkszelet neve ''chunk''.
−
* RAID1: minden diszken pontosan ugyanaz van.
 +
** Bővíthető új diszk hozzáadásával (ilyenkor a kernel előbb RAID4-gyé alakítja a tömböt, hozzáadja az új diszket/diszkeket, újracsíkozza, majd újra RAID0-vá alakítja).
  +
** Online átalakítható RAID4-gyé, RAID5-té és RAID10-zé (2.6.35 óta).
  +
** A chunkméret is módosítható utólag.
  +
* [[RAID#RAID1|RAID1]]: minden diszken pontosan ugyanaz van.
  +
** Párhuzamosan ír minden eszközre.
  +
** Az olvasásokat igyekszik elosztani az eszközök között (ennek főleg többszálú I/O esetén jelentős a hatása).
 
** Ha nem minden diszk egyforma nagy, a nagyobbak pluszkapacitását nem tudjuk kihasználni (a tömbben levő logikai hely annyi lesz, mint a tömb legkisebb elemén levő).
  
** Ha nem minden diszk egyforma nagy, a nagyobbak pluszkapacitását nem tudjuk kihasználni (a tömbben levő logikai hely annyi lesz, mint a tömb legkisebb elemén levő).
 
** "Bővíthető": ha az összes diszket nagyobbra cseréljük benne (szép sorban), akkor a tömb is megnőhet.
  
** "Bővíthető": ha az összes diszket nagyobbra cseréljük benne (szép sorban), akkor a tömb is megnőhet.
−
* RAID4: mint a RAID0, de egy külön eszközön van a csíkok paritása.
 +
*** Persze adható hozzá új diszk, akár tartalékként, akár adatdiszkként; utóbbi eseteben a redundancia nő, a kapacitás nem.
  +
** Online átalakítható RAID5-té.
  +
* [[RAID#RAID4|RAID4]]: mint a [[RAID#RAID0|RAID0]], de egy külön eszközön (az utolsó aktívon) van a csíkok paritása.
 
** Itt is minden eszközből csak annyi kapacitás hasznosul, amennyi a tömb legkisebb elemén rendelkezésre áll.
  
** Itt is minden eszközből csak annyi kapacitás hasznosul, amennyi a tömb legkisebb elemén rendelkezésre áll.
−
** Nem érdemes használni.
 +
** Nem érdemes használni (kivéve, ha az egyik diszk sokkal gyorsabb, mint a többi).
−
** Jelenleg nem bővíthető (csak mint a RAID1).
 +
** 2.6.35 óta bővíthető és csökkenthető is.
−
* RAID5: mint a RAID4, de a paritást is csíkozza.
 +
** Online átalakítható RAID0-vá, RAID4-gyé és RAID5-té.
  +
** A chunkméret is módosítható utólag.
  +
* [[RAID#RAID5|RAID5]]: mint a [[RAID#RAID4|RAID4]], de a paritást is csíkozza.
 
** A legújabb kernelek (2.6.17+) már tudják bővíteni (ehhez a teljes tömböt újra kell írni, úgyhogy nem egyszerű és nem gyors művelet, de legalább lehetséges).
  
** A legújabb kernelek (2.6.17+) már tudják bővíteni (ehhez a teljes tömböt újra kell írni, úgyhogy nem egyszerű és nem gyors művelet, de legalább lehetséges).
−
* RAID6: mint a RAID5, de kétféle paritást tárol, így nem egy, hanem két diszk kiesését viseli el.
 +
*** 2.6.31 óta már csökkenteni is lehet a RAID5-ben levő diszkek számát (így nyilván csökken a tömb kapacitása; gondoskodni kell arról, hogy a rajta tárolt fájlrendszer összehúzza magát, mielőtt elkezdjük).
  +
** Online átalakítható RAID6-tá.
  +
** A chunkméret is módosítható utólag.
  +
* [[RAID#RAID6|RAID6]]: mint a [[RAID#RAID5|RAID5]], de kétféle paritást tárol, így nem egy, hanem két diszk kiesését viseli el.
 
** Általában kicsit lassúbb a RAID5-nél (két diszk kiesése esetén sokkal lassúbb, de legalább még működik).
  
** Általában kicsit lassúbb a RAID5-nél (két diszk kiesése esetén sokkal lassúbb, de legalább még működik).
−
** Jelenleg nem bővíthető (csak mint a RAID1).
 +
** Kb. 2007. nyarától (2.6.31) bővíthető és újabban csökkenthető is, mint a [[RAID#RAID5|RAID5]].
−
* RAID10: egy absztrakciós szinten megvalósított RAID1+0.
 +
** A chunkméret is módosítható utólag.
  +
** A RAID5 és a RAID6 menet közben átalakítható egymásba, akár úgy is, hogy közben diszket adunk hozzá a tömbhöz vagy távolítunk el.
  +
* [[RAID#RAID10|RAID10]]: egy absztrakciós szinten megvalósított [[RAID#RAID1.2B0|RAID1+0]].
 
** Csíkoz, és minden adatot legalább ''n'' példányban tárol.
  
** Csíkoz, és minden adatot legalább ''n'' példányban tárol.
 
** Csinálhatunk pl. 5 diszkből álló csíkozott tömböt, amelynek nettó kapacitása 2,5 diszknyi, és minden adatot két példányban tárol, vagyis egy tetszőleges diszk kiesését túléli.
  
** Csinálhatunk pl. 5 diszkből álló csíkozott tömböt, amelynek nettó kapacitása 2,5 diszknyi, és minden adatot két példányban tárol, vagyis egy tetszőleges diszk kiesését túléli.
 
** De csinálhatunk az 5 diszkből két diszk kiesését túlélő tömböt is, 5/3-ad diszknyi kapacitással.
  
** De csinálhatunk az 5 diszkből két diszk kiesését túlélő tömböt is, 5/3-ad diszknyi kapacitással.
−
** Lehet hozzá hotspare-t adni (RAID0-hoz nem, RAID1+0-hoz sem, RAID0+1-hez pedig legalább kettő kellene).
 +
** Lehet hozzá hotspare-t adni.
−
** Kétféle replika-elhelyezési módszert tud:
 +
** Háromféle replika-elhelyezési módszert támogat:
 
*** near: egy csíkban (vagyis egymáshoz közel) helyezi el a replikákat.
  
*** near: egy csíkban (vagyis egymáshoz közel) helyezi el a replikákat.
 
*** far: egymástól távol helyezi el a replikákat.
  
*** far: egymástól távol helyezi el a replikákat.
 
**** Előnye: jobb szekvenciális olvasási teljesítmény.
  
**** Előnye: jobb szekvenciális olvasási teljesítmény.
 
**** Hátránya: lassúbb írás.
  
**** Hátránya: lassúbb írás.
  +
*** offset: egy adat másolata a következő csíkban, a következő eszközön kap helyet. (2.6.18-as kerneltől)
  +
**** (Vélt?) előnye: a far-ral összemérhető szekvenciális olvasási teljesítmény, ha megfelelő a chunkméret.
  +
**** Kevesebb fejmozgatással megúszható a replikák kiírása, vagyis kevésbé lassul az írás.
  +
*** ''Ezeknek a hatását persze igazából ki kéne mérni.''
  +
*** Kis számú, közepes komolyságú saját mérés eredménye:
  +
**** 12db 7200rpm-es SATA2 diszk, 3 "offset" példány és 256k-s ill. 512k-s chunkméret esetén nincs számottevő különbség a lineáris írás sebességében (kb. 350MB/s);
  +
**** ugyanebben az elrendezésben kb. 10%-kal gyorsabb a lineáris olvasás az 512k-s chunkméret esetén (kb. 580MB/s);
  +
**** nagyjából ugyanezt a sebességet produkálta a tömb 3 "near" replika esetén;
  +
**** ehhez képest 3 "far" példány és 512k-s chunkméret esetén kb. 1300MB/s-os olvasási sebességet mértem;
  +
**** véletlen olvasásokban is a "far" a legjobb, de nem ekkora a különbség.
  +
**** Az írási sebesség sorrendje:
  +
***** lineáris: far (kb. 310MB/s), offset (kb. 350MB/s), near (kb. 390MB/s).
  +
***** 256k-s véletlen (itt volt a legnagyobb a különbség): far (kb. 160MB/s), offset (kb. 215MB/s), near (kb. 220MB/s) - az utóbbi különbség valószínűleg hibahatáron belül van.
  +
*** ''Ez alapján szerintem kizárólag olyan esetben érdemes "far" helyett más layoutot használni, ha az írási sebesség csekély növelése megéri az olvasási sebesség felének elvesztését.'' Természetesen más mérések adhatnak más eredményt!
 
** A replika-elhelyezési módszerek keverhetők: kérhetünk pl. egy near és egy far replikát. ''Jó ez valamire?''
  
** A replika-elhelyezési módszerek keverhetők: kérhetünk pl. egy near és egy far replikát. ''Jó ez valamire?''
−
** Jelenleg nem bővíthető.
 +
** Jelenleg nem bővíthető új diszkkel, de a [http://git.kernel.org/linus/006a09a0ae0a494473a8cd82c8d1d653e37e6663 3.4-es kernel óta] a near és az offset layoutot használó tömbök átméretezhetőek úgy, hogy a meglevő diszkeken több vagy kevesebb helyet foglaljanak (tehát egy tömb tárolókapacitását megnövelhetjük úgy, hogy az összes diszket egyenként nagyobbra cseréljük, majd végül megnöveljük a tömböt -- mint a RAID1 esetében).
   
 
=== A konzisztencia biztosítása, hibakezelés ===
  
=== A konzisztencia biztosítása, hibakezelés ===
46. sor: 60. sor:
 
* Alapesetben írás előtt dirtynek jelöli a tömböt
  
* Alapesetben írás előtt dirtynek jelöli a tömböt
 
* A tömb leállításakor clean lesz
  
* A tömb leállításakor clean lesz
  +
** Tehát bootkor elvileg mindig clean
  +
* De RAID1, RAID4, RAID5, RAID6 és RAID10 esetén legalább két írás kell a konzisztens állapot megőrzéséhez, és ezek nem biztos, hogy pontosan egyszerre mennek végbe
  +
** Vagyis van egy időablak (lehet, hogy innen kapta a nevét a "write hole"), ami alatt ha eltűnik a táp, inkonzisztens (dirty) lesz a tömb
 
* Ha indításkor dirty, resync:
  
* Ha indításkor dirty, resync:
 
** RAID1: az első diszkről a többire másolja a tartalmat
  
** RAID1: az első diszkről a többire másolja a tartalmat
54. sor: 71. sor:
 
** sysfs, procfs: <tt>speed_limit_min</tt>, <tt>speed_limit_max</tt>
  
** sysfs, procfs: <tt>speed_limit_min</tt>, <tt>speed_limit_max</tt>
 
* Ha már nincs redundancia, akkor a 2.6-os kernel a dirty arrayt nem is hajlandó automatikusan elindítani
  
* Ha már nincs redundancia, akkor a 2.6-os kernel a dirty arrayt nem is hajlandó automatikusan elindítani
−
* Ha I/O hibát észlel egy tömb egy elemén, azt az elemet hibásnak (''faulty'') jelöli, és nem használja
 +
* Ha írás közben hibát észlel egy tömb egy elemén, azt az elemet hibásnak (''faulty'') jelöli, és nem használja
 
* Ha van hotspare (tartalék), azonnal elkezd rá szinkronizálni
  
* Ha van hotspare (tartalék), azonnal elkezd rá szinkronizálni
  +
** Ha nincs, de ugyanebben a spare groupban van másik tömb, és abban van, akkor onnan "ellopja"
 
* Ha olvasási hiba van, először megpróbálja javítani úgy, hogy az oda való adatot kiszámítja és kiírja, majd megpróbálja visszaolvasni. Ha ez nem megy, akkor jelöli hibásnak a diszket.
  
* Ha olvasási hiba van, először megpróbálja javítani úgy, hogy az oda való adatot kiszámítja és kiírja, majd megpróbálja visszaolvasni. Ha ez nem megy, akkor jelöli hibásnak a diszket.
  +
** Ez jól hangzik, de nem biztos, hogy a gyakorlatban is jó - lehet, hogy jobb lenne cserélni azt a diszket.
  +
** Persze ha csak tranziens bithiba volt, akkor mégiscsak jó.
  +
** Sajnos nem lehet úgy cserére jelölni egy diszket, hogy addig, amíg be nem fejeződik a tartalék szinkronizálása, még használja a gyengélkedő diszket is (pedig így lehetne redundanciánk a csere alatt, ami még akkor is jobb, mint a semmi, ha a cserélendő diszknek akár csak a fele olvasható).
  +
* Érdemes a tömböket időnként ellenőrizni ("scrubbing"): végigolvasni és összehasonlítani a redundáns példányokat, ellenőrizni a paritást, és persze javítani az esetleges hibákat: <tt>echo repair >/sys/block/mdX/md/sync_action</tt> (de az mdadm tudja ezt automatizálni).
  +
** "repair" helyett kérhetünk "check"-et is; ez nem javítja a hibákat, csak jelzi őket.
  +
** RAID1 és RAID10 esetében, ha swapelünk a tömbre, előfordulhat inkonzisztencia akkor, ha egy éppen kiswapelődő lap tartalma megváltozik írás közben, így az egyik diszkre az egyik, másikra a másik állapot kerül. Ez nem okoz gondot, mert ha a lap módosult, akkor a VM (egyelőre) nem swapeli ki, a kiírt többféle változatot üres swap-helynek tekinti és sosem fogja beolvasni.
   
 
=== Bitmap write-intent logging ===
  
=== Bitmap write-intent logging ===
   
−
* 2.6.13 óta az md driver egy bitmap-naplóban jelzi, hogy hova fog írni
 +
* 2.6.13 óta az md driver, ha kérjük, egy bitmap-naplóban jelzi, hogy hova fog írni
 
* 2.6.13-ban RAID1, 2.6.15-től a többi RAID-hez is megvan
  
* 2.6.13-ban RAID1, 2.6.15-től a többi RAID-hez is megvan
−
* Ez a "szándéknapló" utólag is hozzáadható működő tömbhöz
 +
* Ez a "szándéknapló" utólag is hozzáadható működő tömbhöz, és el is távolítható belőle
−
* Ha az adott területre nem történik több írás, a vonatkozó bitet törli
 +
* Ha az adott területre hosszabb ideig nem történik több írás, a vonatkozó bitet törli
−
* Ha kiveszünk egy diszket a tömbből, a biteket nem törli
 +
* Ha kiveszünk egy diszket a tömbből, a biteket a többin sem törli már
   
 
Így:
  
Így:
   
−
# Tápvesztés után nem kell teljes resync, csak a bitmap alapján piszkos részekhez kell nyúlni
 +
# Tápvesztés és dirty indulás után nem kell teljes resync, csak a bitmap alapján piszkos részekhez kell nyúlni
 
# Ha egy diszket kiveszünk a tömbből, majd visszarakjuk, nem az egész tömböt kell újraszinkronizálni
  
# Ha egy diszket kiveszünk a tömbből, majd visszarakjuk, nem az egész tömböt kell újraszinkronizálni
  +
  +
Persze az írási sebesség valamennyivel biztos kisebb, ha a szándéknaplót is frissítgetni kell (főként, mivel ehhez seekekre van szükség, de nem minden íráskor); ki kellene mérni, mekkora a különbség. Ha kritikus a sebesség, a szándéknaplót tartsuk egy a tömbön kívüli eszközön levő fájlban.
  +
  +
=== Write-mostly ===
  +
  +
[[RAID#RAID1|RAID1]]-en lehet beállítani.
  +
* Ha így jelölünk meg egy tömbelemet, akkor a kernel arról csak akkor fog olvasni, ha muszáj, de írni ír rá.
  +
* Így nem lassul le (annyira) a tömb, ha pl. hálózaton át is mirrorozunk.
   
 
=== Write-behind ===
  
=== Write-behind ===
   
 
* 2.6.14 óta
  
* 2.6.14 óta
−
* RAID1-en
 +
* [[RAID#RAID1|RAID1]]-en
−
* A tömb elemein beállíthatjuk a "write-behind" jelzést, aminek két hatása van:
 +
* A write-mostly tömbelemek viselkednek így, ha van write-intent bitmap.
−
** Az md driver lehetőleg nem olvas az eszközről
 +
* Hatása: az adott eszközre aszinkron módon ír.
−
** Ha van write-intent bitmap is, akkor az adott eszközre aszinkron módon ír
 +
* Értelme: ha aránylag lassú elérésű (mondjuk hálózati) diszk is van a tömbben, az is nagyjából szinkronban lesz, de még annyira sem lassítja a rendszer működését, mint a write-mostly esetén.
−
* Értelme: ha aránylag lassú elérésű (mondjuk hálózati) diszk is van a tömbben, az is nagyjából szinkronban lesz, de nem lassítja a rendszer működését
 +
** Túl lassú (szaturált) kapcsolat esetén persze nem jó.
−
** Túl lassú kapcsolat esetén persze nem jó
  
   
 
=== Újracsíkozás ===
  
=== Újracsíkozás ===
85. sor: 117. sor:
 
* A tömb újraírása a struktúra megváltoztatása érdekében, pl:
  
* A tömb újraírása a struktúra megváltoztatása érdekében, pl:
 
** Diszkek számának növelése ("szélesebb" csíkok)
  
** Diszkek számának növelése ("szélesebb" csíkok)
−
** Blokkméret csökkentése ("sekélyebb" csíkok)
 +
** Chunkméret csökkentése ("sekélyebb" csíkok)
−
** Blokkméret növelése ("mélyebb" csíkok)
 +
** Chunkméret növelése ("mélyebb" csíkok)
−
** Adat- és/vagy paritásstruktúra megváltoztatása (pl. áttérés RAID1-ről RAID5-re vagy RAID5-ről RAID6-ra)
 +
** Adat- és/vagy paritásstruktúra megváltoztatása (pl. áttérés [[RAID#RAID1|RAID1]]-ről [[RAID#RAID5|RAID5]]-re vagy [[RAID#RAID5|RAID5]]-ről [[RAID#RAID6|RAID6]]-ra)
−
* 2.6.17-től a Linux a RAID5-öt tudja újabb diszkkel bővíteni; a többi műveletet is tervezik
 +
** Ezek a műveletek biztonságosak; akkor sem vesztünk adatot, ha közben elmegy az áram (l. man mdadm).
−
** Ráadásul a művelet biztonságos is, ha közben elmegy az áram, nem vesztünk adatot (l. man mdadm)
 +
*** Érdekesség: ha 0.90-es metadata-verziójú tömböt reshape-elünk, akkor a folyamat végéig 0.91-re állítja a verziószámot a kernel, hogy ha megszakadna a reshape és egy régebbi kernelt bootolnánk, ami nem tudja folytatni, ne tegye tönkre a tömböt azzal, hogy megpróbálja összeilleszteni.
   
−
== Kernel-paraméterek ==
 +
== Kernel-paraméterek, sysfs-interfész ==
   
 
* raid=noautodetect: ne ismerje fel és indítsa el automatikusan a 0xfd típusú partíciókat
  
* raid=noautodetect: ne ismerje fel és indítsa el automatikusan a 0xfd típusú partíciókat
97. sor: 129. sor:
 
* md_mod.start_dirty_degraded=1: akkor is elindítja a tömböt, ha degradált is és dirty is - hasznos, ha ez a root filerendszer.
  
* md_mod.start_dirty_degraded=1: akkor is elindítja a tömböt, ha degradált is és dirty is - hasznos, ha ez a root filerendszer.
 
* md=n,dev,dev,...: az md''n'' a megadott eszközökből állítandó össze boot közben.
  
* md=n,dev,dev,...: az md''n'' a megadott eszközökből állítandó össze boot közben.
  +
* A szinkronizálás sebessége állítható a <tt>/sys/block/mdX/md/sync_speed_{max,min}</tt> átírásával (van/volt /proc tunable is hozzá, de ezen a héten a sysfs-t szeretjük jobban)
  +
* A szinkronizálás sorrendjét befolyásolhatjuk így: <tt>echo idle >/sys/block/md1/md/sync_action</tt>. Ekkor az md1 szinkronizálása felfüggesztődik és helyette a sorban következő tömbé kezdődik meg.
  +
* A sysfs-ben állítható két paraméter:
  +
** stripe_cache_size: RAID5 és RAID6 esetén van rosszul dokumentált szerepe (''nincs kedve valakinek megnézni a forrásban?''). Ha növeljük, az használhat a teljesítőképességnek, de memóriába kerül.
  +
** preread_bypass_threshold: szintén csak RAID5-re és RAID6-ra értelmezett. Szintén nem túl jó a dokumentáció; az érték elvileg azt adja meg, hány teljes csíkot érintő műveletet hajtson végre az MD driver, mielőtt sort kerítene egy olvasást is igénylő kis írásra. Ugyanakkor azt is írják, hogy 0-ra állítva a kis írásokat végző szálakat büntetjük, ami ellentmondás.
   
 
== Az mdadm használata ==
  
== Az mdadm használata ==
118. sor: 155. sor:
 
# Misc
  
# Misc
 
#* "Egyéb": pl. RAID szuperblokk törlése; információkérés
  
#* "Egyéb": pl. RAID szuperblokk törlése; információkérés
  +
#** akkor kell törölni a szuperblokkot, ha végleg el akarunk távolítani egy eszközt egy tömbből
   
  +
Néhány tipikus felhasználás:
  +
  +
=== Új tömb létrehozása ===
   
−
Csináljunk magunknak játszóteret:
  
 
<pre>
  
<pre>
−
# mkdir /tmp/raidtest
 +
mdadm --create -l1 -n2 -x1 /dev/md0 /dev/sd[abc]1 # RAID 1, 1 spare
−
# cd /tmp/raidtest
 +
mdadm --create -l5 -n3 -x1 /dev/md0 /dev/sd[abcd]1 # RAID 5, 1 spare
−
# modprobe loop max_loop=64
 +
mdadm --create -l6 -n4 -x1 /dev/md0 /dev/sd[abcde]1 # RAID 6, 1 spare
−
# for i in {0..63}; do dd if=/dev/zero of=loop$i seek=1G bs=1 count=1; done
 +
</pre>
−
# for i in {0..63}; do losetup -f loop$i; done
  
   
−
# mdadm --create /dev/md0 --auto yes --level=1 --raid-devices=2 --spare-devices=1 /dev/loop0 /dev/loop1 /dev/loop2
 +
=== Degradált tömb létrehozása ===
−
mdadm: array /dev/md0 started.
  
   
−
# cat /proc/mdstat
 +
("Féllábúnak" vagy hiányosnak is mondják.)
−
Personalities : [raid1]
  
−
md0 : active raid1 loop2[2](S) loop1[1] loop0[0]
  
−
1048512 blocks [2/2] [UU]
  
−
[=====>...............] resync = 26.9% (282880/1048512) finish=5.8min speed=2176K/sec
  
   
−
unused devices: <none>
 +
A tényleges eszköznév helyére írjuk azt, hogy "missing":
   
−
# mdadm --stop /dev/md0
 +
<pre>
  +
mdadm --create -l5 -n3 /dev/md0 /dev/sda1 missing /dev/sdb1
  +
mdadm --create -l6 -n4 /dev/md0 /dev/sda1 missing /dev/sdb1 missing
  +
</pre>
   
−
# cat /proc/mdstat
 +
=== Tömb összeillesztése ===
−
Personalities : [raid1]
  
−
unused devices: <none>
  
   
  +
* Ha már egyszer korábban létrehoztuk, de a kernel még nem inicializálta:
  +
  +
<pre>
  +
mdadm --assemble --auto=yes /dev/md0 /dev/sd[abc]1
 
</pre>
  
</pre>
  +
  +
* Ha hiányos, nem indul el magától, kell a <tt>--run</tt>:
  +
  +
<pre>
  +
mdadm --assemble --auto=yes --run /dev/md0 /dev/sd[ab]1
  +
</pre>
  +
  +
* Vagy összerakás után külön elindíthatjuk:
  +
  +
<pre>
  +
mdadm --run /dev/md0
  +
</pre>
  +
  +
* A <tt>/etc/mdadm/mdadm.conf</tt>-ban felsorolt összes tömb összeillesztése és elindítása (ilyesmit csinál az <tt>initramfs/initrd</tt>):
  +
  +
<pre>
  +
mdadm --assemble --auto=yes --scan
  +
</pre>
  +
  +
* Hiányos, piszkos tömb összeillesztése és elindítása (a konzisztencia így nem biztosított!):
  +
  +
<pre>
  +
mdadm --assemble --auto=yes --force /dev/md0 /dev/sd[ab]1
  +
mdadm --run /dev/md0
  +
</pre>
  +
  +
=== Tömbök leállítása ===
  +
  +
<pre>
  +
mdadm --stop /dev/md0
  +
</pre>
  +
* Vagy az összesé, ami a configban van:
  +
<pre>
  +
mdadm --stop --scan
  +
</pre>
  +
  +
=== Tömbelemek hozzáadása ===
  +
  +
* Ha már fut a tömb:
  +
<pre>mdadm --add /dev/md0 /dev/sdc1</pre>
  +
* Ha többet adunk hozzá, mint ahányból létrehozáskor állt, a többletből melegtartalék lesz.
  +
  +
=== Tömbelemek eltávolítása ===
  +
  +
* Először jelöljük hibásnak, amit ki akarunk venni:
  +
<pre>mdadm --fail /dev/md0 /dev/sdb1</pre>
  +
* Ekkor elkezdi szinkronizálni a(z egyik) melegtartalékot
  +
* Szedjük is ki a tömbből a hibásnak jelölt eszköz:
  +
<pre>mdadm --remove /dev/md0 /dev/sdb1</pre>
  +
  +
=== Hibás diszk cseréje ===
  +
  +
Ha a /dev/sdb failed állapotban van:
  +
  +
<pre>
  +
mdadm --remove /dev/md0 /dev/sdb
  +
halt # ha nem hot-swappable...
  +
# diszkcsere
  +
mdadm --add /dev/md0 /dev/sdb
  +
</pre>
  +
  +
=== Új aktív diszk hozzáadása RAID1-hez ===
  +
  +
* Már fusson a tömb, és:
  +
<pre>
  +
mdadm --grow -n3 /dev/md0
  +
mdadm --add /dev/md0 /dev/sdc1
  +
</pre>
  +
  +
=== Aktív diszkek számának csökkentése RAID1-ben ===
  +
<pre>
  +
mdadm --fail /dev/md0 /dev/sdc1
  +
mdadm --remove /dev/md0 /dev/sdc1
  +
mdadm --grow -n2 /dev/md0
  +
</pre>
  +
  +
=== Meglevő fájlrendszer RAID1-esítése ===
  +
  +
# Bebootolunk egy live CD-ről (hogy biztosan ne írjon semmi a fájlrendszerbe, miközben másoljuk)
  +
# Létrehozunk egy új, féllábú RAID1-et a második diszken
  +
# Rámásoljuk az adatokat
  +
# Hozzáadjuk a tömbhöz az első diszket
  +
# Rebootolunk a szép új RAIDes fájlrendszerünkkel
  +
  +
Ha a <tt>/dev/sda1</tt> a meglevő fájlrendszer és a <tt>/dev/sdb1</tt> az új diszk, akkor:
  +
  +
<pre>
  +
mdadm --create /dev/md0 -l1 -n2 /dev/sdb1 missing
  +
mkfs -t <type> /dev/md0
  +
mount /dev/sda1 /mnt/sda1
  +
mount /dev/md0 /mnt/md0
  +
rsync -aHSA /mnt/sda1/. /mnt/md0/
  +
vim /mnt/md0/etc/fstab
  +
vim /mnt/md0/boot/grub/menu.lst
  +
umount /mnt/md0
  +
umount /mnt/sda1
  +
mdadm --add /dev/md0 /dev/sda1
  +
</pre>
  +
  +
* Ezt amúgy lehetne helyben is, ha úgy 1 MB-tal összezsugorítanánk előtte a fájlrendszert, de azért nem ajánlott.
  +
  +
=== Meglevő fájlrendszer RAID5/6-ra helyezése ===
  +
* Kb. mint fent, de:
  +
  +
<pre>
  +
# RAID5:
  +
mdadm --create /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 missing
  +
# _vagy_ RAID6:
  +
mdadm --create /dev/md0 -l6 -n4 /dev/sdb1 /dev/sdc1 /dev/sdd1 missing
  +
mkfs -t <type> /dev/md0
  +
mount /dev/sda1 /mnt/sda1
  +
mount /dev/md0 /mnt/md0
  +
rsync -aHSA /mnt/sda1/. /mnt/md0/
  +
vim /mnt/md0/etc/fstab
  +
vim /mnt/md0/boot/grub/menu.lst
  +
umount /mnt/sda1
  +
umount /mnt/md0
  +
mdadm --add /dev/md0 /dev/sda1
  +
</pre>
  +
  +
=== Tömb sorszámának átírása ===
  +
  +
Ha a /dev/mdX-ből mondjuk /dev/md4-et szeretnénk csinálni:
  +
<pre>
  +
mdadm --assemble /dev/md4 /dev/sd[abc]1
  +
</pre>
  +
  +
* Ezt meg fogja jegyezni, a továbbiakban az a tömb magától is md4 lesz
  +
* ... legalábbis 2.6-os kernel és legalább RAID1 esetén
   
 
== Potenciális zh-kérdések ==
  
== Potenciális zh-kérdések ==
152. sor: 325. sor:
 
* Mi a bitmap write intent logging, és mire jó?
  
* Mi a bitmap write intent logging, és mire jó?
 
* Mi a write-behind a linuxos softraid kontextusában, és mire jó?
  
* Mi a write-behind a linuxos softraid kontextusában, és mire jó?
  +
* Mit jelent a linuxos softraid terminológiájában a RAID10? Mik a jellemzői? Mik a (beállítható) paraméterei?

A lap jelenlegi, 2013. április 8., 22:12-kori változata

Linux alatt két programcsomag hivatott a szoftveres RAID kezelésére: a raidtools2 és az mdadm. Mi most csak az mdadm-mal foglalkozunk, mert a raidtools2 kihalófélben van: ha valaki akarja, házi feladatként bemutathatja.

Tartalomjegyzék

[szerkesztés] 1 RAID-tömbök

Linux alatt a RAID-tömböknek is lehet szuperblokkja; ez a tömböt alkotó blockdevice végén (vagy elején) található, és a tömb (automatikus) összerakásához nyújt segítséget. Ebből adódóan a RAID-tömbök tetszőleges mélységben egymásba ágyazhatók (vagyis olyan elrendezésben csinálunk RAID0 fölött RAID1-et vagy fordítva, ahogyan jólesik).

Többféle szuperblokk-verzió van, az alábbi előnyökkel/hátrányokkal:

  • 0.90:
    • a kernel össze tudja rakni a tömböket boot közben;
    • nem hordozható architektúrák között;
    • az eszköz végén van (4k hosszú, és az eszköz utolsó előtti teljes 64k-s blokkjának az elején van);
    • előfordulhat, hogy egy diszk és a rajta levő utolsó partíció RAID-szuperblokkja ugyanoda esik;
    • legfeljebb 28 elemű tömböket támogat.
  • 1.[012]:
    • csak userspace-ből rakhatók össze a tömbök;
      • vagyis ha RAIDről akarunk bootolni, initrd vagy initramfs kell;
      • (a GRUB2 elvileg bootol RAIDről, de ez csak annyit jelent, hogy be tudja tölteni a kernelt és az initrd-t; ha a rootfs RAIDen van, a kernel nem tudja önállóan összerakni);
    • lehet az eszköz elején és végén is;
    • többszáz tömbelemet támogat.

A szuperblokk nem minden konfigurációhoz szükséges (de a redundánsokhoz speciális esetektől eltekintve igen).

A 2.6.28-as kernel óta a meta-adatokat kezelheti egy tömbtől független, userspace processz is (így elvileg akármilyen metaadat-formátum támogatható). A kernel maga a saját formátumain kívül csak az Intel Matrix Storage Manager és a SNIA által szabványosított "Disk Data Format" metaadat-formátumát támogatja.

A /dev/md* eszközökön keresztül érhetjük el a RAID-tömbjeinket, miután "elindítottuk" őket (l. később). (md="multiple device")

Amúgy az mdadm kezelte régebben az ún. multipath konfigurációkat is (amikor redundáns útvonalak vannak a gép és a háttértár között), de ezzel itt nem foglalkozunk.

[szerkesztés] 1.1 RAID-szintek

A Linux a következő RAID-szinteket támogatja:

  • LINEAR: csak összefűzi az eszközöket, nincs se csíkozás, se redundancia; cserébe bővíthető.
  • RAID0: csíkozás. Ha nem egyforma nagyok az eszközök, akkor is az összes helyet használhatjuk, legfeljebb a végére nem lesz annyíra csíkos.
    • Egy csík (stripe) itt egy valamennyi fizikai eszközre kiterjedő, logikailag folytonos blokkcsoportot jelent.
    • Az egy diszkre eső csíkszelet neve chunk.
    • Bővíthető új diszk hozzáadásával (ilyenkor a kernel előbb RAID4-gyé alakítja a tömböt, hozzáadja az új diszket/diszkeket, újracsíkozza, majd újra RAID0-vá alakítja).
    • Online átalakítható RAID4-gyé, RAID5-té és RAID10-zé (2.6.35 óta).
    • A chunkméret is módosítható utólag.
  • RAID1: minden diszken pontosan ugyanaz van.
    • Párhuzamosan ír minden eszközre.
    • Az olvasásokat igyekszik elosztani az eszközök között (ennek főleg többszálú I/O esetén jelentős a hatása).
    • Ha nem minden diszk egyforma nagy, a nagyobbak pluszkapacitását nem tudjuk kihasználni (a tömbben levő logikai hely annyi lesz, mint a tömb legkisebb elemén levő).
    • "Bővíthető": ha az összes diszket nagyobbra cseréljük benne (szép sorban), akkor a tömb is megnőhet.
      • Persze adható hozzá új diszk, akár tartalékként, akár adatdiszkként; utóbbi eseteben a redundancia nő, a kapacitás nem.
    • Online átalakítható RAID5-té.
  • RAID4: mint a RAID0, de egy külön eszközön (az utolsó aktívon) van a csíkok paritása.
    • Itt is minden eszközből csak annyi kapacitás hasznosul, amennyi a tömb legkisebb elemén rendelkezésre áll.
    • Nem érdemes használni (kivéve, ha az egyik diszk sokkal gyorsabb, mint a többi).
    • 2.6.35 óta bővíthető és csökkenthető is.
    • Online átalakítható RAID0-vá, RAID4-gyé és RAID5-té.
    • A chunkméret is módosítható utólag.
  • RAID5: mint a RAID4, de a paritást is csíkozza.
    • A legújabb kernelek (2.6.17+) már tudják bővíteni (ehhez a teljes tömböt újra kell írni, úgyhogy nem egyszerű és nem gyors művelet, de legalább lehetséges).
      • 2.6.31 óta már csökkenteni is lehet a RAID5-ben levő diszkek számát (így nyilván csökken a tömb kapacitása; gondoskodni kell arról, hogy a rajta tárolt fájlrendszer összehúzza magát, mielőtt elkezdjük).
    • Online átalakítható RAID6-tá.
    • A chunkméret is módosítható utólag.
  • RAID6: mint a RAID5, de kétféle paritást tárol, így nem egy, hanem két diszk kiesését viseli el.
    • Általában kicsit lassúbb a RAID5-nél (két diszk kiesése esetén sokkal lassúbb, de legalább még működik).
    • Kb. 2007. nyarától (2.6.31) bővíthető és újabban csökkenthető is, mint a RAID5.
    • A chunkméret is módosítható utólag.
    • A RAID5 és a RAID6 menet közben átalakítható egymásba, akár úgy is, hogy közben diszket adunk hozzá a tömbhöz vagy távolítunk el.
  • RAID10: egy absztrakciós szinten megvalósított RAID1+0.
    • Csíkoz, és minden adatot legalább n példányban tárol.
    • Csinálhatunk pl. 5 diszkből álló csíkozott tömböt, amelynek nettó kapacitása 2,5 diszknyi, és minden adatot két példányban tárol, vagyis egy tetszőleges diszk kiesését túléli.
    • De csinálhatunk az 5 diszkből két diszk kiesését túlélő tömböt is, 5/3-ad diszknyi kapacitással.
    • Lehet hozzá hotspare-t adni.
    • Háromféle replika-elhelyezési módszert támogat:
      • near: egy csíkban (vagyis egymáshoz közel) helyezi el a replikákat.
      • far: egymástól távol helyezi el a replikákat.
        • Előnye: jobb szekvenciális olvasási teljesítmény.
        • Hátránya: lassúbb írás.
      • offset: egy adat másolata a következő csíkban, a következő eszközön kap helyet. (2.6.18-as kerneltől)
        • (Vélt?) előnye: a far-ral összemérhető szekvenciális olvasási teljesítmény, ha megfelelő a chunkméret.
        • Kevesebb fejmozgatással megúszható a replikák kiírása, vagyis kevésbé lassul az írás.
      • Ezeknek a hatását persze igazából ki kéne mérni.
      • Kis számú, közepes komolyságú saját mérés eredménye:
        • 12db 7200rpm-es SATA2 diszk, 3 "offset" példány és 256k-s ill. 512k-s chunkméret esetén nincs számottevő különbség a lineáris írás sebességében (kb. 350MB/s);
        • ugyanebben az elrendezésben kb. 10%-kal gyorsabb a lineáris olvasás az 512k-s chunkméret esetén (kb. 580MB/s);
        • nagyjából ugyanezt a sebességet produkálta a tömb 3 "near" replika esetén;
        • ehhez képest 3 "far" példány és 512k-s chunkméret esetén kb. 1300MB/s-os olvasási sebességet mértem;
        • véletlen olvasásokban is a "far" a legjobb, de nem ekkora a különbség.
        • Az írási sebesség sorrendje:
          • lineáris: far (kb. 310MB/s), offset (kb. 350MB/s), near (kb. 390MB/s).
          • 256k-s véletlen (itt volt a legnagyobb a különbség): far (kb. 160MB/s), offset (kb. 215MB/s), near (kb. 220MB/s) - az utóbbi különbség valószínűleg hibahatáron belül van.
      • Ez alapján szerintem kizárólag olyan esetben érdemes "far" helyett más layoutot használni, ha az írási sebesség csekély növelése megéri az olvasási sebesség felének elvesztését. Természetesen más mérések adhatnak más eredményt!
    • A replika-elhelyezési módszerek keverhetők: kérhetünk pl. egy near és egy far replikát. Jó ez valamire?
    • Jelenleg nem bővíthető új diszkkel, de a 3.4-es kernel óta a near és az offset layoutot használó tömbök átméretezhetőek úgy, hogy a meglevő diszkeken több vagy kevesebb helyet foglaljanak (tehát egy tömb tárolókapacitását megnövelhetjük úgy, hogy az összes diszket egyenként nagyobbra cseréljük, majd végül megnöveljük a tömböt -- mint a RAID1 esetében).

[szerkesztés] 1.2 A konzisztencia biztosítása, hibakezelés

  • Alapesetben írás előtt dirtynek jelöli a tömböt
  • A tömb leállításakor clean lesz
    • Tehát bootkor elvileg mindig clean
  • De RAID1, RAID4, RAID5, RAID6 és RAID10 esetén legalább két írás kell a konzisztens állapot megőrzéséhez, és ezek nem biztos, hogy pontosan egyszerre mennek végbe
    • Vagyis van egy időablak (lehet, hogy innen kapta a nevét a "write hole"), ami alatt ha eltűnik a táp, inkonzisztens (dirty) lesz a tömb
  • Ha indításkor dirty, resync:
    • RAID1: az első diszkről a többire másolja a tartalmat
    • RAID4, RAID5, RAID6: a diszken található adatokból újraszámolja a paritást és azt írja a paritásblokkba
    • RAID10: minden adat első replikáját rámásolja a többire
  • Resync közben a tömb írható és olvasható
    • Igyekszik úgy ütemezni, hogy a resyncre ne nagyon kelljen várnia a többi processznek
    • sysfs, procfs: speed_limit_min, speed_limit_max
  • Ha már nincs redundancia, akkor a 2.6-os kernel a dirty arrayt nem is hajlandó automatikusan elindítani
  • Ha írás közben hibát észlel egy tömb egy elemén, azt az elemet hibásnak (faulty) jelöli, és nem használja
  • Ha van hotspare (tartalék), azonnal elkezd rá szinkronizálni
    • Ha nincs, de ugyanebben a spare groupban van másik tömb, és abban van, akkor onnan "ellopja"
  • Ha olvasási hiba van, először megpróbálja javítani úgy, hogy az oda való adatot kiszámítja és kiírja, majd megpróbálja visszaolvasni. Ha ez nem megy, akkor jelöli hibásnak a diszket.
    • Ez jól hangzik, de nem biztos, hogy a gyakorlatban is jó - lehet, hogy jobb lenne cserélni azt a diszket.
    • Persze ha csak tranziens bithiba volt, akkor mégiscsak jó.
    • Sajnos nem lehet úgy cserére jelölni egy diszket, hogy addig, amíg be nem fejeződik a tartalék szinkronizálása, még használja a gyengélkedő diszket is (pedig így lehetne redundanciánk a csere alatt, ami még akkor is jobb, mint a semmi, ha a cserélendő diszknek akár csak a fele olvasható).
  • Érdemes a tömböket időnként ellenőrizni ("scrubbing"): végigolvasni és összehasonlítani a redundáns példányokat, ellenőrizni a paritást, és persze javítani az esetleges hibákat: echo repair >/sys/block/mdX/md/sync_action (de az mdadm tudja ezt automatizálni).
    • "repair" helyett kérhetünk "check"-et is; ez nem javítja a hibákat, csak jelzi őket.
    • RAID1 és RAID10 esetében, ha swapelünk a tömbre, előfordulhat inkonzisztencia akkor, ha egy éppen kiswapelődő lap tartalma megváltozik írás közben, így az egyik diszkre az egyik, másikra a másik állapot kerül. Ez nem okoz gondot, mert ha a lap módosult, akkor a VM (egyelőre) nem swapeli ki, a kiírt többféle változatot üres swap-helynek tekinti és sosem fogja beolvasni.

[szerkesztés] 1.3 Bitmap write-intent logging

  • 2.6.13 óta az md driver, ha kérjük, egy bitmap-naplóban jelzi, hogy hova fog írni
  • 2.6.13-ban RAID1, 2.6.15-től a többi RAID-hez is megvan
  • Ez a "szándéknapló" utólag is hozzáadható működő tömbhöz, és el is távolítható belőle
  • Ha az adott területre hosszabb ideig nem történik több írás, a vonatkozó bitet törli
  • Ha kiveszünk egy diszket a tömbből, a biteket a többin sem törli már

Így:

  1. Tápvesztés és dirty indulás után nem kell teljes resync, csak a bitmap alapján piszkos részekhez kell nyúlni
  2. Ha egy diszket kiveszünk a tömbből, majd visszarakjuk, nem az egész tömböt kell újraszinkronizálni

Persze az írási sebesség valamennyivel biztos kisebb, ha a szándéknaplót is frissítgetni kell (főként, mivel ehhez seekekre van szükség, de nem minden íráskor); ki kellene mérni, mekkora a különbség. Ha kritikus a sebesség, a szándéknaplót tartsuk egy a tömbön kívüli eszközön levő fájlban.

[szerkesztés] 1.4 Write-mostly

RAID1-en lehet beállítani.

  • Ha így jelölünk meg egy tömbelemet, akkor a kernel arról csak akkor fog olvasni, ha muszáj, de írni ír rá.
  • Így nem lassul le (annyira) a tömb, ha pl. hálózaton át is mirrorozunk.

[szerkesztés] 1.5 Write-behind

  • 2.6.14 óta
  • RAID1-en
  • A write-mostly tömbelemek viselkednek így, ha van write-intent bitmap.
  • Hatása: az adott eszközre aszinkron módon ír.
  • Értelme: ha aránylag lassú elérésű (mondjuk hálózati) diszk is van a tömbben, az is nagyjából szinkronban lesz, de még annyira sem lassítja a rendszer működését, mint a write-mostly esetén.
    • Túl lassú (szaturált) kapcsolat esetén persze nem jó.

[szerkesztés] 1.6 Újracsíkozás

  • Restriping, reshaping
  • A tömb újraírása a struktúra megváltoztatása érdekében, pl:
    • Diszkek számának növelése ("szélesebb" csíkok)
    • Chunkméret csökkentése ("sekélyebb" csíkok)
    • Chunkméret növelése ("mélyebb" csíkok)
    • Adat- és/vagy paritásstruktúra megváltoztatása (pl. áttérés RAID1-ről RAID5-re vagy RAID5-ről RAID6-ra)
    • Ezek a műveletek biztonságosak; akkor sem vesztünk adatot, ha közben elmegy az áram (l. man mdadm).
      • Érdekesség: ha 0.90-es metadata-verziójú tömböt reshape-elünk, akkor a folyamat végéig 0.91-re állítja a verziószámot a kernel, hogy ha megszakadna a reshape és egy régebbi kernelt bootolnánk, ami nem tudja folytatni, ne tegye tönkre a tömböt azzal, hogy megpróbálja összeilleszteni.

[szerkesztés] 2 Kernel-paraméterek, sysfs-interfész

  • raid=noautodetect: ne ismerje fel és indítsa el automatikusan a 0xfd típusú partíciókat
  • raid=partitionable: particionálható tömböket szeretnénk
  • md_mod.start_dirty_degraded=1: akkor is elindítja a tömböt, ha degradált is és dirty is - hasznos, ha ez a root filerendszer.
  • md=n,dev,dev,...: az mdn a megadott eszközökből állítandó össze boot közben.
  • A szinkronizálás sebessége állítható a /sys/block/mdX/md/sync_speed_{max,min} átírásával (van/volt /proc tunable is hozzá, de ezen a héten a sysfs-t szeretjük jobban)
  • A szinkronizálás sorrendjét befolyásolhatjuk így: echo idle >/sys/block/md1/md/sync_action. Ekkor az md1 szinkronizálása felfüggesztődik és helyette a sorban következő tömbé kezdődik meg.
  • A sysfs-ben állítható két paraméter:
    • stripe_cache_size: RAID5 és RAID6 esetén van rosszul dokumentált szerepe (nincs kedve valakinek megnézni a forrásban?). Ha növeljük, az használhat a teljesítőképességnek, de memóriába kerül.
    • preread_bypass_threshold: szintén csak RAID5-re és RAID6-ra értelmezett. Szintén nem túl jó a dokumentáció; az érték elvileg azt adja meg, hány teljes csíkot érintő műveletet hajtson végre az MD driver, mielőtt sort kerítene egy olvasást is igénylő kis írásra. Ugyanakkor azt is írják, hogy 0-ra állítva a kis írásokat végző szálakat büntetjük, ami ellentmondás.

[szerkesztés] 3 Az mdadm használata

Üzemmódjai:

  1. Assemble
    • "Elindítja" (láthatóvá teszi) a megadott tömböt
  2. Build
    • Szuperblokkmentes tömböt rak össze
    • Ilyenkor természetszerűen az első létrehozás és a későbbi újbóli elindítás ugyanaz a művelet
  3. Create
    • Új (szuperblokkos) tömb létrehozása
  4. Follow/Monitor
    • A megadott tömbök állapotát figyeli, reagál a változásokra
    • Csak redundánds tömbökre van értelme
  5. Grow
    • Újracsíkozás
  6. Manage
    • Eszköz hozzáadása tömbhöz, kiszedése, hibásnak jelölése stb
  7. Misc
    • "Egyéb": pl. RAID szuperblokk törlése; információkérés
      • akkor kell törölni a szuperblokkot, ha végleg el akarunk távolítani egy eszközt egy tömbből

Néhány tipikus felhasználás:

[szerkesztés] 3.1 Új tömb létrehozása 

mdadm --create -l1 -n2 -x1 /dev/md0 /dev/sd[abc]1   # RAID 1, 1 spare
mdadm --create -l5 -n3 -x1 /dev/md0 /dev/sd[abcd]1  # RAID 5, 1 spare
mdadm --create -l6 -n4 -x1 /dev/md0 /dev/sd[abcde]1 # RAID 6, 1 spare

[szerkesztés] 3.2 Degradált tömb létrehozása

("Féllábúnak" vagy hiányosnak is mondják.)

A tényleges eszköznév helyére írjuk azt, hogy "missing": 

mdadm --create -l5 -n3 /dev/md0 /dev/sda1 missing /dev/sdb1
mdadm --create -l6 -n4 /dev/md0 /dev/sda1 missing /dev/sdb1 missing

[szerkesztés] 3.3 Tömb összeillesztése

  • Ha már egyszer korábban létrehoztuk, de a kernel még nem inicializálta: 
mdadm --assemble --auto=yes /dev/md0 /dev/sd[abc]1
  • Ha hiányos, nem indul el magától, kell a --run: 
mdadm --assemble --auto=yes --run /dev/md0 /dev/sd[ab]1
  • Vagy összerakás után külön elindíthatjuk: 
mdadm --run /dev/md0
  • A /etc/mdadm/mdadm.conf-ban felsorolt összes tömb összeillesztése és elindítása (ilyesmit csinál az initramfs/initrd): 
mdadm --assemble --auto=yes --scan
  • Hiányos, piszkos tömb összeillesztése és elindítása (a konzisztencia így nem biztosított!): 
mdadm --assemble --auto=yes --force /dev/md0 /dev/sd[ab]1
mdadm --run /dev/md0

[szerkesztés] 3.4 Tömbök leállítása 

mdadm --stop /dev/md0
  • Vagy az összesé, ami a configban van: 
mdadm --stop --scan

[szerkesztés] 3.5 Tömbelemek hozzáadása

  • Ha már fut a tömb: 
mdadm --add /dev/md0 /dev/sdc1
  • Ha többet adunk hozzá, mint ahányból létrehozáskor állt, a többletből melegtartalék lesz.

[szerkesztés] 3.6 Tömbelemek eltávolítása

  • Először jelöljük hibásnak, amit ki akarunk venni: 
mdadm --fail /dev/md0 /dev/sdb1
  • Ekkor elkezdi szinkronizálni a(z egyik) melegtartalékot
  • Szedjük is ki a tömbből a hibásnak jelölt eszköz: 
mdadm --remove /dev/md0 /dev/sdb1

[szerkesztés] 3.7 Hibás diszk cseréje

Ha a /dev/sdb failed állapotban van: 

mdadm --remove /dev/md0 /dev/sdb
halt # ha nem hot-swappable...
# diszkcsere
mdadm --add /dev/md0 /dev/sdb

[szerkesztés] 3.8 Új aktív diszk hozzáadása RAID1-hez

  • Már fusson a tömb, és: 
mdadm --grow -n3 /dev/md0
mdadm --add /dev/md0 /dev/sdc1

[szerkesztés] 3.9 Aktív diszkek számának csökkentése RAID1-ben 

mdadm --fail /dev/md0 /dev/sdc1
mdadm --remove /dev/md0 /dev/sdc1
mdadm --grow -n2 /dev/md0

[szerkesztés] 3.10 Meglevő fájlrendszer RAID1-esítése

  1. Bebootolunk egy live CD-ről (hogy biztosan ne írjon semmi a fájlrendszerbe, miközben másoljuk)
  2. Létrehozunk egy új, féllábú RAID1-et a második diszken
  3. Rámásoljuk az adatokat
  4. Hozzáadjuk a tömbhöz az első diszket
  5. Rebootolunk a szép új RAIDes fájlrendszerünkkel

Ha a /dev/sda1 a meglevő fájlrendszer és a /dev/sdb1 az új diszk, akkor: 

mdadm --create /dev/md0 -l1 -n2 /dev/sdb1 missing
mkfs -t <type> /dev/md0
mount /dev/sda1 /mnt/sda1
mount /dev/md0 /mnt/md0
rsync -aHSA /mnt/sda1/. /mnt/md0/
vim /mnt/md0/etc/fstab
vim /mnt/md0/boot/grub/menu.lst
umount /mnt/md0
umount /mnt/sda1
mdadm --add /dev/md0 /dev/sda1
  • Ezt amúgy lehetne helyben is, ha úgy 1 MB-tal összezsugorítanánk előtte a fájlrendszert, de azért nem ajánlott.

[szerkesztés] 3.11 Meglevő fájlrendszer RAID5/6-ra helyezése

  • Kb. mint fent, de: 
# RAID5:
mdadm --create /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 missing
# _vagy_ RAID6:
mdadm --create /dev/md0 -l6 -n4 /dev/sdb1 /dev/sdc1 /dev/sdd1 missing
mkfs -t <type> /dev/md0
mount /dev/sda1 /mnt/sda1
mount /dev/md0 /mnt/md0
rsync -aHSA /mnt/sda1/. /mnt/md0/
vim /mnt/md0/etc/fstab
vim /mnt/md0/boot/grub/menu.lst
umount /mnt/sda1
umount /mnt/md0
mdadm --add /dev/md0 /dev/sda1

[szerkesztés] 3.12 Tömb sorszámának átírása

Ha a /dev/mdX-ből mondjuk /dev/md4-et szeretnénk csinálni: 

mdadm --assemble /dev/md4 /dev/sd[abc]1
  • Ezt meg fogja jegyezni, a továbbiakban az a tömb magától is md4 lesz
  • ... legalábbis 2.6-os kernel és legalább RAID1 esetén

[szerkesztés] 4 Potenciális zh-kérdések

  • Hasonlítsa össze a RAID0+1 és a RAID1+0 elrendezést! Miért jobb az egyik, mint a másik? Esetleg egyformán jók?
  • A RAID0, a RAID1, a RAID5, a RAID6, a RAID10, 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.)
  • Milyen RAID-elrendezést választana, ha a következő feltételeknek kell megfelelni?
    • 6 darab egyforma nagyságú diszkünk van.
    • Minden adatot legalább két példányban akarunk tárolni, két különböző diszken.
    • Legalább 2,5 diszknyi kapacitásra van szükségünk.
    • Linux softraidet szeretnénk használni.
    • Legalább egy diszkünk legyen hotspare.
  • Mit csinál a Linux újraszinkronizáláskor RAID1, RAID5, RAID6 ill. RAID10 esetén?
  • Mi a bitmap write intent logging, és mire jó?
  • Mi a write-behind a linuxos softraid kontextusában, és mire jó?
  • Mit jelent a linuxos softraid terminológiájában a RAID10? Mik a jellemzői? Mik a (beállítható) paraméterei?
A lap eredeti címe: „http://unixlinux.tmit.bme.hu/index.php?title=Software_RAID_Linux_alatt&oldid=5765”
Személyes eszközök