bcache på md eller md på bcache

bcache tillader et eller flere hurtige diskdrev såsom flashbaseret solid state-drev (SSDer) til at fungere som en cache for en eller flere langsommere harddiske .

Hvis jeg forstår det rigtigt,

  • en SSD * kunne tildeles til cache af flere backing-harddiske, og derefter kunne de resulterende cachede enheder RAIDes med mdadm
    eller
  • flere HDDer kunne RAIDes til en enkelt backing md-enhed, og SSD tildelt cache, der

Jeg undrer mig over, hvad der er den sundere tilgang. Det forekommer mig, at dyrkning af en RAID5 / 6 kan være enklere med en eller anden teknik, men jeg er ikke sikker på hvilken!

Er der gode grunde (f.eks. at udvide opbevaringslageret eller noget andet) til at vælge en tilgang frem for den anden (til et stort ikke-rodfilsystem, der indeholder VM-opbakningsfiler)?


* med “en SSD” Jeg mener en slags redundant SSD-enhed, f.eks. en RAID1 af to fysiske al SSDer

Kommentarer

  • I begge tilfælde alle diske, der bcache ryg skal formateres med bcache – så du ' skal enten oprette en md array, formater den enkelt resulterende disk udelukkende som en bcache -partition, der er understøttet, link den til dens cachedrev og gå derfra, eller formater mange diske med bcache, link dem til deres cache-drev, og formater derefter de mange diske som en matrix. I begge tilfælde er der flere punkter med mulig fejl, som alle afhænger af interoperabilitet mellem to filsystemer – for ikke at nævne de endelige fs. se her : rul ned .
  • Tak til github.com/g2p/blocks , du kan konvertere det på plads, selvom der er nogle begrænsninger for dette.
  • @mikeserv Jeg forstår alt det, dette er til en specialbygget server så det er ' godt. Hvad mener du " to filsystemer "? bcache er ikke et filsystem – det eneste filsystem, jeg ' har, er XFS på den endelige bcache- eller mdadm-enhed (afhængigt af hvilken mulighed jeg vælger).
  • Tak @Adam, konvertering på stedet er ikke noget problem for mig.
  • @mikeserv nej det er ikke ' t. Filsystemer (f.eks. Btrfs, xfs, extN osv.) Lever oven på blokkenheder. mdadm og bcache fungerer på blokeringsenhedsniveau ikke på filsystemniveau (btrfs forveksler problemet med det ' overtrædelse af lagdeling, men det er en helt separat samtale).

Svar

Jeg tror, at caching af hele md-enheden giver mest mening.

At sætte bcache til at cache hele md-enhed ofrer hele ideen om at have raid, fordi den introducerer endnu et enkelt fejlpunkt.

  • OTH-fejl på SSD-diske er relativt sjældne, og bcache kan sættes i writethrough / writearound -tilstand (i modsætning til writeback -tilstand), hvor der ikke er data kun gemt på cache-enheden, og fejl i cachen dræber ikke informationen i raiden gør det til en relativt sikker mulighed.

  • Andet faktum er, at der er betydelig beregningsmæssig overhead af soft RAID-5; når cache hvert roterende raid-element caches separat, skal computeren stadig genberegne alle pariteter, selv på cache-hits

  • Det er klart, at du ofrer noget dyrt SSD-plads, hvis du cacher hvert centrifugeringsdrev separat. – Medmindre du planlægger at bruge raidet ssd-cache.

  • Begge muligheder påvirker relativt ikke tidspunktet for vækstprocessen – skønt indstillingen med spindende drev, der cachelagres separat, har potentiale til at være langsommere på grund af mere bustrafik.

Det er hurtig og relativt enkel proces at konfigurere bcache til at fjerne ssd-drevet, når du skal udskifte det. Takket være blokke skal det være muligt at migrere raidopsætningen begge veje på stedet.

Du skal også huske, at i øjeblikket bor de fleste (alle?) CD-distributioner understøtter ikke bcache , så du kan ikke få adgang til dine data med sådanne værktøjer uanset bcachemdraid layoutmulighed, du valgte.

Kommentarer

  • I ' har opdateret spørgsmålet for at gøre det klart, at jeg ' m ikke planlægger at have en ikke-redundant SSD-cache. Din anden kugle punkt er en fremragende poi nt, tak for det. Din tredje kugle om plads: mener du, fordi du ' lagrer pariteten på SSD? re din sidste para, jeg ' bruger F20, men vil i sidste ende bruge RHEL / CentOS7 eller Debian Jessie (hvis bcache-værktøjer klipper).
  • @JackDouglas Ad 3. punkt: Ja, netop det. Men da du planlægger at bruge razzia-ssd-drev, gælder det ikke ' for dig.
  • Det gør det stadig, fordi de ' ll bliver ikke kun spejlet, men skal også gemme RAID-pariteten til backing-drevne. Dette er ikke ' t tilfældet, hvis RAID er færdig under bcache, som jeg troede var dit pointe
  • Jeg tror du mener det modsatte: ssd matrix gør ' skal ikke gemme de roterende diske ' paritet, hvis den tilføres hele mdraid-drevet.
  • ja, det ' er præcis hvad jeg mener!

Svar

I ” tror, at den sindige tilgang er at cache den resulterende MD-enhed.

bcache er designet til at passere gennem sekventiel læsning og skrivning.

Hvis du cache hver enhed separat, logisk set, flere enheder striping til en raidet eller strippet MD, vil fra bcache-perspektivet konstant skrive tilfældige blokke.

Mens en bcached MD-volumen ser ud som normal, skriver filer til lydstyrken, snarere end tilfældige blokke til flere enheder.

Hele pointen med hard og software raid er at udføre stripning af data i backend, så de resulterende fils tem ligner en normal lydstyrke.

Dette er muligvis ikke korrekt (da bcache-devs kan være kloge og tage højde for den slags situation), men den logiske optimale ting at gøre er at cache diskenheder, snarere end at blokere enheder.

Kommentarer

  • også et meget godt punkt
  • En stor sekventiel skrivning til en RAID5 / 6 producerer sekventiel skrivning til alle komponenterne. Hver komponentenheder får hver N-1-datablok (eller paritet), men de data, den får, er sekventielle. Men du ' har ret i, at det vil fordreje ting. Hvis der er nogle stykker, der ser hyppige delstribe-skrivninger, hvilket resulterer i en read-modify-skrivning af (en del af) paritetsstriben, kan den caches af bcache. At cache det højere op, før skrivningen med delvis stribe nogensinde ramte MD-enheden, ville dog være endnu bedre.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *