Software RAID Linux alatt
a (→RAID-szintek: 3.4 óta a RAID10 korlátozottan bővíthető) |
|||
(egy szerkesztő 12 közbeeső változata nincs mutatva) | |||
4. sor: | 4. sor: | ||
== [[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 [[RAID#RAID0|RAID0]] fölött [[RAID#RAID1|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: |
+ | |||
+ | * 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. |
||
=== [[RAID]]-szintek === |
=== [[RAID]]-szintek === |
||
16. sor: | 16. sor: | ||
* [[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. |
* [[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''. |
+ | ** 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. |
* [[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. |
||
− | * [[RAID#RAID4|RAID4]]: mint a [[RAID#RAID0|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 [[RAID#RAID1|RAID1]]). |
+ | ** 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. |
||
* [[RAID#RAID5|RAID5]]: mint a [[RAID#RAID4|RAID4]], de a paritást is csíkozza. |
* [[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). |
||
+ | *** 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. |
* [[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). |
||
− | ** Kb. 2007. nyarától bővíthető, mint a [[RAID#RAID5|RAID5]]. |
+ | ** Kb. 2007. nyarától (2.6.31) bővíthető és újabban csökkenthető is, mint a [[RAID#RAID5|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. |
||
* [[RAID#RAID10|RAID10]]: egy absztrakciós szinten megvalósított [[RAID#RAID1.2B0|RAID1+0]]. |
* [[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 ([[RAID#RAID0|RAID0]]-hoz nem, [[RAID#RAID1.2B0|RAID1+0]]-hoz sem, [[RAID#RAID0.2B1|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: | 65. 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: | 76. 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 === |
||
75. sor: | 112. sor: | ||
* 2.6.14 óta |
* 2.6.14 óta |
||
* [[RAID#RAID1|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: | 122. 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 [[RAID#RAID1|RAID1]]-ről [[RAID#RAID5|RAID5]]-re vagy [[RAID#RAID5|RAID5]]-ről [[RAID#RAID6|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 [[RAID#RAID5|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: | 134. 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: | 160. 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 == |
||
149. sor: | 327. sor: | ||
** Linux softraidet szeretnénk használni. |
** Linux softraidet szeretnénk használni. |
||
** Legalább egy diszkünk legyen hotspare. |
** Legalább egy diszkünk legyen hotspare. |
||
− | *** User-contributed válasz: |
||
− | *** ha RAID10-et készítünk 5 diszkből, 1 hotspare, akkor ippeg 2,5 diszknyi kapacitást kapunk, valamint minden adat pontosan két példányban, két különböző diszken lesz jelen, sőt még csíkoz is |
||
− | *** ha RAID5-öt készítünk 5 diszkből, 1 hotspare, akkor mintegy 4 diszknyi kapacitást kapunk, feltehetőleg ez sem rossz megoldás |
||
− | *** ha RAID6-ot készítünk 5 diszkből, 1 hotspare, talán még akkor is több, mint 2,5 diszknyi kapacitást kapunk, és ez két kiesett diszk hibát is tolerál |
||
− | |||
* Mit csinál a Linux újraszinkronizáláskor RAID1, RAID5, RAID6 ill. RAID10 esetén? |
* 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 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., 23: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.
[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.
- csak userspace-ből rakhatók össze a tömbök;
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.
- 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.
- Á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:
- 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
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:
- Assemble
- "Elindítja" (láthatóvá teszi) a megadott tömböt
- 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
- Create
- Új (szuperblokkos) tömb létrehozása
- Follow/Monitor
- A megadott tömbök állapotát figyeli, reagál a változásokra
- Csak redundánds tömbökre van értelme
- Grow
- Újracsíkozás
- Manage
- Eszköz hozzáadása tömbhöz, kiszedése, hibásnak jelölése stb
- 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
- "Egyéb": pl. RAID szuperblokk törlése; információkérés
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
- 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 /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?