Ebaõnnestunud draivi asendamine Ubuntu mdadm-massiivis

Selles postituses olev teave põhineb Ubuntu 18.04-l ja selle hoidlates sisalduval mdadmi versioonil; kirjutamise ajal v4.1-rc1. See võib teiste versioonide jaoks kehtida, kuid ei pruugi kehtida.

Minu koduses failiserveris, mis koosneb üheksast draivist mdadm RAID-6 massiivist, tekkis hiljuti ootamatu draivi rike. See on alati hirmutav, kuid õnneks suutsin kiiresti hankida asendusketta, mis tarniti juba järgmisel päeval, et saaksin ümberehitamist alustada.

Tõsi, ma olin failiserveri algselt seadistamisel natuke liiga odav; ainult kaks draivi on tegelikud NAS-draivid (Seagate IronWolf), ülejäänud aga lauaarvuti draivid (Seagate Barracuda). Pole üllatav, et see oli üks lauaarvuti draividest, mis oli loobunud (pärast peaaegu kolmeaastast teenistust). See oli täiesti surnud; pärast selle teisaldamist töölaua USB-korpusesse kuulsin sellest ainult ärritavat klõpsatust ja ei Ubuntu 20.04 ega Windows 10 ei suutnud seda tuvastada.

Ahjaa, asendusosa juurde (ja jah, uus draiv, mille ostsin, oli IronWolf, õppetund saadud) – nii hirmutav kui see on draivi kaotamine töötavas massiivis, on see veelgi hirmutavam, kui te ei tea selle õiget asendamise protseduuri. See pole esimene kord, kui pean mdadm-massiivis ebaõnnestunud draivi asendama, kuid õnneks on see nii haruldane, et tavaliselt pean otsima õigeid käske. Seekord otsustasin koostada oma väikese juhendi edaspidiseks kasutamiseks.

Seega, kui saate mdadmilt kardetud tõrkesündmuse meili, peate kõigepealt tuvastama, milline draiv on ebaõnnestunud. Muidugi, see ütleb teile seadme nime (minu puhul /dev/sdf), kuid ilmselt pole selge, milline füüsiline draiv tegelikult on, kuna need nimed võivad masina käivitamisel muutuda.

Kui te pole isegi kindel, milline seadme nimi ebaõnnestus, saate selle tuvastamiseks kasutada järgmist käsku (asendage /dev/md0 oma RAID-seadmega):

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

Seejärel võite proovida leida ebaõnnestunud draivi seerianumbrit, andes selle 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 ebaõnnestunud.

Seekord mul siiski nii palju ei vedanud. Draiv oli täiesti surnud ja isegi keeldus esitamast SMART-i või muid andmeid, sealhulgas seerianumbrit.

Kuna mul oli serverile füüsiline ligipääs (mida te tõesti vajate, kui kavatsete ise füüsilise draivi välja vahetada ;-)) ja server töötas tegelikult ka siis, kui ketas ebaõnnestus (ja töötas jätkuvalt hästi tänu RAID-6 liiasusele), kasutasin tõeliselt primitiivset, kuid tegelikult väga tõhusat ja ilmset meetodit, mille kohaselt kopeerisin lihtsalt suure faili serverisse ja vaatasin, millist HDD-d tuli vaadata. Mõne sekundiga tuvastasin süüdlase.

Nüüd, enne füüsilise draivi väljatõmbamist on hea mõte sellest kavatsusest ametlikult teavitada mdadm-i, andes välja järgmise käsu (asendage seadmete nimed vastavalt vajadusele enda nimedega):

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

Kui see ebaõnnestub ja ilmub tõrketeade, mis on sarnane "seade või ressurss hõivatud", võib juhtuda, et mdadm pole draivi täielikult tõrkeks registreerinud. Selleks andke see käsk (taas pidage meeles, et asendage seadmete nimed vastavalt vajadusele enda nimedega):

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

Nüüd on aeg draiv tegelikult välja vahetada. Kui olete tõesti - nagu tõesti - kindel, et teie masin ja kontroller toetavad kuumvahetust, saate seda teha ilma masinat välja lülitamata. See oleks õige viis kriitiliste tootmissüsteemide jaoks, mis töötavad tõelisel ja korralikul serveririistvaral, millest teate, et see saab sellega hakkama. Minu kodune failiserver põhineb tarbijaklassi lauaarvuti emaplaadil, mille PCIe-pesades on paar poolnimetut SATA-kontrollerit, et pakkuda rohkem SATA-porte.

Kuigi SATA peaks üldiselt toetama kiirvahetust, ei kavatsenud ma selle seadistuse puhul millegagi riskida, seega otsustasin draivi vahetamise ajal masina välja lülitada.

Enne seda on hea mõte kommenteerida RAID-seadet failis /etc/fstab, et Ubuntu ei prooviks seda järgmisel alglaadimisel 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 lauaarvutisüsteemiga, kuid ma käitan seda serverit ilma peata, ilma monitori või klaviatuurita, nii et see oleks natuke tülikas.

Pärast uue läikiva draiviga masina käivitamist kasutage selle tuvastamiseks lsblk või mõnda muud vahendit. Kui te pole midagi muud muutnud, saab see tõenäoliselt (kuid mitte tingimata ) sama nime kui asendatud draiv. Minu puhul nii, nii et uue nimi on ka /dev/sdf.

Kuna minu massiiv põhineb partitsioonidel, mitte füüsilistel seadmetel, pidin kopeerima partitsioonitabeli töötavalt draivilt uuele kettale, et veenduda, et need on täpselt samad. Kui kasutate massiivi hoopis füüsilistes seadmetes, võite selle sammu vahele jätta.

Selleks kasutasin sgdiski, kopeerides partitsioonitabeli failist /dev/sdc kausta /dev/sdf. Asendage seadmete nimed kindlasti nii, et need vastaksid teie nimele.

Pange tähele järjekorda siin: loetlege kõigepealt sõit "kuni"! See on minu jaoks veidi intuitiivne, kuid veenduge, et teete selle õigesti, et massiivi ei tekiks järjekordset draivi riket ;-)

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

Ja nüüd on lõpuks kätte jõudnud aeg lisada massiivi uus ketas ja alustada ümberehituspidu! (Olgu, see pole tegelikult pidu, see on tegelikult üsna aeglane ja ärritav protsess, kuna te tõesti ei taha, et mõni teine ​​​​draiv sel ajal ebaõnnestuks. Õlu võib siiski aidata)

Igatahes, uue draivi massiivi lisamiseks andke see käsk (veenduge, et asendaksite seadmete nimed vajaduse korral oma nimedega):

Kui kõik läheb hästi, lisatakse draiv massiivi ilma luksumiseta. Usun, et see lisatakse tegelikult vaikimisi "hot spare"-na, kuid kuna sellel massiivil on ketas puudu (see, mis ebaõnnestus), võetakse see kohe kasutusele ja algab ümberehitusprotsess.

Saate sellel silma peal hoida järgmiselt:

See võtab tõenäoliselt veidi aega; minu madalas serveris (põhineb suuresti tarbijakvaliteediga riistvaral ja lauaarvuti draividel, pange tähele) suutis see jõuda veidi alla 100 MB/sek. Pidage meeles, et tegemist on RAID-6-ga, seega on ümberehitusega seotud palju paarsusarvutusi; RAID-10 oleks olnud palju kiirem. Sellel konkreetsel masinal on AMD A10 9700E neljatuumaline protsessor ("E" tähendab, et tegemist on alatakistatud energiasäästliku mudeliga, st mitte ülikiire), et anda teile aimu, mida oodata. Minu seadistatud üheksa 8 TB draivi puhul võttis täielik taastamine veidi üle 24 tunni.

Ümberehitamise ajal saate failisüsteemi massiivi külge ühendada ja seda soovi korral tavapäraselt kasutada, kuid eelistan jätta selle ümberehitamise hooleks, kuni see on tehtud. Pidage meeles, et kui üks draiv ebaõnnestub, võib peagi järgneda teine, nii et soovite, et ümberehitamine toimuks võimalikult kiiresti, kuna te tõesti ei soovi, et teine ​​draiv selle ajal ebaõnnestuks. Seetõttu ärge koormake seda muude IO-dega, mis pole tingimata vajalikud.

Kui see on tehtud, lisage see tagasi oma /etc/fstab faili, taaskäivitage ja nautige oma faile :-)