Die Dateigröße ist weniger wichtig als die Anzahl der Schreibvorgänge zwischen den OPEN und CLOSE Aufrufen für eine Datei. Kleine Dateien haben naturgemäß weniger WRITE Aufrufe, was sie weniger ideal für Write-Back macht. Große Dateien können mehr Schreibvorgänge zwischen OPEN und CLOSE Aufrufen haben, dies ist jedoch nicht garantiert.

Die "FlexCache Richtlinien für Rückschreiben" Seite enthält die aktuellsten Empfehlungen zur maximalen Dateigröße.

Beim Schreiben von einem Client aus sind neben Schreibaufrufen auch andere modifizierende NAS-Aufrufe beteiligt. Dazu gehören unter anderem:

SETATTR und SET_INFO-Aufrufe, die mtime, atime, ctime, owner, group oder size setzen, werden im Cache verarbeitet. Die übrigen Aufrufe müssen am Ursprung verarbeitet werden und lösen ein Zurückschreiben aller schmutzigen Daten aus, die sich im Write-Back-fähigen Cache für die betreffende Datei angesammelt haben. Die IO zur Datei wird bis zum Abschluss des Rückschreibens angehalten.

Die Erkenntnis, dass diese Aufrufe das WAN durchlaufen müssen, hilft Ihnen, Workloads zu identifizieren, die sich für Write-Back eignen. Generell gilt: Je mehr Schreibvorgänge zwischen OPEN und CLOSE Aufrufen durchgeführt werden können, ohne dass einer der anderen oben genannten Aufrufe erfolgt, desto größer ist der Leistungsgewinn durch Write-Back.

Lese-nach-Schreib-Workloads wiesen in der Vergangenheit bei FlexCache eine schlechte Performance auf. Dies ist auf den Write-Around-Betriebsmodus vor 9.15.1 zurückzuführen. Der WRITE Aufruf der Datei musste am Ursprung abgeschlossen werden, und der nachfolgende READ Aufruf musste die Daten zurück in den Cache holen. Dadurch fielen bei beiden Operationen die Latenzen des WAN an. Daher sind Lese-nach-Schreib-Workloads für FlexCache im Write-Around-Modus nicht empfohlen. Mit der Einführung von Write-Back in 9.15.1 werden Daten nun im Cache gespeichert und können sofort aus dem Cache gelesen werden, wodurch die WAN-Latenz entfällt. Wenn der Workload Lese-nach-Schreib-Operationen auf FlexCache Volumes umfasst, sollte der Cache für den Write-Back-Modus konfiguriert werden.

Wenn sich schmutzige Daten in einem Cache in einer Datei ansammeln, schreibt der Cache diese Daten asynchron zurück an den Ursprung. Dies führt dazu, dass der Client die Datei schließt, während schmutzige Daten noch darauf warten, an den Ursprung zurückgeschrieben zu werden. Wenn ein weiterer Öffnungs- oder Schreibvorgang für die gerade geschlossene Datei erfolgt, die noch schmutzige Daten enthält, wird der Schreibvorgang ausgesetzt, bis alle schmutzigen Daten an den Ursprung zurückgeschrieben wurden.

Wenn FlexCache im Write-Back-Betriebsmodus arbeitet, profitieren NAS-Clients mit zunehmender Latenz stärker. Es gibt jedoch einen Punkt, an dem der Overhead des Write-Back die in Umgebungen mit niedriger Latenz gewonnenen Vorteile überwiegt. In einigen NetApp Tests traten die Vorteile des Write-Back ab einer minimalen Latenz zwischen Cache und Ursprung von etwa 8 ms auf. Diese Latenz variiert je nach Arbeitslast, daher empfiehlt sich ein Test, um den optimalen Wendepunkt für die eigene Arbeitslast zu bestimmen.

Die folgende Grafik zeigt den Zeitpunkt des Rückschreibens in NetApp Labortests. Die x-Achse stellt die Dateigröße dar, die y-Achse die verstrichene Zeit. Der Test wurde mit NFSv3 durchgeführt, wobei eine Mount- rsize und wsize von 256 KB sowie eine WAN-Latenz von 64 ms verwendet wurden. Für Cache und Ursprung wurde eine kleine ONTAP Select Instanz verwendet, und es kam ein einzelner Schreibvorgang mit einem Thread zum Einsatz. Die Ergebnisse können variieren.