Cloud Storage: Die Mobilität von Containerdaten gewährleisten
Datenmobilität ist bei Container-, Hybrid- und Multi-Cloud-Infrastrukturen unerlässlich. Ein Data-Plane-Framework und Datenabstraktion können App und Datenmobilität sicherstellen.
In der heutigen Cloud-Welt nutzen IT-Unternehmen Hybrid- und Multi-Clouds in ihrem gesamten Unternehmen. Aus der Sicht von Containern wissen wir, dass Anwendungsmobilität, Flexibilität und Effizienz von Anfang an integriert sind. Aber wie sieht es mit der Mobilität der Containerdaten aus? Wie kann man ein Daten-Framework aufbauen, das die Public Cloud optimiert und eine echte Mobilität für Anwendungen und deren Daten ermöglicht?
Container und Block Storage
Die Popularität von Containern ergibt sich aus der Einführung von Docker, welches Frameworks von Containerlaufzeiten, Anwendungsbibliotheken und Multi-Node (Server)-Konfigurationen einführten. Docker wurde schnell von Kubernetes, der Open-Source-Containerplattform von Google, übernommen.
Beide Plattformen verwenden blockbasierten Speicher, um die Persistenz der Containerdaten zu gewährleisten. Ursprünglich wurde davon ausgegangen, dass Container zustandslos sein würden, indem Anwendungsreplikation und Redundanz genutzt wurden, um den Zugriff auf persistente Daten zu erhalten. Dies erwies sich als unpraktisch, und es wird akzeptiert, dass eine Form persistenten Speichers erforderlich ist, selbst für einen kurzlebigen Container.
Block Storage ist schnell und bietet Anwendungen eine geringe Latenzzeit. Bei Container-Deployments wird ein Block-System mit einem lokalen Dateisystem formatiert und in einen Container gemappt. Je nach Nutzungsanforderung kann der Block Device die Lebensdauer des Containers überstehen oder nur während des Betriebs des Containers verwendet werden.
Wenn sich eine Anwendungsaufgabe in einem Container neustarten lässt, dann muss der Blockspeicher nicht mehr bieten als eine skalierbare, schnelle Speicherung der Containerdaten. Unter Neustart verstehen wir, dass die Anwendungskomponente mit einem frisch formatierten leeren Block-System instanziiert werden kann.
Wenn wir jedoch diese einfachen Grenzen überschreiten, muss die Speicherung mehr bieten. Wenn ein Container beispielsweise aufgrund eines Hardware- oder Softwarefehlers neu gestartet werden muss, kann es sinnvoll sein, die Daten auf einem vorhandenen Blockspeicher wiederzuverwenden, anstatt sie aus einer anderen Quelle neu zu erstellen.
Wenn ein Teil einer Anwendung an einen anderen physischen Ort verschoben werden muss, müssen möglicherweise auch die Containerdaten verschoben werden.
Aufbau eines Data-Plane-Frameworks
Um die Mobilität von Daten und Anwendungen zu erreichen, müssen wir einen Rahmen für die Datenebene schaffen, ein so genanntes Data-Plane-Framework. Daten überdauern jeden einzelnen Container und müssen über mehrere Rechenzentren und Standorte hinweg mobil sein. Dies kann bedeuten, dass man Informationen zwischen Public Clouds und lokalen Standorten bewegen muss. Ein gutes Beispiel ist die Anforderung, Daten in die Public Cloud zu replizieren, um Test- und Entwicklungsumgebungen zu starten.
Object Storage ist eine von vielen Möglichkeiten, ein solches Daten-Framework aufzubauen. Es ist von Natur aus mobil und über WANs mit dem HTTP(S)-Protokoll zugänglich.
Eine weitere Herausforderung für lokale Blockspeicher besteht darin, dass diese Systeme nur mit lokalen Containern oder virtuellen Instanzen verbunden werden können.
Objektspeicher bieten die Möglichkeit, sich über Entfernungen zu replizieren und können leicht plattformübergreifend arbeiten. Die Hauptherausforderungen für Object Storage liegen in der Implementierung einer guten Sicherheit und der Zuordnung von Daten zu einer Anwendungshierarchie, zum Beispiel durch die Verwendung von Buckets und Ordnern, um Anwendungsnamen zu mappen.
Das Hinzufügen von Block- und Dateispeicher zu einem Container-Framework ist komplexer. Blockspeicher haben eine geringere Latenz und einen höheren Durchsatz als Dateispeicher, aber das ist nicht mehr der Fall. Mit neuen Medien wie NVMe bauen Start-ups leistungsstarke, skalierbare Dateisysteme auf, die sowohl in lokalen Standorten als auch in Public Clouds funktionieren.
Eine weitere Herausforderung für lokale Blockspeicher, wie beispielsweise die Elastic Compute Cloud von AWS, besteht darin, dass diese Systeme nur mit lokalen Containern oder virtuellen Instanzen verbunden werden können. Es gibt keine direkte Möglichkeit, Blockspeicher innerhalb der Public Cloud zu einem anderen Anbieter oder vor Ort zu replizieren.
Datenabstraktion
Wenn die Datenportabilität unerlässlich ist, dann ist es am besten, eine unabhängige Datenebene (Data Plane) aufzubauen, die nicht auf den nativen Speicher des Public-Cloud-Anbieters angewiesen ist. Es gibt Produkte, die eine Skalierung der Block- und Dateispeicher ermöglichen, entweder über einzelne oder mehrere geografische Standorte hinweg. Dazu gehört auch die Zusammenführung von Public und Private Clouds.
Einige Scale-Out-Produkte können eine einzige Ansicht der Daten über mehrere Standorte hinweg darstellen, während andere Snapshots zur Datenreplikation verwenden. Das bedeutet, dass Daten kopiert werden und Prozesse vorhanden sind, um sicherzustellen, dass die neueste Kopie verfolgt und verwaltet werden kann. Bei der Bereitstellung von Daten in einem weiten Bereich wird es zu Problemen mit der Latenz kommen.
Die Rolle der APIs und die verbleibenden Herausforderungen
Entwickler von Ökosystemen haben damit begonnen, APIs für Storage hinzuzufügen. Kubernetes verfügt über das Container Storage Interface (CSI), das eine Reihe von Funktionen zum Erstellen und Anhängen von Volumes an Container bereitstellt. CSI stellt sicher, dass der Speicher erfolgreich auf Container innerhalb von Pods abgebildet wird, die auf mehreren physischen Servern bereitgestellt werden können.
Docker verwendet Volume Plug-Ins, um die gleiche Funktionalität wie CSI zu erreichen. Benutzer können dann Volume-Treiber von Speicherhardware und -software bereitstellen, die sicherstellen, dass die Daten vom Speicher bis zum Container korrekt zugeordnet werden.
Die Herausforderungen bleiben bestehen, wenn es um die Speicherung von Containerdaten und mehrere Containerimplementierungen sowie um die nahtlose Datenmigration zwischen den Plattformen geht. AWS Fargate unterstützt beispielsweise keine anderen externen Volumes als die von Elastic Cloud Compute. Der Aufbau einer echten Multi-Cloud-Containerumgebung bedeutet derzeit, dass maßgeschneiderte Container-Builds anstelle von nativen Cloud-Funktionen verwendet werden.
