Software-Defined Storage: Kriterien für Server-Hardware

Besonders häufig ist ein Hardware-RAID-Controller mit aktivem Write-Cache der Auslöser: Er verdeckt den physischen Zustand der Datenträger vor Ceph, vSAN oder Storage Spaces Direct. Die Software kann dann weder Fehlerzustände noch Latenzen und Rebuild-Vorgänge korrekt steuern.

Die Software-Defined-Storage-Hardware-Auswahl beginnt daher nicht bei der nutzbaren Kapazität. Entscheidend sind direkter Laufwerkszugriff, konsistente Latenzzeiten, Netzwerkanbindung, RAM für Metadaten sowie die Schreibfestigkeit der Flash-Schicht. Erst danach folgen Laufwerksdichte und Anschaffungspreis.

SDS benötigt keine intelligente RAID-Abstraktion. SDS benötigt unverfälschten Zugriff auf Medien, Fehlerzustände und Warteschlangen.

Vom RAID-Controller zum HBA: Direkter Laufwerkszugriff als Basis

Klassische RAID-Controller wurden für ein anderes Betriebsmodell entwickelt. Sie fassen mehrere Laufwerke zu einem logischen Volume zusammen, nutzen einen eigenen Cache und behandeln Fehler auf Controller-Ebene. Das ist bei einem einzelnen Server mit lokalem Dateisystem sinnvoll. In einem verteilten Speichercluster kollidiert dieses Modell mit der Speicherlogik der SDS-Software.

Ceph verteilt Daten und Replikate selbst. VMware vSAN verwaltet Speicherobjekte über mehrere Hosts. Storage Spaces Direct bildet virtuelle Datenträger aus den lokalen Medien der Clusterknoten. Jede dieser Plattformen benötigt Sicht auf einzelne Laufwerke. Dazu gehören SMART-Werte, Medienfehler, Warteschlangentiefe, Ausfallstatus und die reale Latenz pro Gerät.

Ein Hardware-RAID-Controller mit aktivem Write-Back-Cache verschiebt diese Informationen hinter eine Abstraktionsschicht. Das erzeugt mehrere Probleme:

• Die SDS-Schicht erkennt nicht mehr zuverlässig, welches physische Laufwerk Latenzspitzen oder Medienfehler verursacht.
• Ein Controller-Cache kann Schreibbestätigungen liefern, bevor Daten dauerhaft auf dem Medium liegen.
• Rebuild-Logik des Controllers und Replikationslogik der SDS-Plattform arbeiten parallel, aber ohne gemeinsame Zustandsbasis.
• Ein ausgefallener Controller wird zum zusätzlichen Engpass und erschwert den Hardwaretausch.
• Laufwerkswechsel und Firmware-Diagnose sind weniger transparent.

Die passende Komponente ist ein Host Bus Adapter im IT-Modus. IT steht hier für Initiator Target. Der Adapter reicht SAS- oder SATA-Laufwerke ohne RAID-Virtualisierung an das Betriebssystem durch. Die SDS-Software erhält damit direkten Zugriff auf jeden Datenträger.

Bei NVMe-Laufwerken ist die bevorzugte Anbindung noch direkter: PCIe-Verbindung ohne RAID-Schicht. NVMe wurde für parallele Warteschlangen und geringe Protokoll-Overheads entwickelt. Ein zusätzlicher RAID-Layer reduziert diesen Vorteil meist statt ihn zu nutzen.

Tri-Mode-Adapter für gemischte Backplanes

Gemischte Serverkonfigurationen sind im SDS-Betrieb üblich. Ein Host kann NVMe-SSDs für Cache oder WAL/DB-Bereiche, SAS-SSDs für Kapazitätsdaten und große SATA-HDDs für kalte Daten kombinieren. Tri-Mode-Adapter vereinfachen diese Architektur. Sie unterstützen SAS, SATA und NVMe über eine gemeinsame Backplane.

Das reduziert Verkabelungsaufwand und schafft Flexibilität bei der Laufwerksbestückung. Es ersetzt jedoch keine Prüfung der Plattformfreigabe. Backplane, Adapter, PCIe-Slots und verwendete Laufwerke müssen die gewünschte Anzahl von PCIe-Lanes tatsächlich bereitstellen. Eine NVMe-Backplane mit hoher Laufwerksdichte ist wertlos, wenn sie intern über zu wenige PCIe-Lanes angebunden ist.

Für die Software-Defined-Storage-Kompatibilität gilt eine klare Reihenfolge:

1. SDS-Plattform und Version definieren. Ceph, vSAN, Storage Spaces Direct und OpenZFS-basierte Systeme haben unterschiedliche Hardware- und Treiberanforderungen.

2. Den Laufwerkszugriff prüfen. Für SAS und SATA ist ein HBA im IT-Modus erforderlich. Für NVMe ist eine direkte PCIe-Anbindung vorzuziehen.

3. Backplane und PCIe-Topologie prüfen. Entscheidend ist nicht nur die Zahl der Einschübe, sondern die reale Lane-Zuordnung pro Laufwerk.

4. Firmwarestände vereinheitlichen. HBA, Backplane, SSDs, Netzwerkkarten und Mainboard müssen in einem dokumentierten, getesteten Stand betrieben werden.

5. Keine verdeckte RAID-Funktion aktiv lassen. Ein Controller im JBOD-Modus kann je nach Modell weiterhin Caching oder Fehlerbehandlung zwischen Betriebssystem und Laufwerk schalten. IT-Modus ist eindeutiger.

Netzwerk-Performance: Warum RDMA und 25 GBit/s den Unterschied machen

SDS repliziert, verteilt und korrigiert Daten über das Netzwerk. Der Netzwerkpfad ist damit Teil des Storage-Backends. Ein Cluster mit schnellen NVMe-SSDs und 10-Gbit/s-Uplinks produziert keine NVMe-Latenz. Er produziert Netzwerkwartezeiten.

Bei klassischen HDD-Architekturen blieb ein langsames Netzwerk oft hinter der Medienlatenz verborgen. Eine einzelne rotierende Festplatte arbeitet im Millisekundenbereich. Moderne NVMe-SSDs antworten dagegen in Mikrosekunden. Der Flaschenhals verlagert sich vollständig auf Netzwerk, CPU, Speicherbus und Protokollverarbeitung.

Für produktive SDS-Cluster mit Flash-Speicher ist 25 GBit/s die belastbare Untergrenze bei größeren Konfigurationen. Storage Spaces Direct empfiehlt für Cluster ab vier Knoten 25-Gbit/s-Netzwerkkarten mit RDMA-Unterstützung. 10 GBit/s kann bei kleinen, moderat belasteten Installationen funktionieren. Es bietet jedoch wenig Reserve für Rebalancing, Rebuilds, Migrationen und parallele Client-Last.

RDMA reduziert CPU-Overhead, weil Daten direkt zwischen Netzwerkkarte und Arbeitsspeicher übertragen werden können. Die CPU muss nicht jede Kopie durch den normalen Netzwerkstack bewegen. Je nach Plattform kommen iWARP oder RoCE zum Einsatz. NVMe over RoCE v2 kann End-to-End-Latenzen von etwa 80 bis 150 µs ermöglichen. Diese Werte sind nur erreichbar, wenn das gesamte Design konsistent ist: Netzwerkkarten, Switches, Treiber, Pufferkonfiguration und Priorisierung.

RoCE erfordert eine saubere Ethernet-Konfiguration. Verlustfreie oder kontrolliert verlustarme Übertragung, passende Puffer und konsistente Einstellungen auf allen Switchports sind keine Detailarbeit. Fehlkonfigurationen führen zu Paketverlusten, Retransmits und Latenzspitzen. Der Durchsatz bleibt dann auf dem Datenblatt hoch, während die Anwendung unregelmäßig reagiert.

Ein zweites physisches Netzwerk oder zumindest klar getrennte logische Pfade für Storage-Verkehr, Management und Client-Zugriffe verhindert, dass Wartungsaufgaben den Datenpfad verdrängen. Besonders bei Rebuilds ist diese Trennung relevant. Der Cluster muss ausgefallene oder verschobene Daten replizieren, während produktive I/O weiterläuft.

Die Netzwerkbandbreite bestimmt nicht nur den Spitzendurchsatz. Sie bestimmt, wie schnell ein Cluster nach einem Fehler wieder einen konsistenten Schutzstatus erreicht.

RAM-Dimensionierung für Metadaten und Cache-Operationen

Arbeitsspeicher ist im SDS-Host kein allgemeiner Komfortparameter. Er trägt Metadaten, Caches, Prüfsummenstrukturen, Netzwerkpuffer und Verwaltungsdaten der Storage-Dienste. Zu wenig RAM reduziert nicht nur Cache-Treffer. Er verlängert Recovery-Vorgänge und kann den gesamten Host unter Last instabil machen.

Die Anforderungen unterscheiden sich erheblich nach Plattform. Storage Spaces Direct benötigt mindestens 4 GB RAM pro TB Cache-Kapazität. Diese Angabe betrifft die Verwaltung der Cache-Schicht und ersetzt nicht den Speicherbedarf des Betriebssystems, der virtuellen Maschinen oder weiterer Rollen auf dem Host.

Bei Ceph ist der Speicherbedarf stark an die Zahl und Art der OSDs gebunden. Für BlueStore-OSDs sind etwa 4 bis 8 GiB RAM pro OSD als betriebliche Größenordnung anzusetzen. Bei Rebalancing, Recovery oder hoher Metadatenlast steigt der Bedarf. Ein Host mit vielen kleinen SSDs kann dadurch mehr RAM benötigen als ein Host mit wenigen großen Laufwerken, obwohl die Rohkapazität identisch ist.

OpenZFS-basierte Systeme setzen ECC-RAM voraus. ZFS berechnet und prüft Prüfsummen entlang des Datenpfads. Ein Bitfehler im Arbeitsspeicher kann Daten oder Metadaten verfälschen, bevor die Prüfsumme geschrieben wird. ECC-RAM verhindert nicht jede Form von Datenverlust. Er reduziert jedoch das Risiko nicht korrigierter Einzelbitfehler im Speicher erheblich.

Für ein vSAN-ESA-Einstiegsprofil gelten mindestens 16 CPU-Kerne und 128 GB RAM pro Host als brauchbare Größenordnung. Das ist kein universeller Sollwert für jede SDS-Plattform. Es zeigt jedoch die Richtung: NVMe-basierte Speicherarchitekturen benötigen keine schwächer dimensionierten Server. Sie benötigen in vielen Fällen mehr CPU- und RAM-Reserve als hybride Systeme, weil Medienlatenzen wegfallen und die Software schneller arbeiten muss.

Bei der RAM-Planung ist daher nicht die Bruttokapazität der Laufwerke der erste Wert. Maßgeblich sind:

• Anzahl der OSDs, Disk-Gruppen oder Storage-Pools pro Host.
• Größe und Typ der Cache-Schicht.
• Replikations- oder Erasure-Coding-Verfahren.
• Zahl paralleler virtueller Maschinen, Container oder Datenbank-Workloads.
• Erwartete Rebuild- und Rebalance-Last.
• Speicherbedarf des Hypervisors und der Management-Dienste.

Schreibfestigkeit und PLP: Anforderungen an Enterprise-SSDs

Eine SSD für Kapazitätsdaten und eine SSD für Schreibcache erfüllen unterschiedliche Aufgaben. Die Schnittstelle kann identisch sein. Das Belastungsprofil ist es nicht.

Die Kennzahl DWPD beschreibt, wie oft die vollständige nominelle Kapazität einer SSD pro Tag über die spezifizierte Lebensdauer geschrieben werden darf. Kapazitäts-SSDs liegen häufig bei 0,3 bis 1 DWPD. Für eine stark beanspruchte Cache-Schicht sind mindestens 3 DWPD die sachliche Untergrenze. Spezialisierte SLC-basierte Schreibcaches können bis zu 65 DWPD erreichen.

Die Auswahl darf nicht auf TBW-Angaben eines einzelnen Laufwerks reduziert werden. Entscheidend ist die reale Schreibverstärkung der Plattform. Replikation erzeugt zusätzliche Netzwerk- und Medienwrites. Erasure Coding erzeugt Berechnungs- und Schreibvorgänge für Paritätsdaten. Datenbanken, VDI-Umgebungen und Log-basierte Anwendungen schreiben in kurzen, intensiven Mustern. Eine nominell große SSD mit geringer DWPD kann dabei schneller verschleißen als eine kleinere Enterprise-SSD mit hoher Ausdauer.

Power-Loss Protection ist für Cache-, Journal- und SLOG-nahe Rollen Pflicht. PLP hält bei Stromausfall genügend Energie vor, um Daten aus flüchtigen DRAM- oder Controller-Puffern in den NAND-Speicher zu schreiben. Ohne diese Funktion kann ein Laufwerk bereits bestätigte Schreibvorgänge verlieren. In einem verteilten System ist das kein lokaler Schönheitsfehler. Es kann Konsistenzprüfungen, Recovery-Zeiten und Fehlerdiagnosen erheblich verschärfen.

Consumer-SSDs sind daher keine Alternative für produktive SDS-Write-Caches. Auch wenn kurzfristige Benchmark-Werte überzeugend aussehen, fehlen häufig PLP, konsistente Latenz unter Dauerlast, definierte Firmware-Zyklen und ausreichende Schreibausdauer.

Hybrid-Architekturen korrekt dimensionieren

In Hybrid-Systemen kombiniert die Architektur Flash für Cache und HDDs für Kapazität. Die Flash-Schicht darf nicht nach dem Motto „so groß wie möglich innerhalb des Budgets“ gewählt werden. Sie muss zur effektiv genutzten Kapazität und zum erwarteten Arbeitssatz passen.

VMware vSAN fordert in Hybrid-Konfigurationen, dass das Flash-Cache-Laufwerk mindestens 10 Prozent der erwarteten genutzten Speicherkapazität der Kapazitätslaufwerke abdeckt. Diese Grenze ist ein Mindestwert, keine Leistungszusage. Hohe Schreiblast, viele kleine Blöcke oder Datenbank-I/O erfordern mehr Reserve.

CPU-Last und NVMe-Anbindung: Engpässe in modernen SDS-Clustern

Schneller Flash-Speicher reduziert die Wartezeit auf Medien. Er reduziert nicht die Arbeit der Software. Im Gegenteil: Sobald SSDs und Netzwerk keine langen Pausen mehr erzeugen, treten CPU-Last und Speicherbandbreite deutlich hervor.

Ceph kann für ein einzelnes NVMe-OSD etwa fünf bis sechs CPU-Kerne auslasten. Unter Spitzenlast sind deutlich höhere Werte möglich. Ursachen sind Prüfsummen, Kompression, Verschlüsselung, Replikation, Netzwerkverarbeitung, BlueStore-Verwaltung und Recovery-Prozesse. Ein Server mit hoher NVMe-Dichte und zu wenig Kernen erreicht dann nicht die erwarteten IOPS. Die SSDs warten auf CPU-Zeit.

Die Kernzahl allein genügt nicht. Relevante Parameter sind auch:

• PCIe-Generation und verfügbare Lanes pro CPU-Sockel.
• NUMA-Zuordnung von Netzwerkkarten und NVMe-Backplanes.
• Speicherkanäle und bestückte DIMM-Module.
• Interrupt-Verteilung der Netzwerkkarten und NVMe-Geräte.
• Taktverhalten unter Dauerlast und thermische Verlustleistung.
• Reserven für Rebuild, Scrubbing und Software-Updates.

Ein häufiger Konstruktionsfehler ist die Anbindung vieler NVMe-Laufwerke über einen einzelnen PCIe-Switch oder einen Engpass zwischen CPU und Backplane. Die Laufwerke sind technisch vorhanden, teilen sich aber eine zu schmale Uplink-Verbindung. Das Resultat ist ein hoher nomineller SSD-Durchsatz bei niedriger realer Clusterleistung.

NUMA-Effekte sind ebenfalls messbar. Befindet sich die RDMA-Netzwerkkarte an CPU-Sockel 0 und die Mehrzahl der NVMe-Laufwerke an Sockel 1, laufen Daten über den Interconnect zwischen den Prozessoren. Das erhöht Latenz und reduziert die Skalierung. Bei hoher I/O-Last sollten Netzwerkkarten, NVMe-Pfade und die zuständigen CPU-Kerne möglichst innerhalb derselben NUMA-Domäne liegen.

Thermik gehört in dieselbe Bewertung. NVMe-SSDs, leistungsstarke Netzwerkkarten und moderne CPUs erzeugen unter permanenter I/O-Last relevante Abwärme. Drosselt eine SSD wegen unzureichender Luftführung, verändert sich nicht nur ihr Durchsatz. Es verändern sich die Latenzverteilung und damit das Verhalten des gesamten Pools. Ein Servergehäuse mit hoher Laufwerksdichte benötigt deshalb einen klaren Luftstrom über Backplane, NVMe-Träger, Prozessoren und NICs.

Die Auswahl muss zur SDS-Software passen

Es gibt keine universelle SDS-Server-Hardware-Empfehlung. Ceph, vSAN, Storage Spaces Direct und OpenZFS setzen unterschiedliche Schwerpunkte. Die technischen Grundregeln bleiben jedoch konstant: direkte Laufwerksanbindung, Enterprise-SSDs mit PLP, ausreichender ECC-RAM, schnelle Netzwerkkarten und CPU-Reserven für die Softwareebene.

Die folgende Zuordnung verdichtet die relevanten Spezifikationen.

Software-Defined Storage verlagert die Intelligenz vom Controller in den Cluster. Die Server-Hardware muss diese Architektur nicht ersetzen, sondern präzise unterstützen. Direkter Zugriff, niedrige Latenz, definierte Ausfallsicherheit und berechenbare Reserven sind die messbaren Kriterien. Wer diese Reihenfolge einhält, baut keinen Server mit vielen Laufwerken. Er baut einen Speicherhost, der unter Last, bei Rebuilds und nach Komponentenausfällen kontrollierbar bleibt.