Ebaõnnestunud draivi asendamine Ubuntu mdadm-massiivis

Selle postituse teave põhineb Ubuntu 18.04-l ja selle repositooriumides sisalduval mdadm-i versioonil; kirjutamise ajal v4.1-rc1. See võib teiste versioonide puhul kehtida või mitte.

Hiljuti tekkis mul koduses failiserveris ootamatu ketta rike, mis koosneb üheksast kettast mdadm RAID-6 massiivis. See on alati hirmutav, aga õnneks õnnestus mul kiiresti leida asendusketas, mis toodi kohale juba järgmisel päeval, nii et sain taastamist alustada.

Tunnistan, et olin failiserveri algsel seadistamisel pisut liiga kitsi; ainult kaks draivi on päris NAS-draivid (Seagate IronWolf), ülejäänud aga lauaarvuti draivid (Seagate Barracuda). Pole üllatav, et see oli üks lauaarvuti draividest, mis oli üles öelnud (küll pärast peaaegu kolmeaastast kasutamist). See oli täiesti surnud; pärast selle lauaarvuti USB-korpusesse teisaldamist kuulsin sealt vaid häirivat klõpsatust ja ei Ubuntu 20.04 ega Windows 10 suutnud seda tuvastada.

Noh, nüüd asendusosa juurde (ja jah, uus ketas, mille ostsin, oli IronWolf, õppetund selge) – nii hirmutav kui ongi ketta kaotamine töötavas massiivis, on see veelgi hirmutavam, kui sa ei tea õiget vahetamise protseduuri. See pole esimene kord, kui ma olen pidanud mdadm-massiivis rikkis ketast vahetama, aga õnneks on see nii haruldane, et pean tavaliselt õiged käsud üles otsima. Seekord otsustasin edaspidiseks kasutamiseks oma väikese juhendi kokku panna.

Seega, esiteks, kui saate mdadm-ilt kardetud tõrkesündmuse e-kirja, peate tuvastama, milline ketas on rikkis. Muidugi, see ütleb teile seadme nime (minu puhul /dev/sdf), kuid ilmselt pole ilmne, milline füüsiline ketas see tegelikult on, kuna need nimed võivad masina käivitamisel muutuda.

Kui te pole isegi kindel, milline seadme nimi nurjus, saate selle välja selgitada järgmise käsuga (asendage /dev/md0 oma RAID-seadme nimega):

Nagu mainitud, oli minu puhul see /dev/sdf, seega jätkame sellega.

Seejärel võite proovida leida rikkis draivi seerianumbri, andes järgmise käsu:

(kui smartctl-i ei leita, peate Ubuntule installima smartmontoolsi paketi)

Seejärel saab seerianumbrit võrrelda draivide füüsilisel sildil olevate seerianumbritega, et välja selgitada, milline neist on rikkis.

Seekord mul aga nii palju õnne ei olnud. Kõvaketas oli täiesti surnud ja keeldus isegi SMART-i või muid andmeid, sealhulgas seerianumbrit, edastamast.

Kuna mul oli serverile füüsiline ligipääs (mida on vist tõesti vaja, kui kavatsed füüsilise kõvaketta ise välja vahetada ;-)) ja server ketta rikke ajal tegelikult töötas (ja tänu RAID-6 koondamise tõttu töötas see laitmatult edasi), valisin ma üsna primitiivse, aga tegelikult väga tõhusa ja ilmselge meetodi – kopeerisin suure faili serverisse ja jälgisin, milline kõvaketta tuli ei vilgu. Mõne sekundi jooksul olin süüdlase tuvastanud.

Enne füüsilise draivi väljavõtmist on hea mõte mdadm-i sellest kavatsusest ametlikult teavitada, andes järgmise käsu (asendage seadmete nimed vastavalt oma nimedega):

Edu korral vastab mdadm teatega, et see "eemaldas draivi kuumalt", ilmselt seetõttu, et virtuaalne RAID-seade sel ajal tegelikult töötab.

Kui see ebaõnnestub ja kuvatakse veateade, mis sarnaneb "seade või ressurss on hõivatud", võib olla, et mdadm pole draivi täielikult rikkis olevaks registreerinud. Selleks käivitage järgmine käsk (jällegi pidage meeles, et asendage seadmete nimed oma nimedega vastavalt vajadusele):

Pärast seda peaksite saama seadme massiivist eelmise käsuga eemaldada.

Nüüd on aeg draiv välja vahetada. Kui oled tõesti, tõesti – nagu, tõesti – kindel, et su masin ja kontroller toetavad käigultvahetust, saad seda teha ilma masinat välja lülitamata. Nii toimiksid kriitiliste tootmissüsteemide puhul, mis töötavad päris ja korralikul serveririistvaral, mille kohta tead kindlalt, et see sellega hakkama saab. Minu kodune failiserver põhineb tarbijaklassi lauaarvuti emaplaadil, millel on paar pool-nimetut SATA kontrollerit PCIe pesades, et pakkuda rohkem SATA porte.

Kuigi SATA peaks üldiselt toetama hot swappimist, ei kavatsenud ma selle seadistusega midagi riskida, seega otsustasin ketta vahetamise ajaks masina välja lülitada.

Enne seda on hea mõte RAID-seade failis /etc/fstab välja kommenteerida, et Ubuntu ei prooviks seda järgmisel käivitamisel automaatselt ühendada, kuna see võib halvenenud RAID-massiivi tõttu hanguda ja sundida teid taasterežiimi. See ei pruugi olla suur probleem, kui tegemist on lauaarvutiga, aga mina käitan seda serverit ilma monitori ja klaviatuurita, seega oleks see natuke tülikas.

Pärast masina käivitamist uue draiviga tuvasta see käsuga lsblk või mõnel muul viisil. Kui sa pole midagi muud muutnud, saab see tõenäoliselt (kuid mitte tingimata) sama nime, mis asendatud draiv. Minu puhul sai see nii, seega on uue draivi nimi samuti /dev/sdf.

Kuna minu massiiv põhineb partitsioonidel, mitte füüsilistel seadmetel, pidin ma töötava ketta partitsioonitabeli uuele kettale kopeerima, et veenduda nende täpses identsuses. Kui käitate massiivi hoopis füüsilistel seadmetel, võite selle sammu vahele jätta.

Selleks kasutasin käsku sgdisk, kopeerides partitsioonitabeli /dev/sdc-st /dev/sdf-i. Veendu, et seadmete nimed on vastavalt oma nimedele asendatud.

Pane tähele järjekorda: esimesena loetled sihtketta! See on minu jaoks veidi ebaloogiline, aga veendu, et sa loed selle õigesti, et massiivis ei tekiks järjekordset ketta riket ;-)

Seejärel UUID-konfliktide vältimiseks genereerige uue draivi jaoks uued UUID-d:

Ja nüüd on lõpuks käes aeg uus ketas massiivi lisada ja taasehituspidu alustada! (Olgu, see pole päris pidu, see on tegelikult üsna aeglane ja närvesööv protsess, kuna sa tõesti, tõesti ei taha, et veel üks ketas sel ajal üles ütleks. Õlu võib aga aidata.)

Igatahes, uue draivi massiivi lisamiseks andke see käsk (jällegi veenduge, et asendate seadmete nimed vastavalt oma nimedele):

Kui kõik läheb hästi, lisatakse ketas massiivi viperusteta. Usun, et see lisatakse vaikimisi "kuumvaruna", aga kuna selles massiivis puudub ketas (see, mis rikki läks), võetakse see kohe kasutusele ja algab taastamisprotsess.

Saate seda jälgida nii:

See võtab ilmselt aega; minu tagasihoidlikul serveril (mis põhineb suuresti tarbijaklassi riistvaral ja lauaarvuti kõvaketastel) suutis see saavutada veidi alla 100 MB/s. Pidage meeles, et see on RAID-6, seega on ümberehitamisega seotud palju pariteediarvutusi; RAID-10 oleks olnud palju kiirem. Sellel konkreetsel masinal on AMD A10 9700E neljatuumaline protsessor ("E" tähendab, et see on alatakteeritud energiasäästlik mudel, st mitte ülikiire), et anda teile aimu, mida oodata. Minu seadistuses oleva üheksa 8 TB kõvakettaga võttis täielik ümberehitamisega tegelemine aega veidi üle 24 tunni.

Ümberehituse ajal saate failisüsteemi massiivile paigaldada ja seda soovi korral tavapäraselt kasutada, kuid eelistan jätta selle kuni ümberehituse lõpuni hooleks. Pidage meeles, et kui üks ketas rikki läheb, võib peagi tekkida teine, seega on soovitatav ümberehitus võimalikult kiiresti teha, kuna te ei soovi, et selle ajal mõni teine ketas rikki läheks. Seetõttu ärge koormake seda muu IO-ga, mis pole hädavajalik.

Kui see on tehtud, lisa see tagasi oma /etc/fstab faili, taaskäivita ja naudi oma faile :-)