Phenquestions
Konfigurera cache i din ZFS-pool
Om du har gått igenom våra tidigare inlägg om ZFS-grunderna vet du nu att detta är ett robust filsystem. Den utför kontrollsummor för varje block av data som skrivs på disken och viktiga metadata, som själva kontrollsummen, skrivs på flera olika platser. ZFS kan förlora dina data, men det ger garanterat aldrig tillbaka fel data, som om det vore rätt.
Det mesta av redundansen för en ZFS-pool kommer från de underliggande VDEV: erna. Detsamma gäller för lagringspoolens prestanda. Både läs- och skrivprestanda kan förbättras väsentligt genom att lägga till snabba SSD-enheter eller NVMe-enheter. Om du har använt hybridskivor där en SSD och en snurrande skiva buntas som en enda hårdvara, vet du hur dåliga cachemekanismerna på hårdvarunivån är. ZFS är inget liknande på grund av olika faktorer som vi kommer att utforska här.
Det finns två olika cachar som en pool kan använda:
- ZFS Intent Log, eller ZIL, för att buffra WRITE-operationer.
- ARC och L2ARC som är avsedda för LÄS-operationer.
Synkron vs Asynkron skrivning
ZFS, som de flesta andra filsystem, försöker upprätthålla en buffert för skrivoperationer i minnet och sedan skriva ut den till diskarna istället för att skriva den direkt till diskarna. Detta kallas asynkron skriva och det ger anständiga prestationsvinster för applikationer som är feltoleranta eller där dataförlust inte skadar mycket. Operativsystemet lagrar helt enkelt data i minnet och berättar för applikationen, som begärde skrivningen, att skrivningen är klar. Detta är standardbeteendet för många operativsystem, även när du kör ZFS.
Faktum kvarstår dock att i händelse av systemavbrott eller strömavbrott går alla buffrade skrivningar i huvudminnet förlorade. Så applikationer som vill ha konsekvens över prestanda kan öppna filer i synkron och sedan anses data endast vara skrivna när de faktiskt finns på skivan. De flesta databaser och applikationer som NFS förlitar sig på synkrona skrivningar hela tiden.
Du kan ställa in flaggan: synkronisering = alltid för att göra synkron skriver standardbeteendet för en viss dataset.
$ zfs set sync = alltid mypool / dataset1Naturligtvis kanske du vill ha en bra prestanda oavsett om filerna är i synkront läge eller inte. Det är där ZIL kommer in i bilden.
ZFS Intent Log (ZIL) och SLOG-enheter
ZFS Intent Log refererar till en del av din lagringspool som ZFS använder för att lagra ny eller modifierad data först innan den sprids över hela lagringspoolen och strippar över alla VDEVs.
Som standard huggs alltid ut en liten mängd lagring från poolen för att fungera som ZIL, även när du bara använder en massa snurrskivor för din lagring. Du kan dock göra bättre om du har en liten NVMe eller någon annan typ av SSD till ditt förfogande.
Det lilla och snabba lagringsutrymmet kan användas som en separat avsiktslogg (eller SLOG), det är där de nyanlända data lagras tillfälligt innan de spolas till poolens större huvudlagring. För att lägga till en slog-enhet kör du kommandot:
$ zpool lägg till tanklogg ada3Var tank är namnet på din pool, logga är nyckelordet som säger till ZFS att behandla enheten ada3 som en SLOG-enhet. Din SSD-enhetsnod kanske inte nödvändigtvis är det ada3, använd rätt nodnamn.
Nu kan du kontrollera enheterna i din pool enligt nedan:
Du kanske fortfarande är orolig för att data i ett icke-flyktigt minne skulle misslyckas om SSD misslyckas. I så fall kan du använda flera SSD-enheter som speglar varandra eller i vilken RAIDZ-konfiguration som helst.
$ zpool lägg till tankloggspegel ada3 ada4
För de flesta användningsfall är de små 16 GB till 64 GB riktigt snabb och hållbar flash-lagring de mest lämpliga kandidaterna för en SLOG-enhet.
Adaptivt utbytescache (ARC) och L2ARC
När vi försöker cacha läsoperationerna ändras vårt mål. Istället för att se till att vi får bra resultat, liksom tillförlitliga transaktioner, flyttas nu ZFS motiv till att förutsäga framtiden. Detta innebär att man cachar den information som en applikation skulle kräva inom en snar framtid, samtidigt som man kasserar de som kommer att behövas längst fram i tid.
För att göra detta används en del av huvudminnet för att cachelagra data som antingen har använts nyligen eller att data nås oftast. Det är där termen Adaptive Replacement Cache (ARC) kommer ifrån. Förutom traditionell läscaching, där endast de senast använda objekten cachas, uppmärksammar ARC också hur ofta data har nås.
L2ARC, eller nivå 2 ARC, är ett tillägg till ARC. Om du har en dedikerad lagringsenhet för att fungera som din L2ARC kommer den att lagra all data som inte är så viktig för att stanna kvar i ARC men samtidigt är data tillräckligt användbar för att förtjäna en plats i det långsammare än minnet NVMe-enhet.
För att lägga till en enhet som L2ARC i din ZFS-pool kör du kommandot:
$ zpool lägg till tankcache ada3
Var tank är din pools namn och ada3 är enhetsnodnamnet för din L2ARC-lagring.
Sammanfattning
För att förkorta en lång historia buffrar ett operativsystem ofta skrivoperationer i huvudminnet om filerna öppnas i asynkront läge. Detta ska inte förväxlas med ZFS faktiska skrivcache, ZIL.
ZIL är som standard en del av icke-flyktig lagring av poolen där data går för tillfällig lagring innan den sprids ordentligt i alla VDEV. Om du använder en SSD som en dedikerad ZIL-enhet är den känd som SLOG. Som alla VDEV kan SLOG vara i spegel- eller raidz-konfiguration.
Läscache, lagrad i huvudminnet, kallas ARC. På grund av den begränsade storleken på RAM kan du alltid lägga till en SSD som en L2ARC, där saker som inte passar i RAM-minnet cachas.
