ONTAP FlexCache Rückschreibrichtlinien
FlexCache Write-Back umfasst viele komplexe Interaktionen zwischen dem Ursprung und den Caches. Für eine optimale Performance sollte die Umgebung diesen Richtlinien entsprechen. Diese Richtlinien basieren auf der neuesten Hauptversion von ONTAP (ONTAP 9.17.1), die zum Zeitpunkt der Inhaltserstellung verfügbar war.
Es empfiehlt sich, Ihre Produktions-Workload in einer Nicht-Produktionsumgebung zu testen. Dies ist besonders wichtig, wenn FlexCache Write-Back außerhalb dieser Richtlinien implementiert wird.
Die folgenden Richtlinien sind intern bei NetApp erprobt. Es wird dringend empfohlen, sich daran zu halten. Andernfalls kann unerwartetes Verhalten auftreten.
-
Wesentliche Verbesserungen für FlexCache Write-Back wurden in ONTAP 9.17.1P1 eingeführt. Es wird dringend empfohlen, nach 9.17.1P1 die aktuell empfohlene Version sowohl auf dem Ursprungs- als auch auf dem Cache-Cluster zu verwenden. Falls die Codeline 9.17.1 nicht ausgeführt werden kann, ist die neueste P-Version von 9.16.1 die nächstempfohlene Version. ONTAP 9.15.1 enthält nicht alle notwendigen Korrekturen und Verbesserungen für FlexCache Write-Back und wird nicht für Produktions-Workloads empfohlen.
-
In der aktuellen Version sollte der FlexCache Write-Back-Cache mit einem einzigen Bestandteil für das gesamte FlexCache Volume konfiguriert werden. Mehrere Bestandteile eines FlexCaches können zu unerwünschtem Entfernen von Daten aus dem Cache führen.
-
Die Tests wurden mit Dateien unter 100GB und WAN-Roundtrip-Zeiten zwischen Cache und Origin mit maximal 200ms durchgeführt. Arbeitslasten außerhalb dieser Grenzen können zu unerwarteten Leistungseigenschaften führen.
-
Das Schreiben in alternative SMB-Datenströme führt dazu, dass die Hauptdatei aus dem Cache entfernt wird. Alle schmutzigen Daten der Hauptdatei müssen an den Ursprung übertragen werden, bevor weitere Vorgänge an dieser Datei stattfinden können. Der alternative Datenstrom wird ebenfalls an den Ursprung weitergeleitet.
-
Das Umbenennen einer Datei führt dazu, dass die Datei aus dem Cache entfernt wird. Alle schmutzigen Daten der Datei müssen an den Ursprung übertragen werden, bevor weitere Vorgänge an dieser Datei stattfinden können.
-
Zum jetzigen Zeitpunkt können auf dem Write-Back-fähigen FlexCache Volume nur die folgenden Attribute einer Datei geändert oder festgelegt werden:
-
Zeitstempel
-
Modusbits
-
NT-ACLs
-
Eigentümer
-
Gruppe
-
Größe
Alle weiteren geänderten oder festgelegten Attribute werden an den Ursprung weitergeleitet, was dazu führen kann, dass die Datei aus dem Cache entfernt wird. Wenn weitere Attribute im Cache geändert oder festgelegt werden müssen, sollte Ihr Account-Team gebeten werden, ein PVR zu eröffnen.
-
-
Die am Ursprungsvolume erstellten Snapshots führen dazu, dass alle ausstehenden schmutzigen Daten aus jedem Write-Back-fähigen Cache, der diesem Ursprungsvolume zugeordnet ist, abgerufen werden. Dies kann mehrere Wiederholungsversuche der Operation erfordern, wenn umfangreiche Write-Back-Aktivitäten im Gange sind, da das Entfernen dieser schmutzigen Dateien einige Zeit in Anspruch nehmen kann.
-
SMB Opportunistic Locks (Oplocks) für Schreibvorgänge werden auf Write-Back-fähigen FlexCache Volumes nicht unterstützt.
-
Write-Back-Caches schalten automatisch in den Write-Around-Modus, sobald der freie Speicherplatz des Ursprungsvolumes auf 20 % oder darunter sinkt. Dies hilft zu verhindern, dass am Ursprungsvolume der Speicherplatz ausgeht, was dazu führen würde, dass schmutzige Daten in einem Write-Back-fähigen Cache verwaist zurückbleiben. Ist das Ursprungsvolume jedoch überprovisioniert, das heißt, seine logisch bereitgestellte Größe ist größer als der freie Speicherplatz im Aggregat, kann der gemeldete freie Speicherplatzanteil diesen Schwellenwert früher als erwartet auslösen. Der 20-%-Schwellenwert wird sowohl anhand des gemeldeten freien Speicherplatzes des Ursprungsvolumes als auch der verfügbaren physischen Kapazität des Aggregats bewertet.
-
Geringe Bandbreite und/oder verlustbehaftete Intercluster-Netzwerke können die FlexCache Write-Back-Performance erheblich beeinträchtigen. Obwohl es keine spezifische Bandbreitenanforderung gibt, da diese stark von Ihrer Arbeitslast abhängt, wird dringend empfohlen, auf die Stabilität der Intercluster-Verbindung zwischen Cache(s) und Ursprung zu achten.