Î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 repozitoriile sale; la momentul scrierii, v4.1-rc1. Este posibil să fie sau nu valabile pentru alte versiuni.

Recent, am avut o defecțiune bruscă a unității de stocare pe 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ă găsesc rapid o unitate de schimb care a fost livrată chiar a doua zi, astfel încât să pot începe reconstrucția.

Trebuie să recunosc că am fost puțin cam zgârcit când am configurat inițial serverul de fișiere; doar două dintre unități sunt unități NAS (Seagate IronWolf), în timp ce restul sunt unități desktop (Seagate Barracuda). Nu este surprinzător că una dintre unitățile desktop a cedat (după aproape trei ani de utilizare). Era complet moartă; după ce a fost mutată într-o carcasă USB desktop, tot ce am auzit de la ea a fost un clic tulburător și nici Ubuntu 20.04, nici Windows 10 nu au putut să-l detecteze.

Ei bine, să trecem la piesa de schimb (și da, noua unitate pe care am cumpărat-o era un IronWolf, lecție învățată) - oricât de înfricoșător este să pierzi o unitate dintr-o matrice funcțională, este și mai înfricoșător dacă nu știi procedura corectă pentru înlocuirea ei. Nu este prima dată când a trebuit să înlocuiesc o unitate defectă într-o matrice mdadm, dar din fericire se întâmplă atât de rar încât de obicei trebuie să caut comenzile corecte. De data aceasta am decis să-mi creez propriul mic ghid pentru referințe viitoare.

Deci, în primul rând, când primești temutul e-mail de la mdadm cu un eveniment de eroare, trebuie să identifici ce unitate a defectat. Sigur, îți va spune numele dispozitivului (în cazul meu /dev/sdf), dar probabil nu este evident ce unitate fizică este aceasta, deoarece aceste nume se pot schimba la pornirea mașinii.

Dacă nici măcar nu ești sigur ce nume de dispozitiv a eșuat, poți folosi următoarea comandă pentru a afla (înlocuiește /dev/md0 cu dispozitivul tău RAID):

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

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

(dacă nu se găsește smartctl, trebuie să instalați pachetul smartmontools pe Ubuntu)

Numărul de serie poate fi apoi comparat cu numerele de serie de pe eticheta fizică a unităților pentru a afla care dintre ele a defectat.

De data aceasta însă, nu am avut același noroc. Unitatea era complet moartă și chiar a refuzat să furnizeze date SMART sau de altă natură, inclusiv numărul de serie.

Întrucât aveam acces fizic la server (ceea ce chiar ai nevoie dacă vei înlocui singur o unitate fizică, presupun ;-)) și serverul funcționa deja când discul s-a defectat (și a continuat să funcționeze fără probleme datorită redundanței RAID-6), am ales metoda destul de primitivă, dar de fapt extrem de eficientă și evidentă, de a copia pur și simplu un fișier mare pe server și de a observa care becul HDD nu pâlpâia. În câteva secunde am identificat vinovatul.

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

În caz de succes, mdadm va răspunde cu un mesaj care spune că a „dezactivat la cald” unitatea, aparent pentru că dispozitivul virtual raid rulează în acel moment.

Dacă eșuează și afișează un mesaj de eroare similar cu „dispozitiv sau resursă ocupată”, este posibil ca mdadm să nu fi înregistrat unitatea ca fiind complet defectă. Pentru a face acest lucru, executați această comandă (din nou, nu uitați să înlocuiți numele dispozitivelor cu propriile nume, după caz):

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

Acum e momentul să înlocuiți efectiv unitatea. Dacă sunteți într-adevăr sigur că mașina și controlerul dvs. acceptă înlocuirea la cald, puteți face acest lucru fără a opri mașina. Aceasta ar fi calea de urmat pentru sistemele de producție critice care rulează pe hardware de server real, adecvat, despre care știți cu siguranță că poate gestiona acest lucru. Serverul meu de fișiere de acasă se bazează pe o placă de bază desktop de calitate consumer, cu câteva controllere SATA semi-fără nume în sloturile PCIe pentru a oferi mai multe porturi SATA.

Deși SATA ar trebui, în general, să accepte înlocuirea la cald, nu aveam de gând să risc nimic în această configurație, 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 să vă forțeze să intrați în modul de recuperare din cauza matricei RAID degradate. Acest lucru s-ar putea să nu fie o problemă mare dacă este un sistem desktop, dar eu rulez acest server headless fără monitor sau tastatură conectate, așa că ar fi puțin complicat.

După ce porniți mașina cu noua unitate instalată, folosiți comanda lsblk sau alte metode pentru a o identifica. Dacă nu ați modificat nimic altceva, probabil (dar nu neapărat) va primi același nume ca unitatea pe care ați înlocuit-o. În cazul meu, așa a primit, așa că cea nouă se numește tot /dev/sdf.

Deoarece matricea mea se bazează pe partiții și nu pe dispozitive fizice, a trebuit să copiez tabela de partiții de pe o unitate funcțională pe noua unitate pentru a mă asigura că sunt exact la fel. Dacă rulați matricea pe dispozitive fizice, puteți sări peste acest pas.

Am folosit sgdisk în acest scop, copiind tabela 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 de aici: listați unitatea „către” mai întâi! Acest lucru este puțin contraintuitiv pentru mine, dar asigurați-vă că îl scrieți corect, astfel încât să nu mai apară o eroare de unitate în matrice ;-)

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

Și acum, în sfârșit, a venit momentul să adăugăm noua unitate la matrice și să începem petrecerea de reconstrucție! (Bine, nu e chiar o petrecere, e de fapt un proces destul de lent și enervant, deoarece chiar nu vrei să se defecteze o altă unitate în acest moment. Totuși, berea ar putea ajuta.)

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

Dacă totul merge bine, unitatea va fi adăugată la matrice fără probleme. Cred că este de fapt adăugată ca „hot spare” în mod implicit, dar, deoarece acestei matrice îi lipsește un disc (cel care a eșuat), este pusă imediat în funcțiune și procesul de reconstrucție va începe.

Poți să-l urmărești astfel:

Probabil va dura ceva timp; pe serverul meu modest (bazat în mare parte pe hardware de calitate consumer și unități desktop, rețineți) a reușit să atingă puțin sub 100 MB/sec. Rețineți că acesta este RAID-6, deci există multe calcule de paritate implicate în reconstrucție; un RAID-10 ar fi fost mult mai rapid. Această mașină anume are un procesor quad core AMD A10 9700E („E” înseamnă că este un model cu eficiență energetică sub-tactată, adică nu super rapid), doar ca să vă faceți o idee despre 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 normal, dacă doriți, dar prefer să las procesul de reconstrucție până la finalizare. Rețineți că, dacă o unitate se defectează, alta poate urma în curând, așa că doriți ca reconstrucția să fie făcută cât mai repede posibil, deoarece nu doriți ca o altă unitate să se defecteze în acest timp. Prin urmare, nu o supraîncărcați cu alte operațiuni de I/O care nu sunt strict necesare.

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