Phenquestions
Cache configureren op uw ZFS-pool
Als je onze eerdere berichten over ZFS-basics hebt gelezen, weet je inmiddels dat dit een robuust bestandssysteem is. Het voert controlesommen uit op elk gegevensblok dat op de schijf wordt geschreven en belangrijke metagegevens, zoals de controlesommen zelf, worden op meerdere verschillende plaatsen geschreven. ZFS kan uw gegevens verliezen, maar het geeft u gegarandeerd nooit verkeerde gegevens terug, alsof het de juiste was.
Het grootste deel van de redundantie voor een ZFS-pool komt van de onderliggende VDEV's. Hetzelfde geldt voor de prestaties van de opslagpool. Zowel de lees- als schrijfprestaties kunnen enorm verbeteren door de toevoeging van snelle SSD's of NVMe-apparaten. Als je hybride schijven hebt gebruikt waarbij een SSD en een draaiende schijf zijn gebundeld als een enkel stuk hardware, dan weet je hoe slecht de cachingmechanismen op hardwareniveau zijn. ZFS is niet zo, vanwege verschillende factoren, die we hier zullen onderzoeken.
Er zijn twee verschillende caches waar een pool gebruik van kan maken:
- ZFS Intent Log, of ZIL, om WRITE-bewerkingen te bufferen.
- ARC en L2ARC die bedoeld zijn voor LEES-bewerkingen.
Synchrone versus asynchrone schrijfbewerkingen
ZFS probeert, net als de meeste andere bestandssystemen, een buffer van schrijfbewerkingen in het geheugen te behouden en deze vervolgens naar de schijven te schrijven in plaats van deze rechtstreeks naar de schijven te schrijven. Dit staat bekend als asynchroon schrijven en het geeft behoorlijke prestatieverbeteringen voor toepassingen die fouttolerant zijn of waar gegevensverlies niet veel schade aanricht. Het besturingssysteem slaat de gegevens eenvoudig op in het geheugen en vertelt de toepassing, die het schrijven heeft aangevraagd, dat het schrijven is voltooid. Dit is het standaardgedrag van veel besturingssystemen, zelfs wanneer ZFS . wordt uitgevoerd.
Het feit blijft echter dat in het geval van een systeemstoring of stroomuitval, alle gebufferde schrijfacties in het hoofdgeheugen verloren gaan. Dus toepassingen die consistentie boven prestaties wensen, kunnen bestanden openen in synchroon modus en dan worden de gegevens pas als geschreven beschouwd als ze daadwerkelijk op de schijf staan. De meeste databases en toepassingen zoals NFS vertrouwen altijd op synchrone schrijfacties.
U kunt de vlag instellen: sync=altijd om synchrone schrijfacties het standaardgedrag te maken voor een bepaalde dataset.
$zfs set sync=always mypool/dataset1Natuurlijk wilt u misschien een goede prestatie hebben, ongeacht of de bestanden in de synchrone modus staan. Dat is waar ZIL in beeld komt.
ZFS Intent Log (ZIL) en SLOG-apparaten
ZFS Intent Log verwijst naar een deel van uw opslagpool dat ZFS gebruikt om eerst nieuwe of gewijzigde gegevens op te slaan, voordat deze wordt verspreid over de hoofdopslagpool, waarbij alle VDEV's worden gestript.
Standaard wordt er altijd een kleine hoeveelheid opslagruimte uit de pool gehaald om als ZIL te werken, zelfs als u slechts een aantal draaiende schijven voor uw opslag gebruikt. Je kunt het echter beter doen als je een kleine NVMe of een ander type SSD tot je beschikking hebt.
De kleine en snelle opslag kan worden gebruikt als een afzonderlijk intentielogboek (of SLOG), waar de nieuw binnengekomen gegevens tijdelijk worden opgeslagen voordat ze worden doorgespoeld naar de grotere hoofdopslag van de pool. Voer de opdracht uit om een slog-apparaat toe te voegen:
$zpool tanklog toevoegen ada3Waar tank is de naam van uw zwembad, log is het sleutelwoord dat ZFS vertelt om het apparaat te behandelen? ada3 als een SLOG-apparaat. Het apparaatknooppunt van uw SSD is misschien niet noodzakelijk: ada3, gebruik de juiste knooppuntnaam.
Nu kunt u de apparaten in uw zwembad controleren zoals hieronder weergegeven:
U kunt zich nog steeds zorgen maken dat de gegevens in een niet-vluchtig geheugen zouden mislukken als de SSD faalt. In dat geval kunt u meerdere SSD's gebruiken die elkaar spiegelen of in elke RAIDZ-configuratie.
$zpool tanklog spiegel toevoegen ada3 ada4
Voor de meeste gebruikssituaties zijn de kleine 16 GB tot 64 GB aan echt snelle en duurzame flashopslag de meest geschikte kandidaten voor een SLOG-apparaat.
Adaptive Replacement Cache (ARC) en L2ARC
Bij het cachen van de leesbewerkingen, verandert ons doel. In plaats van ervoor te zorgen dat we goede prestaties en betrouwbare transacties krijgen, verschuift het motief van ZFS nu naar het voorspellen van de toekomst. Dit betekent dat de informatie die een applicatie in de nabije toekomst nodig heeft in de cache wordt opgeslagen, terwijl de informatie die het verst van tevoren nodig is, wordt weggegooid.
Om dit te doen, wordt een deel van het hoofdgeheugen gebruikt voor het cachen van gegevens die recentelijk zijn gebruikt of die het vaakst worden gebruikt. Dat is waar de term Adaptive Replacement Cache (ARC) vandaan komt. Naast traditionele leescaching, waarbij alleen de meest recent gebruikte objecten in de cache worden opgeslagen, let de ARC ook op hoe vaak de gegevens zijn geopend.
L2ARC, of Level 2 ARC, is een uitbreiding op de ARC. Als u een speciaal opslagapparaat heeft dat als uw L2ARC fungeert, slaat het alle gegevens op die niet zo belangrijk zijn om in de ARC te blijven, maar tegelijkertijd zijn die gegevens nuttig genoeg om een plaats te verdienen in het trager-dan-geheugen NVMe-apparaat.
Voer de volgende opdracht uit om een apparaat als L2ARC aan uw ZFS-pool toe te voegen:
$zpool tankcache toevoegen ada3
Waar tank is de naam van uw zwembad en ada3 is de naam van het apparaatknooppunt voor uw L2ARC-opslag.
Samenvatting
Om een lang verhaal kort te maken: een besturingssysteem buffert schrijfbewerkingen vaak in het hoofdgeheugen, als de bestanden in asynchrone modus worden geopend. Dit moet niet worden verward met de werkelijke schrijfcache van ZFS, ZIL.
ZIL maakt standaard deel uit van de niet-vluchtige opslag van de pool waar gegevens tijdelijk worden opgeslagen voordat deze correct worden verspreid over alle VDEV's. Als u een SSD als een speciaal ZIL-apparaat gebruikt, staat dit bekend als SLOG. Zoals elke VDEV kan SLOG in mirror- of raidz-configuratie zijn.
Leescache, opgeslagen in het hoofdgeheugen, staat bekend als de ARC. Vanwege de beperkte omvang van RAM kun je echter altijd een SSD toevoegen als een L2ARC, waar dingen die niet in het RAM passen in de cache worden opgeslagen.
