Starnberg, 13. Juli 2021 - Datensicherheit, Replikation, Thin Provisioning, Hochverfügbarkeit, Backups und weitere speicherbezogene Funktionen werden wichtiger...
Um was es hier geht: Als Container-Technologien wie Docker zu umfangreichen Orchestrierungslösungen wie Kubernetes führten, lag der Fokus nicht gerade auf der Bereitstellung von persistenten „Enterprise-Class-Storage" Funktionalitäten. Für Anwender führt dies immer wieder zu Schwierigkeiten im Zusammenhang mit der Storage-Bereitstellung, zumal Kubernetes generell nicht gerade einfach zu verwalten ist. Klassischer Enterprise Storage jedenfalls rechnet nicht mit kurzlebigen, sprunghaften Dev-Ops-Workloads. Auch Container Storage Interface (CSI) Implementierungen lösen das Problem jedoch nicht vollständig, denn mit der Erstellung und dem ‚Ableben’ von Containern werden auch die Verbindungen zu den Speicher-Volumes verändert. Diese Prozesse belasten wiederum auch den Unternehmensspeicher, vor allem bei komplexen schnellwachsenden und sehr dynamischen Umgebungen.
Gerade weil sich moderne Applikations-Arbeitslasten in Richtung Container verschieben, steht der Storage weiterhin im Mittelpunkt.
-
Anwendungsbeispiel Industrie 4.0 (hier Shop Floor 4.0): erfordert eine effiziente und vertikale Vernetzung der Geschäftsprozessebene mit produktionsnahen Systemen, Mess- und Steueraggregaten. Das aktuelle Fraunhofer IESE BaSys 4.0 als Open Source Projekt z.B. fungiert als Betriebssystem, das Produktionsanlagen miteinander sowie mit Planungs- und Steuerungssystemen vernetzt. Das System sorgt dafür, dass sich Fertigungsprozesse flexibel an sich verändernde Bedingungen wie durch ein neues Produkt, anpassen lassen. In diesem Umfeld kommen Container anstelle virtueller Maschinen (VMs) zum Einsatz. Eine persistente Speicherlösung unter Kubernetes zur Vereinfachung und Automatisierung des persistenten Container Storage ist hier von Vorteil, denn manuelle Ticket für die Bereitstellung entfallen und das Self-Service-Speicher- und Datenmanagement in der Sprache des Containers ist gewährleistet. Querverweis / Link > https://storageconsortium.de/content/content/persistent-storage-f%C3%BCr-docker-container-und-shop-floor-40
-
Die Communities stellen als Reaktion auf diese Herausforderungen regelmäßig Updates ihrer Spezifikationen bereits, um über das Container Storage Interface (CSI) Enterprise-Speichersysteme besser mit Container-basierten Workloads zu integrieren. Dies löst aber nicht den grundsätzlich anderen Architekturansatz, der im Zusammenhang mit Cloud-nativen Workloads und Entwicklungen wie künftig Infrastructure-as-a-Code nötig wird. Insbesondere bei der höheren Anwendungsdichte und Workload-Dynamik (keine statisch vorhersagbare Arbeitslasten) im Vergleich zu virtualisierten Architekturen (Faktor 10 bis 20) kommen potentielle Schwachstellen CSI-basierter Speicheranbindungen zum Tragen.
-
Komplexe Container-Umgebungen sind einfach nicht optimal auf traditionelle Server-Workloads und dem damit verbundenen Storage abzubilden. Um nicht missverstanden zu werden: CSI-Treiber für Kubernetes-Umgebungen wie z.B. die VMware Tanzu, funktionieren ausgezeichnet und der Ansatz ist für viele Anwendungsumgebungen ausreichend. Aber es macht im Sinne einer längerfristigen Strategie hin zu Software Definierten Infrastrukturen einen Unterschied, ob der externe Unternehmensspeicher über CSI angebunden wird, ober ob Storage nativ innerhalb einer von Kubernetes-gesteuerten Umgebungen heraus direkt gesteuert und verwaltet werden kann.
Bildquelle: Container Storage Interface (CSI) for Kubernetes GA
Link > https://kubernetes.io/blog/2019/01/15/container-storage-interface-ga/
Cloud-native Speicherarchitekturen: Vom SAN über HCI zu CAS & SDS
-
Anwendungsbasierte Datenspeicher-Dienste werden den steigenden Applikationsanforderungen hier nicht immer gerecht und bringen zudem einen Datenreplikations- und E/A-Overhead mit sich. Moderene Anwendungen verlangen nach lokal verbundenen, persistenten Volumes, die alle Eigenschaften traditioneller Unternehmensspeicher-Lösungen wie Ausfallsicherheit, hohe Leistung und Optimierungsfunktionen (Thin Provisioning etc.) mit sich bringen, aber nicht als ausgeprägter externen Overhead mit Latenzen und Komplexität.
-
Softwaredefinierte Speicherlösungen (SDS), die persistenten Speicher für Container-basierte Anwendungsinfrastrukturen bereitstellen, setzen hier an und nutzen moderne Hochleistungs-Speichermedien wie NVMe-SSDs mit hohem Durchsatz bei geringer Latenz. Die Kombination ermöglicht neben hoher Flexibilität die gewünschte Leistung bei dynamischer Skalierbarkeit. Container Attached Storage (CAS) bildet dazu die Speicherphysik auf Container-basierte Workloads ab. Persistenter Speicher wird hier als Software-definierter Speicher (SDS) implementiert, der in Containern auf derselben Infrastruktur wie die Anwendungen selbst läuft. Die Komponenten der Speicherlösung werden als eine Reihe von Containern über Knoten innerhalb eines Container-basierten Clusters ausgeführt. CAS-Lösungen können ohne weiteres auch in der öffentlichen Cloud eingesetzt werden.
-
Die Speichergeräte werden bei CAS lokal von Prozessen angesprochen, die auf demselben Server oder derselben virtuellen Maschine wie die Anwendung laufen. Es gibt kein dazwischenliegendes separates Speichernetzwerk, welches Latenzen verursachen kann. Ausfallsicherheit, Kapazität und Leistung können mit einer Container-basierten Cluster-Lösung wie Kubernetes zudem dynamisch nach oben als auch nach unten skaliert werden.
Abb.: CNCF to host the Rook project to further cloud-native storage capabilities
Link > https://www.cncf.io/blog/2018/01/29/cncf-host-rook-project-cloud-native-storage-capabilities/
Anmerkung: Rook konzentriert sich darauf, bestehende und bereits bewährte Speichersysteme wie Ceph in eine Reihe von Cloud-nativen Diensten zu verwandeln, die direkt unter Kubernetes laufen. Rook lässt sich tief in Kubernetes integrieren und liefert ein einheitliches Umfeld für Sicherheit, Richtlinien, Quotas, Lifecycle-Management und zur Ressourcenverwaltung.
Auch wenn Kubernetes verteilte Dateisysteme wie Network File System (NFS) und GlusterFS verwenden kann, ist der Einsatz einer Container-fähigen Storage-Implementierung sinnvoll, die spezifisch auf die Anforderungen von zustandsabhängigen Workloads in der Produktion ausgelegt ist. Betreiber können derzeit bereits aus einer wachsenden Anzahl von Open-Source-Projekten sowie kommerziellen Implementierungen wählen, zumal der Markt ein lukratives Wachstum verspricht.
Ein Fazit: Wenn die Speichersoftware von der Hardware getrennt wird, wird es für IT-Teams in dem geschilderten Zusammenhang einfacher, Industriestandard-Laufwerke zu ersetzen, wenn sie es für erforderlich halten und die Trends in diesem Bereich zeigen die Richtung auf: Speichersysteme werden mittelfristig verstärkt, genau wie andere IT-Infrastrukturplattformen, über Software bereitgestellt (Infrastructure as a code). Aber wo ein Vorteil, da meist auch ein Nachteil... rein Kostenseitig geht es hier nicht nur um die Unterschiede zwischen SAS-Drives und Flash, also die reinen Speicherkosten (CAPEX); ebenso müssen Storage-Server, Wartungs-, Strom- und alle Software-Lizenzkosten, die mit verschiedenen Speicherebenen oder auch Software Defined Storage Plattformen aus Speicherverwaltungssicht verbunden sind, mitberücksichtigt werden. Nicht zu reden von einer mitunter deutlich höheren Gesamtkomplexität und den damit verbundenen Herausforderungen.
Hochintegrierte Cloud-nativer Speicherstacks für containerisierte Anwendungsumgebungen unterstützen jedenfalls zustandsabhängige Workloads innerhalb von Containern sehr effektiv, indem persistente Volumes als Service bereitstellt werden. Ein aktuelles Beispiel: Pure Storage Portworx wird vollständig von Containern in Kubernetes (und anderen Container-Orchestratoren) ausgeführt und kann Speicher erkennen und diesen on-the-fly bereitstellen und verwalten, um persistente Kapazitäten für Unternehmensanwendungen bereitzustellen.
Querverweis: Nachfolgend eine Übersicht zu aktuellen Anbietern (keinerlei Anspruch auf Vollständigkeit):
1. Komplett Storage Hardware-unabhängige, 'Software-only' Angebote:
- Rook
- Ceph, incl. Red Hat
- Suse (Rancher Labs, Longhorn)
- MayaData OpenEBS (open-source initiative)
- DataCore
- StorageOS
- ROBIN.io
- usw...
2. Storagesystem Anbieter (HW-/SW) - initiierte Lösungen mit Hardware-unabhängigem Community-Charakter:
- NetApp Trident / NetApp Astra / Spot Wave by NetApp
- Pure Storage Portworx
3. Storage-System-bezogene CSI Implementierungen:
- Infinidat
- IBM Storage
- NetApp
- HPE Storage
- DellEMC
- Hitachi Vantara
- usw...
(4) Ergänzung zu den oben genannten Block Storage Optionen:
-
Scality, Cloudian (S3 Object Storage Bereitstellung über Container).