Înlocuirea unei unități eșuate într-o matrice mdadm pe Ubuntu

Informațiile din această postare se bazează pe Ubuntu 18.04 și versiunea mdadm inclusă în depozitele sale; la momentul scrierii v4.1-rc1. Poate fi valabil sau nu pentru alte versiuni.

Am avut recent o defecțiune bruscă a unității în serverul meu de fișiere de acasă, care constă din nouă unități într-o matrice RAID-6 mdadm. Este întotdeauna înfricoșător, dar din fericire am reușit să obțin rapid o unitate de schimb care a fost livrată deja a doua zi, astfel încât să pot începe reconstrucția.

Desigur, am fost puțin prea ieftin când am configurat inițial serverul de fișiere; doar două dintre unități sunt unități NAS reale (Seagate IronWolf), în timp ce restul sunt unități desktop (Seagate Barracuda). Nu este surprinzător, a fost una dintre unitățile desktop care renunțaseră (după aproape trei ani de serviciu, totuși). Era complet mort; După ce l-am mutat într-o carcasă USB pentru desktop, tot ce am scos din ea a fost un sunet deranjant și nici Ubuntu 20.04, nici Windows 10 nu au reușit să-l detecteze.

Ei bine, trecem la piesa de schimb (și da, noua unitate pe care am cumpărat-o a fost un IronWolf, lecție învățată) - pe cât de înfricoșător este pierderea unei unități într-o matrice care rulează, este și mai înfricoșător dacă nu cunoașteți procedura corectă de înlocuire. Nu este prima dată când trebuie să înlocuiesc o unitate defectă într-o matrice mdadm, dar, din fericire, este atât de rar încât de obicei trebuie să caut comenzile adecvate. De data aceasta m-am hotărât să-mi pregătesc propriul ghid mic pentru referințe viitoare.

Așadar, în primul rând, când primiți temutul e-mail cu evenimentul de eșec de la mdadm, trebuie să identificați ce unitate a eșuat. Sigur, vă va spune numele dispozitivului (în cazul meu /dev/sdf), dar probabil că nu este evident ce unitate fizică este de fapt, deoarece aceste nume se pot schimba la pornirea mașinii.

Dacă nici măcar nu sunteți sigur ce nume de dispozitiv a eșuat, puteți utiliza următoarea comandă pentru a afla (înlocuiți /dev/md0 cu dispozitivul RAID):

După cum am menționat, în cazul meu a fost /dev/sdf, așa că hai să continuăm cu asta.

Apoi, puteți încerca să găsiți numărul de serie al unității eșuate lansând această comandă:

(dacă smartctl nu este găsit, trebuie să instalați pachetul smartmontools pe Ubuntu)

Numărul de serie poate fi apoi comparat cu numerele de serie de pe eticheta fizică de pe unități pentru a afla care dintre ele a eșuat.

De data asta, totuși, nu am fost atât de norocos. Unitatea era complet moartă și chiar a refuzat să furnizeze date SMART sau alte date, inclusiv numărul de serie.

Deoarece aveam acces fizic la server (de care chiar aveți nevoie dacă aveți de gând să înlocuiți singur o unitate fizică, presupun ;-)) și serverul rula de fapt când discul a eșuat (și a continuat să funcționeze bine datorită redundanței RAID-6), am folosit metoda cu adevărat primitivă, dar de fapt extrem de eficientă și evidentă, de a copia pur și simplu un fișier mare pe server și de a viziona care ușura HDD. În câteva secunde identificasem vinovatul.

Acum, înainte de a scoate unitatea fizică, este o idee bună să informați oficial mdadm despre această intenție, lansând această comandă (înlocuiți numele dispozitivelor cu ale dvs. după caz):

La succes, mdadm va răspunde cu un mesaj care spune că a „înlăturat la cald” unitatea, se pare că dispozitivul de raid virtual rulează de fapt în acel moment.

Dacă eșuează cu un mesaj de eroare similar cu „dispozitiv sau resursă ocupat”, este posibil ca mdadm să nu fi înregistrat de fapt unitatea ca să fi eșuat complet. Pentru a face acest lucru, lansați această comandă (din nou, amintiți-vă să înlocuiți numele dispozitivelor cu propriile dvs., după caz):

După aceea, ar trebui să puteți elimina dispozitivul din matrice cu comanda anterioară.

Acum este timpul să înlocuiți efectiv unitatea. Dacă sunteți într-adevăr, într-adevăr - ca, într-adevăr - sigur că aparatul și controlerul dvs. acceptă schimbarea la cald, puteți face acest lucru fără a opri mașina. Acesta ar fi calea de a merge pe sistemele de producție critice care rulează pe un server hardware real și adecvat, despre care știți cu siguranță că se poate descurca. Serverul meu de fișiere de acasă se bazează pe o placă de bază desktop pentru consumator, cu câteva controlere SATA semi-noname în sloturile PCIe pentru a oferi mai multe porturi SATA.

Deși, în general, SATA ar trebui să accepte schimbarea la cald, nu eram pe cale să risc nimic în această configurare, așa că am optat pentru oprirea mașinii în timp ce înlocuiam unitatea.

Înainte de a face asta, este o idee bună să comentați dispozitivul raid în fișierul /etc/fstab, astfel încât Ubuntu să nu încerce să-l monteze automat la următoarea pornire, deoarece s-ar putea bloca și vă poate forța în modul de recuperare din cauza matricei RAID degradate. S-ar putea să nu fie o problemă mare dacă este un sistem desktop, dar rulez acest server fără cap fără monitor sau tastatură atașată, așa că ar fi un pic o bătaie de cap.

După ce porniți mașina cu noua unitate strălucitoare instalată, utilizați lsblk sau alte mijloace pentru a o identifica. Dacă nu ați schimbat nimic altceva, probabil (dar nu neapărat ) va primi același nume ca și unitatea pe care ați înlocuit-o. În cazul meu a făcut-o, așa că cel nou se numește și /dev/sdf.

Deoarece matricea mea se bazează mai degrabă pe partiții decât pe dispozitive fizice, trebuia să copiez tabelul de partiții de pe o unitate de lucru pe noua unitate pentru a mă asigura că sunt exact aceleași. Dacă rulați matricea pe dispozitive fizice, puteți sări peste acest pas.

Am folosit sgdisk în acest scop, copiend tabelul de partiții din /dev/sdc în /dev/sdf. Asigurați-vă că înlocuiți numele dispozitivelor pentru a se potrivi cu ale dvs., după caz.

Observați ordinea aici: enumerați mai întâi conducătorul „la”! Acest lucru este un pic contra-intuitiv pentru mine, dar asigurați-vă că ați înțeles corect, astfel încât să nu primiți o altă defecțiune a unității în matrice ;-)

Apoi, pentru a evita conflictele UUID, generați noi UUID-uri pentru noua unitate:

Și acum, în sfârșit, a sosit momentul să adăugați noua unitate la matrice și să începem petrecerea de reconstrucție! (Bine, nu este chiar o petrecere, este de fapt un proces destul de lent și deranjant, pentru că într-adevăr, chiar nu vrei să se defecteze o altă unitate în acest moment. Berea ar putea ajuta, totuși)

Oricum, pentru a adăuga noua unitate la matrice, lansați această comandă (din nou, asigurați-vă că înlocuiți numele dispozitivelor cu propriile dvs., după caz):

Dacă totul merge bine, unitatea va fi adăugată la matrice fără sughițuri. Cred că este de fapt adăugat ca „de rezervă la cald” în mod implicit, dar din moment ce acestei matrice îi lipsește un disc (cel care a eșuat), este imediat pus în uz și va începe procesul de reconstrucție.

Îl poți urmări așa:

Acest lucru va dura probabil ceva timp; pe serverul meu modest (bazat în mare parte pe hardware de consum și pe unități desktop, rețineți) a fost capabil să ajungă la puțin sub 100 MB/sec. Rețineți că acesta este RAID-6, deci sunt multe calcule de paritate implicate cu o reconstrucție; un RAID-10 ar fi fost mult mai rapid. Această mașină specială are un procesor cu patru nuclee AMD A10 9700E („E” înseamnă că este un model eficient din punct de vedere energetic, adică nu foarte rapid), doar pentru a vă oferi o idee la ce să vă așteptați. Cu cele nouă unități de 8 TB din configurația mea, reconstrucția completă a durat puțin peste 24 de ore.

În timpul reconstrucției, puteți monta sistemul de fișiere pe matrice și îl puteți utiliza ca de obicei, dacă doriți, dar prefer să îl las la reconstrucție până când se termină. Rețineți că, dacă o unitate se defectează, poate urma în curând o alta, așa că doriți ca reconstrucția să se facă cât mai repede posibil, deoarece nu doriți ca o altă unitate să eșueze în acest timp. Prin urmare, nu-l împovărați cu alte IO care nu sunt strict necesare.

După ce ați terminat, adăugați-l înapoi în fișierul dvs. /etc/fstab, reporniți și bucurați-vă de fișierele dvs. :-)