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

ONTAP FlexCache Write-Back-Architektur

07/23/2026 Beitragende

PDFs

FlexCache wurde mit starker Konsistenz im Sinn entwickelt, einschließlich beider Modi des Schreibvorgangs: Write-Back und Write-Around. Sowohl der traditionelle Write-Around Betriebsmodus als auch der neue Write-Back Betriebsmodus, der in ONTAP 9.15.1 eingeführt wurde, gewährleisten, dass die abgerufenen Daten stets zu 100 % konsistent, aktuell und kohärent sind.

Die folgenden Konzepte erläutern, wie das FlexCache Write-Back funktioniert.

Delegationen

Sperrdelegierungen und Datendelegierungen helfen FlexCache, sowohl Write-Back- als auch Write-Around-Caches konsistent, kohärent und aktuell zu halten. Der Ursprung orchestriert beide Delegierungen.

Sperrdelegationen

Eine Sperrdelegierung ist eine Sperrberechtigung auf Protokollebene, die der Ursprungsserver einem Cache pro Datei erteilt, um bei Bedarf Protokollsperren an Clients auszugeben. Dazu gehören exklusive Lock-Delegationen (XLD) und Shared Lock Delegations (SLD).

XLD und Rückschreiben

Um zu gewährleisten, dass ONTAP niemals einen widersprüchlichen Schreibvorgang abgleichen muss, wird einem Cache, bei dem ein Client das Schreiben einer Datei anfordert, ein XLD zugewiesen. Wichtig ist, dass für jede Datei zu jedem Zeitpunkt nur ein XLD existieren kann, was bedeutet, dass nie mehr als ein Schreibvorgang gleichzeitig auf eine Datei erfolgt.

Wenn eine Anfrage zum Schreiben in eine Datei in einem Write-Back-fähigen Cache eingeht, erfolgen die folgenden Schritte:

Der Cache prüft, ob bereits eine XLD für die angeforderte Datei vorhanden ist. Ist dies der Fall, wird dem Client das Schreibsperre erteilt, solange kein anderer Client im Cache auf die Datei schreibt. Falls der Cache keine XLD für die angeforderte Datei hat, wird eine vom Ursprung angefordert. Dies ist ein proprietärer Aufruf, der das Intercluster-Netzwerk durchläuft.
Nach Erhalt der XLD-Anfrage aus dem Cache prüft der Origin, ob für die Datei in einem anderen Cache bereits eine ausstehende XLD vorhanden ist. Falls ja, wird die XLD dieser Datei zurückgerufen, was einen Flush aller schmutzige Daten aus diesem Cache zurück zum Origin auslöst.
Sobald die schmutzigen Daten aus diesem Cache zurückgeschrieben und im stabilen Speicher am Ursprung gespeichert sind, erteilt der Ursprung dem anfragenden Cache die XLD für die Datei.
Sobald die XLD der Datei empfangen wurde, gewährt der Cache dem Client die Sperre und der Schreibvorgang beginnt.

Ein übergeordnetes Sequenzdiagramm, das einige dieser Schritte abdeckt, ist im Write-Back Sequence Diagramm enthalten.

Aus Kundensicht funktioniert die Sperrung so, als ob auf ein Standard FlexVol oder FlexGroup geschrieben würde, mit einer möglichen kleinen Verzögerung, wenn die Schreibsperre angefordert wird.

In der aktuellen Version blockiert ONTAP jeden Zugriff auf eine Datei in anderen Caches, einschließlich READ-Operationen, wenn ein Write-Back-fähiger Cache das XLD für eine Datei hält.

Es gilt eine Obergrenze von 170 XLDs pro Herkunftsbestandteil.

Datendelegierungen

Eine Datendelegierung ist eine dateibezogene Garantie, die dem Cache vom Ursprung gegeben wird, dass die für diese Datei zwischengespeicherten Daten aktuell sind. Solange der Cache über eine Datendelegierung für eine Datei verfügt, kann er dem Client die zwischengespeicherten Daten dieser Datei bereitstellen, ohne den Ursprung kontaktieren zu müssen. Verfügt der Cache nicht über eine Datendelegierung für die Datei, muss er den Ursprung kontaktieren, um die vom Client angeforderten Daten zu erhalten.

Im Write-Back-Modus wird die Datendelegierung einer Datei widerrufen, wenn ein XLD für diese Datei in einem anderen Cache oder am Ursprung vorgenommen wird. Dadurch wird die Datei effektiv für Clients in allen anderen Caches und am Ursprung gesperrt, selbst für Lesezugriffe. Dies ist ein notwendiger Kompromiss, um sicherzustellen, dass niemals auf alte Daten zugegriffen wird.

Lesevorgänge in einem Write-Back-fähigen Cache verhalten sich im Allgemeinen wie Lesevorgänge in einem Write-Around-Cache. Sowohl bei Write-Around- als auch bei Write-Back-fähigen Caches kann es zu einem anfänglichen READ Leistungsverlust kommen, wenn die angeforderte Datei in einem anderen Write-Back-fähigen Cache als dem, in dem der Lesevorgang ausgelöst wurde, eine exklusive Schreibsperre besitzt. Die XLD muss aufgehoben und die schmutzigen Daten müssen an den Ursprung übertragen werden, bevor der Lesevorgang im anderen Cache bedient werden kann.

Verfolgung schmutziger Daten

Das Zurückschreiben vom Cache zum Ursprung erfolgt asynchron. Das bedeutet, dass schmutzige Daten nicht sofort zum Ursprung zurückgeschrieben werden. ONTAP verwendet ein schmutzige Daten Record System, um schmutzige Daten pro Datei zu verfolgen. Jeder schmutzige Daten Record (DDR) repräsentiert ungefähr 20 MB schmutzige Daten für eine bestimmte Datei. Wenn eine Datei aktiv beschrieben wird, beginnt ONTAP mit dem Zurückschreiben schmutziger Daten, nachdem zwei DDRs gefüllt wurden und der dritte DDR beschrieben wird. Dadurch verbleiben während des Schreibvorgangs etwa 40 MB schmutzige Daten im Cache. Bei zustandsbehafteten Protokollen (NFSv4.x, SMB) werden die verbleibenden 40 MB Daten beim Schließen der Datei zum Ursprung zurückgeschrieben. Bei zustandslosen Protokollen (NFSv3) werden die 40 MB Daten zurückgeschrieben, wenn entweder der Zugriff auf die Datei über einen anderen Cache erfolgt oder nachdem die Datei zwei oder mehr Minuten inaktiv war, maximal jedoch fünf Minuten. Weitere Informationen zum zeit- oder speichergesteuerten Zurückschreiben schmutziger Daten finden sich unter Cache-Scrubber.

Zusätzlich zu den DDRs und Scrubbern lösen einige Frontend-NAS-Operationen auch das Leeren aller schmutzigen Daten einer Datei aus:

SETATTR
- SETATTR-Anweisungen, die nur mtime, atime und/oder ctime ändern, können im Cache verarbeitet werden, wodurch die Belastung durch das WAN vermieden wird.
CLOSE
OPEN an einem anderen Cache
READ an einem anderen Cache
READDIR an einem anderen Cache
READDIRPLUS an einem anderen Cache
WRITE an einem anderen Cache

Getrennter Modus

Wenn ein XLD für eine Datei in einem Write-Around-Cache gehalten wird und dieser Cache die Verbindung zum Ursprung verliert, sind Lesezugriffe auf diese Datei in den anderen Caches und am Ursprung weiterhin erlaubt. Dieses Verhalten unterscheidet sich, wenn ein XLD von einem Write-Back-fähigen Cache gehalten wird. In diesem Fall führen Lesezugriffe auf die Datei überall zu einem Hängenbleiben, wenn der Cache die Verbindung verliert. Dadurch wird sichergestellt, dass vollständige Konsistenz, Aktualität und Kohärenz erhalten bleiben. Im Write-Around-Betriebsmodus sind Lesezugriffe erlaubt, da beim Ursprung garantiert alle Daten verfügbar sind, die dem Client als geschrieben bestätigt wurden. Im Write-Back-Betriebsmodus kann der Ursprung bei einer Trennung nicht garantieren, dass alle Daten, die an den Write-Back-fähigen Cache geschrieben und von diesem bestätigt wurden, vor der Trennung den Ursprung erreicht haben.

Falls ein Cache mit einer XLD-Berechtigung für eine Datei über einen längeren Zeitraum getrennt ist, kann ein Systemadministrator die XLD-Berechtigung am Ursprung manuell widerrufen. Dadurch kann die IO auf die Datei in den verbleibenden Caches und am Ursprung fortgesetzt werden.

Das manuelle Widerrufen der XLD führt zum Verlust aller schmutzigen Daten der Datei im getrennten Cache. Das manuelle Widerrufen einer XLD sollte nur im Falle einer schwerwiegenden Unterbrechung zwischen Cache und Origin erfolgen.

Cache-Scrubber

Es gibt Scrubber in ONTAP, die bei bestimmten Ereignissen ausgeführt werden, beispielsweise wenn ein Timer abläuft oder Speicherplatzgrenzen überschritten werden. Die Scrubber nehmen eine exklusive Sperre auf die zu bereinigende Datei und frieren so die IO für diese Datei ein, bis der Scrub abgeschlossen ist.

Zu den Scrubbern gehören:

Änderungszeitbasierter Scrubber im Cache: Dieser Scrubber startet alle fünf Minuten und überprüft alle Dateien, die zwei Minuten lang unverändert im Cache liegen. Befinden sich noch schmutzige Daten für die Datei im Cache, wird die IO zu dieser Datei angehalten und ein Write-Back ausgelöst. Die IO wird fortgesetzt, nachdem das Write-Back abgeschlossen ist.
Änderungszeitbasierter Scrubber auf dem Ursprungsserver: Ähnlich dem änderungszeitbasierten Scrubber im Cache wird auch dieser alle fünf Minuten ausgeführt. Er bereinigt jedoch alle Dateien, die 15 Minuten lang unverändert geblieben sind, wobei die Delegierung des Inodes zurückgerufen wird. Dieser Scrubber initiiert keinen Schreibvorgang.
RW-Limit-basierter Scrubber am Ursprung: ONTAP überwacht, wie viele RW-Sperrdelegierungen pro Ursprungskomponente vergeben werden. Überschreitet diese Zahl 170, beginnt ONTAP mit der Bereinigung von Schreibsperrdelegierungen nach dem Least-Recently-Used-Prinzip (LRU).
Speicherbasierte Bereinigung auf dem Cache: Wenn ein FlexCache Volume zu 90 % gefüllt ist, wird der Cache bereinigt, wobei Elemente nach dem LRU-Prinzip entfernt werden.
Speicherbasierter Scrubber auf dem Ursprungsvolume: Wenn ein FlexCache Ursprungsvolume zu 90 % gefüllt ist, wird der Cache bereinigt, wobei die Elemente nach dem LRU-Prinzip entfernt werden.

Sequenzdiagramme

Diese Sequenzdiagramme veranschaulichen den Unterschied bei den Schreibbestätigungen zwischen Write-Around und Write-Back Modus.

Write-around

FlexCache Write-Around-Sequenzdiagramm

Write-Back

FlexCache Write-Back-Sequenzdiagramm