RTFM1 – mindig van mit faragni

(Volt ilyenem a CentOS4 → 5 → 6 során is bőven, de ez természetesen nem OS függő.) Ilyen hátralék ez a téma is, egy rakás mellébeszéléssel. :) (Ami meg nem az, az jegyzet magamnak is.)

Az első HDD-m, amire Linuxot (is) telepítettem, egy 3½-es 30GB-os merevlemez volt. (A méretéből kitalálható, hogy ez se tegnapi...A diszk még mindig megvan, 2001 februári gyártású, természetesen IDE-s. Nem számított akkor ez még kicsinek, a kapacitást 5 lemeztányérral / 10 fejjel (!) rakták össze. Egyszer tuti szétszedem, kíváncsi vagyok arra a tumultusra...) Nálam a dolgok nem szoktak csak úgy elpusztulni (inkább megjavulni... :) ), ezzel is elvoltam egy darabig. De ehhez tartozik az első igazi HDD-s problémám is, egyik nap az OS betöltése alatt hisztis lett, csúnya hangok kíséretében nekiállta „csapkodni” a fejet. Szerencsére – mint kiderült – csak szektorhiba... Mivel már akkor is mindig „szétparticionáltam” a meghajtó(ka)t, a munkáimat sikerült hiánytalanul lementeni róla, a szektorhiba az elején volt, még az OS alatt. („Hurcolászós” háttértárnak még sokáig használatban volt utána, a hibás szektorok környékét a megfelelő particionálással kihagyva. Ha nem járt arra a fej, nem is volt vele látszólag semmi gond.) Az eset akkor kellőképpen „megijesztett”, de nem csere-diszk, hanem csere-diszkek lett a megoldás. Ezek egyformák, még szintén IDE-s darabok, de már 80GB-os kapacitásúak. A terv annyi volt, hogy egy – lehetőleg olcsó – RAID vezérlő kártyával fogja a gép használni tükrözéses üzemmódban, így mindig minden két példányban is meglesz.

A RAID egy mozaikszó, a „Redundant Array of Independent Disks” rövidítése. Magyarra talán „Redundáns Tömb Független Merevlemezekből” módon lehetne lefordítani, de – ha nem gond – inkább maradok az eredeti angol rövidítésnél... :)

És igen, tudom, hogy a RAID nem backup! De egyszeri diszk-halál esetén legalább kisebb lesz a para. :) Ezzel a felállással is jó darabig elvoltam, míg egyszer csak a RAID vezérlő kártya BIOS-a ki nem dobta az egyik diszket azzal az indokkal, hogy nem egyforma kapacitásúak. (Érdekes, évekig egyformák voltak? :-D ) Szóval eljött ennek is a csereideje, de előtte kipróbáltam még ezt-azt. Kerestem a RAID vezérlőhöz FW frissítést, amit találtam is, sőt, a kártyán levő csip dokumentációja is meglett. Ekkor derült ki, hogy az olcsó RAID vezérlő kártyám NEM un. FakeRAID vezérlő, hanem „rendes”, amit nem gondoltam volna. A diszkek közül az egyik még ma is használatban van, látszólag semmi baja. Persze a történet nem maradt annyiban, a hozzávalók le lettek cserélve. A felállás megmaradt, csak az IDE-s eszközöket két SATA-s, 2½-es 160GB-os példány váltotta, amik ráadásul különböző gyártótól vannak. (Mivel tükrözéses felállásban ugyanazt a terhelést kapja a két diszk, ha ugyanakkor és ugyanott készültek, jó eséllyel ugyanaddig is fogják bírni. Ha a gyártó más, akkor két paraméter is eltér...) A poén az, hogy attól függetlenül, hogy két külön gyártó, szektorra pontosan megegyezik a méretük! (Csak nem ugyanattól veszik a fejet? :-D ) Ez a felállás már ténylegesen FakeRAID verzió lett. Az alaplappal együtt a többi komponens közben szépen cserélődött, de ez a két diszk valahogy maradt. Néha „biztonsági mentést” csináltam rájuk, de egy ideje már nem voltak aktív használatban.

A mostani migrálás után az lett az ötlet, hogy a 160GB-os tükröt befoghatnám a munkafájljaim tárolására, ehhez csak egy könyvtárat kell a megfelelő helyre tenni / linkelni. Az eddig használt Linux-ok (többé kevésbé) látták normálisan a FakeRAID tömböt, de automatikusan csatolni még nem akartam. Most ez a feladat, az /etc/fstab fájlba beírva nem sikerült. A boot mindig elakadt a partíció csatolásánál. A kereső túlzottan nem volt a barátom ismét, Linux témában a SoftRAID a jellemző (ahol a BIOS még külön kezeli a diszkeket), de ilyet eddig még nem csináltam. A leírások alapján nem egy rocket science a feladat, emiatt a legtöbb találat RAID tömbre való telepítéssel foglalkozik, nekem most meg nem az kell. Azért találni sima „how-to”-t is, amit végül használtam, azt most meg nincs meg. :)

Nulladik lépésként még a BIOS RAID konfiguráló részével „szét kell bontani” a FakeRAID tömböt, hogy az ne kavarjon be. A többi feladat már az OS oldaláról van.

1. Kell az mdadm csomag, ezt egy
   # yum install mdadm
   paranccsal fel lehet rakni.
2. A két diszk nálam a /dev/sdc illetve a /dev/sdd ponton érhető el. Ez fontos, mert „bántani fogom” őket, másban nem kellene semmilyen kárt okozni! Mindkét diszken létre kell hozni egy partíciót, mindkettőnek ugyanolyan méretűnek kell lennie, illetve a partíció típusa 0xFD („linux_raid_automatic”, vagy valami ilyesmi) kell hogy legyen. Erre a feladatra kiváló a cfdisk parancs, természetesen mindkét diszken külön meg kell ezt csinálni. Mivel esetemben a két HDD szektorra pontosan megegyező méretű, illetve egy darab partíciót akartam, így a feladat nem különösen bonyolult; mindkét diszken egy elsődleges partíció lett létrehozva, ami kitölti a teljes helyet.
3. A biztonság kedvéért a rendszerrel újra be célszerű olvastatni a megváltozott partíciós táblát, ezt a
   # partprobe /dev/sdc
# partprobe /dev/sdd
   parancsokkal a legegyszerűbb megoldani.
4. Jöhet a tömb generálása, erre az
   # mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdc1 /dev/sdd1
   parancs szolgál. A /dev/md0 lesz az eszköz „neve”, amire majd a fájlrendszer fog kerülni. A --level=1 jelenti a tükrözést, a --raid-devices=2 után a tükrözendő partíciók nevei vannak. (Az előbb létrehozott partíciók vannak megadva, nem az eszközök maguk!) Hogy ilyenkor melyik meghajtóról melyikre másolódik az adat, az jó kérdés (lehet hogy írja...), de ez most nem számít, mivel „üres” partíciókról van szó.
5. Az előző feladat eltart egy ideig, de ezt a rendszer a háttérben, „magától” csinálja. Az hogy hol is tart, azt egy
   # watch cat /proc/mdstat
   paranccsal nyomon lehet követni:
   
6. Mikor ez végzett (Vagy ezt ki se kell várni? Én türelmes vagyok...), akkor egy egyszerű ls /dev/md* paranccsal ellenőrizhető, hogy az md0 eszköz létre jött-e.
7. Jöhet a fájlrendszer létrehozása, ez az
   # mkfs.ext3 /dev/md0
   parancsra szépen meg is történik. (Ez már nem tart órákig...)
8. A fájlrendszer elkészült, csak elfelejtettem neki kötetcímkét adni. (Jó az, kell...) Ezt a gondot utólag egy
   # e2label /dev/md0 160GS_R
   paranccsal egyszerű megoldani.
9. Az imént elkészült partíciót lassan illene tesztből felcsatolni, ehhez egy szimpla
   # mount /dev/md0 /mnt/raid
   parancs tökéletes lesz. (A /mnt/raid könyvtár mint csatolási pont persze már korábban létre lett hozva.) Amennyiben működik, akkor eljutottam ismét oda, ahol a FakeRAID esetében alapból tartottam... :)
10. Amiért az egész folyamat készült, jöhet az automatikus csatolás a boot-folyamat alatt. Ehhez az /etc/fstab-ba a
    /dev/md0 /mnt/raid ext3 defaults 1 2
    sort fel kell venni. Működik a
    LABEL=160GS_R /mnt/raid ext3 defaults 1 2
    sor is, de ezt inkább nem erőltetném. (Ha esetleg a későbbiekben valamiért nem épülne föl a tömb, akkor – mint szimpla partíciót – ne akarja csatolni a címke alapján. Bár lehet hogy ez nem is menne...)

Ezután egy „gyors” reboot, és igen, tudja csatolni automatikusan a partíciót! Hurrá! :) A megfelelő jogosultságok beállítása után gyorsan be is lett lakva. Tényleg nem lett bonyolult a dolog, nem is értem, miért nem csináltam meg ezt már régen... Pár különbség van azért a FakeRAID illetve a most felépített SoftRAID között. Eredetileg maguk a diszkek voltak RAID1-be összefogva, ezen az összefogott eszközön lett a partíciós tábla a partícióval létrehozva, majd utána lett a fájlrendszer fölépítve. (A /dev/mapper alatt ekkor két eszköz is látszott, egyrészt az egész tömb, másrészt a tömbön létrehozott partíció. Természetesen az utóbbit kellett csatolni.) Most van két egyforma partícióm, ezek vannak RAID-ben összefogva, ebből lett a /dev/md0 eszköz, ezen van a fájlrendszer létrehozva. Mindkét megoldás mögött érteni vélem a logikát, de ez a második egy kissé – hogy is mondjam – idegen. :) Persze működik, szóval a feladat letudva. A /proc/mdstat „fájlban” a későbbiekben is figyelhető a tömb állapota:

Erre valami egyszerű GUI-s cucc vajon van-e? ;)

Ezt pusztán azért kérdezem, mert a RAID1 összeállítása után pár napra az egyik diszket a rendszer ki is dobta a tömbből. :) Régiek a diszkek, az már igaz... Az kiderült, hogy az /etc/fstab-ba beírva automatikusan nem csatolja a rendszer a féllábú tükröt, egy emergency shell-t kap az ember a boot folyamat alatt. (Legalábbis itt, CentOS7-en.) Kézzel viszont minden további nélkül csatolható, az adatok le is menthetők róla. A neten keresgetve több oldalon olvasni olyat, hogy a /dev/sdX számok nem tutira ugyanazok mindig, így az ember jobb ha az eszközök generált neveivel (a /dev/disk/by-id/ könyvtárban levő symlinkekkel) hivatkozik a partíciókra. Hogy az MD kezelőt zavarja-e az, hogy az alap eszköznevek változnak, az jó kérdés, az mdadm --create parancsnál mindenesetre a „generált neveket” adtam meg másodszorra, a /proc/mdstat alatt viszont már a közvetlen eszköznevek látszanak, szóval a tippem az lenne, hogy nem. :) A hiba után megpróbáltam újra generálni a RAID1 tömböt, ehhez először le kell állítani. Erre az
# mdadm --stop /dev/md0
# mdadm --remove /dev/md0
parancsok hasznosak. Az újra generálás alatt az egyik diszket úgyszintén kihajította, szóval valami tényleg nem kerek... Egy utolsó esélyként kicseréltem a SATA kábeleket, utána már lefutott a szinkronizáció, újra működik a tömb szépen. Szóval nem ártana valami kis util, ami probléma esetén visítozik. :-D

Konklúzió: A SATA csatlakozók az elektronikai ipar szégyenei. :-| (Az UDMA66/100/133 csatlakozó se volt éppen kutya, de ez... Valami dokumentációban olvastam régebben, hogy – írd és mondd: – 30 db. csatlakoztatást kell nekik kibírni.) Egyelőre a diszkek jónak tűnnek, úgy tűnik tényleg kábel-gond volt. Azóta lefutott egy ellenőrzés is:

Ezt az ellenőrzést – gondolom – időnként automatikusan elvégzi. De ha később is kihullik valamelyik diszk, akkor ki lesz(nek) cserélve, bár ez most valahogy nincs a költségvetésbe betervezve.

Ápdét: pár hete már megtörténtek a fent leírtak, eddig úgy tűnik minden rendben van a diszkekkel. Sanszos, hogy tényleg valamelyik kábel volt a hunyó a történetben. (Még az is lehet, hogy elég lett volna átmozgatni a csatlakozókat.) Szóval örülünk! A fenti képen is látható ellenőrzésbe nekifogott pár napja is, talán két hetenként „check”-el? (Nagyon csodálkoznék, ha ezt nem lehetne állítani, de annyira nem érdekelt a dolog, hogy utána is keressek.) A mostani ellenőrzést viszont nem tudtam kivárni, le kellett állítani a gépet. Másnap viszont mintha nem folytatta volna... De ez nem tuti, bekapcsoláskor elfelejtettem figyelni, amikor meg ránéztem, már a „normál állapot” volt. De a lényeg: HDD csere elnapolva. ;)

Ápdét #2: de szeretem én az óra-átállítást... :\ (Az órát csak odébb csavarják, nekem meg egy hétig tart átállnom...) A RAID1 tömb bő 1 éve (megy az idő...) hibátlanul üzemel. Mivel az éjszaka ismét nekiállt ellenőrizni magát, én meg a sokadik alkalommal lőttem volna le pont eközben, ezért inkább „rákerestem” erre az automatikus ellenőrzés időzítésre. Egyrészt lehet ezt – természetesen – kézzel is indítani:

# echo check > /sys/block/md0/md/sync_action

Illetve megállítani:

# echo idle > /sys/block/md0/md/sync_action

Az automatikus ellenőrzéshez nem készítettek semmi varázslatot, mivel Linuxon (meg egyéb UNIX-okon illetve kompatibilis rendszereken is) van az ilyen ütemezett feladatok végrehajtására megoldás, ami nem más mint a cron. CentOS7 alatt is van a tesztelés indításához egy „bejegyzés”, ami egy fájl az /etc/cron.d/raid-check helyen / néven:

# Run system wide raid-check once a week on Sunday at 1am by default
0 1 * * Sun root /usr/sbin/raid-check

Ezen fájl alapján az /usr/sbin/raid-check szkriptet indítja el a root felhasználó jogosultságával, mégpedig minden héten vasárnap, hajnali 1 órakor. És tényleg... Ezt most akkor módosítom is:

0 21 * * Sat root /usr/sbin/raid-check

Az indítás így szombaton lesz, 21 órakor. Legalábbis remélem... :) Mivel a teljes ellenőrzés nagyjából 1 óra 20 percig tart, azért kisebb eséllyel fogom így elkaszálni.

Linkek:

• SoftRAID mdadm segítségével – leírás
• SoftRAID újra – egy másik leírás
• Puska az mdadm-hoz
• RAID leírás az Arch Wiki-ből

balagesz

---

2015.03.02.
2015.03.16. Állapotjelentés :)
2016.03.28. Automatikus ellenőrzés, + link
2019.12.16. D8.