Von Hardware-zentrierter Speicherverwaltung zu 'Software-Defined Cloud Native' Architekturen

Starnberg, 26. Okt. 2021 - Applikationskritische Container und Microservices; Storage wird als hochverfügbarer Software Definierter Dienst für Block-, File- und Object gefordert...

Um was es hier geht: Um Angesichts einer beschleunigten digitalen Transformation erfolgreich zu sein, sollten zwei kritische Aspekte beachtet werden. Einerseits vorhandene Ressourcen und Fähigkeiten durch Innovationen nutzen und andererseits in neue Märkte und Technologien investieren, in denen diese Ressourcen bzw. Fähigkeiten direkte Wettbewerbsvorteile liefern können. In Bezug auf den IT Betrieb (ops) und der Anwendungsentwicklung (dev) - Gartner hat das als „Bi-modale IT“ definiert - ergeben sich an den Storage und das Daten-Management daraus spezifische Anforderungen, die ich kurz versuchen werde, in diesem Beitrag zusammenzufassen:

Entwickler schätzen Hyperscale-Anbieter wegen der agilen und schnellen Bereitstellung von Ressourcen. Diese Fähigkeit beruht im wesentlichen auf Software-definierten Compute- und Speicherumgebungen (SDS), um kostenoptimierte IT-Infrastrukturdienste anzubieten. SDS verwendet dazu eine verteilte Systemarchitektur, für Primär-, Sekundär- und Archivdaten. Das ist auch der Grund, weshalb sich Software-gesteuerte Infrastruktur-Implementierungen mittelfristig auch in der Breite wohl als dominierende Methode zum Aufbau von hybriden- und Multi-Cloud-Speicherinfrastrukturen durchsetzen werden.

  • Dies geht einher mit dem allgemeinen Trend bei Unternehmen, sich weg von isolierten Infrastrukturen hin zu flexibleren, skalierbaren Cloud-unterstützen hybriden Plattformen zu bewegen. Automatisierung und DevOps-Verfahren, um schneller Cloud-native und skalierbare Anwendungen auf Basis von Containern sowie Mikroservices zu erstellen, sind dazu notwendig, aber parallel dazu ist es auch wichtig, wie bisher im Produktivbetrieb die Anforderungen nach Hochverfügbarkeit, Performance, Compliance- und Datensicherheit-/Schutz zu erfüllen.

  • Während im klassischen Anwendungsumfeld (ops) primär die Stabilität im Betrieb im Fokus steht, gilt beim Mode 2 (dev) Agilität als oberstes Prinzip, doch dass hat sich geändert. Bei Projekten im Zusammenhang mit anwendungskritischen Container-Umgebungen und Microservices wird Storage nicht mehr nur als flexible Option, sondern als hochverfügbare Software Definierter Dienst für Block-, File- und Objekt gefordert. Ein Motivation für diese Entwicklung liegt natürlich auch darin, dass ein Anwender, der jetzt einen neuen Container deployed, sich nicht mehr an einen Storage Admin. wenden muss, falls er Speicherressourcen für sich beansprucht; jetzt initiiert er seinen Container über Openshift via Kubernetes und bekommt den zugehörigen Storage Container automatisch gemapped. Mit einer nicht in diese Architektur integrierten externen Speicherverwaltung ist das in der Form schlecht möglich.

Kennzeichen und Vorteile einer integrativen Datenstrategie

  • Unternehmen, die einen integrierten Ansatz verfolgen, sind in der Lage, die Bereitstellung von Anwendungen zu beschleunigen und komplexe Infrastruktur-Silos aufzulösen. Software Definierte Infrastrukturen sind dabei für das Datenmanagement essentiell, weil sich im Kontext einer bi-modalen IT damit zwei Ziele im Auge behalten lassen: Beweglichkeit und Elastizität des Storage-Layers im laufenden Betrieb. Mehr Kapazität oder Rechenleistung bedeutet hier: Sie fügen diese Ressourcen als hoch-virtualisierte Instanzen im laufenden Betrieb hinzu. Mehr Kapazität oder keine Hardware zur Verfügung: Sie nutzen kostengünstige skalierbare Ressourcen innerhalb der Public-Cloud im laufenden Betrieb. Damit können Unternehmen jederzeit auf sich verändernde Anforderungen reagieren.

  • Soweit zur Theorie, denn in der Praxis die Integration des Storage im Sinne der oben genannten übergreifenden Architektur zwischen on-premise und Cloud noch nicht gelöst. Storage und das damit verbundene Datenmanagement stellt unzweifelhaft eine der wichtigsten Komponenten von Cloud Native Computing dar, aber persistente Speichersysteme laufen in der Regel (noch) außerhalb der nativen Cloud-Umgebungen auf separaten Systemen.

  • Das Interesse an der Bereitstellung von Stateful-Applikationen auf (Kubernetes-) Clustern steigt auch deshalb, weil sich Anwender nicht auf ein separates Team verlassen wollen, das ihren Speicher extern verwaltet. Es ist kostengünstiger und zeitsparender, wenn dieselben IT-Mitarbeiter, die den Kubernetes-Cluster verwalten, auch alle mit diesem Cluster verbundenen Speicherressourcen verwalten. Zudem hat die Anzahl zustandsabhängiger Anwendungen inzwischen zugenommen, die bereitgestellt werden. Damit steigt der Bedarf an einer Automatisierung von Speicherverwaltungsaufgaben über alle Arten von Clustern, an die jeweils sehr unterschiedliche Speicherdienste angeschlossen sein können.

Zu den Kennzeichen Cloud-nativer Technologien

  • Sie ermöglichen es, skalierbare Anwendungen in modernen, dynamischen Umgebungen wie öffentlichen, privaten und-/oder hybriden Clouds zu erstellen und auszuführen. Container, Servicenetze, Mikroservices, unveränderliche Infrastruktur sowie deklarative APIs veranschaulichen diesen Ansatz. Diese Techniken ermöglichen lose gekoppelte Systeme, die belastbar, handhabbar und zentral zu kontrollieren sind. In Kombination mit einer robusten Automatisierung ermöglichen sie es, mit minimalem Aufwand im laufenden Betrieb Änderungen vorzunehmen.

  • Aus Speicherverwaltungs-Sicht sind in diesem Umfeld auf Open-Source-Technologie basierende neue Lösungen deshalb nicht zu unterschätzen. Diese integrieren Datei-, Block- und Objektspeicherdienste direkt im Applikations-Cluster und führen sie mit anderen Anwendungen bzw. Diensten zusammen, die den Speicher allokieren. Dadurch wird der Cloud-native Cluster autark und portabel über Public Clouds und On-Premise-Bereitstellungen hinweg. Unternehmen werden in die Lage zu versetzt, ihre Rechenzentren mit dynamischer Anwendungsorchestrierung für verteilte Speichersysteme in lokalen und öffentlichen Cloud-Umgebungen zu modernisieren.

Auch wenn Kubernetes verteilte Dateisysteme wie Network File System (NFS) und GlusterFS verwenden kann, ist der Einsatz einer Container-fähigen „Storage-Fabric“ sinnvoll, die auf die Anforderungen von zustandsabhängigen Workloads in der Produktion ausgelegt ist. Betreiber können aktuell aus einer wachsenden Anzahl von Open-Source-Projekten und kommerziellen Implementierungen wählen. Das Cloud-Native-Ökosystem hat über Container Storage Interface (CSI) Spezifikationen definiert, um einen standardisierten, portablen Ansatz zur Implementierung und Nutzung von Storage-Services durch containerisierte Workloads zu beschleunigen.

Ceph, Longhorn, OpenEBS und Rook sind einige native Storage-Open-Source-Projekte, während Kubera von MayaData, Trident von NetApp, Portworx von Pure Storage oder die Container Storage Platform von Red Hat kommerziell verfügbare Support-Angebote darstellen. Bekannte Anbieter wie NetApp, Pure Storage, IBM, HPE, VMware etc. bieten Storage-Plugins für Kubernetes an. Tool-seitig ist auch ein neues Open-Source-Projekt wie z.B. Kubestr dazu in der Lage, die relativen Leistungswerte verschiedener Speicherkonfigurationen über Cloud-Anbieter hinweg zu analysieren.


Querverweis: