Storage
An Containern führt kein Weg vorbei
Fortsetzung des Artikels von Teil 1
Shared Storage für Applikations-Container
Mit einem verteilten Filesystem, das Speichergrößen im Petabereich unterstützt, lassen sich gemeinsam genutzte Daten oder auch Konfigurationsdaten für Stateful Container bereitstellen. In einem solchen Fall kommt es den Applikationen nicht auf einen isolierten Datenspeicher an. Sie benötigen vielmehr ein Shared Persistent Filesystem zur Speicherung und gemeinsamen Nutzung der Daten durch mehrere, auf verschiedenen Hosts verteilte Applikations-Container. Weit verbreitet sind Implementierungsmodelle, bei denen große Datenmengen von mehreren Clients beziehungsweise Tenants gemeinsam verwendet werden wie zum Beispiel zur Datenanalyse.
Einige Applikationen benötigen jedoch eine Datenisolierung oder nur eine geringe Speicherkapazität für individuelle Applikations-Container. In diesem Fall kann eine Storagelösung auch Block Devices über ein Cluster-Orchestrierungs-Framework wie Kubernetes bereitstellen. Zudem lässt sich die weit verbreitete S3-Storage-API für Object Storage und den Zugriff auf persistenten Speicher in Applikations-Containern einsetzen. In konventionellen Implementierungen, bei denen Applikations-Container auf eigens dafür optimierten Infrastrukturplattformen laufen, kommen zum Zugriff auf Storage Cluster oder Storage Appliances Protokolle und Schnittstelen wie NFS, iSCSI oder Fibre Channel zu Einsatz. Storage wird dabei im File- oder Block-Format bereitgestellt. Storage Appliances stehen im deutlichen Gegensatz zum dynamischen Ansatz von Containern. Mit traditionellen Storage-Lösungen geht es meist nicht so leicht, schnell einmal ein paar zusätzliche Storage-Einschübe hinzufügen, um eine neue Multi-Tier-Anwendung zu testen. Eine Software-basierte Storage Lösung hat hier erhebliche Vorteile.
Storage-Container und Hyperkonvergenz
Der Wechsel auf Microservices-getriebene Architekturen wird auch die Art der Bereitstellung von Storage ändern. Je stärker sich Microservices durchsetzen, desto wichtiger wird die zentrale Verwaltung von persistentem Storage über eine einheitliche Steuerebene (Control Plane). Dies bedeutet, dass die Storage-Plattform selbst containerisiert wird – Storage steht dann als Microservice über dedizierte Storage-Container bereit. In einem künftigen Szenario könnten dann beispielsweise in OpenShift, einer Open-Source-Container-Applikationsplattform, neben Applikations-Containern auch Storage-Container bereitstehen, die über das Open-Source-Orchestrierungs-Framework Kubernetes verwaltet werden. Container-Images für Storage-Container stehen bereits jetzt als Tech-Previews zur Verfügung. Als hyperkonvergentes Konstrukt können Kubernetes-Knoten Storage- und Applikations-Container ausführen. Storage-Container könnten dann zum Beispiel als Gluster Storage Bricks implementiert werden, aus denen zusammen genommen ein hochverfügbares GlusterFS Volume entsteht. Über dieses Volume lassen sich dann die Storage-Anforderungen einzelner Server-Knoten bedienen. Anders ausgedrückt besteht dann kein Bedarf mehr für dedizierte Storage-Hardware. Auf dem gleichen Knoten, auf dem eine Infrastrukturplattform für den Betrieb von Applikations-Containern läuft, können auch Storage-Container implementiert werden. Als Speicherkapazitäten werden die jeweils in den Applikations-Servern verbauten Festplatten beziehungsweise die SSDs genutzt und nach dem Scale-Out-Ansatz in einem Pool gesteuert. Es wird ein kompletter Storage-Layer eingespart und die Storageschicht wird – zumindest teilweise – von Kubernetes mitverwaltet.
Abhängig von der Systemkonfiguration können in diesem Szenario einige Container als reine Storage-Container, einige als Applikations-Container und ein dritte Gruppe als hyperkonvergente Storage- und Applikations-Container laufen. Über das Orchestrierungs-Framework Kubernetes lassen sich bei Bedarf zusätzliche Storage-Container starten oder nach dem Ausfall eines Knotens automatisch wieder herstellen. In Spitzenzeiten aktiviert ein Administrator weitere containerisierte Server-Instanzen und bei einem Hardwareausfall werden zuvor deaktivierte Applikations- und Storage-Container wieder gestartet.
Mit hyperkonvergentem Storage in Form von Storage-Containern können Entwickler künftig Speicherkapazitäten deutlich granularer als heute steuern und überwachen. Auch aus DevOps-Aspekten bringt hyperkonvergenter Storage Vorteile, denn Storage- und IT-Administratoren sind dann in der Lage, Rechen- und Speicherkapazitäten zu verwalten.
- An Containern führt kein Weg vorbei
- Shared Storage für Applikations-Container
- Object Storage
Lesen Sie mehr zum Thema
