Unternehmensweit eingesetzte, universelle Datenspeichersysteme sind für die hochverfügbare Speicherung und Archivierung großer Informationsmengen geschaffen. Die damit verbundenen Funktionen zum Storage-Management sind im Gegensatz zu kleineren lokalen Speicherlösungen darauf ausgelegt, Workloads zu verwalten – I/O-Profile von vielen unterschiedlichen Benutzern hauptsächlich über File- und Blockzugriffe. Sie werden als virtualisierte, zentralisierte Infrastrukturen wie NAS und SAN-Arrays, aber auch als direkt angeschlossener Speicher (DAS) für spezifische Anwendungs-Workloads mit einer direkten LUN-zu-App-Beziehung implementiert.

In diesem Zusammenhang beginnt sich auch Computational Storage stärker zu entwickeln. Dieser Begriff definiert Architekturen, die mit dem Speicher gekoppelte, rechnergestützte Storage-Funktionen bereitstellen, um die Server-Verarbeitung zu entlasten und/oder Datenbewegung über Netzwerke zu minimieren. Ein Teil der Datenverarbeitung erfolgt nun direkt auf der Speicherebene, anstatt die Daten in den Hauptspeicher zur Verarbeitung durch die Host-CPU zu verschieben.

Dieser Ansatz ermöglicht Verbesserungen bei der Anwendungsleistung mittels Integration von Rechenressourcen außerhalb der traditionellen Rechen- und Speicherarchitektur entweder direkt mit dem Speicher oder zwischen dem Host und dem Speicher. Computational Storage ist für Hochleistungs-Workloads von modernen Datenbanken und Big Data Analytics ideal. Typischerweise verfügen diese Systeme aufgrund des Einsatzzwecks über eine für die Systemumgebung optimierte Speicher- und Dateisystemverwaltung, während sich eine kommerziell breit verfügbare Enterprise-Speicherverwaltungsplattform auch rein als Software zusammen mit JBODs implementieren lässt.

Zentrale Elemente leistungsfähiger Software zur Speicherverwaltung umfassen unter anderem die (Remote-)Überwachung sowie Administration und Fehlerbehebung zu allen wesentlichen Komponenten des Speichersystems. Sie beinhalten zudem Komprimierung und Deduplizierung sowie Optimierungsmöglichkeiten zur Bereitstellung, Auslastung und Performance. Neben der reinen Überwachung aller hardwarenahen Systemelemente lässt sich damit zudem die Einhaltung von Vorschriften in Bezug auf Datenaufbewahrung (WORM) und Datenschutzstandards vereinfachen.

Eine plattformübergreifende Speicherverwaltung im Unternehmen ist für die Skalierbarkeit der Speicherarchitektur insgesamt von Bedeutung, weil sich vorhandene Kapazitäten damit je nach

Geschäftsanforderungen relativ unkom­pliziert und schnell erweitern oder migrieren lassen. Das Storage-Management adressiert dabei die Verlagerung von Speicherkapazitäten bis in die Cloud, das Hinzufügen von weiterer Hardware wie Controller, Festplatten und SSDs sowie virtualisierter (Disk-)Ressourcen aufgrund von Erweiterungen mit Hypervisor-Systemen. Die einheitliche Verwaltung von Speicherressourcen vereinfacht Backup-Restore- und Disaster-Recovery-Prozesse erheblich. Mit der geeigneten Speicherverwaltung lassen sich Ressourcen gezielt zuweisen, um Ausfälle zu vermeiden und die Leistung zu verbessern.

Zentrale Datenspeicher – bislang typischerweise skalierbare Fibre-Channel-Hochleistungs-Arrays in Kombination mit Schnittstellen und Tools zum Datenschutz – sind zur umfassenden Verwaltung der Unternehmensdaten mit Schutz- und Freigabeprotokollen sowie einem einheitlichen Ansatz für den Zugriff auf und die Sicherung von Geschäftsinformationen versehen. Hierbei gibt es herstellerspezifische Unterschiede, die Implementierung erfolgt nah an der Hardware. Dieser Ansatz hat sich für definierte Anwendungsfälle zwar bewährt, ist jedoch auf Grund der zunehmenden Menge an unstrukturierten Daten und rasch wachsender neuer Anwendungs-Workloads mit Millionen von Objekten und hunderttausenden Containern nicht hinreichend skalierbar und stößt damit auch wirtschaftlich an Grenzen.

Aktuell wird auf immer mehr Daten immer weniger zugegriffen – Cold Data lautet der entsprechende Fachbegriff. Kostenseitig stellt dies nicht nur im eigenen Rechenzentrum, sondern auch für Cloud-anbieter aufgrund des schnellen Wachstums ein Problem dar. Es ist deshalb sinnvoll, die Konsolidierung von Flash, hochkapazitativen Festplatten und Bandlaufwerken unter Einbeziehung von Cloudspeicher zu einer mehrstufigen, logisch einheitlich zu verwaltenden Architektur in Betracht zu ziehen.

Gerade im Zusammenhang mit systemnahen Archiven wird dieser Ansatz oft unterschätzt. Ein Beispiel: Office-Anwendungen erzeugen die Masse aller Geschäftsdaten. Diese Daten altern zügig, was zu immer mehr Online-Speicherkapazitäten bei nur geringer Zugriffshäufigkeit führt. Eine Speicherung der kalten Daten auf Band oder in der Public Cloud ergibt in diesem Fall Sinn, um zusammen mit HDDs und Flash eine kostenoptimierte, mehrstufige und hybride Speicherverwaltung aufzubauen – Stichwort automatisiertes Data-Life-Cycle-Management. Darin kann die Cloud als weitere, nahtlos integrierte Speicherebene (Tier) fungieren, ohne dabei die Kontrolle über die eigenen Daten zu verlieren. Hier gilt es aber zu beachten, dass Langzeitdaten inzwischen häufig als Quelle für Analysen oder sogar als primärer kostengünstiger Speicher für selten abgerufene Daten fungieren.

Für jedes Unternehmen summieren sich bei den Anbietern von Cloud-Storage die Speicherkosten über den gesamten Lebenszyklus. Diese Kosten können innerhalb kürzester Zeit steigen, selbst wenn sich die abzurufende Datenmenge nur um wenige Prozente verändert. Bis die Daten für die Nutzung durch den Anwender vor Ort zurückgeholt werden, sind die Kosten dann oft höher als bei der Verwendung von Primärspeichersystemen und On-Premises-Plattformen. Denn oft erheben Cloudanbieter zusätzliche Gebühren für Befehle, die Verwendung finden, um Daten aus dem Langzeitarchiv abzurufen. Umso wichtiger ist es deshalb, dass eine intelligente Datenverwaltungsstrategie die möglichst automatisierte Klassifizierung relevanter Daten vor der Migration in die Cloud berücksichtigt.

Entwickler schätzen Hyperscale-Anbieter wegen der agilen und schnellen Bereitstellung von Ressourcen. Diese Fähigkeit beruht im Wesentlichen auf softwaredefinierte Compute- und Speicherumgebungen. Software-defined Storage (SDS) verwendet dazu eine verteilte System­architektur für Primär-, Sekundär- und Archivdaten. Das ist auch der Grund, weshalb sich softwaregesteuerte Infrastrukturen mittelfristig wohl als dominieren­de Methode zum Aufbau von hybriden und Multicloud-Speicher-infrastrukturen durch­setzen werden. Dies geht einher mit dem allgemeinen Trend bei Unternehmen, sich weg von isolierten Infra­strukturen hin zu flexibleren, skalierbaren, durch die Cloud unterstützte hybriden Plattformen zu bewegen. Automatisierung und DevOps-Verfahren, um schneller cloudnative und skalierbare Anwendungen auf Basis von Containern sowie Mikroservices zu erstellen, sind dazu notwendig. Aber parallel dazu ist es wichtig, wie bisher im Produktivbetrieb die Anforderungen nach Hochverfügbarkeit, Performance, Compliance und Datensicherheit zu erfüllen.

Während wie gesehen im klassischen Anwendungsumfeld (Ops) primär die Stabilität im Betrieb im Fokus steht, gilt im Dev-Bereich Agilität als oberstes Prinzip. Doch dies beginnt sich gerade zu ändern. Bei Projekten im Zusammenhang mit anwendungskritischen Container-Umgebungen und Microservices ist Storage nicht mehr nur als flexible Option, sondern als hochverfügbarer, softwaredefinierter Dienst für Block-, File- und Objektspeicher gefordert. Eine Motivation für diese Entwicklung liegt darin, dass ein Nutzer, der jetzt einen neuen Container deployed, sich nicht mehr an einen Storage-Admin wenden muss, falls er Speicherressourcen für sich beansprucht; nun initiiert er seinen Container einfach über OpenShift via Kubernetes und bekommt den zugehörigen Storage-Container automatisch gemapped. Mit einer nicht in eine derartige Architektur integrierten externen Speicherverwaltung ist das so nicht möglich.

Unternehmen, die einen integrierten Ansatz verfolgen, wollen die Bereitstellung von Anwendungen beschleunigen und komplexe Infrastruktursilos auflösen. Softwaredefinierte Infrastrukturen sind dabei für das Datenmanagement essenziell, weil sich damit zwei Ziele im Auge behalten lassen: Beweglichkeit und Elastizität des Storage-Layers im laufenden Betrieb. Bei Bedarf an mehr Kapazität oder Rechenleistung fügen Unternehmen diese Ressourcen als virtualisierte Instanzen hinzu. Steht keine eigene Hardware zur Verfügung, kommen im laufenden Betrieb skalierbare Ressourcen innerhalb der Public Cloud hinzu. Damit können IT-Verantwortliche jederzeit auf sich verändernde Anforderungen reagieren.

Soweit jedenfalls zur Theorie, denn leider ist in der Praxis die Integration des Storage im Sinne der oben genannten übergreifenden Architektur zwischen On-Premises und Cloud in vielen Unternehmen nicht gelöst. Storage und das damit verbundene Datenmanagement stellt unzweifelhaft eine der wichtigsten Komponenten von cloudnativem Computing dar, aber persistente Speichersysteme laufen in der Regel (noch) außerhalb der Cloudumgebungen auf separaten Systemen.

Das Interesse an der Bereitstellung von Stateful-Applikationen zum Beispiel auf Kubernetes-Clustern steigt nicht zuletzt 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 Cluster verwalten, auch alle mit diesem verbundenen Speicherressourcen managen. Zudem hat die Anzahl zustandsabhängiger Anwendungen inzwischen zugenommen. Damit steigt der Bedarf an einer Automatisierung von Speicherverwaltungsaufgaben über alle Arten von Clustern, an die jeweils sehr unterschiedliche Speicherdienste angeschlossen sein können. Native Cloudtechnologien erlauben es, skalierbare Anwendungen in modernen, dynamischen Umgebungen wie öffentlichen, privaten und/oder hybriden Clouds zu erstellen und auszuführen. Container, Servicenetze, Mikroservices, eine 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 gestatten sie es, mit minimalem Aufwand im laufenden Betrieb Änderungen vorzunehmen.

Aus Speicherverwaltungssicht sind in diesem Umfeld auf Open Source basierende neue Werkzeuge deshalb nicht zu unterschätzen. Diese integrieren Datei-, Block- und Objektspeicherdienste direkt im Applikations-Cluster und führen sie mit anderen Anwendungen beziehungsweise Diensten zusammen, die den Speicher allokieren. Dadurch wird der cloudnative Cluster autark und ist portabel über Public Clouds und On-Premises-Bereitstellungen hinweg. Unternehmen sind dann dazu in der Lage, ihre Rechenzentren mit dynamischer Anwendungsorchestrierung für verteilte Speichersysteme in lokalen und öffentlichen Cloudumgebungen zu modernisieren.

Auch wenn Kubernetes verteilte Dateisysteme wie das 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 cloudnative Ökosystem hat mit dem Container Storage Interface (CSI) Spezifikationen definiert, um einen standardisierten, portablen Ansatz zur Implementierung und Nutzung von Storage-Diensten durch containerisierte Workloads zu beschleunigen.

Ceph, Longhorn, OpenEBS und Rook sind einige native freie Storage-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 et cetera bieten ebenfalls Storage-Plug-ins für Kubernetes an. Toolseitig ist ein neues Open-Source-Projekt wie Kubestr in der Lage, die relativen Leistungswerte verschiedener Speicherkonfigurationen über Cloudanbieter hinweg zu analysieren.

Der Betrieb von Systemen in der Produktion beinhaltet steigende Anforderungen an Hochverfügbarkeit, Ausfallsicherheit und Wiederherstellung nach einem Ausfall. Auch beim Betrieb von cloudnativen Anwendungen ist aber davon auszugehen, dass CPU-Nodes ausfallen, Cluster-Knoten wegbrechen und Microservices-Instanzen nicht erreichbar sein können, der Service aber trotzdem weiterlaufen soll. Ein modernes Datenmanagement sollte diese Anforderungen somit priorisieren.

Ist die Speichersoftware von der Hardware getrennt, gestaltet es sich für IT-Teams einfacher, Industriestandard-Laufwerke (NVMe, SAS et cetera) einfach zu ersetzen. Die Trends in diesem Bereich zeigen die Richtung auf: Unternehmen stellen Speichersysteme mittelfristig, genau wie andere IT-Infrastrukturplattformen, über Software bereit (Infrastructure-as-a-code). Kostenseitig geht es allerdings aber nicht nur um die Unterschiede zwischen SAS-Drives und Flash, also die reinen Speicherkosten; ebenso gilt es, Kosten für Storage-Server, Wartung, Strom und alle Softwarelizenzen, die mit verschiedenen Speicherebenen oder SDS-Plattformen aus Speicherverwaltungssicht verbunden sind, zu berücksichtigen.

Zusammengefasst lässt sich auf Basis der bisher geschilderten Randbedingungen eine softwarezentrierte Infrastruktur- und Datenverwaltung wie folgt beschreiben: Als Plattform virtualisiert die Softwareschicht alle dazu notwendigen Speicher- und Netzwerk-Ressourcen (Beispiel: Container-as-a-Service-Plattform) und aggregiert diese logisch zusammen mit den jeweiligen Speicherebenen. Intelligente Datenverwaltungssoftware arbeitet KI-unterstützt im Hintergrund und automatisiert alle Arbeitsabläufe, die sonst manuell zu steuern wären. Das verschlankt und beschleunigt IT-Prozesse, inklusive Monitoring und Reporting. Darüber hinaus sind Funktionen wie Chargeback für die transparente Verrechnung der IT-Ressourcen verfügbar. Diese Entwicklung lässt sich momentan exemplarisch in verschiedenen Bereichen verfolgen:

1. Als Bestandteil hyperkonvergenter Produkte mit Hypervisor-unabhängigen SDS-Infrastrukturlösungen und Speicherverwaltungsfunktionen.

2. Als Plattform für unstrukturierte Daten, die softwarebasierte, verteilte Filesysteme und Objektspeicher nutzen.

3. Als cloudnativer Speicher für containerisierte Anwendungsumgebungen, der zustandsabhängige Workloads innerhalb von Containern unterstützt, indem er persistente Volumes bereitstellt.

IT-Organisationen sollten heute nicht mehr die reine Speicherverwaltung, sondern ihr Datenmanagement als den entscheidenden Faktor betrachten. Storage selbst entwickelt sich in diesem Modell zu einem Service-bezogenen Dienst. Dieser Ansatz impliziert die Verwendung von Multicloud-Architekturen und verlangt den Einsatz von standardisierten Schnittstellen und hochintegrierten, softwaregesteuerten Infrastrukturkomponenten. Die Themen Hyperkonvergenz und Einsatz von cloudnativen Technologien wird im Spannungsfeld von knappen Budget- sowie Personalressourcen und zunehmender Komplexität der Cloud in naher Zukunft bei vielen Unternehmen eine noch stärkere Aufmerksamkeit erfordern.