Phenquestions
Konfiguration af cache på din ZFS-pool
Hvis du har været igennem vores tidligere indlæg om ZFS basics, ved du nu, at dette er et robust filsystem. Det udfører kontrolsummer på hver blok af data, der skrives på disken, og vigtige metadata, som selve kontrolsummen, skrives flere forskellige steder. ZFS mister muligvis dine data, men det giver dig garanteret aldrig tilbage forkerte data, som om det var den rigtige.
Det meste af redundansen for en ZFS-pool kommer fra de underliggende VDEV'er. Det samme gælder for lagerpoolens ydeevne. Både læse- og skriveydelsen kan forbedres meget ved at tilføje højhastigheds-SSD'er eller NVMe-enheder. Hvis du har brugt hybriddiske, hvor en SSD og en spindende disk er samlet som et enkelt stykke hardware, så ved du, hvor dårlige cachemekanismerne til hardwareniveauet er. ZFS er ikke noget som dette på grund af forskellige faktorer, som vi vil undersøge her.
Der er to forskellige cacher, som en pool kan bruge:
- ZFS Intent Log, eller ZIL, til buffer WRITE-operationer.
- ARC og L2ARC, som er beregnet til LÆS-operationer.
Synkron versus asynkron skrivning
ZFS, som de fleste andre filsystemer, forsøger at opretholde en buffer til skriveoperationer i hukommelsen og derefter skrive den ud til diskene i stedet for direkte at skrive den til diskene. Dette er kendt som asynkron skriv, og det giver anstændige præstationsgevinster for applikationer, der er fejltolerante, eller hvor datatab ikke skader meget. Operativsystemet gemmer simpelthen dataene i hukommelsen og fortæller applikationen, der anmodede om skrivning, at skrivningen er afsluttet. Dette er standardopførelsen for mange operativsystemer, selv når du kører ZFS.
Faktum er dog fortsat, at i tilfælde af systemfejl eller strømafbrydelse går alle de bufrede skrivninger i hovedhukommelsen tabt. Så applikationer, der ønsker konsistens i forhold til ydeevne, kan åbne filer i synkron tilstand, og derefter betragtes dataene kun for at være skrevet, når de faktisk er på disken. De fleste databaser og applikationer som NFS er afhængige af synkroniserede skrivninger hele tiden.
Du kan indstille flaget: synkronisering = altid at gøre synkron skriver standardadfærd for et givet datasæt.
$ zfs sæt synkronisering = altid mypool / datasæt1Selvfølgelig kan du ønske at have en god præstation, uanset om filerne er i synkron tilstand eller ej. Det er her ZIL kommer ind i billedet.
ZFS Intent Log (ZIL) og SLOG-enheder
ZFS Intent Log refererer til en del af din lagringspool, som ZFS bruger til at gemme nye eller modificerede data først, før den spredes ud over hovedlagerpoolen og striper på tværs af alle VDEV'er.
Som standard er der altid skåret en lille mængde lagerplads ud af puljen for at fungere som ZIL, selv når du kun bruger en masse roterende diske til din opbevaring. Du kan dog gøre det bedre, hvis du har en lille NVMe eller en anden type SSD til din rådighed.
Den lille og hurtige opbevaring kan bruges som en separat hensigtslog (eller SLOG), hvor de nyankomne data vil blive gemt midlertidigt, før de skylles til poolens større hovedlager. For at tilføje en slog-enhed skal du køre kommandoen:
$ zpool tilføj tank log ada3Hvor tank er navnet på din pool, log er nøgleordet, der fortæller ZFS at behandle enheden ada3 som en SLOG-enhed. Din SSD's enhedsknude er muligvis ikke nødvendigvis det ada3, Brug det rigtige knudenavn.
Nu kan du kontrollere enhederne i din pool som vist nedenfor:
Du kan stadig være bekymret for, at dataene i en ikke-flygtig hukommelse mislykkes, hvis SSD'en fejler. I så fald kan du bruge flere SSD'er, der spejler hinanden eller i enhver RAIDZ-konfiguration.
$ zpool tilføj tank log spejl ada3 ada4
For de fleste brugssager er den lille 16 GB til 64 GB virkelig hurtig og holdbar flashlagring de mest egnede kandidater til en SLOG-enhed.
Adaptiv erstatningscache (ARC) og L2ARC
Når vi prøver at cache læseoperationerne, ændres vores mål. I stedet for at sikre, at vi får god ydeevne samt pålidelige transaktioner, skifter ZFS 'motiv nu til at forudsige fremtiden. Dette betyder at cache de oplysninger, som en applikation vil kræve i den nærmeste fremtid, mens du kasserer dem, der skal bruges længst frem i tide.
For at gøre dette bruges en del af hovedhukommelsen til caching af data, der enten blev brugt for nylig, eller der er ofte adgang til dataene. Det er her udtrykket Adaptive Replacement Cache (ARC) kommer fra. Ud over traditionel læsecaching, hvor kun de senest anvendte objekter er cachelagret, lægger ARC også vægt på, hvor ofte der er adgang til dataene.
L2ARC, eller niveau 2 ARC, er en udvidelse til ARC. Hvis du har en dedikeret lagerenhed til at fungere som din L2ARC, gemmer den alle de data, der ikke er for vigtige for at blive i ARC, men samtidig er data nyttige nok til at fortjene et sted i den langsommere end hukommelsen NVMe-enhed.
For at tilføje en enhed som L2ARC til din ZFS-pool skal du køre kommandoen:
$ zpool tilføj tank cache ada3
Hvor tank er din pools navn og ada3 er enhedsnodenavnet til din L2ARC-lager.
Resumé
For at afkorte en lang historie kort buffrer et operativsystem ofte skriveoperationer i hovedhukommelsen, hvis filerne åbnes i asynkron tilstand. Dette må ikke forveksles med ZFS 'faktiske skrivecache, ZIL.
ZIL er som standard en del af ikke-flygtig lagring af puljen, hvor data går til midlertidig lagring, før de spredes ordentligt i alle VDEV'er. Hvis du bruger en SSD som en dedikeret ZIL-enhed, er den kendt som SLOG. Som enhver VDEV kan SLOG være i spejl- eller raidz-konfiguration.
Læsecache, der er gemt i hovedhukommelsen, er kendt som ARC. På grund af den begrænsede størrelse på RAM kan du dog altid tilføje en SSD som en L2ARC, hvor ting, der ikke kan passe i RAM'en, caches.
