Dacă înțeleg corect,
- un SSD * ar putea fi atribuit memoriei cache a mai multor HDD-uri de backing, iar apoi dispozitivele cache rezultate ar putea fi RAID cu mdadm
sau - HDD-urile multiple ar putea fi RAID într-un singur dispozitiv MD backing și SSD atribuit cache-ului pe care
mă întreb care este abordarea mai sănătoasă. Mi se pare că creșterea unui RAID5 / 6 poate fi mai simplă cu una sau alta tehnică, dar nu sigur care!
Există motive întemeiate (de exemplu, creșterea spațiului de stocare sau orice altceva) pentru alegerea unei abordări față de cealaltă (pentru un sistem de fișiere mare non-rădăcină care conține fișiere de rezervă VM)?
* prin „un SSD” mă refer la un fel de dispozitiv SSD redundant, de ex. un RAID1 de două SSD-uri al
Comentarii
Răspuns
Cred că cache-ul întregului dispozitiv MD are cel mai mult sens.
Punerea bcache în cache întregul dispozitiv MD sacrifică întreaga idee de a face raid, deoarece introduce un alt punct unic de eșec.
-
Eșecurile OTH ale discurilor SSD sunt relativ rare și bcache poate fi introdus în
writethrough
/writearound
(spre deosebire de modulwriteback
), unde nu există date stocat numai pe dispozitivul cache, iar eșecul cache-ului nu ucide informațiile din raid face din aceasta o opțiune relativ sigură. -
Un alt fapt este că există calcule semnificative cheltuielile superioare ale RAID-5; atunci când cache fiecare membru al raidului se rotește separat, computerul trebuie să o facă recalculați toate paritățile, chiar și la accesările cache
-
Evident, ați sacrifica un spațiu ssd scump, dacă veți memora separat fiecare unitate rotativă.– Cu excepția cazului în care intenționați să utilizați cache SSD atacat. -
Ambele opțiuni relativ nu afectează timpul procesului de creștere – deși opțiunea cu discuri rotative fiind stocate în cache separat are potențialul de a fi mai lent datorită mai mult trafic cu autobuzele.
Este un proces rapid și relativ simplu de configurat bcache pentru a elimina unitatea SSD, atunci când trebuie să o înlocuiți. Mulțumită blocuri ar trebui să fie posibilă migrarea configurării raidului în ambele sensuri la fața locului.
De asemenea, ar trebui să vă amintiți că în acest moment majoritatea (toate?) live- Distribuțiile de CD-uri nu acceptă bcache
, astfel încât să nu puteți accesa datele dvs. cu astfel de instrumente, indiferent de bcache
– mdraid
opțiunea de aspect pe care ați ales-o.
Comentarii
- I ' Am actualizat întrebarea pentru a clarifica faptul că <
nu intenționez să am un cache SSD non-redundant. Al doilea dvs. glonț punctul este un poi excelent nt, mulțumesc pentru asta. Al treilea glonț despre spațiu: vrei să spui pentru că ' ar fi stocarea parității pe SSD? ca ultimul dvs. para, eu ' m folosind F20, dar în cele din urmă voi folosi RHEL / CentOS7 sau Debian Jessie (dacă bcache-tools face tăierea).
Răspuns
I ” Cred că abordarea corectă este de a memora în cache dispozitivul MD rezultat.
bcache este conceput pentru a trece prin citiri și scrieri secvențiale.
Dacă bcacheți fiecare dispozitiv separat, în mod logic, mai multe dispozitive dezinfectarea într-un MD atacat sau dezbrăcat, din perspectiva bcache, va scrie în mod constant blocuri aleatorii.
În timp ce un volum MD bcached va arăta normal, scriind fișiere în volum, mai degrabă decât blocuri aleatorii în mai multe dispozitive.
Întregul punct al raidului hard și software este de a efectua strângerea de date în backend, astfel încât fișierele rezultate tem arată ca un volum normal.
Acest lucru s-ar putea să nu fie corect (deoarece dev-urile bcache ar putea fi inteligente și să țină cont de acel tip de situație), dar lucrul optim logic de făcut este să memorați în cache volumele, mai degrabă să blocați dispozitive.
Comentarii
- , de asemenea, un punct foarte bun
- O scriere secvențială mare pe un RAID5 / 6 produce scrieri secvențiale pe toate dispozitivele componente. Fiecare dispozitiv component primește fiecare bloc de date N-1 (sau paritate), dar datele pe care le obține sunt secvențiale. Dar ai ' dreptate că va distorsiona lucrurile. Dacă există unele bucăți care văd frecvente scrieri cu bandă parțială, rezultând o citire-modificare-scriere a (parțială) a benzii de paritate, care ar putea fi stocată în cache de bcache. Așezarea în cache mai sus, înainte ca scrierea cu bandă parțială să atingă vreodată dispozitivul MD, ar fi chiar mai bună.
bcache
spatele va trebui formatat cubcache
– deci ' va trebui fie să creați unmd
array, formatați singurul disc rezultat în întregime ca o partiție susținută debcache
, conectați-l la unitatea cache și mergeți de acolo sau formatați multe discuri cubcache
, conectați-le la unitatea cache, apoi formatați numeroasele discuri ca o singură matrice. În ambele cazuri există mai multe puncte de eșec posibil, toate depinzând de interoperabilitatea dintre două sisteme de fișiere – ca să nu mai vorbim de f-urile finale. vezi aici : derulează în jos .