Container Native Storage
Speicher für und in Containern
Die Containertechnik ist unbestritten weiter auf dem Vormarsch. Linux-Container, die Applikationslogik und Konfigurationsangaben enthalten, haben sich als komfortable und effiziente Methode zur Entwicklung und Bereitstellung von Applikationen etabliert.
Container gelten auch als Schlüsseltechnologie für die Einführung von Micro-Services: Solche Services können Entwickler mit containerbasierten Umgebungen einfach erstellen und mit Applikationen verbinden. Dabei können sie völlig unabhängig von IT-Infrastruktur-Spezialisten agieren. Die Vorteile sind eine Verzahnung von Applikationsentwicklung und Betrieb der IT-Infrastruktur, kürzere Testzyklen, eine höhere Softwarequalität sowie eine schnellere Bereitstellung und bessere Portabilität von Applikationen.
Container verkapseln eine Applikation und deren Laufzeitumgebung. Bis vor Kurzem waren sie jedoch primär "stateless", das heißt, es fehlte die Möglichkeit, Applikationsdaten über den gesamten Lebenszyklus eines Containers und darüber hinaus zu speichern. Außerdem sind Container von Natur aus kurzlebig. Zustandsbezogene Anwendungen verlieren alle ihre Daten, wenn ein Container ausfällt, was zu Geschäftseinbußen und Compliance-Verstößen führen kann.
Für den Einsatz von Containern in Produktionsumgebungen wird also robuster, skalierbarer, sicherer und persistenter Storage benötigt. Mit Software-Defined Storage (SDS) lässt sich persistenter Speicher nun auch für Container bereitstellen, ohne dass dafür eine dedizierte Storage-Plattform eingeführt werden muss; das heißt, SDS wird als Softwarecontainer zur Verfügung gestellt.
Entwickler können damit Speicherkapazitäten für Applikationscontainer auf Basis eines verteilten File-Systems - eines Shared Persistent File System - als Storage-Service bereitstellen. Zum Einsatz kommt gemeinsam genutzter persistenter Speicher, der deutlich flexibler als eine Storage-Appliance ist. Ein typisches Anwendungsfeld sind etwa Big-Data-Analysen durch mehrere Clients; dabei lassen sich Speicher und Rechenpower je nach Bedarf dynamisch hinzufügen. Der Einsatz von persistentem Storage für Container ist aber nicht nur auf neuere Anwendungsszenarien wie Big Data Analytics beschränkt, sondern lässt sich auch für vorhandene Applikationen nutzen, die Daten in der Containerplattform verarbeiten und speichern müssen.
Kubernetes vereinheitlicht Orchestrierung
Die Einführung von Micro-Services in den Applikationsarchitekturen erfordert ebenfalls eine andere Art der Bereitstellung von Storage. Das heißt, Speicherkapazitäten sollten im Hinblick auf Packaging und Deployment als Micro-Service, und damit verpackt in einem Container, bereitstehen. Zudem ergibt sich aus der zunehmenden Verbreitung von Micro-Services der Bedarf nach einer zentralen Verwaltung von persistentem Storage über eine einheitliche Control Plane.
Unternehmen können mit der über das Orchestrierungs-Framework Kubernetes verwalteten Red Hat OpenShift Container Platform neben Applikations- auch persistente Storage-Container (Container Native Storage) bereitstellen. Mit dem Kubernetes Persistent Volume (PV) Framework besteht die Möglichkeit, persistenten Speicher für einen Pool von Anwendungscontainern zur Verfügung zu stellen, die auf verteilten Servern laufen. Entwickler können dann, ohne dass sie über genauere Kenntnisse der zugrundeliegenden Storage-Infrastruktur verfügen müssen, via Persistent Volume Claims (PVCs) PV-Ressourcen anfordern und damit den Einsatz und die Provisionierung von Storage für Applikations-Container deutlich vereinfachen. Red Hat OpenShift Container Platform unterstützt folgende PV-Plug-ins: AWS Elastic Block Store (EBS), Ceph RBD, GlusterFS, HostPath, NFS, OpenStack Cinder, GCE Persistent Disk, iSCSI und Fibre Channel; GlusterFS hat zudem den Vorteil, auch als Container Native Storage einsetzbar zu sein.
Hyperkonvergente Architekturen
Container Native Storage unterstützt die dynamische Storage-Provisionierung und stellt über QoS-Labels (Quality of Service) in Kubernetes verschiedene Speichertypen und Multi-Tier-Speicher bereit. Mit Container Native Storage profitieren OpenShift-Anwender zusätzlich von einer softwaredefinierten, hochverfügbaren und skalierbaren Speicherlösung, die sowohl On-Premise als auch in Public-Cloud-Umgebungen zu verwenden ist. Genereller Vorteil für Anwender ist, dass sie keine Storage- oder Infrastruktur-Experten mehr sein müssen, um eine Storage-Umgebung für Enterprise-Anwendungen zu implementieren; sie nutzen einfach die Speicherkapazitäten als Service (Storage as a Service).
Auf einem einzigen Kubernetes-Cluster und auf einer Containerplattform können Unternehmen verschiedene Entwicklungsprojekte, Applikationen und Lifecycle-Umgebungen gänzlich isoliert voneinander betreiben und dabei Ressourcen gemeinsam nutzen. Implementiert in einer hyperkonvergenten Architektur sind Kubernetes-Knoten in der Lage, Storage- und Applikations-Container auszuführen. Zudem besteht die Möglichkeit, dass Infrastrukturadministratoren Storage-Container zum Beispiel als Gluster Storage Bricks implementieren, die kombiniert miteinander ein hochverfügbares GlusterFS Volume bilden. Damit entfällt der Bedarf an dedizierter Storage-Hardware, denn über dieses Volume lassen sich die Storage-Kapazitäten einzelner Server-Knoten zusammenfassen.
Auf dem gleichen Knoten, auf dem eine PaaS-Umgebung für den Betrieb von Applikationscontainern läuft, können Entwickler oder Administratoren auch native Storage-Container einrichten. Die in den Applikations-Servern genutzten Festplatten beziehungsweise SSDs stehen dann als virtualisierter Speicherpool zur Verfügung, und Anwendungen können nach Bedarf isolierte Speicherbereiche anfordern und dynamisch provisionieren. In dieser Konfiguration sparen sich Unternehmen eine separate Storage-Infrastruktur. Ein zentraler Vorteil von hyperkonvergentem Storage in Form von Container Native Storage für Entwickler ist die granulare und sichere Steuerung und Überwachung von Speicherkapazitäten. Nicht zuletzt bieten hyperkonvergente Systeme auch aus DevOps-Sicht Vorteile, da Storage- und IT-Administratoren Rechen- und Speicherkapazitäten gemeinsam verwalten können.
Lesen Sie mehr zum Thema
