Inhaltsverzeichnis

Der lokale Cache ist die Komponente, die über die wahrgenommene Performance des gesamten Systems entscheidet. 

Dateien, die physisch im Cache vorhanden sind, werden lokal bereitgestellt, und der Zugriff bleibt im LAN. Dateien, die nur als Stub vorliegen, müssen über das WAN aus dem zentralen Storage geladen werden; erst dann werden Bandbreite und Latenz relevant. Ein Global File System beseitigt die Physik eines WAN also nicht. Es verändert die Wahrscheinlichkeit, mit der ein Benutzer für seine tägliche Arbeit überhaupt über das WAN auf Nutzdaten zugreifen muss. 

Warum ein Prozentwert nicht trägt 

Eine häufige Planungsfrage lautet, wie groß der Edge Cache sein muss. Eine pauschale Antwort wie zehn Prozent des gesamten Datenbestands ist dafür nicht belastbar. 

Relevant ist das Working Set eines Standorts, also die dort tatsächlich regelmäßig verwendeten Daten. Ein Standort kann auf einen logischen Bestand von 200 TB zugreifen, davon aber nur einen kleinen Teil aktiv bearbeiten, während ein anderer Standort bei gleichem Gesamtbestand regelmäßig auf einen erheblich größeren Anteil zugreift. Zusätzlich beeinflussen die aktive Datenmenge, Anzahl und Arbeitsweise der Benutzer, Dateigrößen, Änderungsrate, gepinnte Ordner, Neudatenaufkommen, eingesetzte Anwendungen und zeitliche Zugriffsmuster das erforderliche Cache-Volumen. 

CTERA stellt für die Planung Discovery-Funktionen bereit. Ein Edge Filer kann ohne Lizenz und ohne Datenplatte installiert und für einen Discovery-Job gegen den abzulösenden Fileserver eingesetzt werden. Der Bericht enthält Shares mit Anzahl Ordner, Anzahl Dateien und Größe sowie Auswertungen zu letztem Zugriff, letzter Änderung und Dateitypen jeweils nach Anzahl und Volumen; für eine Aufschlüsselung je Share ist allerdings eine Datenplatte erforderlich. 

Der entscheidende Architekturparameter lautet damit nicht, wie groß der gesamte Share ist, sondern wie groß und wie dynamisch das Working Set des jeweiligen Standorts ist. 

Warum wir die Prozentregel aufgegeben haben 

In frühen Projekten haben wir Cache-Sizing teilweise anhand von Erfahrungswerten vorgenommen. Eine Größenordnung von ungefähr zehn Prozent des Shares beziehungsweise eine Orientierung an der regelmäßig aktiven Datenmenge konnte als Ausgangspunkt dienen, funktioniert aber ausdrücklich nicht für jede Umgebung, und in einzelnen Projekten mussten wir nachjustieren. 

Seit der Nutzung der Discovery-Funktionen lässt sich das tatsächliche Datenprofil vor der Migration wesentlich besser erfassen. Aus unserer Erfahrung ist damit eine deutlich belastbarere Dimensionierung möglich als mit einer statischen Prozentregel. 

Eviction entfernt Inhalte, nicht Dateien 

Ein Cache benötigt einen Mechanismus, der entscheidet, welche Daten lokal verbleiben. CTERA verwendet dafür Watermarks: Die Eviction beginnt, wenn die Speicherbelegung den High Watermark von 75 Prozent des gesamten Edge-Filer-Speichers erreicht, und entfernt Dateiinhalte, bis der Low Watermark von 65 Prozent erreicht ist. Zurück bleibt jeweils der Stub. Die Auswahl erfolgt dabei nach Tagen seit dem letzten Zugriff und nicht nach Dateigröße; innerhalb einer Gruppe wird nicht weiter nach Zugriffsalter differenziert. 

Drei Kategorien werden nie evicted: Dateien in als pinned markierten Ordnern, aktuell geöffnete Dateien und – dieser Punkt wird häufig übersehen – Dateien, die noch nicht zum Portal synchronisiert wurden. Damit ist der Zusammenhang zwischen Cache-Auslastung und Synchronisationszustand kein Zufall, sondern Mechanik: Ein Standort mit hohem Neudatenaufkommen und langsamer oder gestörter Synchronisation akkumuliert nicht evictierbare Daten im Cache. 

CTERA reserviert für Schreib-Bursts 25 Prozent des Speichers. Wird der freie Speicher trotzdem zu knapp, greift Throttling, sodass Benutzer weiterschreiben können, die Schreibgeschwindigkeit des Clients aber auf WAN-Geschwindigkeit reduziert wird, damit nicht schneller geschrieben als in die Cloud ausgelagert wird. CTERA bezeichnet dieses Szenario als unüblich, mit zwei Ausnahmen: der Migration großer Datenmengen und sehr starken Schreib-Bursts. 

Technisch wichtig ist dabei, dass die Eviction die persistente Datei nicht aus dem Global File System löscht, sondern lediglich deren lokalen Cache-Zustand verändert. Der Edge Filer ist damit ein dynamisch verwalteter lokaler Arbeitsbereich vor einem wesentlich größeren persistenten Datenbestand. 

Thrashing ist die aussagekräftigere Metrik als die Hit Rate 

Für den laufenden Betrieb stellt CTERA eine Cache-Hit-Statistik bereit, die drei Zustände unterscheidet: einen Hit, wenn die Datei aus dem Cache bedient wurde; einen Miss, wenn ein Stub heruntergeladen werden musste und die Datei zuvor mindestens 24 Stunden nicht zugegriffen wurde; und Thrashing, wenn ein Stub heruntergeladen werden musste, der weniger als 24 Stunden zuvor noch im Cache lag. 

Thrashing bedeutet also, dass kürzlich evictierte Dateien erneut benötigt werden, und ist damit die direkte Messgröße für ein zu klein dimensioniertes Working Set. Für die Bewertung einer Umgebung ist dieser Wert deutlich aussagekräftiger als die Hit Rate allein, weil eine hohe Hit Rate eine dauerhafte Verdrängung des aktiven Arbeitsbestands verdecken kann. 

Aus unserer Erfahrung kommt ein vollständig ausgelasteter Edge Filer in produktiven Umgebungen vor, allerdings vergleichsweise selten. Das Thema bleibt trotzdem relevant, weil Cache-Auslastung, gepinnte Daten und noch nicht synchronisierte lokale Änderungen gemeinsam betrachtet werden müssen. Cache-Monitoring gehört deshalb zum laufenden Betrieb und ist keine einmalige Sizing-Aufgabe bei der Installation. 

Arbeiten bei WAN-Ausfall 

Die Konsequenz dieser Cache-Mechanik zeigt sich am deutlichsten, wenn die WAN-Verbindung ausfällt. Ein zentraler Fileserver, der ausschließlich remote erreichbar ist, wird mit dem WAN-Ausfall für den Standort unerreichbar. Bei einem Edge Filer befindet sich dagegen ein Teil des Datenbestands lokal und kann weiterhin lokal verarbeitet werden, wobei die Einschränkung offensichtlich ist: Daten, die nur als Stub vorliegen, können ohne funktionierenden Datenpfad nicht nachgeladen werden. 

Unsere Beobachtung aus produktiven Umgebungen ist hier pragmatisch. Solange ein Benutzer während des Ausfalls keine bisher nicht lokal verfügbaren Daten benötigt, bemerkt er beim normalen Arbeiten unter Umständen keinen unmittelbaren Unterschied. 

Das ist keine vollständige Standortautarkie, sondern Working-Set-Autarkie. Ein Edge Filer macht nicht den gesamten globalen Datenbestand WAN-unabhängig, sondern den lokal vorhandenen Arbeitsbestand. Damit ist Cache-Sizing gleichzeitig eine Resilience-Entscheidung: Die Frage, wie viel Cache ein Standort erhält, ist identisch mit der Frage, wie lange und wie vollständig dieser Standort bei einem WAN-Ausfall weiterarbeiten kann.