Sostituzione di un'unità guasta in un array mdadm su Ubuntu

Le informazioni in questo post si basano su Ubuntu 18.04 e sulla versione di mdadm inclusa nei suoi repository; al momento della scrittura v4.1-rc1. Potrebbero essere valide o meno per altre versioni.

Di recente ho avuto un guasto improvviso di un'unità nel mio file server domestico, che consiste di nove unità in un array mdadm RAID-6. È sempre spaventoso, ma fortunatamente sono riuscito a procurarmi rapidamente un'unità sostitutiva che è stata consegnata già il giorno dopo, così ho potuto iniziare la ricostruzione.

Devo ammettere che sono stato un po' troppo tirchio quando ho configurato originariamente il file server; solo due delle unità sono vere unità NAS (Seagate IronWolf), mentre le altre sono unità desktop (Seagate Barracuda). Non sorprende che fosse una delle unità desktop che si era arresa (dopo quasi tre anni di servizio, però). Era completamente morta; dopo averla spostata in un contenitore USB desktop, tutto quello che ne ho ricavato è stato un fastidioso clic e né Ubuntu 20.04 né Windows 10 sono stati in grado di rilevarlo.

Oh bene, passiamo alla parte di ricambio (e sì, il nuovo drive che ho comprato era un IronWolf, lezione imparata): per quanto spaventoso sia perdere un drive in un array in esecuzione, è ancora più spaventoso se non si conosce la procedura corretta per sostituirlo. Non è la prima volta che devo sostituire un drive guasto in un array mdadm, ma fortunatamente è così raro che di solito devo cercare i comandi corretti. Questa volta ho deciso di improvvisare la mia piccola guida per riferimento futuro.

Quindi, prima di tutto, quando ricevi la temuta e-mail di evento di errore da mdadm, devi identificare quale unità è guasta. Certo, ti dirà il nome del dispositivo (nel mio caso /dev/sdf), ma probabilmente non è ovvio quale unità fisica sia in realtà, poiché quei nomi possono cambiare quando la macchina viene avviata.

Se non sei nemmeno sicuro di quale nome del dispositivo non funziona, puoi usare il seguente comando per scoprirlo (sostituisci /dev/md0 con il tuo dispositivo RAID):

Come accennato, nel mio caso era /dev/sdf, quindi continuiamo con quello.

Quindi, puoi provare a trovare il numero di serie dell'unità guasta emettendo questo comando:

(se smartctl non viene trovato, è necessario installare il pacchetto smartmontools su Ubuntu)

Il numero di serie può quindi essere confrontato con i numeri di serie riportati sull'etichetta fisica delle unità per individuare quale unità è guasta.

Questa volta, però, non sono stato così fortunato. L'unità era completamente morta e si rifiutava persino di fornire dati SMART o di altro tipo, incluso il numero di serie.

Poiché avevo accesso fisico al server (di cui hai davvero bisogno se devi sostituire un'unità fisica da solo, suppongo ;-)) e il server era effettivamente in esecuzione quando il disco si è rotto (e ha continuato a funzionare correttamente grazie alla ridondanza RAID-6), ho scelto il metodo davvero primitivo, ma in realtà altamente efficace e ovvio, di copiare semplicemente un file di grandi dimensioni sul server e guardare quale luce dell'HDD non tremolava. In pochi secondi avevo identificato il colpevole.

Ora, prima di estrarre l'unità fisica, è una buona idea informare formalmente mdadm di questa intenzione, emettendo questo comando (sostituisci i nomi dei dispositivi con i tuoi, se appropriato):

In caso di successo, mdadm risponderà con un messaggio in cui comunica che l'unità è stata "rimossa a caldo", apparentemente perché il dispositivo raid virtuale è effettivamente in esecuzione in quel momento.

Se fallisce con un messaggio di errore simile a "dispositivo o risorsa occupati", potrebbe essere che mdadm non abbia effettivamente registrato l'unità come completamente guasta. Per farlo, emetti questo comando (di nuovo, ricorda di sostituire i nomi dei dispositivi con i tuoi, se appropriato):

Dopodiché dovresti riuscire a rimuovere il dispositivo dall'array con il comando precedente.

Ora è il momento di sostituire effettivamente l'unità. Se sei davvero, davvero - tipo, davvero - certo che la tua macchina e il tuo controller supportino lo scambio a caldo, potresti farlo senza spegnere la macchina. Questo sarebbe il modo di procedere su sistemi di produzione critici che girano su hardware server reale e appropriato che sai per certo che può gestirlo. Il mio file server domestico è basato su una scheda madre desktop di livello consumer con un paio di controller SATA semi-noname negli slot PCIe per fornire più porte SATA, però.

Sebbene SATA in genere supporti la sostituzione a caldo, non avevo intenzione di rischiare nulla con questa configurazione, quindi ho optato per spegnere la macchina durante la sostituzione dell'unità.

Prima di farlo, è una buona idea commentare il dispositivo raid nel file /etc/fstab in modo che Ubuntu non provi a montarlo automaticamente al prossimo avvio, perché potrebbe bloccarsi e costringerti a passare alla modalità di ripristino a causa del RAID array degradato. Potrebbe non essere un grosso problema se si tratta di un sistema desktop, ma io eseguo questo server headless senza monitor o tastiera collegati, quindi potrebbe essere un po' una seccatura.

Dopo aver avviato la macchina con il nuovo drive scintillante installato, usa lsblk o qualche altro mezzo per identificarlo. Se non hai cambiato nient'altro, probabilmente (ma non necessariamente ) avrà lo stesso nome del drive che hai sostituito. Nel mio caso l'ha fatto, quindi il nuovo si chiama anche /dev/sdf.

Poiché il mio array è basato su partizioni anziché su dispositivi fisici, ho dovuto copiare la tabella delle partizioni da un'unità funzionante a quella nuova per assicurarmi che fossero esattamente le stesse. Se esegui il tuo array su dispositivi fisici, puoi saltare questo passaggio.

Ho usato sgdisk per questo scopo, copiando la tabella delle partizioni da /dev/sdc a /dev/sdf. Assicurati di sostituire i nomi dei dispositivi in modo che corrispondano ai tuoi, come appropriato.

Nota l'ordine qui: elenca prima l'unità "to"! Per me è un po' controintuitivo, ma assicurati di farlo bene in modo da non avere un altro guasto dell'unità nell'array ;-)

Quindi, per evitare conflitti UUID, generare nuovi UUID per la nuova unità:

E ora finalmente è giunto il momento di aggiungere il nuovo drive all'array e di dare inizio alla festa di ricostruzione! (Ok, non è proprio una festa, è in realtà un processo piuttosto lento e snervante, perché non vuoi proprio che un altro drive si guasti in questo momento. La birra potrebbe aiutare, però)

In ogni caso, per aggiungere la nuova unità all'array, emetti questo comando (assicurati di nuovo di sostituire i nomi dei dispositivi con i tuoi, se necessario):

Se tutto va bene, l'unità verrà aggiunta all'array senza intoppi. Credo che in realtà venga aggiunta come "hot spare" di default, ma poiché a questo array manca un disco (quello che si è rotto), viene immediatamente messo in uso e il processo di ricostruzione inizierà.

Puoi tenerlo d'occhio in questo modo:

Probabilmente ci vorrà un po'; sul mio modesto server (basato in gran parte su hardware di fascia consumer e unità desktop, badate bene) è riuscito a raggiungere poco meno di 100 MB/sec. Tenete presente che si tratta di un RAID-6, quindi ci sono molti calcoli di parità coinvolti in una ricostruzione; un RAID-10 sarebbe stato molto più veloce. Questa macchina in particolare ha una CPU quad core AMD A10 9700E (la "E" significa che è un modello a basso consumo energetico, ovvero non super veloce), giusto per darvi un'idea di cosa aspettarvi. Con le nove unità da 8 TB nella mia configurazione, la ricostruzione completa ha richiesto poco più di 24 ore.

Durante la ricostruzione, puoi montare il filesystem sull'array e usarlo normalmente se lo desideri, ma preferisco lasciare che sia la ricostruzione a terminare. Tieni presente che se un'unità si guasta, un'altra potrebbe seguirne presto, quindi vuoi che la ricostruzione venga eseguita il più velocemente possibile, perché non vuoi che un'altra unità si guasti durante la ricostruzione. Pertanto, non caricarla con altri IO che non siano strettamente necessari.

Una volta fatto, aggiungilo nuovamente al tuo file /etc/fstab, riavvia e goditi i tuoi file :-)