Andmete taastamine ja ebaõnnestunud tarkvara RAID-de ülesehitamine - 8. osa
Selle RAID-seeria eelmistes artiklites läksite nullist RAID-kangelaseks. Vaatasime üle mitmed tarkvara RAID-konfiguratsioonid ja selgitasime igaühe põhitõdesid koos põhjustega, miks te oma konkreetse stsenaariumi järgi ühe või teise poole kaldute.
Selles juhendis käsitleme, kuidas taastada tarkvara RAID massiivi ilma andmekaotust ketta rikke korral. Lühiduse huvides kaalume ainult RAID 1 seadistamist, kuid mõisted ja käsud kehtivad kõikidel juhtudel.
Enne jätkamist veenduge, et olete seadistanud RAID 1 massiivi, järgides selle sarja 3. osas toodud juhiseid: Kuidas RAID 1 (peegel) Linuxis seadistada.
Ainsad variatsioonid meie praegusel juhul on järgmised:
1) CentOS-i (v7) versioon, mis on selles artiklis kasutatud (v6.5), ja
2) erinevad ketasuurused/dev/sdb ja/dev/sdc jaoks (kumbki 8 GB).
Kui SELinux on jõustamisrežiimis lubatud, peate lisama vastavad sildid kataloogi, kuhu RAID-seadme ühendate. Vastasel juhul jookseb see hoiatusteade selle installimise ajal:
Selle saate parandada, käivitades:
# restorecon -R /mnt/raid1
RAID-seire seadistamine
Mäluseade võib ebaõnnestuda mitmel põhjusel (SSD-d on selle juhtumise tõenäosust siiski oluliselt vähendanud), kuid hoolimata põhjusest võite olla kindel, et probleeme võib tekkida igal ajal ja peate olema valmis ebaõnnestunud asendama teie andmete kättesaadavuse ja terviklikkuse tagamiseks.
Kõigepealt nõu. Isegi kui saate RAID-de oleku kontrollimiseks/proc/mdstat kontrollida, on parem ja aega säästev meetod, mis seisneb mdadmi käivitamises monitori + skannimise režiimis, mis saadab e-posti teel teatised etteantud saajale.
Selle seadistamiseks lisage kataloogi /etc/mdadm.conf järgmine rida:
MAILADDR [email <domain or localhost>
Minu puhul:
MAILADDR [email
Mdadmi käivitamiseks monitor + skannimisrežiimis lisage juurena järgmine crontabi kirje:
@reboot /sbin/mdadm --monitor --scan --oneshot
Vaikimisi kontrollib mdadm RAID-massiive iga 60 sekundi järel ja saadab probleemi korral teate. Seda käitumist saate muuta, lisades ülalolevasse crontabi kirjesse valiku --delay koos sekundite arvuga (näiteks --delay 1800 tähendab 30 minutit).
Lõpuks veenduge, et teil oleks installitud Mail User Agent (MUA), näiteks mutt või mailx. Vastasel juhul ei saa te teateid.
Minuti pärast näeme, kuidas mdadmi saadetud hoiatus välja näeb.
Ebaõnnestunud RAID-mäluseadme simuleerimine ja asendamine
RAID massiivi ühe salvestusseadmega probleemi simuleerimiseks kasutame valikuid --manage ja --set-default järgmiselt:
# mdadm --manage --set-faulty /dev/md0 /dev/sdc1
Selle tulemusel märgitakse/dev/sdc1 vigaseks, nagu näeme kataloogis/proc/mdstat:
Mis veelgi olulisem, vaatame, kas saime sama hoiatusega meilisõnumi:
Sellisel juhul peate seadme RAID-massiivist eemaldama:
# mdadm /dev/md0 --remove /dev/sdc1
Seejärel saate selle füüsiliselt masinast eemaldada ja asendada selle varuosaga (/ dev/sdd, kus varem on loodud partii tüüp fd):
# mdadm --manage /dev/md0 --add /dev/sdd1
Meie õnneks hakkab süsteem massiivi automaatselt üles ehitama just selle osaga, mille me just lisasime. Saame seda testida, märkides/dev/sdb1 vigaseks, eemaldades selle massiivist ja veendudes, et failile tecmint.txt on endiselt juurdepääs aadressil/mnt/raid1:
# mdadm --detail /dev/md0 # mount | grep raid1 # ls -l /mnt/raid1 | grep tecmint # cat /mnt/raid1/tecmint.txt
Ülaltoodud pilt näitab selgelt, et pärast massiivi/dev/sdd1 lisamist/dev/sdc1 asendajana viis süsteem andmete ülesehitamise automaatselt meie sekkumiseta.
Ehkki see pole rangelt nõutav, on hea mõte varuseade käepärane olla, et vigase seadme hea draiviga asendamine saaks toimuda kohe. Selleks lisame uuesti/dev/sdb1 ja/dev/sdc1:
# mdadm --manage /dev/md0 --add /dev/sdb1 # mdadm --manage /dev/md0 --add /dev/sdc1
Koondamiskahjust taastumine
Nagu varem selgitatud, ehitab mdadm andmed automaatselt ümber, kui üks ketas rikki läheb. Aga mis juhtub, kui massiivi 2 ketast ebaõnnestuvad? Simuleerime sellist stsenaariumi, märkides/dev/sdb1 ja/dev/sdd1 vigaseks:
# umount /mnt/raid1 # mdadm --manage --set-faulty /dev/md0 /dev/sdb1 # mdadm --stop /dev/md0 # mdadm --manage --set-faulty /dev/md0 /dev/sdd1
Katsed massiivi uuesti luua samamoodi nagu see loodi praegu (või kasutades valikut --assume-clean ), võib tulemuseks olla andmete kadu, mistõttu tuleks see jätta viimase abinõuna.
Proovime taastada andmed näiteks/dev/sdb1-st sarnasesse ketta sektsiooni (/ dev/sde1 - pange tähele, et selleks on vaja enne jätkamist luua partitsioon tüüp fd kataloogis/dev/sde):
# ddrescue -r 2 /dev/sdb1 /dev/sde1
Pange tähele, et seni pole me puudutanud/dev/sdb ega/dev/sdd - RAID massiivi osi.
Ehitame nüüd massiivi, kasutades/dev/sde1 ja/dev/sdf1:
# mdadm --create /dev/md0 --level=mirror --raid-devices=2 /dev/sd[e-f]1
Pange tähele, et reaalses olukorras kasutate tavaliselt samu seadmete nimesid nagu algse massiivi korral, see tähendab/dev/sdb1 ja/dev/sdc1 pärast seda, kui ebaõnnestunud kettad on uutega asendatud.
Selles artiklis otsustasin kasutada masinate uuesti loomiseks uhiuute ketastega ja vältida segiajamist algsete nurjunud draividega lisaseadmeid.
Kui küsitakse, kas jätkata massiivi kirjutamist, tippige Y ja vajutage sisestusklahvi. Massiiv peaks olema käivitatud ja peaksite saama jälgida selle edenemist:
# watch -n 1 cat /proc/mdstat
Kui protsess on lõpule jõudnud, peaksite saama juurde pääseda oma RAID-i sisule:
Kokkuvõte
Selles artiklis oleme vaadanud, kuidas RAID-i tõrgetest ja koondamiskadudest taastuda. Kuid peate meeles pidama, et see tehnoloogia on salvestuslahendus ja EI asenda varukoopiaid.
Selles juhendis selgitatud põhimõtted kehtivad nii kõigi RAID-seadistuste kui ka kontseptsioonide kohta, mida käsitleme selle seeria järgmises ja viimases juhendis (RAID-haldus).
Kui teil on selle artikli kohta küsimusi, loobuge meile märkusest, kasutades allolevat kommentaarivormi. Ootame teid huviga!