Inhaltsverzeichnis

Dies ist eines der stärksten technischen Argumente für eine Edge-basierte Architektur. Ein Unternehmen besitzt einen sehr großen gemeinsamen Datenbestand, ein einzelner Standort arbeitet aber regelmäßig nur mit einem Teil davon. Der Standort muss deshalb nicht den gesamten globalen Datenbestand physisch vorhalten. Stattdessen kann der vollständige Namespace sichtbar sein, während nur aktive Daten lokal gespeichert werden und weniger häufig benötigte Inhalte auf dem zentralen Storage verbleiben. 

Dieses Prinzip ist nicht auf einen einzelnen Hersteller beschränkt. Microsoft beschreibt bei Azure File Sync die Trennung von lokal vorhandenem Namespace und ausgelagerten Dateiinhalten, wobei häufig verwendete Dateien lokal gehalten werden. CTERA beschreibt für seine Implementierung ein vergleichbares Modell: Ein Stub enthält nur die Metadaten einer Datei — Name, Größe, Änderungsdatum — während der eigentliche Inhalt zentral liegt. Der Edge Filer kann dadurch deutlich weniger physischen Speicher besitzen, als den Benutzern an Kapazität sichtbar zur Verfügung steht. 

Das Verhältnis von lokalem Working Set zum globalen Datenbestand wird damit zur zentralen Planungsgröße. Je kleiner das regelmäßig benötigte Working Set gegenüber dem Gesamtbestand ist, desto stärker lässt sich die physische Speicherkapazität am Standort von der Größe des globalen Datenbestands entkoppeln. 

Warum Cache-Sizing sich am Zugriff orientieren muss 

Aus diesem Architekturprinzip folgt unmittelbar ein Problem: Ein zu kleiner Cache führt dazu, dass häufig benötigte Dateien nicht lokal vorliegen und die Zahl der Recalls aus dem zentralen Storage steigt. Microsoft benennt diese Konsequenz explizit — enthält der lokale Cache nur einen kleinen Teil des Arbeitsdatenbestands, treten häufiger Recalls auf, was die Zugriffslatenz erhöht und zusätzliche Transaktions- und Datentransferkosten verursachen kann. Empfohlen wird deshalb, nach dem Setzen der Policies den Egress zu beobachten, insbesondere über die Metriken zur Recall-Größe und die Cache Hit Rate des jeweiligen Server-Endpunkts. 

An dieser Stelle ist eine Unterscheidung wichtig, die in Projekten regelmäßig verwischt wird. Microsoft nennt durchaus einenStartwert und empfiehlt, das Cloud Tiering zunächst mit deaktivierter Date Policy und einer Volume Free Space Policy von etwa 10 bis 20 Prozent zu betreiben, wobei 20 Prozent für die meisten Fileserver-Volumes als beste Wahl gelten. Dieser Wert beschreibt jedoch den freizuhaltenden Anteil des lokalen Volumes — nicht den Anteil des Caches am globalen Datenbestand. Eine daraus abgeleitete Faustregel wie „der Cache muss zehn Prozent des Gesamtdatenbestands betragen" ist technisch nicht belastbar, weil sie eine lokale Volume-Reserve mit einer globalen Kapazitätsrelation verwechselt. 

Zwei Standorte mit jeweils 500 TB sichtbarem Datenbestand können völlig unterschiedliche Cache-Anforderungen besitzen. Arbeitet Standort A regelmäßig mit 20 TB und Standort B mit 150 TB, führt dieselbe Prozentregel an einem der beiden Standorte zwangsläufig zu einer Fehldimensionierung. Für das Sizing sind daher nicht die Größe des globalen Datenbestands maßgeblich, sondern: 

aktives Datenvolumen, 

Änderungshäufigkeit, 

Zugriffsverteilung, 

Dateigrößen, 

Anzahl gleichzeitiger Benutzer, 

zwingend lokal verfügbare Daten, 

WAN-Bandbreite und WAN-Latenz. 

Bemerkenswert ist in diesem Zusammenhang, dass Prozentangaben auch von Herstellerseite verbreitet werden — CTERA wirbt etwa damit, dass Edge Filer nur rund 20 Prozent der aktiven Daten cachen. Als Größenordnung für einen typischen Fall mag das zutreffen. Als Sizing-Grundlage für einen konkreten Standort ersetzt es keine Analyse des tatsächlichen Zugriffsverhaltens. 

Unsere Projekterfahrung: Cache nach Nutzung dimensionieren 

In den von uns begleiteten Global-File-System-Projekten hat sich genau dieser Punkt als kritisch erwiesen. Eine einfache prozentuale Ableitung des Edge-Caches aus dem gesamten Datenbestand war nicht für alle Standorte ausreichend präzise; je nach tatsächlichem Zugriffsmuster mussten wir die Dimensionierung nachträglich anpassen. Mit Werkzeugen zur Analyse des realen Datenzugriffs lässt sich das lokale Working Set inzwischen deutlich besser abschätzen. 

Für die Architekturentscheidung bedeutet das: Der globale Datenbestand bestimmt, wie viel Storage zentral benötigt wird. Das lokale Nutzungsverhalten bestimmt, wie viel Cache am jeweiligen Standort benötigt wird. Diese beiden Größen sollten nicht miteinander verwechselt werden.