Starnberg, 14. Jan. 2022 - Cloud-native, containerisierte Anwendungen und Microservices benötigen hierfür konzipierte Speicherumgebungen; eine Standortbestimmung...
Zum Hintergrund: Aufgrund der Beliebtheit von Containern für die Entwicklung und Bereitstellung von Anwendungen rückt das Thema „Persistenter Speicher“ in den Mittelpunkt. Zu Beginn dieser Entwicklung wurde einfach davon ausgegangen, dass der Container-Storage zustandslos ist, aber kritische Anwendungsfälle, bei denen Daten über den Lebenszyklus eines Containers hinaus bestehen bleiben müssen, erforderten andere Speicheransätze wie beispielsweise performante „bind mounts“ oder auch Docker-Volumes zur Ausführung zustandsabhängiger Anwendungen.
Mit Hilfe von APIs lässt sich die Datenpersistenz relativ leicht herstellen
Ein Volume-Plugin integriert dazu Container-Orchestrierungssysteme wie Kubernetes (oder Docker Swarm) über APIs mit den verfügbaren Speichersystemen. Ferner lassen sich persistente Volumes nativ bereitstellen und einer Applikation zuordnen, die in einem Container läuft. Übersteht das persistente Volume die Beendigung des Containers, bleiben auch die von der Anwendung geschriebenen Zustandsdaten über die Lebensdauer des Containers hinaus erhalten. Das Container Storage Interface (CSI) stellt dazu eine von gängigen Speicheranbietern unterstützte Spezifikation dar, um die Container-Orchestrierung zu vereinheitlichen.
Diese Möglichkeiten erweitern die Auswahl an persistenten Speicher für container-Apps. Zu den Optionen gehören neben modernen Cloud-nativen Speicherlösungen für orchestrierte Systeme auch Möglichkeiten zur Einbindung älterer Software-definierter (SDS) Plattformen sowie klassischer (Block-/File) Unternehmens-Speichersystem. Für Kubernetes können Entwickler mithilfe von CSI Plugins schreiben, um neue Speichersysteme bereitzustellen, ohne dabei Kubernetes selbst zu modifizieren. Der Speicher läßt sich über Cluster-Ressourcen dynamisch verwalten. Dies mit Optionen wie Persistent Volume Claims zur Bereitstellung von dynamischen Speicherplatz, Storage Class als Bereitstellung von Speicher mit verschiedenen Serviceklassen sowie Persistent Volume Storage.
Das Interesse an der Bereitstellung von Stateful-Applikationen auf (Kubernetes-) Clustern steigt auch deshalb, weil man sich nicht immer auf ein separates Team verlassen will-/kann, das den Speicher extern verwaltet. Es kann - das nötige Know-how vorausgesetzt - kostengünstiger bzw.zeitsparender sein, wenn dasselbe IT-Team, das den Kubernetes-Cluster verwaltet, auch alle mit diesem Cluster verbundenen Speicherressourcen betreut. Zudem steigt der Bedarf an der Automatisierung von Speicherverwaltungsaufgaben über alle Arten von Clustern, an die jeweils sehr unterschiedliche Speicherdienste angeschlossen sein können.
Vorteile cloud-nativer Technologien
Cloud-native Architekturen ermöglichen es, skalierbare Anwendungen zu dynamischen Umgebungen für öffentlichen, privaten und-/oder hybriden Clouds zu erstellen und auszuführen. So entstehen lose gekoppelte Systeme, die sowohl robust als auch zentral verwaltbar sind. In Kombination mit einer robusten Automatisierung lassen sich dann mit minimalem Aufwand im laufenden Betrieb Änderungen vorzunehmen.
Die aus Speicherverwaltungs-Sicht in diesem Umfeld auf Open-Source-Technologie basierenden Lösungen integrieren Datei-, Block- und Objektspeicherdienste direkt im Applikations-Cluster und führen sie mit anderen Diensten zusammen, die den Speicher allokieren. Dadurch wird der Cloud-native Cluster autark und portabel über Public Clouds und On-Premise-Bereitstellungen hinweg.
Ceph, Longhorn, OpenEBS und Rook sind einige native open-source Storageprojekte, während z.B. Kubera von MayaData, Robin.io, Trident von NetApp, Pure Storage Portworx oder auch die Red Hat Container Storage Platform (kein Anspruch auf Vollständigkeit...) kommerziell verfügbare Angebote mit entsprechendem Support darstellen.
Leistungsmerkmale bei der Auswahl einer Lösung:
- Storage-as-a-Service Option, um die Dienste als Cloud-ähnlichen Service bereitstellen zu können
- Hoher Automatisierungsgrad, so dass die Bereitstellung selbst nicht IT-gebunden sein muss
- Optimierte Integration mit bestehenden Entwicklerprozessen
- End-to-end Funktionalitäten (Edge-to-Core-to Multi-Cloud).
Fazit: Verschiedene Speicheroptionen geben Betreibern die Möglichkeit, beim Übergang zu containerisierten Anwendungen sowie Microservices eine persistente, cloud-native Umgebung mit hohem Automatisierungsgrad und SLA-Funktionen für wichtige Anwendungsdaten zu schaffen, ohne dass die Bereitstellung dazu per se IT-Ops gebunden sein muss. Wichtig bei der Auswahl der Technologie ist, dass in jedem Fall eine konsistente Anwendungsleistung (QoS) sichergestellt wird (Stichwort: Hochverfügbarkeit) und die Lösung auch leistungsmäßig skaliert.
Querverweis:
Kubernetes Blog „How to deploy a CSI driver?“ > Kubernetes users interested in how to deploy or manage an existing CSI driver on Kubernetes should look at the documentation provided by the author of the CSI driver.
Link > https://github.com/container-storage-interface/spec/blob/master/spec.md