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

Informasjonen i dette innlegget er basert Ubuntu 18.04 og versjonen av mdadm som er inkludert i depotene; I skrivende stund v4.1-RC1. Det kan være gyldig for andre versjoner.

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

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 stasjonære stasjoner som hadde gitt opp (etter nesten tre års tjeneste, skjønt). Den var helt død; etter å ha flyttet den til et stasjonært USB-kabinett, var alt jeg fikk ut av den en nervepirrende klikkelyd, og verken Ubuntu 20.04 eller Windows 10 klarte å oppdage den.

Å vel, videre 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 løpende matrise, 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 mislykket 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 å piske opp min egen lille guide for fremtidig referanse.

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

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

Som nevnt var det i mitt tilfelle /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 å oppgi 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 fint takket være RAID-6-redundansen), gikk jeg med den virkelig primitive, men faktisk svært effektive og åpenbare, metoden med å bare kopiere en stor fil til serveren og se hvilket HDD-lys 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é å formelt informere mdadm 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 den mislykkes med en feilmelding som ligner på "enhet eller ressurs opptatt", kan det være at mdadm faktisk ikke har registrert stasjonen for å ha sviktet fullstendig. For å få det til å gjøre det, gi denne kommandoen (igjen, husk å erstatte enhetsnavn med dine egne etter behov):

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

Nå er det på tide å faktisk bytte ut stasjonen. Hvis du virkelig er sikker på at maskinen og kontrolleren 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, riktig servermaskinvare som du vet med sikkerhet kan håndtere det. Hjemmefilserveren min er basert på et stasjonært hovedkort av 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 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ære litt av et problem.

Etter å ha startet opp maskinen med den skinnende nye stasjonen installert, bruk lsblk eller andre midler for å identifisere den. Hvis du ikke har endret noe annet, vil den sannsynligvis (men ikke nødvendigvis) få samme navn som stasjonen du byttet ut. I mitt tilfelle gjorde den det, så den nye kalles 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 like. 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 enhetsnavnene slik at de samsvarer med dine egne etter behov.

Legg merke til rekkefølgen her: du viser "til"-stasjonen 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 matrisen ;-)

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

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

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

Hvis alt går bra, vil stasjonen bli lagt til matrisen 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 øye med det slik:

Dette vil sannsynligvis ta en stund; på min lave server (hovedsakelig basert på maskinvare og stasjonære stasjoner av forbrukerkvalitet, 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 ha vært mye raskere. Denne spesielle maskinen har en AMD A10 9700E firekjerners 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 den fullstendige ombyggingen 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, da du virkelig ikke vil at en annen stasjon skal mislykkes under det. Derfor, ikke belast den med andre IO som ikke er strengt nødvendige.

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