Om jag förstår rätt,
- en SSD * kan tilldelas till cachning av flera hårddiskar för säkerhetskopiering, och sedan kan de resulterande cachade enheterna RAIDas med mdadm
eller - flera hårddiskar kan RAIDas till en enda backing md-enhet och SSD tilldelad till cache som
Jag undrar vilken som är det bättre. Det tänker mig att växa en RAID5 / 6 kan vara enklare med en eller annan teknik, men jag är inte säker på vilken!
Finns det goda skäl (t.ex. att växa lagringsutrymmet eller något annat) för att välja ett tillvägagångssätt framför det andra (för ett stort icke-rotfilsystem som innehåller VM-stödfiler)?
* med ”en SSD” menar jag någon form av redundant SSD-enhet, t.ex. en RAID1 av två fysiska al SSD-enheter
Kommentarer
Svar
Jag tror att cachning av hela md-enheten är mest meningsfull.
Att sätta bcache för att cache hela md-enheten offrar hela idén att ha raid, eftersom det introducerar en annan enda felpunkt.
-
OTH-fel på SSD-skivor är relativt sällsynta och bcache kan läggas i
writethrough/writearound-läge (i motsats tillwriteback-läget), där det inte finns data lagras endast på cache-enheten och cache-fel misslyckas inte med informationen i raiden gör det till ett relativt säkert alternativ. -
Ett annat faktum är att det finns betydande beräkningar överhead på mjuk RAID-5; när varje cache-caching cachas separat måste datorn fortfarande göra det beräkna om alla pariteter, även vid cachetreffar
-
Uppenbarligen skulle du offra lite dyrt SSD-utrymme om du cachar varje spinndrivning separat.– Såvida du inte planerar att använda raided ssd-cache. -
Båda alternativen påverkar inte tidpunkten för odlingsprocessen relativt – även om alternativet med roterande enheter som cachas separat har potential att bli långsammare på grund av mer busstrafik.
Det är en snabb och relativt enkel process att konfigurera bcache för att ta bort SSD-enheten när du behöver byta ut den. Tack vare blockerar det borde vara möjligt att migrera raidinställningen åt båda hållen på plats.
Du bör också komma ihåg att just nu (mest?) bor- CD-distributioner stöder inte bcache så att du helt enkelt kan komma åt dina data med sådana verktyg oavsett bcache – mdraid layoutalternativ du valde.
Kommentarer
- I ' har uppdaterat frågan för att klargöra att jag ' m inte planerar att ha en icke-redundant SSD-cache. Din andra punkt poäng är en utmärkt poi nt, tack för det. Din tredje punkt om rymden: menar du för att du ' lagrar pariteten på SSD? är din sista punkt, jag ' använder F20 men kommer så småningom att använda RHEL / CentOS7 eller Debian Jessie (om bcache-verktyg gör klippningen).
- @JackDouglas Ann tredje punkt: Ja, exakt det. Men eftersom du planerar att använda raserade ssd-enheter gäller det inte '.
- Det gör det fortfarande eftersom de ' kommer inte bara att speglas utan kommer också att behöva lagra RAID-paritet för backing-enheterna. Detta är inte ' t fallet om RAID är gjort under bcache som jag trodde var din poäng
- Jag tror att du menar det motsatta: ssd-matris gör ' måste lagra snurrskivorna ' paritet, om den matas hela mdraid-enheten.
- ja, det ' exakt vad jag menar!
Svar
I ” d tror att den förnuftiga metoden är att cacha den resulterande MD-enheten.
bcache är utformad för att passera genom sekventiella läsningar och skrivningar.
Om du bachar varje enhet separat, logiskt sett, flera enheter stripning till en raidet eller strippad MD, kommer från bcache-perspektivet att ständigt skriva slumpmässiga block.
Medan en bcached MD-volym ser ut som normal, skriver filer till volymen, snarare än slumpmässiga block till flera enheter.
Hela poängen med hård och mjukvara är att göra stripning av data i backend så att de resulterande filerna tem ser ut som en normal volym.
Detta kanske inte är korrekt (eftersom bcache-devs kan vara smart och ta hänsyn till den typen av situation), men det logiska optimala är att cache-volymer, snarare än att blockera enheter.
Kommentarer
- också en mycket bra punkt
- En stor sekventiell skrivning till en RAID5 / 6 ger sekventiell skrivning till alla komponenterna. Varje komponentenhet får varje N-1-datablock (eller paritet), men den data den får är sekventiell. Men du ' har rätt i att det kommer att snedvrida saker. Om det finns några bitar som ser frekventa delremsskrivningar, vilket resulterar i en läs-modifier-skriv av (en del av) paritetsremsan, kan det cachas av bcache. Att cachelagra det högre upp, innan skrivningen av partiell rand någonsin träffade MD-enheten, skulle dock vara ännu bättre.
bcacheryggen måste formateras medbcache– så att du ' antingen måste skapa enmdarray, formatera den enskilda resulterande disken helt som enbcache-partition som backas upp, länka den till dess cache-enhet och gå därifrån, eller formatera många diskar medbcache, länka dem till deras cache-enhet och formatera sedan de många skivorna som en matris. I båda fallen finns det flera olika möjliga fel som alla beror på interoperabilitet mellan två filsystem – för att inte tala om de slutliga fs. se här : rulla ner .