Disaggregiertes Storage: Architektur und Funktionsweise

Funktionsweise und technische Grundlagen

Disaggregiertes Storage ist eng mit dem Konzept der Composable Infrastructure verwandt. Hierbei werden physische Ressourcen wie Compute, Storage und Netzwerk in logische Pools abstrahiert und Workloads dynamisch per Software zugewiesen.

Über NVMe-oF werden Speicherblöcke mit minimaler Latenz über das Netzwerk bereitgestellt. Dabei kommen unterschiedliche Transportschichten zum Einsatz, zum Beispiel RDMA (RoCE, iWARP) oder NVMe/TCP, je nach Hardwareumgebung und Leistungsanforderung.

Die Architektur basiert meist auf einem Shared-Pool-Prinzip, bei dem mehrere Knoten gleichzeitig auf gemeinsam verfügbare Speicherressourcen zugreifen. Eine verteilte Control Plane sorgt für Konsistenz, Zugriffskontrolle und Lastverteilung, sodass Performance und Datenintegrität gewahrt bleiben.

Disaggregierte Systeme bieten in der Regel folgende Funktionen:

• Programmierbares Provisioning: Speicherressourcen werden über APIs (zum Beispiel REST, Redfish) dynamisch zugewiesen und freigegeben.
• SLA-gesteuertes Management: Workloads erhalten garantierte Performance- oder Verfügbarkeitsparameter über Quality-of-Service-Mechanismen.
• Datenoptimierung: Inline-Kompression, Deduplikation und Thin Provisioning reduzieren Speicherverbrauch.
• Resilienzmechanismen: Funktionen wie RAID, Erasure Coding und Replikation sorgen für Fehlertoleranz und Hochverfügbarkeit.
• Intelligente Telemetrie: KI-gestützte Analysewerkzeuge erkennen Anomalien frühzeitig und unterstützen Self-Healing und Predictive Maintenance.

Ein wachsender Trend ist die Integration von In-Storage-Computing, Computational Storage und KI-basierter Speicheranalyse, die zunehmend in Highend-Systemen Einzug hält. Solche Systeme verschieben Analysefunktionen teilweise direkt in den Speicher oder nutzen Machine Learning (ML), um I/O-Lasten proaktiv zu optimieren.

Die Vor- und Nachteile von disaggregiertem Storage

Wie jede Technologie bietet auch der disaggregierte Speicher spezifische Vor- und Nachteile, die IT-Verantwortliche vor der Integration einer solchen Lösung gegeneinander abwägen müssen.

Vorteile

• Elastische Skalierbarkeit: Compute- und Speicherressourcen lassen sich unabhängig voneinander erweitern oder reduzieren.
• Effiziente Ressourcennutzung: Gemeinsame Speicherpools ermöglichen bessere Auslastung und vermeiden Über-Provisionierung.
• Hohe Performance: Durch NVMe-oF und RDMA sind Latenzen nur minimal höher als bei lokalem NVMe-Storage.
• Automatisiertes Management: API-zentrierte Control-Planes und Echtzeit-Telemetrie ermöglichen automatisierte Planung, Analyse und Wiederherstellung.
• Leistungsstarke Workload-Unterstützung: Ideal für containerisierte Umgebungen, KI/ML-Modelle, Edge-Deployments und Cloud-native Anwendungen.
• Kosteneffizienz im Betrieb: Besonders in Storage-as-a-Service- oder Pay-per-Use-Modellen lassen sich OPEX-Kosten deutlich senken.

Nachteile und Herausforderungen

• Betriebliche Komplexität: Planung, Monitoring und Fehlersuche sind anspruchsvoller und erfordern spezialisierte Tools sowie Fachwissen.
• Netzwerkabhängigkeit: Performance hängt stark von Latenz, Bandbreite und Netzwerkdesign ab. Hochleistungs-Fabrics (RDMA, RoCE) sind oft Voraussetzung.
• Initiale Investitionen: Hardware, Netzwerk und Software-Lizenzen verursachen höhere Einstiegskosten, bevor Skaleneffekte greifen.
• Interoperabilität: Unterschiedliche Anbieter und Protokolle können Integrations- und Kompatibilitätsprobleme verursachen.
• Sicherheitsanforderungen: Die Öffnung des Speichernetzwerks bringt neue Angriffsflächen (zum Beispiel Fabric-Manipulation, RDMA-Angriffe). Authentifizierung, Verschlüsselung und Zugriffsisolation werden daher zu Pflichtkomponenten zuverlässiger Implementierungen.

Composable vs. disaggregierte Infrastruktur

Composable Infrastructure und disaggregierte Infrastruktur sind eng miteinander verbunden, beschreiben jedoch unterschiedliche Ebenen.

Disaggregierte Infrastruktur meint die physische und logische Trennung ehemals fest verbundener IT-Komponenten (Compute, Storage, Netzwerk). Diese Ressourcen sind über Hochgeschwindigkeitsnetzwerke verbunden und in Pools organisiert, die unabhängig skaliert werden können.

Composable Infrastructure erweitert dieses Prinzip um eine softwaredefinierte Orchestrierungsschicht, die es ermöglicht, disaggregierte Ressourcen in Echtzeit zusammenzusetzen (zu komponieren), also dynamisch Workloads zuzuweisen und wieder freizugeben.

Disaggregierte Architekturen bilden also die Grundlage; Composability beschreibt die Fähigkeit, diese Ressourcen per Software intelligent zusammenzusetzen. Gemeinsam bilden sie den Übergang von statischen Infrastrukturen hin zu hochdynamischen, API-gesteuerten Rechen- und Speicherplattformen der nächsten Generation.

Verfügbare Produkte und Anbieter: unterschiedliche Ansätze

Am Markt haben sich mehrere Produktgruppen herausgebildet, die unterschiedliche Ansätze für disaggregiertes Storage adressieren, von klassischen All-Flash-Arrays mit disaggregationsfähigen Control-Planes bis hin zu reinen, für Disaggregation entworfenen Plattformen.

Traditionelle Storage-Vendors mit disaggregationsfähigen Plattformen

Viele etablierte Hersteller bieten heute Systeme an, die sich in Richtung Disaggregation und Shared-Pool-Betrieb weiterentwickeln haben, ohne allerdings das klassische Array-Betriebsmodell vollständig aufzugeben. Es gibt zahlreiche Beispiele hierfür, an dieser Stelle seien stellvertretend zwei genannt:

• Dell (PowerStore / PowerScale / APEX-STaaS): Dell beschreibt seine PowerStore und PowerScale weiterhin als NVMe-optimierte Plattformen mit Cloud-Management- und Scale-Out-Funktionen. In der Praxis bestehen diese Angebote aus integrierten Storage-Arrays mit Funktionen zur zentralen Verwaltung und Cloud-Service-Anbindung, nicht unbedingt aus rein physisch disaggregierten Baukästen. Das bedeutet, es gibt Shared-Pool-Betriebsmodi, aber die Architektur entspricht häufig einem neuen Array-Design mit erweiterten Verwaltungs- und Service-Features.
• Pure Storage (FlashArray / FlashBlade / Evergreen): Pure legt weiterhin Schwerpunkt auf NVMe-Performance und unterbrechungsfreie Upgrades. Die Produkte sind in vielen Fällen als hoch-performante All-Flash-Arrays ausgelegt, die zwar Scale-Out- und NVMe-Netzwerkfunktionen unterstützen, aber primär als integrierte Arrays verkauft werden. Für Kunden bedeutet das: sehr niedrige Latenz und konsistente IOPS, aber nur begrenzte native Disaggregation, wenn man echte physische Trennung von Compute und Kapazität erwartet.

Disaggregation (Shared-Pool / Scale-Out) als Architekturprinzip

Einige Anbieter positionieren ihre Plattformen gezielt als disaggregierte Lösungen. Dabei gibt es unterschiedliche technische Ansätze wie Shared-Everything-Modelle, separate Kapazitäts- und Compute-Knoten oder DPU-/softwaregetriebene Architekturen.  Beispiele hierfür sind:

• HPE Alletra Storage MP (GreenLake-Betrieb): HPE positioniert die Alletra-MP-Serie ausdrücklich als Disaggregated, Scale-Out Block Storage mit Cloud-gesteuertem Management und SLA-Versprechen. Diese Plattform kombiniert Elemente der physischen Entkopplung (separat skalierende Performance- und Kapazitätskomponenten) und eine zentrale Cloud Control Plane, was ein Beispiel dafür ist, wie etablierte Anbieter Disaggregation integrieren, ohne auf proprietäre Arrays zu verzichten. Bei solchen Angeboten ist zu prüfen, wie offen die Schnittstellen sind und ob Kapazität und Leitung wirklich unabhängig skaliert werden können.
• VAST Data (DASE — Disaggregated Shared Everything): VAST verfolgt einen dedizierten Disaggregationsentwurf (DASE), bei dem Control-/Compute-Ressourcen und Kapazitätseinheiten getrennt skaliert werden können. Kapazität kann unabhängig hinzugefügt werden, während Controller-/Serviceressourcen skaliert werden, um Performance-Ziele zu erreichen. VAST zielt hier klar auf KI/HPC-Workloads und positioniert das System als echte Disaggregation statt nur als modernes Array.
• IBM Storage Scale / IBM-unterstützte Ceph-Varianten: IBM bietet mit Storage Scale (früher GPFS / Spectrum Scale) und IBM Storage Ceph Software-Stacks Lösungen an, die große verteilte Datei-/Objekt-/Blockpools erlauben. Diese Softwareansätze sind per Design skalierbar und erlauben in Hyperscaler-ähnlichen Designs eine Trennung von Performance- und Kapazitäts-Ressourcen. In vielen Implementierungen wird Disaggregation per Software über Commodity-Hardware realisiert. IBM unterstützt Ceph mit Enterprise-Add-ons und integriert es in seine Cloud-Pak- und OpenShift-Umgebungen.

Neue Hardwareansätze: Data Processing Unit und Computational-Storage

Einige neuere Ansätze versuchen, Disaggregation mit Spezialhardware (DPU, SmartNICs, Computational-Storage) zu ermöglichen, was Performance- und Offload-Vorteile bringen kann: Als Beispiel sei hier Fungible kurz erklärt:

• Fungible: Fungible verfolgte einen DPU-basierten Ansatz für sehr hohe IOPS und niedrige Latenz in disaggregierten Clustern. Der DPU-Ansatz ist weiter relevant, aber mittlerweile weniger als eigenständiges Produkt im Markt sichtbar. DPU-basierte Systeme adressieren genau die Netzwerk-und Offload-Probleme, die Disaggregation sonst limitiert. Fungible wurde 2023 von Microsoft übernommen. Der von Fungible initiierte DPU-Ansatz lebt aber in verschiedenen OEM-Integrationen fort (zum Beispiel Nvidia BlueField, AMD Pensando), die ähnliche Ziele wie Offload und Fabric-Optimierung verfolgen.

Composable und Server-embedded Lösungen

Composable-Anbieter sind nicht identisch mit disaggregiertem Shared-Pool-Storage. Sie fokussieren auf dynamisches Zusammenstellen von Ressourcen, oft PCIe/PCIe-Fabric oder Server-embedded Funktionalitäten:

• Liqid: Liqid bietet eine Softwaredefinierte Composable-Plattform, die PCIe-/NVMe-Ressourcen (und zunehmend GPU/Memory via CXL) in Pools verwaltet und sie den Hosts dynamisch zuweist. Das ist ein klassischer Composable-Ansatz: sehr gute Eignung für Bare-Metal und GPU-zentrierte KI-Workloads, weniger ein direktes Storage-Array-Replacement im traditionellen Sinne.
• Nebulon: Nebulon verfolgt ein Server-Embedded, Cloud-verwaltetes Modell und bietet so Cloud-defined Storage-Services direkt in Servern an. Das ist ein hybrider Ansatz zwischen lokalem Server-Storage und einer gelenkten, zentralisierten Managementebene. Das eignet sich für lokale Cloud-Bereitstellungen, gestaltet sich aber strukturell anders als ein rein disaggregierter Shared-Pool.

Wie die unterschiedlichen Ansätze die Anforderungen adressieren

Jeder Ansatz hat seinen Platz in den zahlreichen Anwendungsfällen in heutigen Rechenzentren. Im Folgenden geben wir einen Kurzüberblick, wofür sich die oben genannten Ansätze eignen.

Moderne Arrays mit Disaggregations-Features (Dell, Pure, NetApp etc.): sinnvoll, wenn Organisationen bestehende Betriebsmodelle behalten, aber NVMe-Performance und Cloud-Orchestrierung benötigen; geringer Migrationsaufwand, oft proprietäre Control Plane.

Native Disaggregated Platforms (VAST, IBM Scale-Designs): bieten echte physische Trennung von Kapazität und Compute; besser geeignet, wenn sehr große KI/HPC-Workloads und unabhängige Wachstumsprofile zu bedienen sind.

DPU und Computational Storage (Fungible): lösen Netzwerk-/CPU-Bottlenecks durch Offload; technisch anspruchsvoll, oft in Hyperscaler- und sehr Performance-kritischen Umgebungen sinnvoll.

Composable und Server-Embedded (Liqid, Nebulon): lösen das Problem der schnellen, APL-spezifischen Ressourcenzusammenstellung (zum Beispiel GPUs, NVMe), ideal für Bare-metal-KI-Workloads oder Edge-Umgebungen; kein vollwertiger Ersatz für ein zentrales disaggregiertes Storage-Pool-Design.

Checkliste: So vergleichen Sie Anbieter

IT-Verantwortliche und -Entscheider sollten verschiedene Fragen und Anforderungen auf ihrer Checkliste haben, bevor sie ihre Wahl für eine disaggregierte Storage-Lösung wählen.

• Handelt es sich um echte physische Disaggregation: Kann Kapazität unabhängig von Control und Performance skaliert werden. Gibt es separate Geräteeinheiten und Nodes? Ist es ein Array mit besserer Verwaltungsabstraktion? (zum Beispiel DASE-Modelle statt Arrays).
• Welcher Transport- und Protokoll-Stack wird genutzt: Unterstützt die Lösung NVMe-oF (RDMA/RoCE) oder NVMe/TCP? Welche Netzwerkanforderungen bestehen (HCAs, Switch-Support, Congestion-Control)?
• Wie gestatelt sich die Offload- und DPU-Integration: Nutzt der Anbieter DPU/SmartNIC-Offload oder Computational Storage, und wie bewährt ist die Software-Ökologie dafür? So bieten DPU-Ansätze beispielsweise Performance, erhöhen aber die Komplexität.
• Wie steht es um die APIs, Orchestrierung und Composability: Gibt es offene APIs (REST/Redfish/Kubernetes-CSI), Integrationen zu Kubernetes/OpenStack, und wie leicht lässt sich Composability  realisieren?
• Wie werden Sicherheit und Mandantenfähigkeit gewährleistet: Wie sind Authentifizierung, Verschlüsselung (Data in Flight oder Data at Rest) und Mandantenisolation realisiert?
• Wie gut sind die betriebliche Reife und das Ökosystem: Wie gut sind Monitoring, Telemetrie, AIOps-Funktionen und der Support-Stack? Das ist besonders relevant bei hochautomatisierten und Cloud-ähnlichen Betriebsmodellen.

Fazit

Disaggregiertes Storage steht für eine zukunftssichere Speicherarchitektur, die Flexibilität, Performance und Effizienz in den Mittelpunkt stellt. Durch die Trennung von Rechen- und Speicherressourcen können Unternehmen Workloads präziser steuern, Ressourcen besser auslasten und auf sich ändernde Anforderungen schneller reagieren.

Den Vorteilen stehen jedoch erhöhte Anforderungen an Netzwerkleistung, Management-Komplexität und Sicherheit gegenüber. Eine erfolgreiche Implementierung setzt daher auf durchdachte Architektur, automatisierte Orchestrierung und ein hohes Maß an Transparenz.

Langfristig ist zu erwarten, dass AI-gestütztes Storage-Management, In-Storage-Analytics und integrierte Cybersecurity-Funktionen zum Standard werden – und so den Weg zu noch autonomeren, resilienteren Speicherinfrastrukturen ebnen.