Hvis jeg forstår riktig,
- en SSD * kan tildeles til hurtigbuffering av flere harddisker med sikkerhetskopiering, og deretter kan de resulterende hurtigbufrede enhetene RAIDes med mdadm
eller - flere HDDer kan RAIDes til en enkelt backing md-enhet og SSD tilordnet cache som
Jeg lurer på hva som er den sunnere tilnærmingen. Det forekommer meg at det å dyrke en RAID5 / 6 kan være enklere med en eller annen teknikk, men jeg er ikke sikker på hvilken!
Er det gode grunner (for eksempel å utvide lagringsplassen eller noe annet) for å velge en tilnærming fremfor den andre (for et stort ikke-rotfilsystem som inneholder VM-backingfiler)?
hr>
* med «en SSD» Jeg mener en slags overflødig SSD-enhet, f.eks. en RAID1 av to fysiske al SSD-er
Kommentarer
Svar
Jeg tror det er mest fornuftig å cache hele md-enheten.
Å sette bcache for å cache hele md-enheten ofrer hele ideen om å ha raid, fordi den introduserer et annet enkelt feilpunkt.
-
OTH-feil på SSD-disker er relativt sjeldne, og bcache kan settes i
writethrough
/writearound
-modus (i motsetning tilwriteback
-modus), der det ikke er data bare lagret på hurtigbufferenheten, og feil på hurtigbufferen dreper ikke informasjonen i raidet, gjør det til et relativt trygt alternativ. -
Et annet faktum er at det er betydelig beregning overhead av myk RAID-5; når du cacher hvert spinnende raidmedlem separat, må datamaskinen fortsatt Beregn alle paritetene på nytt, selv på cache-treff
-
Selvfølgelig vil du ofre litt dyr SSD-plass hvis du cache hver spinnedrev separat.– Med mindre du planlegger å bruke raidet ssd-cache. -
Begge alternativene påvirker ikke tiden for vekstprosessen – selv om alternativet med spinnende stasjoner som er hurtigbufret hver for seg, har potensial til å være tregere pga. mer busstrafikk.
Det er rask og relativt enkel prosess å konfigurere bcache for å fjerne ssd-stasjonen, når du trenger å bytte den ut. Takk til blokkerer det burde være mulig å migrere raidoppsettet begge veier på stedet.
Du bør også huske at for øyeblikket de fleste (alle?) bor- CD-distribusjoner støtter ikke bcache
, så du kan ikke bare få tilgang til dataene dine med slike verktøy uavhengig av bcache
– mdraid
layoutalternativ du valgte.
Kommentarer
- I ' har oppdatert spørsmålet for å gjøre det klart at jeg ' m ikke planlegger å ha en ikke-overflødig SSD-cache. Din andre punkt poeng er en utmerket poi nt, takk for det. Din tredje kule om plass: mener du fordi du ' lagrer pariteten på SSD? re din siste para, jeg ' bruker F20, men vil til slutt bruke RHEL / CentOS7 eller Debian Jessie (hvis bcache-verktøy gjør kuttet).
- @JackDouglas Ad 3. punkt: Ja, akkurat det. Men siden du planlegger å bruke raided ssd-stasjoner, gjelder ikke det '.
- Det gjør det fortsatt fordi de ' vil ikke bare bli speilet, men vil også måtte lagre RAID-pariteten for støttestasjonene. Dette er ikke ' t tilfellet hvis RAID er gjort under bcache som jeg trodde var poenget ditt
- Jeg tror du mener det motsatte: ssd matrise gjør ' må ikke lagre spinneskivene ' paritet, hvis den mates hele mdraid-stasjonen.
- ja, det ' er akkurat det jeg mener!
Svar
I » d tror den sunne tilnærmingen er å cache den resulterende MD-enheten.
bcache er designet for å passere gjennom sekvensiell lesing og skriving.
Hvis du cache hver enhet separat, logisk sett, flere enheter striping til en raidet eller strippet MD, vil fra bcache-perspektivet stadig skrive tilfeldige blokker.
Mens et bcached MD-volum vil se ut som normalt, og skrive filer til volumet, snarere enn tilfeldige blokker til flere enheter.
Hele poenget med hard og programvare raid er å gjøre striping av data i bakenden slik at de resulterende filene tem ser ut som et normalt volum.
Dette er kanskje ikke riktig (ettersom bcache-devs kan være smart og redegjøre for den slags situasjoner), men den logiske optimale tingen å gjøre er å cache volumer, i stedet for å blokkere enheter.
Kommentarer
- også et veldig godt poeng
- En stor sekvensiell skriving til en RAID5 / 6 produserer sekvensiell skriving til alle komponentenhetene. Hver komponentenhet får hver N-1 datablokk (eller paritet), men dataene den får er sekvensiell. Men du ' har rett i at det vil forvride ting. Hvis det er noen biter som ser hyppige delstripeskrifter, noe som resulterer i en lesemodifiser-skriv av (en del av) paritetsstripen, som kan caches av bcache. Å cache den høyere opp, før skrivingen med delvis stripe noen gang traff MD-enheten, ville være enda bedre.
bcache
ryggen må formateres medbcache
– så du ' enten må du opprette enmd
array, formatere den enkelt resulterende disken helt som enbcache
-støttet partisjon, koble den til cache-stasjonen og gå derfra, eller formater mange disker medbcache
, koble dem til hurtigbufferstasjonen, og formater deretter de mange diskene som en matrise. I begge tilfeller er det flere punkter med mulig feil som alle avhenger av interoperabilitet mellom to filsystemer – for ikke å nevne den endelige fs. se her : rull ned .