Bytte ut en mislykket stasjon i en mdadm-array på Ubuntu

Informasjonen i dette innlegget er basert på Ubuntu 18.04 og versjonen av mdadm inkludert i depotene; i skrivende stund v4.1-rc1. Det kan være eller ikke være gyldig for andre versjoner.

Jeg hadde nylig en plutselig stasjonsfeil i hjemmefilserveren min, som består av ni stasjoner i en mdadm RAID-6-array. Det er alltid skummelt, men jeg klarte heldigvis raskt å skaffe en erstatningsstasjon som ble levert allerede dagen etter, slik at jeg kunne få i gang gjenoppbyggingen.

Jeg var riktignok litt for billig da jeg opprinnelig satte opp filserveren; bare to av stasjonene er faktiske NAS-stasjoner (Seagate IronWolf), mens resten er stasjonære stasjoner (Seagate Barracuda). Ikke overraskende var det en av skrivebordsstasjonene som hadde gitt opp (men etter nesten tre års bruk). Den var helt død; etter å ha flyttet den til et stasjonær USB-kabinett, var alt jeg fikk ut av det en nervepirrende klikkelyd, og verken Ubuntu 20.04 eller Windows 10 var i stand til å oppdage det.

Nåvel, til erstatningsdelen (og ja, den nye stasjonen jeg kjøpte var en IronWolf, lærdom lært) - så skummelt som det er å miste en stasjon i en kjørende array, er det enda skumlere hvis du ikke vet riktig prosedyre for å erstatte den. Det er ikke første gang jeg har måttet bytte ut en defekt stasjon i en mdadm-array, men heldigvis er det så sjeldent at jeg vanligvis må slå opp de riktige kommandoene. Denne gangen bestemte jeg meg for å lage min egen lille guide for fremtidig referanse.

Så først av alt, når du får den fryktede feilhendelsen e-post fra mdadm, må du identifisere hvilken stasjon som har feilet. Jada, det vil fortelle deg enhetsnavnet (i mitt tilfelle /dev/sdf), men det er sannsynligvis ikke åpenbart hvilken fysisk stasjon som faktisk er, da disse navnene kan endres når maskinen startes opp.

Hvis du ikke en gang er sikker på hvilket enhetsnavn som har feilet, kan du bruke følgende kommando for å finne ut (erstatt /dev/md0 med RAID-enheten):

Som nevnt, i mitt tilfelle var det /dev/sdf, så la oss fortsette med det.

Deretter kan du prøve å finne serienummeret til den mislykkede stasjonen ved å gi denne kommandoen:

(hvis smartctl ikke blir funnet, må du installere smartmontools-pakken på Ubuntu)

Serienummeret kan deretter sammenlignes med serienumrene på den fysiske etiketten på stasjonene for å finne ut hvilken som har feilet.

Denne gangen var jeg imidlertid ikke så heldig. Stasjonen var helt død og nektet til og med å gi SMART eller andre data, inkludert serienummeret.

Siden jeg hadde fysisk tilgang til serveren (som du virkelig trenger hvis du skal bytte ut en fysisk stasjon selv, antar jeg ;-)) og serveren faktisk kjørte da disken sviktet (og fortsatte å kjøre bra takket være RAID-6 redundansen), gikk jeg med den virkelig primitive, men faktisk svært effektive og åpenbare metoden med å kopiere en stor fil til serveren og se hvilken HDD som ikke flimret. I løpet av få sekunder hadde jeg identifisert den skyldige.

Nå, før du drar ut den fysiske stasjonen, er det en god idé å informere mdadm formelt om denne hensikten, ved å gi denne kommandoen (erstatt enhetsnavn med dine egne etter behov):

Ved suksess vil mdadm svare med en melding som sier at den "varmt fjernet" stasjonen, tilsynelatende fordi den virtuelle raid-enheten faktisk kjører på det tidspunktet.

Hvis det feiler med en feilmelding som ligner på "enhet eller ressurs opptatt", kan det være at mdadm faktisk ikke har registrert at stasjonen har feilet fullstendig. For å få det til å gjøre det, utfør denne kommandoen (igjen, husk å erstatte enhetsnavn med dine egne etter behov):

Etter det skal du kunne fjerne enheten fra arrayet med forrige kommando.

Nå er det på tide å faktisk bytte ut stasjonen. Hvis du virkelig er sikker på at maskinen og kontrolleren din støtter hot swapping, kan du gjøre dette uten å slå av maskinen. Det ville være veien å gå på kritiske produksjonssystemer som kjører på ekte, skikkelig servermaskinvare som du vet kan håndtere det. Min hjemmefilserver er basert på et stasjonært hovedkort i forbrukerkvalitet med et par semi-noname SATA-kontrollere i PCIe-sporene for å gi flere SATA-porter.

Selv om SATA generelt skal støtte hot swapping, var jeg ikke i ferd med å risikere noe i dette oppsettet, så jeg valgte å slå av maskinen mens jeg byttet ut stasjonen.

Før du gjør det, er det en god idé å kommentere ut raid-enheten i /etc/fstab-filen slik at Ubuntu ikke prøver å montere den automatisk ved neste oppstart, fordi den kan henge og tvinge deg til gjenopprettingsmodus på grunn av den degraderte RAID-arrayen. Det er kanskje ikke et stort problem hvis det er et stasjonært system, men jeg kjører denne serveren hodeløs uten skjerm eller tastatur tilkoblet, så dette ville vært litt av et problem.

Etter å ha startet opp maskinen med den skinnende nye stasjonen installert, bruk lsblk eller andre måter for å identifisere den. Hvis du ikke har endret noe annet, vil den sannsynligvis (men ikke nødvendigvis ) få samme navn som stasjonen du erstattet. I mitt tilfelle gjorde det det, så den nye heter også /dev/sdf.

Siden matrisen min er basert på partisjoner i stedet for fysiske enheter, trengte jeg å kopiere partisjonstabellen fra en fungerende stasjon til den nye stasjonen for å sikre at de er nøyaktig de samme. Hvis du kjører matrisen på fysiske enheter i stedet, kan du hoppe over dette trinnet.

Jeg brukte sgdisk til dette formålet, og kopierte partisjonstabellen fra /dev/sdc til /dev/sdf. Sørg for å erstatte enhetsnavn for å matche dine egne etter behov.

Legg merke til rekkefølgen her: du lister opp "til"-kjøringen først! Dette er litt kontraintuitivt for meg, men bare sørg for at du får det riktig slik at du ikke får en ny stasjonsfeil i arrayet ;-)

For å unngå UUID-konflikter, generer du nye UUID-er for den nye stasjonen:

Og nå er tiden endelig inne for å legge til den nye disken i arrayet og få i gang gjenoppbyggingsfesten! (Ok, det er egentlig ikke en fest, det er faktisk en ganske langsom og nervepirrende prosess ettersom du virkelig, virkelig ikke vil at en ny stasjon feiler på dette tidspunktet. Øl kan imidlertid hjelpe)

Uansett, for å legge til den nye stasjonen til matrisen, utsted denne kommandoen (igjen, sørg for å erstatte enhetsnavn med dine egne etter behov):

Hvis alt går bra, vil stasjonen bli lagt til arrayet uten hikke. Jeg tror det faktisk er lagt til som en "hot spare" som standard, men siden denne matrisen mangler en disk (den som mislyktes), blir den umiddelbart tatt i bruk og gjenoppbyggingsprosessen vil starte.

Du kan holde et øye med det slik:

Dette vil nok ta litt tid; på den lave serveren min (i stor grad basert på maskinvare og stasjonære stasjoner, vel å merke) var den i stand til å nå i underkant av 100 MB/sek. Husk at dette er RAID-6, så det er mange paritetsberegninger involvert i en gjenoppbygging; en RAID-10 ville vært mye raskere. Denne spesielle maskinen har en AMD A10 9700E quad core CPU ("E" betyr at det er en underklokket energieffektiv modell, dvs. ikke superrask), bare for å gi deg en ide om hva du kan forvente. Med de ni 8 TB-stasjonene i oppsettet mitt tok hele gjenoppbyggingen litt over 24 timer.

Under gjenoppbyggingen kan du montere filsystemet på arrayet og bruke det som normalt hvis du ønsker det, men jeg foretrekker å overlate det til gjenoppbyggingen til det er ferdig. Husk at hvis en stasjon svikter, kan en annen snart følge, så du vil at gjenoppbyggingen skal gjøres så raskt som mulig, siden du virkelig ikke vil at en annen stasjon skal svikte i løpet av det. Derfor, ikke belast den med annen IO som ikke er strengt nødvendig.

Når det er gjort, legg det tilbake til /etc/fstab-filen din, start på nytt og nyt filene dine :-)