Konfigurere ZFS -cache for høy hastighet IO

Konfigurere hurtigbuffer på ZFS -bassenget

Hvis du har vært gjennom våre tidligere innlegg om ZFS -grunnleggende, vet du nå at dette er et robust filsystem. Den utfører sjekksum på hver datablokk av data som blir skrevet på disken og viktige metadata, som sjekkumsumene, er skrevet flere forskjellige steder. ZFS kan miste dataene dine, men det er garantert å aldri gi deg feil data, som om det var den rette.

Det meste av redundans for et ZFS -basseng kommer fra de underliggende VDEV -ene. Det samme er tilfelle for lagringsbassengets ytelse. Både lese- og skriveytelsen kan forbedre seg veldig ved tillegg av SSD -er eller NVME -enheter med høy hastighet. Hvis du har brukt hybrid disker der en SSD- og spinningsdisk er samlet som et enkelt stykke maskinvare, vet du hvor dårlig maskinvarenivå hurtigbufringsmekanismer er. ZFS er ingenting som dette, på grunn av forskjellige faktorer, som vi vil utforske her.

Det er to forskjellige hurtigbuffer som et basseng kan benytte seg av:

1. ZFS Intent Log, eller Zil, for å buffere skriveoperasjoner.
2. Bue og l2arc som er ment for leseoperasjoner.

Synkron vs asynkrone skriver

ZFS, som de fleste andre filsystemer, prøver å opprettholde en buffer av skriveoperasjoner i minnet og deretter skrive den ut til diskene i stedet for å skrive den direkte til diskene. Dette er kjent som asynkron Skriv og det gir anstendige resultatgevinster for applikasjoner som er feiltolerante eller hvor tap av data ikke gjør mye skade. OS lagrer ganske enkelt dataene i minnet og forteller applikasjonen, som ba om skrivingen, at skrivingen er fullført. Dette er standardatferden til mange operativsystemer, selv når du kjører ZFS.

Faktum gjenstår at i tilfelle systemfeil eller strømtap, er alle de buffrede skriver i hovedminnet tapt. Så applikasjoner som ønsker konsistens over ytelse kan åpne filer i synkron modus og da anses dataene bare for å være skrevet når de faktisk er på disken. De fleste databaser og applikasjoner som NFS, er avhengige av synkrone skriver hele tiden.

Du kan stille inn flagget: Synkronisering = alltid å gjøre synkron skriver standardatferden for et gitt datasett.

Selvfølgelig kan det hende du ønsker å ha en god ytelse uavhengig av om filene er i synkron modus eller ikke. Det er der Zil kommer inn i bildet.

ZFS Intent Log (ZIL) og slagordenheter

ZFS Intent Log refererer til en del av lagringsbassenget som ZFS bruker for å lagre nye eller modifiserte data først, før de sprer dem ut gjennom hovedlagringsbassenget, stripping over alle VDEV -ene.

Som standard er en liten mengde lagring alltid skåret ut fra bassenget for å fungere som Zil, selv når du bare bruker en haug med spinnende disker for lagringen din. Imidlertid kan du gjøre det bedre hvis du har en liten NVME eller annen type SSD til din disposisjon.

Den lille og raske lagringen kan brukes som en egen intensjonslogg (eller slog), og det er her de nyankomne dataene vil bli lagret midlertidig før de ble skyllet til den større hovedlagringen av bassenget. For å legge til en slog -enhet Kjør kommandoen:

Hvor tank er navnet på bassenget ditt, Logg er nøkkelordet som forteller ZFS å behandle enheten Ada3 Som en slagordenhet. SSDs enhetsnode er kanskje ikke nødvendigvis Ada3, Bruk riktig nodenavn.

Nå kan du sjekke enhetene i bassenget ditt som vist nedenfor:

Du kan fremdeles være bekymret for at dataene i et ikke-flyktig minne vil mislykkes, hvis SSD mislykkes. I så fall kan du bruke flere SSD -er som speiler hverandre eller i hvilken som helst RAIDZ -konfigurasjon.

For de fleste brukstilfeller er den lille 16 GB til 64 GB virkelig rask og holdbar flash -lagring de mest passende kandidatene til en slog -enhet.

Adaptiv erstatningsbuffer (ARC) og L2ARC

Når vi prøver å cache leseoperasjonene, endres våre objektive. I stedet for å sørge for at vi får god ytelse, så vel som pålitelige transaksjoner, skifter nå ZFS 'motiv til å forutsi fremtiden. Dette betyr å cache informasjonen som en applikasjon vil kreve i nærmeste fremtid, samtidig.

For å gjøre dette brukes en del av hovedminnet til hurtigbufringsdata som enten ble brukt nylig, eller at dataene får tilgang til hyppigst. Det er der begrepet adaptiv erstatningsbuffer (ARC) kommer fra. I tillegg til tradisjonell lest hurtigbufring, der bare de sist brukte objektene er hurtigbufret, legger buen også oppmerksom på hvor ofte dataene har blitt tilgjengelig.

L2ARC, eller nivå 2 -bue, er en forlengelse av buen. Hvis du har en dedikert lagringsenhet for å fungere som din L2ARC, vil den lagre alle dataene som ikke er for viktig å holde seg i buen, men samtidig som data er nyttig nok til å fortjene et sted i den langsommere enn-Memory NVME -enhet.

For å legge til en enhet som L2ARC i ZFS -bassenget, kjør kommandoen:

Hvor tank er bassengets navn og Ada3 er enhetsnodenavnet for L2ARC -lagring.

Sammendrag

For å kutte en lang historie kort, buffer et operativsystem ofte operasjoner i hovedminnet, hvis filene åpnes i asynkron modus. Dette skal ikke forveksles med ZFS 'faktiske skrivebuffer, Zil.

Zil er som standard en del av ikke-flyktig lagring av bassenget der data går for midlertidig lagring før den er spredt ordentlig gjennom alle VDEV-ene. Hvis du bruker en SSD som en dedikert ZIL -enhet, er det kjent som slog. Som enhver VDEV, kan slog være i speil- eller RAIDZ -konfigurasjon.

Les cache, lagret i hovedminnet, er kjent som buen. På grunn av den begrensede størrelsen på RAM kan du imidlertid alltid legge til en SSD som en L2ARC, der ting som ikke kan passe inn i RAM -en er hurtigbufret.