Hybrid Cloud Storage: Datenpfade, Performance und Recovery richtig planen
 

Dieselben Komponenten, drei verschiedene Architekturen. Entscheidend ist, ob und wie der Datenpfad das WAN quert. 

Cloud als zusätzlicher Storage-Tier 

Der aktive Datenbestand liegt zunächst lokal. Abhängig von Regeln oder ihrem Zustand wandern Daten auf eine externe Ebene: Hot Data bleibt lokal, Cold Data geht in die Cloud. Eine lokale Metadaten- oder Stub-Struktur sorgt dafür, dass ausgelagerte Daten weiterhin im Namespace erscheinen. Greift jemand später darauf zu, müssen sie gegebenenfalls zurückgeholt werden. 

Aus der Kapazitätsfrage wird damit eine Frage der Data Placement Policy. Wann darf ein Datenblock oder Objekt die lokale Performance-Ebene verlassen? Das Alter einer Datei reicht als Kriterium selten aus. Letzter Zugriff, Änderungsfrequenz, Dateityp, Wiederherstellungsanforderungen und die verfügbare lokale Kapazität spielen ebenso hinein. 

Cloud als Schutz- und Recovery-Ebene 

Ein anderes Modell hält die aktiven Daten vollständig On-Premises und überträgt nur zusätzliche Kopien in die Cloud, erzeugt über Snapshots, Backups oder Replikation. Cloud Storage liegt dann nicht im normalen I/O-Pfad der Anwendung. 

Das hat eine wichtige Konsequenz. Die WAN-Latenz beeinflusst den Zugriff auf die Primärdaten nicht. Netzwerk- und Cloud-Performance werden erst relevant, sobald Daten übertragen oder wiederhergestellt werden müssen. Genau deshalb gehören RPO und RTO hier getrennt betrachtet. Ein sehr kleines RPO sagt nichts darüber aus, wie schnell mehrere hundert Terabyte nach einem Ausfall wieder produktiv bereitstehen. 

Cloud im aktiven Datenpfad 

Technisch anspruchsvoller sind Architekturen, in denen lokale Komponenten und Cloud Storage gemeinsam einen logischen Storage Service bilden. Der Client greift auf einen lokalen Cache oder Edge Filer zu, die persistente Datenbasis liegt auf einem entfernten Object Storage. Häufig genutzte Daten bleiben lokal verfügbar. 

Damit wird die lokale Komponente Bestandteil der Konsistenz- und Failure-Architektur des Gesamtsystems, nicht bloß ein Gateway. Cache-Kohärenz, Metadatenverwaltung, Locking, der Umgang mit Dirty Data, das Write-back-Verhalten, Konfliktbehandlung sowie Reconnect und Synchronisation nach WAN-Ausfällen müssen sauber definiert sein. 

Was wir in Projekten sehen 

Die drei Modelle verteilen sich in unserer Projektpraxis sehr ungleich. 

Im klassischen Enterprise-Storage-Umfeld haben wir die Cloud-Ebene nahezu ausschließlich als Schutzebene eingesetzt. Die Primärdaten bleiben im Rechenzentrum, in die Cloud gehen Kopien. Das folgt aus der Bauart dieser Systeme: Ihr Datenpfad ist auf lokale Latenz ausgelegt. Eine entfernte Ebene lässt sich daneben stellen, aber nur schwer dazwischen schieben. 

Bei Global-File-System-Projekten sieht das anders aus. Dort haben mehrere Kunden die Cloud als Bestandteil des aktiven Datenpfads genutzt. Das ist keine Frage der Vorliebe, sondern eine Folge der Architektur. Ein Global File System bringt Edge-Schicht, Cache, verteiltes Locking und globale Metadatenverwaltung von vornherein mit. Der Object Storage im Hintergrund ist dort kein nachträglich angebauter Tier, sondern die vorgesehene persistente Datenbasis. Was im ersten Modell eine Erweiterung wäre, ist hier der Normalfall. 

Das Tiering-Modell begegnet uns derzeit vor allem in Gesprächen, und der Auslöser ist selten technisch. Die deutlich gestiegenen Preise für Storage-Kapazität verschieben die Rechnung für Archivbestände, die einmal geschrieben und über Jahre kaum gelesen werden. Genau dort liegt allerdings auch die Prüffrage: Ob das Modell trägt, hängt daran, ob die Daten wirklich kalt bleiben oder ob Recalls den Zugriff regelmäßig ausbremsen.