Zamenjava okvarjenega pogona v matriki mdadm na Ubuntu

Informacije v tej objavi temeljijo na Ubuntu 18.04 in različici mdadm, ki je vključena v njegove repozitorije; v času pisanja v4.1-rc1. Lahko velja ali ne velja za druge različice.

Pred kratkim sem imel nenadno odpoved pogona v domačem datotečnem strežniku, ki je sestavljen iz devetih pogonov v polju mdadm RAID-6. To je vedno strašljivo, a na srečo sem lahko hitro dobil nadomestni pogon, ki je bil dostavljen že naslednji dan, da sem lahko začel z obnovo.

Ko sem prvotno nastavil datotečni strežnik, sem bil nekoliko prepoceni; le dva od pogonov sta dejanska pogona NAS (Seagate IronWolf), ostali pa so namizni pogoni (Seagate Barracuda). Ni presenetljivo, da je bil to eden od namiznih pogonov, ki je obupal (po skoraj treh letih uporabe). Bilo je popolnoma mrtvo; po tem, ko sem ga premaknil v namizno ohišje USB, sem iz tega dobil le moteč klikajoč zvok, ki ga niti Ubuntu 20.04 niti Windows 10 nista mogla zaznati.

No, pa k nadomestnemu delu (in ja, novi pogon, ki sem ga kupil, je bil IronWolf, pridobljena lekcija) – tako strašno kot je izguba pogona v delujočem nizu, še bolj grozljivo je, če ne poznate pravilnega postopka za njegovo zamenjavo. Ni prvič, da sem moral zamenjati okvarjeni pogon v polju mdadm, a na srečo je to tako redko, da moram običajno poiskati ustrezne ukaze. Tokrat sem se odločil pripraviti svoj mali vodnik za prihodnjo uporabo.

Torej, najprej, ko od mdadm prejmete e-pošto o strašnem dogodku okvare, morate ugotoviti, kateri pogon je odpovedal. Seveda vam bo povedal ime naprave (v mojem primeru /dev/sdf), vendar verjetno ni očitno, kateri fizični pogon je to v resnici, saj se ta imena lahko spremenijo, ko se stroj zažene.

Če sploh niste prepričani, katero ime naprave je spodletelo, lahko to ugotovite z naslednjim ukazom (zamenjajte /dev/md0 z vašo napravo RAID):

Kot že omenjeno, je bil v mojem primeru to /dev/sdf, zato nadaljujmo s tem.

Nato lahko poskusite najti serijsko številko pokvarjenega pogona tako, da izdate ta ukaz:

(če smartctl ni najden, morate namestiti paket smartmontools na Ubuntu)

Serijsko številko lahko nato primerjate s serijskimi številkami na fizični nalepki na pogonih, da ugotovite, kateri je odpovedal.

Tokrat pa nisem imel te sreče. Pogon je bil popolnoma mrtev in celo ni hotel zagotoviti SMART ali drugih podatkov, vključno s serijsko številko.

Ker sem imel fizični dostop do strežnika (ki ga verjetno res potrebujete, če nameravate sami zamenjati fizični pogon ;-)) in je strežnik dejansko deloval, ko je disk odpovedal (in je še naprej dobro deloval zaradi redundance RAID-6), sem se odločil za res primitivno, a dejansko zelo učinkovito in očitno metodo preprostega kopiranja velike datoteke na strežnik in opazovanja, katera lučka trdega diska ne utripa. V nekaj sekundah sem prepoznal krivca.

Preden izvlečete fizični pogon, je dobro, da uradno obvestite mdadm o tej nameri, tako da izdate ta ukaz (imena naprav zamenjajte s svojimi, kot je primerno):

Ob uspehu bo mdadm odgovoril s sporočilom, da je "vroče odstranil" pogon, očitno zato, ker se virtualna raid naprava takrat dejansko izvaja.

Če odpove s sporočilom o napaki, podobnim "naprava ali vir zaseden", je morda mdadm dejansko ni registriral pogona kot popolnoma odpovedal. Če želite to narediti, izdajte ta ukaz (spet ne pozabite zamenjati imen naprav s svojimi, kot je ustrezno):

Po tem bi morali imeti možnost odstraniti napravo iz matrike s prejšnjim ukazom.

Zdaj je čas za dejansko zamenjavo pogona. Če ste res, res - tako, res - prepričani, da vaša naprava in krmilnik podpirata vročo zamenjavo, lahko to storite, ne da bi izklopili napravo. To bi bil način za kritične produkcijske sisteme, ki delujejo na pravi, ustrezni strežniški strojni opremi, za katero zagotovo veste, da jo lahko obvlada. Moj domači datotečni strežnik temelji na matični plošči za namizne računalnike potrošniškega razreda z nekaj pol-nonim krmilniki SATA v režah PCIe, ki zagotavljajo več vrat SATA.

Čeprav bi moral SATA na splošno podpirati vročo zamenjavo, nisem nameraval tvegati ničesar pri tej nastavitvi, zato sem se odločil za zaustavitev stroja med zamenjavo pogona.

Preden to storite, je dobro, da napravo za raid komentirate v datoteki /etc/fstab, da je Ubuntu ne bo poskušal samodejno namestiti ob naslednjem zagonu, ker bi lahko obvisela in vas prisilila v obnovitveni način zaradi poslabšanega polja RAID. To morda ni velika težava, če gre za namizni sistem, vendar ta strežnik brezglavo poganjam brez priključenega monitorja ali tipkovnice, zato bi bilo to malo težav.

Po zagonu stroja z nameščenim sijajnim novim pogonom uporabite lsblk ali kakšen drug način za njegovo identifikacijo. Če niste spremenili ničesar drugega, bo verjetno (vendar ne nujno ) dobil isto ime kot pogon, ki ste ga zamenjali. V mojem primeru se je, zato se novi imenuje tudi /dev/sdf.

Ker moje polje temelji na particijah in ne na fizičnih napravah, sem moral kopirati tabelo particij z delujočega pogona na nov pogon, da bi se prepričal, da so popolnoma enaki. Če svoje polje namesto tega izvajate na fizičnih napravah, lahko ta korak preskočite.

V ta namen sem uporabil sgdisk in kopiral particijsko tabelo iz /dev/sdc v /dev/sdf. Ne pozabite zamenjati imen naprav, da bodo ustrezala vašim.

Upoštevajte vrstni red tukaj: najprej navedete pogon "do"! Zame je to nekoliko kontraintuitivno, vendar pazite, da boste pravilno razumeli, da ne boste dobili nove okvare pogona v nizu ;-)

Nato, da se izognete sporom UUID, ustvarite nove UUID-je za nov pogon:

In zdaj je končno prišel čas, da dodamo nov pogon v niz in začnemo z obnovo! (V redu, to ni prava zabava, je pravzaprav precej počasen in vznemirjajoč proces, saj res, res ne želite, da bi še en pogon trenutno odpovedal. Pivo bi lahko pomagalo)

Kakorkoli že, če želite dodati nov pogon v polje, izdajte ta ukaz (spet se prepričajte, da imena naprav zamenjate s svojimi, kot je ustrezno):

Če bo šlo vse v redu, bo pogon dodan v polje brez težav. Verjamem, da je dejansko privzeto dodan kot "vroča rezerva", toda ker tej matriki manjka disk (tisti, ki je odpovedal), se takoj uporabi in začne se postopek obnove.

Na to lahko paziš takole:

To bo verjetno trajalo nekaj časa; na mojem skromnem strežniku (ki temelji predvsem na potrošniški strojni opremi in namiznih pogonih, ne pozabite) je lahko dosegel nekaj manj kot 100 MB/s. Upoštevajte, da je to RAID-6, zato je pri obnovi vključenih veliko paritetnih izračunov; RAID-10 bi bil veliko hitrejši. Ta določena naprava ima štirijedrni procesor AMD A10 9700E (»E« pomeni, da gre za energijsko učinkovit model s prenizko frekvenco, tj. ni super hiter), samo zato, da dobite predstavo o tem, kaj lahko pričakujete. Z devetimi 8 TB pogoni v moji nastavitvi je popolna obnova trajala nekaj več kot 24 ur.

Med vnovično gradnjo lahko datotečni sistem namestite na matriko in ga uporabljate kot običajno, če želite, vendar ga raje prepuščam vnovični gradnji, dokler ni končana. Upoštevajte, da če en pogon odpove, lahko kmalu sledi drugi, zato želite, da se obnova izvede čim hitreje, saj res ne želite, da med tem odpove drug pogon. Zato ga ne obremenjujte z drugimi IO, ki niso nujno potrebni.

Ko je končano, ga dodajte nazaj v datoteko /etc/fstab, znova zaženite in uživajte v datotekah :-)