Rezumând problema:
Am trecut cu JBOD de ani de zile, dar în sfârșit am nevoie de un adevărat „micro centru de date”. Am cumpărat 3 unități pentru cutia mea centos8-stream timp de câteva luni, dar am auzit că ar putea fi atât bine, cât și rău să obținem aceleași unități de la același număr de lot. Toate erau unități WD Red TB: WD80EFAX*. Dar dracu în detalii, primul a fost umplut cu heliu wd80efax-68LHPN0, Mfg În iulie 2019, ultimele două la vânzare au fost umplute cu aer WD80EFAX-68KNBN0 din 2020. Carcasele arătau diferit, dar am procedat oricum, deoarece erau aceleași versiune majoră și majoritatea comercianților cu amănuntul nici măcar nu listează sau diferențiază restul. Din păcate, primele mele încercări nu merg bine și, desigur, este singurul umplut cu heliu care pare să nu se reunească la matricea mdadm/RAID.
Detalii și orice cercetare: Folosesc asta ca stocare/NAS, nu ca server web, deocamdată. Nu am nevoie ca acesta să fie disponibil la pornire, de fapt, s-ar putea să nu doresc această posibilitate, în funcție de modul în care este utilizat computerul în acea zi. S-ar putea să fiu nevoit să epuizez puțin și nu am niciun partener de încredere aproape fizic în acea zi, așa că trebuie să înțeleg și să ajustez configurația în orice moment. Nu că sunt așa de tare, dar ar fi nasol să aibă această matrice nesigură să scrie la 1/10 viteză în cel mai rău moment posibil. Oricum,
Mi-am creat matricea ca atare:
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd
a omis configurarea unei partiții, ca am auzit că nu este necesar dacă vrei doar un volum învecinat pe care nu-l vei schimba niciodată și poate îngreuna chiar lucrurile. Se pare că funcționează bine, cu excepția unei unități care nu se va asocia cu matricea de la sine.
cryptsetup luksFormat /dev/md0, pentru a formata matricea mea de raid pentru anumite tipuri de luks
deschis, configurați sistemul de fișiere. Pentru flexibilitate viitoare, am ales LVM
pvcreate /dev/mapper/devicename
verificați crearea reușită cu: pvs (arata bine)
creați un grup de volum cu vgcreate stocare /dev/mapper/devname, și apoi puneți lvm pe asta. lvcreate -n myLVMname -L 16T storageName
De fapt, a trebuit să folosească 14.55T după cum se pare că un spațiu este rezervat sau există o greșeală de calcul a spațiului la această dimensiune, pe măsură ce discrepanța dintre TB și TiB crește. Oricum, văd că totul este bine cu:
pvs, vgs și Eu versus.
E timpul să faci FS:
mkfs.ext4 /dev/mapper/devname, iar în acest moment lsblk arată toate unitățile mele astfel:
sde // disc
ââmd0 // raidul nostru
ââcrypt-storage //container enc
ââstorage-https //montabil vol
cu imprimare identică pentru /dev/sdd și /dev/sdc. Este deschis și montat acum.
a deschis /etc/fstab, poate vedea `/dev/mapper/devicename este montat la /run/media/username/moutpoint.
Dacă aș fi vrut să se monteze la boot, în acest moment, ar trebui să fac câteva lucruri suplimentare. Dar nu, vreau să-l montez singur după cum este necesar. Pentru o măsură bună, creați mdadm.conf cu mdadm --verbose --detail --scan > /etc/mdadm.conf, deși ar trebui să poată reconstrui matricea cu datele din superblocuri, nu?
Dacă vreau să montez la pornire, trebuie să actualizez /etc/crypttab cu UUID-ul dispozitivului meu de raid /dev/md0, actualizați-mi initramf-urile, cu dracut -f -v, și actualizați grub cu grub2-mkconfig -o /etc/grub2-efi.cfg, sau pentru centos, configurația este de obicei legată la /boot/efi/EFI/centos/grub.cfg. Cu toate acestea, nu am actualizat grub sau crypttab, deoarece nu credeam că trebuie/nu vreau, dacă nu trebuie, totul ar trebui să se întâmple după pornire.
Am repornit, dar lsblk arată problemă: (tuns)
`
sdc
ââsdc1
sdd
ââmd0
sde
ââmd0
`
se pare că wd80efax-68LHPN0 umplut cu heliu (/dev/sdc aici) nu este introdus în matricea md0 (chiar înainte de lvm pe luks). Se crede că există o partiție „sdc1”. Acest lucru se datorează unei probleme cu modul în care l-am configurat, hardware diferit sau firmware diferit? Așa cum am menționat anterior, comercianții cu amănuntul nu vor furniza de multe ori ultimele caractere ale numărului de model, așa că aș sper că toate WD80EFAX* vor funcționa împreună? WD nu pare să ofere firmware pentru hard disk-uri simple? https://community.wd.com/t/firmware-wdc-wd80efzx-68uw8n0/218166/2
Duckduck nu o găsește? (uneori poate depăși Google, cu siguranță funcția de căutare WD)
Am demontat câteva plăci logice înainte și am vrut întotdeauna să mă încurc cu firmware-ul, dar nu în timp ce toate datele mele tocmai au fost mutat (aceasta a fost copia de rezervă) în această stivă criptată, cu unele unități anterioare deja șterse pentru a fi folosite ca unități mari. Să-mi fie rușine că nu am o altă copie de rezervă, este încă lizibil, dar sunt și resurse limitate și încerc să consolidez aceste 5+ unități JBOD, astfel încât să pot organiza această creștere nesfârșită a datelor din viața mea pentru a avea timp pentru mai mult voluntari/afaceri eforturi. Cel puțin acum am învățat pasul temut de a recupera/lucra la o matrice raid criptată, într-o oarecare măsură.
Când este cazul, descrie ce ai încercat:
Pot opri md0 dispozitiv (mdadm --stop /dev/md0, adaugă-l:
mdadm --add /dev/md0 /dev/sdc (și sdc1, deși nu ar adăuga o partiție)
(nu-l re-adăugați și mi-e frică de a folosi --asumă-curat (auzit dacă nu un expert nu folosește)), dar apoi are nevoie de o resincronizare de 2 zile de fiecare dată când pornesc mașina, care este uzură inutilă, ca să nu mai vorbim de timpul de nefuncționare. Nu este bun pentru producție sau chiar nimic.Folosind mdadm --detail /dev/md0 starea arată că este într-adevăr „degradat”, un dispozitiv este „eliminat”. Pot încă să deblochez cele două unități, să le montez și să le citesc, scrierea pare mai lentă, dar acum datele mele atârnă de o stâncă criptată dacă aceste 2 unități rămase eșuează.
Așa că am (re)adaugat aceeași unitate, am lăsat-o să se sincronizeze, folosind ceas pe /proc/mdstat. M-am asigurat că mi-am actualizat initramf-urile (deși nu ar trebui să fie nevoie?) cu dracut -f -v, copiați toate informațiile despre unitate cu blkid pentru orice eventualitate, reporniți. Aceeași problemă, /dev/sdc (unitatea cu heliu mai veche, dar cu același număr de model major) nu face parte din md0.
folosind mdadm -v --assemble /dev/md0 --uuid=<informații din /etc/mdadm.conf> scanează și spune curios:
nu s-a găsit niciun superbloc RAID pe /dev/sdc sau /dev/sdc1, așteptat magic a92something, a primit 00000000*,
pentru /dev/sdc1 („partiția” (care nu ar trebui să fie acolo), nu dispozitiv), așteptat magic a92somethingRAIDUUIDthing, a primit 00000401.
Unitățile bune:
mdadm: /dev/sdf este identificat ca membru al /dev/md0, slotul <1 sau 2>
Asa de Bănuiesc că problema este aici dacă este ceva ce am făcut în configurație. Unele postări în altă parte sugerează că ceva ar putea șterge superblocul, dar nu știu nimic din oprirea sau repornirea mea care ar putea face acest lucru, dar nu am făcut un audit de servitoare rău de ceva timp și nici nu vreau să fiu. necesar pentru a face unul și aș folosi instrumentele și notele de pe această mașină pentru a face acest lucru. Probabil că nu este asta, dar este posibil.
Aș putea încă să actualizez grub sau /etc/crypttab-ul meu, dar se pare că nu ar trebui să fac asta, acesta este practic un thumbdrive RAID uriaș pe care uneori va trebui să îl conectez la restul sistemului. Se pare că se întâmplă altceva în legătură cu superblocuri, hardware sau firmware, mai ales că există diferențe vizibile pe carcasă și placă între unitatea cu heliu și celelalte două care funcționează bine (din păcate).
vreo idee?
ca:
- să-mi examinez mai bine programele de pornire? (pare puțin probabil, dar)
- vreo modalitate de a flash-o firmware nou pe unități? Deși aș dori OEM sau metode deschise, dacă este posibil. Ei citesc blocuri de aceeași dimensiune etc., așa că asta nu ar trebui conteaza oricum?
- cumpăr mai multe drive-uri până găsesc o potrivire sau mergi pe ebay și ghici? sună scump și risipitor
- Aș putea încerca să ghicesc la magazinul local de calculatoare, dar ce trebuie să facă cineva care nu are unul dintre acestea?
- ce aș face după unitatea cu heliu dacă este inutilă ca unitate de rezervă pentru matrice?
- postați pe SuperUser sau în altă parte? Acest loc părea grozav
nu ma intereseaza:
- pornirea ferestrelor (nu se joacă bine cu Linux și ascunde complet driverele mele nesemnate pentru proiectele cu override pentru a ajunge la override îngropată în bios, pentru că f*ck M$)
- deși am o cutie 8.1 pentru echipe M$ care au nevoie de cheie de recuperare și unele suporturi HDD dacă trebuie
- un utilitar de hard disk cu sursă închisă incomplet, chiar dacă ASM a fost codificat manual de Isus Hristos însuși
- a scăpa de raid (știu că există povești de groază, în special adăugarea de criptare, probabil că nu este necesară pentru un sistem static, dar depinde de mediul dvs. de amenințare, dar există și o mulțime de companii care își pariază afacerea pe ele). Mi-ar plăcea să învăț de la acesta și să mai construiesc câteva, acum că acest incident m-a forțat să învăț o grămadă despre ei.
Se pare că există suficiente instrumente și cunoștințe deschise pentru a înțelege acest lucru, nu este știință rachetă, dar este o mulțime de părți mobile care lucrează împreună cu care s-ar putea să nu fiu complet familiarizat, după câteva săptămâni de reparații, postări târâte și RTFM, am crezut că ar trebui să întreb. Sper că am oferit suficiente detalii, dar nu le-am tras.
