De ce mdadm nu poate face față unui disc „aproape eșuat”?

De mai multe ori în cariera mea am întâlnit acum seturi mdadm RAID (RAID1+0, 5, 6 etc) în diferite medii (de exemplu, cutii CentOS/Debian, Synology/QNAP NAS) care par pur și simplu incapabile să gestioneze discul defect. Acesta este un disc care nu este complet mort, dar are zeci de mii de sectoare defecte și pur și simplu nu poate gestiona I/O. Dar, nu este complet mort, încă funcționează. Jurnalul nucleului este de obicei plin de erori UNC.

Uneori, SMART va identifica discul ca fiind defect, alteori nu există alte simptome decât I/O lentă.

I/O lentă determină de fapt întregul sistem să înghețe. Conectarea prin ssh durează o veșnicie, webGUI (dacă este un NAS) nu mai funcționează de obicei. Rularea comenzilor prin ssh durează și ea o veșnicie. Asta până când deconectez / „eșuez” în mod intenționat discul din matrice, apoi lucrurile revin la „normal” - care este cât se poate de normal cu o matrice degradată.

Mă întreb doar dacă un disc durează atât de mult pentru a citi/scrie, de ce să nu-l scoateți din matrice, să lăsați un mesaj în jurnal și să continuați? Se pare că oprirea întregului sistem, deoarece un disc este cam prost, anulează total unul dintre principalele beneficii ale utilizării RAID (toleranța la erori - capacitatea de a continua să ruleze dacă un disc eșuează). Pot să înțeleg că într-un scenariu cu un singur disc (de exemplu, sistemul tău are un singur disc SATA conectat și nu poate executa corect citirea/scrierea) acest lucru este catastrofal, dar într-un set RAID (în special „personalitățile”) tolerante la defecte pare nu numai enervant, ci și contrar bunului simț.

Există un motiv foarte întemeiat pentru care comportamentul implicit al mdadm este de a paraliza cutia până când cineva intră de la distanță și o repară manual?

În general, scopul a RAID, în funcție de nivelul de raid ales, oferă un echilibru diferit între obiectivele cheie Redundanță de date, disponibilitate, performanţă și capacitate.

Pe baza cerințelor specifice, este responsabilitatea proprietarului depozitului a decide care dintre diverșii factori este cel potrivit pentru scopul dat, pentru a crea a de încredere soluţie.

Treaba soluției Raid alese (aici în acest caz vorbim despre software mdadm) este de a asigura în primul rând protecția datelor. Având în vedere acest lucru, devine clar că nu este sarcina soluției de raid să pondereze continuitatea afacerii mai mult decât integritatea datelor.

Cu alte cuvinte: treaba lui mdadm este să evite un raid eșuat. Atâta timp cât un „disc cu comportament ciudat” nu este complet rupt, el contribuie în continuare la raid.

Deci, de ce nu scoateți pur și simplu un disc cu un comportament ciudat din matrice, lăsați un mesaj în jurnal și continuați? Pentru că acest lucru ar crește riscul de a pierde date.

Adică ai dreptate, pentru momentul dat, din perspectivă de business, pare soluția mai bună doar să continui.În realitate însă, mesajul care a fost aruncat în jurnal poate rămâne nedetectat, astfel încât starea degradată a raidului rămâne nedetectată. Un timp mai târziu, în cele din urmă, un alt disc din același raid eșuează, ca urmare datele stocate pe raid-ul eșuat au dispărut în cele din urmă.

În plus: este greu de definit exact ce este un „disc care se comportă ciudat”. Exprimat în alt mod: Care este încă un comportament de operare acceptabil al unui singur disc, operat într-o matrice de discuri?

Unii dintre noi ar putea răspunde „discul prezintă unele erori”. Alții pot răspunde: „Atâta timp cât erorile pot fi corectate, totul este în regulă”. Alții pot răspunde: „Atâta timp cât discul răspunde la toate comenzile într-un timp dat, totul este în regulă”. Alții spun „în cazul în care temperatura discului diferă cu mai mult de 5°C în comparație cu temperatura medie a tuturor discurilor din aceeași matrice”. Un alt răspuns ar putea fi „atâta timp cât un scrub nu dezvăluie erori” sau „atâta timp cât SMART nu arată erori”.

Ceea ce este scris nu este o listă lungă și nici nu completă.

Ideea este că definiția „comportamentului acceptabil al unui disc” este o chestiune de interpretare și, prin urmare, și responsabilitatea proprietarului spațiului de stocare, și nu ceva ce mdadm ar trebui să decidă singur.

Problema cheie este că o unitate de disc SATA defectă poate uneori să înghețe întreaga magistrală pe durata procedurii sale interne de recuperare a erorilor. Din acest motiv, ar trebui să se folosească compatibil TLER unități numai în matrice RAID (și de preferință un model de nivel enterprise).

Unitățile SAS suferă mai puțin de această problemă, dar nici nu sunt absolut libere de ea.

Pe lângă ceea ce s-a spus, vreau să adaug banul meu, dar acesta este o considerație importantă.

Ce un drum când sectorul este lent de citit?

Se presupune că conduce un dispozitiv proiectat să funcționeze singur, de ex. g. unități „desktop” tipice, presupunem că nu există altă modalitate de a prelua datele stocate în acel sector defect. Ei vor încerca să recupereze datele cu orice preț, repetând din nou și din nou, pentru o perioadă lungă de timp. Desigur, vor marca și acel sector ca eșuat, așa că îl vor remapa data viitoare când îi scrieți, dar trebuie să scrieți pentru asta. Până când îl rescrieți, se vor sufoca de fiecare dată când citiți din acel loc. Într-o setare RAID, aceasta înseamnă că pentru RAID unitatea încă funcționează și nu există niciun motiv pentru a o da afară, dar pentru aplicație matricea va încetini până la un crawl.

Pe de altă parte, unitățile „întreprindere”, în special cele „de marcă”, presupun adesea că sunt întotdeauna folosite în setarea RAID. Un controler „de marcă”, văzând unitatea „de marcă”, ar putea chiar notifica firmware-ul lor despre prezența RAID. Deci unitatea se va opri mai devreme și va raporta o eroare I/O, chiar dacă a fost posibil să faceți mai multe încercări și să citiți sectorul. Apoi, controlerul are șansa să răspundă mai rapid, oglindind instrucțiunile de citire pe o unitate frate (și scoțând-o pe cea proastă din matrice). Când retrageți și explorați/testați cu atenție acea unitate declanșată, nu găsiți nicio problemă aparente – a fost doar încetinită pentru o clipă și a fost suficient pentru a înceta să o mai utilizați, conform unei logici a controlerului.

Speculez că asta poate fi singura diferența dintre unitățile „desktop” și cele „de marcă”/„întreprindere” NL-SAS și SATA. Acesta este, probabil, motivul pentru care plătiți de trei ori mai mult atunci când cumpărați o unitate „HPE” care a fost de fapt produsă de Toshiba, în comparație cu cumpărarea celei cu marca „Toshiba”.

Cu toate acestea, unele unități acceptă unele controale generice ale acestui lucru. Se numește SCT ERC care shands pentru Control de recuperare a erorilor de transport SMART Command. Așa arată înăuntru smartctl:

nesuportat

# smartctl --all /dev/sda
=== ÎNCEPEREA SECȚIUNII DE CITIRE DE DATE INTELIGENTE ===
Capabilități SCT: (0x3037) Stare SCT acceptată.
                                        SCT Feature Control acceptat.
                                        Tabel de date SCT acceptat.

sprijinit

=== ÎNCEPEREA SECȚIUNII DE CITIRE DE DATE INTELIGENTE ===
...
Capacități SCT: (0x003d) Stare SCT acceptată.
                                        SCT Error Recovery Control acceptat.
                                        SCT Feature Control acceptat.
                                        Tabel de date SCT acceptat.

Dacă aveți noroc, puteți controla această funcție cu smartctl. Puteți să preluați sau să setați două timeout-uri, cât timp să încercați să recitiți și cât să încercați să rescrieți:

# smartctl -l scterc /dev/sda
Control de recuperare a erorilor SCT:
           Citire: 70 (7,0 secunde)
          Scriere: 70 (7,0 secunde)

# smartctl -l scterc /dev/sde
Control de recuperare a erorilor SCT:
           Citiți: Dezactivat
          Scriere: Dezactivat

# smartctl -l scterc /dev/sdd
Avertisment: dispozitivul nu acceptă comanda SCT Error Recovery Control

smartctl -l scterc,120,60 /dev/sde

Ceea ce înseamnă: 120 de zecimi de secundă pentru a reîncerca citirea; 60 de zecimi de secundă pentru a reîncerca scrierea. Zero înseamnă „reîncearcă până mori”. Diferite unități au setări implicite diferite pentru aceasta.

Așadar, dacă utilizați singur unitatea „RAID edition”, mai bine setați timeout-urile ERC la zero, sau puteți pierde date. Pe de altă parte, dacă utilizați unități în RAID, este mai bine să setați o setare rezonabilă și scăzută, diferită de zero.

Sursa de amarao @ Habrahabr, în rusă.

P.S. Și o notă despre SAS. Utilizare sdparm, acceptă mai multe controale ale acestui lucru.

Am avut situații în care un disc nu a funcționat, dar a scos controlerul într-un fel.

Din punct de vedere istoric, acest lucru a fost posibil cu PATA, unde unitățile master și slave erau pe același cablu, iar o unitate defectuoasă ar putea interfera cu accesul la cealaltă unitate încă bună. Îndepărtarea unității proaste ar putea reactiva accesul la unitatea rămasă sau ar putea avea nevoie de un ciclu de pornire, dar raid-ul ar putea fi degradat și apoi recuperarea ar putea începe.

SATA este mai puțin vulnerabil la acest lucru, dar este posibil ca controlerul să fie afectat. Din experiența mea cu raidurile software, există mai multe dintre interiorurile sângeroase expuse, care ar fi ascunse de un controler de raid dedicat.

Nu am experimentat asta cu SAS sau NVME, dar SAS înseamnă adesea controlere raid hardware care au mai multă inteligență în gestionarea discurilor în interior.