bcache på md eller md på bcache (Norsk)

bcache tillater en eller flere raske diskstasjoner som flashbasert solid state-stasjoner (SSD-er) for å fungere som en hurtigbuffer for en eller flere langsommere harddiskstasjoner .

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

  • I begge tilfeller alle diskene som bcache ryggen må formateres med bcache – så du ' enten må du opprette en md array, formatere den enkelt resulterende disken helt som en bcache -støttet partisjon, koble den til cache-stasjonen og gå derfra, eller formater mange disker med bcache, 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 .
  • Takk til github.com/g2p/blocks , du kan konvertere den på plass, selv om det er noen begrensninger i dette.
  • @mikeserv Jeg forstår alt det, dette er for en spesialbygd server så det er '. Hva mener du " to filsystemer "? bcache er ikke et filsystem – det eneste filsystemet jeg ' vil ha vil være XFS på den endelige bcache- eller mdadm-enheten (avhengig av hvilket alternativ jeg velger).
  • Takk @Adam, konvertering på stedet er ikke noe problem for meg.
  • @mikeserv nei det er ikke ' t. Filsystemer (f.eks. Btrfs, xfs, extN osv.) Lever på toppen av blokkenheter. mdadm og bcache fungerer på blokkeringsenhetsnivå, ikke på filsystemnivå (btrfs forveksler problemet med det ' lagbrudd, men det er en helt egen samtale).

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 til writeback -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 bcachemdraid 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.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *