Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

FlexCache Nutzungsfälle für die Rückschreibung

Beitragende
PDFs

Dies sind Schreibprofile, die sich am besten für eine schreibBack-fähige FlexCache eignen. Sie sollten Ihren Workload testen, um festzustellen, ob Write-Back- oder Write-Around die beste Performance bietet.

Hinweis Write-Back ist kein Ersatz für Write-Around. Obwohl Write-Back-Anwendungen mit schreibintensiven Workloads konzipiert sind, ist die Write-Around-Lösung immer noch die bessere Wahl für viele Workloads.

Ziel-Workloads

Dateigröße

Die Dateigröße ist weniger wichtig als die Anzahl der Schreibvorgänge, die zwischen dem und -Aufrufen für eine Datei ausgegeben OPEN CLOSE wurden. Kleine Dateien haben von Natur aus weniger WRITE Anrufe, wodurch sie weniger ideal für das Zurückschreiben sind. Große Dateien können mehr Schreibvorgänge zwischen und Aufrufen haben OPEN CLOSE , aber dies ist nicht garantiert.

Schreibgröße

Beim Schreiben von einem Client sind andere NAS-Anrufe außer Schreibanrufe beteiligt:

  • CREATE

  • OPEN

  • CLOSE

  • READDIR/READDIRPLUS

  • SETATTR: SETATTR Aufrufe, die nur ändern mtime, atime`oder `ctime im Cache verarbeitet werden.

Diese Aufrufe müssen am Ursprung verarbeitet werden und einen Rückschreib aller schmutzigen Daten auslösen, die im schreibrückaktivierten Cache für die Datei gesammelt werden, auf der ausgeführt wird. IO auf die Datei wird stillgelegt, bis der Schreibvorgang abgeschlossen ist.

Wenn Sie wissen, dass diese Anrufe das WAN durchlaufen müssen, können Sie Workloads identifizieren, die sich für Write-Back eignen. Im Allgemeinen gilt: Je mehr Schreibvorgänge zwischen und Anrufen erfolgen können OPEN CLOSE , ohne dass einer der anderen Anrufe von <write-size,above> ausgegeben wird, desto besser ist die Performance-Steigerung für Write-Back.

Read-after-Write

Workloads mit Lese-/Schreibzugriff hatten in der Vergangenheit bei FlexCache eine schlechte Performance. Dies ist auf den Schreibmodus vor 9.15.1 zurückzuführen. Der WRITE Aufruf der Datei muss am Ursprung erfolgen, und der nachfolgende READ Aufruf müsste die Daten zurück in den Cache verschieben. Dies führt dazu, dass beide Vorgänge die WAN-Einbußen nach sich nehmen. Daher werden für FlexCache im Write-Around-Modus von Read-after-Write-Workloads abgeraten. Mit der Einführung von Write-Back im Jahr 9.15.1 werden Daten nun im Cache gespeichert und können sofort aus dem Cache gelesen werden, wodurch die WAN-Einbußen eliminiert werden. Wenn Ihr Workload auf FlexCache Volumes Lese-nach-Schreiben beinhaltet, sollten Sie den Cache für den Write-Back-Modus konfigurieren.

Tipp Wenn Read-after-write ein wichtiger Teil Ihrer Arbeitslast ist, sollten Sie Ihren Cache so konfigurieren, dass er im Write-Back-Modus arbeitet.
Write-after-Write

Wenn eine Datei schmutzige Daten in einem Cache akkumuliert, schreibt der Cache die Daten asynchron zurück zum Ursprung. Dies führt natürlich zu Zeiten, wenn der Client die Datei mit schmutzigen Daten schließt, die noch darauf warten, wieder an den Ursprung zurückgespült zu werden. Wenn für die gerade geschlossene Datei ein weiterer offener oder ein anderer Schreibvorgang eingeht und noch schmutzige Daten enthält, wird der Schreibvorgang unterbrochen, bis alle fehlerhaften Daten auf den Ursprung übertragen wurden.

Überlegungen zur Latenz

Wenn FlexCache im Write-Back-Modus arbeitet, ist dies für NAS-Clients vorteilhafter, da sich die Latenz zwischen Cache und Ursprung erhöht. Es gibt jedoch einen Punkt, an dem der Overhead von Write-Back die Vorteile überwiegt, die in Umgebungen mit niedriger Latenz erzielt werden. In einigen NetApp-Tests führten die Vorteile bei Write-Back zu einer minimalen Latenz zwischen Cache und Ursprung von 8 ms. Diese Latenz variiert je nach Workload. Stellen Sie daher sicher, dass Sie die Vorteile Ihres Nutzens genau kennen.

Das folgende Diagramm zeigt den Rückgabepunkt für den Rückschreibvorgang in NetApp Labortests. Die x Achse ist die Dateigröße und die y Achse die verstrichene Zeit. Bei dem Test wurde NFSv3 verwendet, wobei ein und 256 KB und 64 ms WAN-Latenz gemountet rsize wsize werden. Dieser Test wurde mit einer kleinen ONTAP Select-Instanz sowohl für den Cache als auch für den Ursprungs sowie mit einem einzigen Thread-Schreibvorgang durchgeführt. Ihre Ergebnisse können variieren.

Point of Return
Wichtig Write-Back sollte nicht für Intracluster-Caching verwendet werden. Intracluster-Caching findet statt, wenn sich Ursprung und Cache im selben Cluster befinden.