Hoeveel vrije ruimte moet ZFS behouden voordat de prestaties van snapshots afnemen?

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Houd als praktisch uitgangspunt ongeveer 20% van een ZFS-pool vrij. De bekende regel van 80% gebruik is een veiligheidsmarge, geen harde grens: de werklast, vdev-indeling, recordgrootte, fragmentatie en blokken die door snapshots worden vastgehouden bepalen wanneer de prestaties daadwerkelijk afnemen.

Snapshots zijn belangrijk omdat overschreven of verwijderde blokken niet opnieuw beschikbaar komen zolang een snapshot ernaar verwijst. Een pool kan er daardoor stabiel uitzien totdat een grote herschrijving, replication receive of opschoning laat zien hoe weinig werkruimte er nog over is. Dit onderscheid bepaalt de meetmethode, veiligheidsmarge en stopconditie. Dit onderscheid bepaalt de meetmethode, veiligheidsmarge en stopconditie.

Behandel 80% gebruik als een drempel voor vroegtijdige actie

Bij een lage bezettingsgraad heeft ZFS meer mogelijkheden om nieuwe blokken toe te wijzen. Naarmate de pool voller raakt, wordt het moeilijker om vrije gebieden te vinden en kunnen copy-on-write-updates meer werk van de allocator vereisen, vooral op gefragmenteerde HDD-pools.

Begin rond 80% gebruik met capaciteitsmaatregelen in plaats van te wachten op een melding dat er geen ruimte meer is. VM-opslag met veel schrijfbewerkingen, databases en kleine willekeurige I/O hebben meer vrije ruimte nodig dan een archief met voornamelijk sequentiële toegang.

Meet zowel op poolniveau als op datasetniveau. Quota's en reserveringen kunnen ervoor zorgen dat een dataset geen ruimte meer heeft terwijl de pool vrije ruimte meldt, terwijl snapshots ruimte kunnen vasthouden die gewone tools voor directory's niet tonen.

Let op de signalen die echte druk zichtbaar maken

Houd de poolcapaciteit, fragmentatie, schrijflatentie, trend in vrije ruimte, gebruikte snapshotruimte en de omvang van wachtende replicatie- of back-uptaken bij. Eén percentage kan al deze beperkingen niet beschrijven.

Vergelijk de latentie tijdens de normale werklast bij 70%, 80% en een hogere bezettingsgraad, als je dat veilig kunt doen. De relevante waarschuwing is een herhaalbare stijging van de latentie of een daling van de doorvoer bij dezelfde belasting.

Gebruik de onderstaande beslissingstabel om gebruik en gedrag naar actie te vertalen.

Waargenomen toestand	Beoordeling	Volgende actie
Minder dan 70% gebruikt; stabiele latentie	Gezonde marge	Trend blijven volgen
Rond 80% gebruikt of stijgende latentie	Actiedrempel	Veilig opschonen, gegevens verplaatsen of uitbreiden
Meer dan 90% gebruikt; mislukte toewijzingen	Kritiek	Stop niet-essentiële schrijfbewerkingen en herstel ruimte

Herstel vrije ruimte zonder een tweede incident te veroorzaken

Verwijder alleen snapshots buiten de goedgekeurde bewaartermijn en controleer of ze niet nodig zijn als basis voor replicatie. Het verwijderen van een recente gemeenschappelijke snapshot kan een volledige nieuwe verzending afdwingen, waarvoor nog meer ruimte nodig is.

Verplaats koude gegevens, breid de pool uit met een ondersteunde topologie of verminder inkomende schrijfbewerkingen voordat je zwaar onderhoud uitvoert. Start geen scrub, resilver, replicatie-ontvangst en massale verwijdering tegelijk op een bijna volle pool.

De diagnose voor snapshotruimte van ZimaSpace maakt onderscheid tussen snapshots, prullenbakken en actieve bestanden.

De analyse van OpenZFS-snapshots van Klara Systems koppelt volle pools, snapshotgebruik en praktische capaciteitsplanning aan elkaar.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

Test de oorspronkelijke werklast opnieuw na het opschonen

Herhaal dezelfde werklast met schrijfbewerkingen, snapshots en bladeren door directory's nadat je ruimte hebt vrijgemaakt. Vergelijk latentie, doorvoer en druk op de allocator in plaats van ervan uit te gaan dat een lager percentage het probleem heeft opgelost.

Controleer of de volgende geplande snapshot- en replicatiecyclus wordt voltooid en of de pool niet onmiddellijk opnieuw de waarschuwingsdrempel bereikt. Stel waarschuwingen vroeg genoeg in om normale groei plus de grootste verwachte tijdelijke taak op te vangen.

Houd de grens van 20% vrije ruimte aan wanneer metingen ontbreken. Verhoog deze grens als de schrijflatentie stijgt, de fragmentatie hoog is of grote afwijkingen tussen snapshots regelmatig voorkomen; stop nieuwe schrijfbewerkingen als de pool bijna vol raakt of toewijzingen beginnen te mislukken.