bcache vs dm-cache: SSD-caching på Linux

SSD-enheter är snabba men dyra per gigabyte. HDD-enheter är billiga men långsamma. Linux erbjuder två verktyg på kernelnivå för att kombinera dem: bcache och dm-cache. Båda använder en SSD som en transparent cache framför en större HDD, men de skiljer sig åt i arkitektur, installationskrav och var de fungerar bäst.

Hur bcache fungerar

Bcache har funnits i Linux-kärnan sedan version 3.10 (juni 2013). Det fungerar på blocknivå, så det fungerar med alla filsystem som stöder UUID:er.

Internt använder bcache en hybridstruktur av B+-träd och logg. Den delar upp SSD-lagringen i fack av fast storlek (128 K till 2 MB), anpassade efter raderingsblockgränserna. Detta omvandlar slumpmässiga skrivningar till sekventiella, vilket minskar skrivförstärkningen och förlänger SSD-enhetens livslängd. Sekventiella I/O-operationer över 4 MB kringgår automatiskt cachen, vilket gör att SSD-enheten kan fokusera på de slumpmässiga åtkomstmönster där den tillför mest värde.

Bcache övervakar också SSD-latensen i realtid. Om läslatensen överstiger 2 ms eller skrivlatensen överstiger 20 ms, stryper den trafiken för att förhindra att cacheenheten blir en flaskhals.

Inställning

Installera bcache-tools, formatera sedan din bakgrundsenhet och cacheenhet:

make-bcache -B /dev/sdb          # format HDD as backing device
make-bcache -C /dev/sdc          # format SSD as cache device
echo <UUID> > /sys/block/bcache0/bcache/attach   # attach cache

Justering under körning sker via /sys/block/bcache<N>/bcache/ sysfs-gränssnittet, där du kan justera cachelagringslägen, tröskelvärden för sekventiell I/O och latensmål. För RAID-matriser använder du --data-offset för att anpassa till din stripe-bredd.

Haken: installationen är destruktiv. Båda enheterna måste formateras som bcache-mål, så du kan inte lägga till bcache till ett befintligt filsystem utan att först radera det. Bcache-enheter kan inte heller ändras i storlek efter att de skapats.

Prestanda

Bcaches skrivkonsolidering ger starka siffror för slumpmässig skrivning. I prestandatester har den nått ungefär 18 500 slumpmässiga 4K-skriv-IOPS jämfört med 12 200 IOPS på den vanliga SSD-enheten ensam. Genomströmningen för slumpmässig läsning kan nå ungefär 1 000 000 IOPS med lämplig hårdvara.

För krypterade arbetsbelastningar, lägg dm-crypt ovanpå /dev/bcache<N> enheten istället för att kryptera de underliggande enheterna individuellt. Detta ger vanligtvis bättre prestanda eftersom bcache fortfarande kan konsolidera skrivningar före kryptering.

Hur dm-cache fungerar

dm-cache är ett Device Mapper-mål som ligger ovanför en befintlig logisk volym. Det använder tre underenheter: en ursprungsenhet (HDD), en cacheenhet (SSD eller NVMe) och en metadatenhet som spårar blockplatser och smutsiga tillstånd. Standardcachepolicyn är smq (Stochastic Multi-Queue), som identifierar het data i blandade arbetsbelastningar.

Den största fördelen: dm-cache kan läggas på en aktiv LVM-volym utan att förstöra befintliga data. Du kan också ändra storleken med hjälp av standardkommandon för LVM.

Konfiguration med LVM

Det praktiska sättet att konfigurera dm-cache är via lvmcache. Manuell dmsetup konfiguration är möjlig men felbenägen och överlever inte omstarter. LVM-metoden:

1. Skapa fysiska volymer (PV) på både HDD och SSD.
2. Lägg till båda PV:erna i en enda volymgrupp (VG).
3. Skapa tre logiska volymer: en för säkerhetskopiering av data (HDD), en för cache (SSD) och en för metadata (SSD).
4. Kombinera cache- och metadatavolymerna till en cachepool:
   lvconvert --type cache-pool --poolmetadata <meta_lv> <cache_lv>
5. Koppla poolen till källan:
   lvconvert --type cache --cachepool <pool_lv> <data_lv>

En sak att tänka på: montera filsystemet via dess /dev/mapper/ sökväg, inte via UUID. Montering via UUID kan kringgå cachelagret och gå direkt till källenheten.

Prestanda och minne

I writeback-läge under en 90/10 läs/skriv-Zipf-arbetsbelastning har dm-cache uppnått läshastigheter på cirka 193 MB/s och skrivhastigheter på ungefär 21 MB/s. I ett annat benchmarktest ökade cachelagring av en 100 GB HDD med en 10 GB NVMe-partition slumpmässiga skriv-IOPS från 118 till 798.

Nackdelen är minnesanvändningen. dm-caches metadataöverhead beror på blockstorleken. En blockstorlek på 512 byte kan förbruka över 16 GB RAM per 100 GB cache. Om man ökar den till 4 096 byte sjunker minnesanvändningen till cirka 2 GB per 100 GB. Välj en blockstorlek som ligger nära din genomsnittliga I/O-storlek (64 KB är en rimlig utgångspunkt) och se till att den är en multipel av 64 sektorer (32 KB), inom intervallet 32 KB till 1 GB.

Metadata töms vid varje FLUSH- eller FUA-skrivning, eller minst en gång per sekund. För hög tillgänglighet bör du spegla metadatienheten för att undvika en enda felpunkt.

Cachelagringslägen

Både bcache och dm-cache stöder samma grundläggande cachelagringslägen. Valet påverkar både prestanda och datasäkerhet.

Writethrough är det säkra standardalternativet för båda verktygen. Writeback är snabbare men medför en reell risk: om SSD:n går sönder medan den innehåller data som inte har skrivits till, går den datan förlorad och filsystemet kan skadas. Använd writeback endast när du har redundanta SSD:er eller kan tolerera tillfällig dataförlust.

bcache vs dm-cache: Vilket ska man använda

Använd bcache när du bygger ett nytt system från grunden och vill ha bästa möjliga slumpmässiga I/O-prestanda. Det är det bästa valet för skrivintensiva arbetsbelastningar som databaser och VM-lagring, samt för RAID 6-matriser där slumpmässiga skrivfördröjningar är allvarliga.

Använd dm-cache när du behöver lägga till caching till en server som redan är i drift. Dess LVM-integration innebär att du kan ansluta en cache utan driftstopp eller datamigrering. Det passar bättre för läsintensiva arbetsbelastningar och miljöer där du behöver flexibilitet att ändra storlek på eller omkonfigurera lagring i farten.

Slutsats

Båda verktygen löser samma problem, men de passar olika situationer. Bcache är det bästa valet för nya installationer. dm-cache är det praktiska valet för befintliga LVM-system. Oavsett vilket du väljer, börja med writethrough-läge tills du är säker på din SSD:s tillförlitlighet, och byt sedan till writeback om du behöver skrivprestanda.

Om du behöver dedikerade servrar med SSD-cachingkonfigurationer, utforska FDC:s alternativ för dedikerade servrar.