Welche Hardware braucht ein Storage-Cluster? Labor vs. Produktion

Kurz gesagt: Ein Storage-Cluster braucht pro Node vor allem genug Arbeitsspeicher, genug CPU-Threads für jeden Speicherdienst, verlässliche Datenträger und ein schnelles Netz. Für Ceph gilt als Faustregel laut Doku: mindestens 8 GiB RAM und ein bis drei CPU-Threads pro Festplatte (bei NVMe vier bis sechs), dazu Enterprise-SSDs mit Power-Loss-Protection, ein HBA statt RAID-Controller und mindestens 10 Gbit/s. Zum Lernen reichen drei VMs auf einem Rechner; für echten Betrieb empfehlen Ceph und Proxmox mindestens drei möglichst gleiche Server. Dieser Guide trennt beides konsequent.

Bei einem einzelnen NAS ist die Hardwarefrage überschaubar: genug Festplattenschächte, etwas RAM, fertig. Ein Storage-Cluster stellt andere Anforderungen, weil jede Schreiboperation auf mehreren Servern landet, weil ein ausgefallener Server von den übrigen aufgefangen werden muss und weil die Speicherdienste selbst Rechenleistung und Arbeitsspeicher verbrauchen. Wer hier am falschen Ende spart, bekommt einen Cluster, der im Normalbetrieb funktioniert und genau dann einbricht, wenn er seine Aufgabe erfüllen soll: bei einem Ausfall.

Für wen ist dieser Guide? Für alle, die einen Storage-Cluster mit Ceph, Proxmox VE und Ceph, LINSTOR/DRBD oder Longhorn planen und wissen wollen, welche Hardware sie brauchen: vom Homelab-Einsteiger, der drei Mini-PCs vergleicht, bis zur Admin, die eine Bestellung für den Produktivbetrieb begründen muss.

Voraussetzungen: Du weißt, was ein Storage-Cluster ist und dass er Daten mehrfach über mehrere Server verteilt. Falls nicht, lies zuerst Was ist ein Storage-Cluster?. Linux-Grundkenntnisse helfen beim Prüfen vorhandener Hardware.

Was du lernst:

• wie du den CPU- und RAM-Bedarf pro Node aus der Anzahl der Datenträger ableitest, mit den Formeln aus der offiziellen Doku,
• worauf es bei HDD, SATA-SSD und NVMe ankommt und warum Power-Loss-Protection (PLP) so oft fällt,
• warum ein RAID-Controller im Storage-Cluster stört,
• welche Hardware für ein Lernlabor, einen Homelab-Cluster und den Produktivbetrieb sinnvoll ist,
• wie du vorhandene Hardware mit lesenden Befehlen prüfst, bevor du irgendetwas installierst.

Hinweis zum Stand: Alle Zahlen und Empfehlungen stammen aus der offiziellen Dokumentation, Stand Oktober 2026: Ceph 20.2 Tentacle, Proxmox VE 9.2, DRBD 9 und LINSTOR (LINBIT User Guides) sowie Longhorn 1.13.0. LabKompass hat die genannten Hardwarekonfigurationen nicht selbst vermessen. Gleiche die Angaben vor einem Kauf mit der Doku deiner Version ab und probiere neue Aufbauten zuerst in einer Testumgebung aus.

Warum ein Storage-Cluster andere Hardware braucht als ein NAS #

Drei Eigenschaften bestimmen den Hardwarebedarf eines Storage-Clusters, und sie gelten für Ceph, DRBD und Longhorn gleichermaßen:

1. Jeder Schreibvorgang passiert mehrfach. Bei dreifacher Replikation schreibt der Cluster jedes Byte auf drei Server. Das kostet Netzwerkbandbreite, CPU-Zeit und Schreibleistung auf jedem beteiligten Datenträger. Bei Ceph meldet das primäre OSD dem Client den Erfolg erst, nachdem die übrigen OSDs die Kopie bestätigt haben; DRBD mit dem üblichen Protokoll C wartet ebenfalls auf den Schreibvorgang beim Partner. Der langsamste beteiligte Datenträger bestimmt also mit, wie lange eine Anwendung wartet.
2. Die Speicherdienste sind Software. Ceph startet für jeden Datenträger einen eigenen Dienst, das OSD (Object Storage Daemon, der Dienst, der einen Datenträger im Cluster verwaltet). Jedes OSD braucht eigenen Arbeitsspeicher und eigene CPU-Zeit. Dazu kommen Monitore (MON, sie halten per Mehrheitsentscheid fest, wie der Cluster gerade aussieht) und Manager (MGR, Dashboard und Metriken).
3. Ausfälle erzeugen Last. Fällt ein Datenträger oder Server aus, stellt der Cluster die fehlenden Kopien auf den übrigen Datenträgern wieder her. Diese Recovery läuft zusätzlich zum normalen Betrieb und braucht spürbar mehr Arbeitsspeicher, CPU und Netzwerk. Die Proxmox-Doku nennt ausdrücklich Recovery, Rebalancing und Backfilling als Situationen mit erhöhtem Speicherbedarf.

Daraus folgt der wichtigste Grundsatz dieses Guides: Dimensioniere für den Fehlerfall, nicht für den Leerlauf. Ein Cluster, der im Normalbetrieb 90 Prozent seines Arbeitsspeichers belegt, hat keine Reserve für die Recovery.

Ein zweiter Grundsatz kommt aus der Proxmox-Doku: Ein hyperkonvergenter Cluster aus Proxmox VE und Ceph soll aus mindestens drei, möglichst identischen Servern bestehen. Identisch ist kein Selbstzweck. Ein Cluster verteilt Daten gleichmäßig; ein schwächerer Node bremst alle Vorgänge, an denen er beteiligt ist, und ein Node mit mehr Kapazität trägt bei einem Ausfall einen überproportionalen Teil der Daten.

Drei Hardwareklassen: Lernlabor, Homelab-Cluster, Produktion #

Bevor es um einzelne Komponenten geht, hilft eine ehrliche Einordnung. Laut Ceph-Doku können kleine Produktiv- und Entwicklungscluster „mit bescheidener Hardware“ erfolgreich laufen, und eine Sandbox auf einem Laptop oder drei Raspberry Pi kommt mit weniger aus als ein großer Produktivcluster; für Produktion betont die Doku aber ausdrücklich Enterprise-Datenträger. Dazwischen liegt der typische Homelab-Cluster.

Die wichtigste Zeile ist die letzte. Ein Lernlabor in VMs ist ideal, um Befehle, Zustände und Ausfälle kennenzulernen. Es sagt aber nichts über die Leistung echter Hardware aus: Drei VMs auf demselben Rechner teilen sich CPU, Arbeitsspeicher und den physischen Datenträger. Ein Homelab-Cluster wiederum kann sehr zuverlässig laufen, unterschreitet aber oft einzelne Empfehlungen der Doku, etwa beim Netzwerk oder bei Consumer-SSDs. Das ist eine bewusste Entscheidung, keine Schande, solange du weißt, an welcher Stelle du abweichst und was im Fehlerfall passiert.

CPU: Threads je Dienst zählen #

Die CPU wird in Storage-Clustern oft unterschätzt, weil Speicher nach „Festplattenjob“ klingt. Tatsächlich rechnet jedes OSD Prüfsummen, verwaltet Metadaten, spricht über das Netz mit anderen OSDs und koordiniert Replikation und Recovery.

Was die Ceph-Doku empfiehlt (Tentacle):

• Pro HDD-OSD mindestens 1, empfohlen 3 CPU-Threads; pro NVMe-OSD mindestens 4, empfohlen 6 Threads.
• NVMe-OSDs können laut Doku in echten Clustern leicht fünf bis sechs Kerne auslasten.
• Bei der Auswahl solle man auf IOPS pro Kern achten, also wie viele Ein- und Ausgabeoperationen pro Sekunde ein Kern verarbeiten kann.
• Monitore und Manager brauchen nur bescheidene Prozessoren; für einen Monitor nennt die Mindesttabelle 2 Kerne.
• Der Metadaten-Server für CephFS (MDS) arbeitet single-threaded und profitiert von hohem Takt mehr als von vielen Kernen.

Was die Proxmox-Doku empfiehlt: Als einfache Faustregel mindestens einen CPU-Kern oder Thread pro Ceph-Dienst. Das Beispiel dort: ein Monitor, ein Manager und sechs OSDs ergeben acht Kerne, die nur für Ceph reserviert werden sollen. Für sehr schnelle NVMe-OSDs rechnet Proxmox mit vier bis sechs Threads pro OSD.

Die beiden Zahlen widersprechen sich nicht, sie beantworten verschiedene Fragen. Die Proxmox-Regel beschreibt das Minimum für stabilen Betrieb, die Ceph-Tabelle die Empfehlung für gute Leistung. Ein Rechenbeispiel für einen Node mit vier NVMe-OSDs, einem Monitor und einem Manager:

Läuft der Node hyperkonvergent, also mit VMs oder Containern auf demselben Server, kommen deren Threads oben drauf. Die Ceph-Troubleshooting-Doku warnt übrigens ausdrücklich, dass Prozesse, die auf derselben Hardware wie die OSDs laufen und selbst in Ceph schreiben (etwa VMs), deutliche OSD-Latenzen verursachen können, und hält solche Nachbarschaft „im Allgemeinen“ nicht für empfehlenswert. Proxmox setzt trotzdem genau dieses Modell um; es funktioniert, wenn du die Ressourcen bewusst aufteilst.

Ein Wort zu ARM: Proxmox VE gibt es seit August 2026 auch für 64-Bit-ARM. Die Ceph-Doku schränkt aber ein, dass ARM-Container „Stand Dezember 2025“ nur einen Teil der Ceph-Dienste bereitstellen; der SMB-Dienst etwa fehlt noch. Für ein Lernlabor ist ARM eine Option, für Produktion prüfst du die Liste der unterstützten Dienste deiner Version.

Arbeitsspeicher: die wichtigste Rechnung #

Fehlt Arbeitsspeicher, werden OSDs langsam oder vom Kernel wegen Speichermangels beendet, genau dann, wenn eine Recovery zusätzlichen Speicher verlangt. Deshalb lohnt es sich, hier sauber zu rechnen.

Ceph: osd_memory_target mal zwei #

Jedes BlueStore-OSD (BlueStore ist das Speicherformat, mit dem Ceph-OSDs direkt auf den Datenträger schreiben) richtet seinen Cache nach dem Wert osd_memory_target. Der Standard liegt bei 4 GiB. Der Wert ist ein Ziel, keine harte Grenze: Das OSD kann kurzfristig mehr belegen.

Die Ceph-Doku empfiehlt, dass der gesamte Server-RAM größer ist als Anzahl OSDs mal osd_memory_target mal 2, und rät zusätzlich, mindestens 20 Prozent Reserve für Lastspitzen einzuplanen.Herstellerangabe Als Größenordnung nennt sie einen 1U-Server mit acht bis zehn OSDs, der mit 128 GB gut ausgestattet sei. Für die Einstellung selbst gilt:

• unter 2 GB: nicht empfohlen,
• 2 bis 4 GB: funktioniert meist, aber womöglich mit schlechterer Leistung,
• 4 GB: aktueller Standard,
• bei HDD-OSDs kann ein effektiver Wert von mindestens 6 GiB helfen, langsame Anfragen zu vermeiden.

Proxmox formuliert es knapper: mindestens 8 GiB pro OSD für gute Leistung, das OSD selbst benötige standardmäßig 4 GiB. Das ist dieselbe Größenordnung wie die Ceph-Formel.

Rechenbeispiel für einen Node mit vier OSDs, einem Monitor und einem Manager, ohne VMs:

Wer Proxmox hyperkonvergent betreibt, addiert den Arbeitsspeicher aller VMs und Container, die auf diesem Node laufen sollen, und zwar auch die, die bei einem Ausfall eines anderen Nodes hierher umziehen. Genau diese Gäste vergisst man in der Planung am häufigsten.

Autotuning unter cephadm #

Installierst du Ceph mit cephadm, schaltet der Bootstrap laut Doku standardmäßig osd_memory_target_autotune ein und reserviert dafür 70 Prozent des gesamten Host-Speichers für Ceph (Einstellung autotune_memory_target_ratio = 0,7). Für konvergente Hosts, auf denen noch andere Dienste laufen, zeigt die Doku diesen Befehl:

ceph config set mgr mgr/cephadm/autotune_memory_target_ratio 0.2

Damit beansprucht Ceph nur noch 20 Prozent des Host-Speichers. Ob das für deine Anzahl OSDs reicht, rechnest du mit der Formel oben nach. Proxmox nutzt diesen cephadm-Mechanismus nicht; dort setzt du den Wert bei Bedarf direkt, das Beispiel aus der Proxmox-Doku lautet ceph config set osd osd_memory_target 8G.

Monitore, Manager und Metadaten-Server #

Die Ceph-Doku nennt für Monitor- und Manager-Nodes: Für sehr kleine Cluster genügen 32 GB, für Cluster bis etwa 300 OSDs 64 GB. In einem typischen Drei-Node-Cluster laufen MON und MGR aber auf denselben Servern wie die OSDs; dann zählst du ihren Bedarf einfach zum Node dazu. Für den MDS (nur bei CephFS) enthält die Hardware-Seite einen Widerspruch: Der Fließtext nennt 1 GiB als Minimum, die Mindesttabelle „8+ GiB per daemon“. Plane im Zweifel mit dem höheren Wert.

LINSTOR/DRBD und Longhorn #

DRBD arbeitet im Kernel und braucht deutlich weniger Arbeitsspeicher als ein Ceph-OSD. Der DRBD-User-Guide nennt für die Bitmap, mit der DRBD sich merkt, welche Blöcke noch synchronisiert werden müssen, etwa 32 MiB pro 1 TiB Speicher bei 4-KiB-Granularität; seit DRBD 9.3 lässt sich eine gröbere Granularität wählen. Der LINSTOR-Controller ist eine Java-Anwendung und braucht eine Java-Laufzeit; konkrete RAM-Mindestwerte nennt der Guide dafür nicht, plane also mit Messwerten aus deinem eigenen Testaufbau.

Longhorn nennt in seinen Best Practices als Mindest-Empfehlung für die V1-Data-Engine 3 Nodes mit je 4 vCPUs und 4 GiB RAM. Für die neuere V2-Data-Engine kommen pro Node ein dedizierter CPU-Kern (der Instance Manager lastet ihn laut Doku zu 100 Prozent aus) und 2 GiB RAM für Huge Pages dazu. Diese Werte gelten für Longhorn selbst; Kubernetes und deine Anwendungen brauchen zusätzlich Ressourcen.

ECC-RAM #

ECC-Speicher (Error Correcting Code) erkennt und korrigiert einzelne umgekippte Bits im Arbeitsspeicher. Die Ceph-Hardware-Empfehlungen erwähnen ECC nicht. Proxmox empfiehlt im ZFS-Kapitel ausdrücklich „hochwertigen ECC-RAM“, um Datenkorruption zu vermeiden, und die HA-Doku zählt ECC-RAM neben USV und redundanten Netzteilen zu den Maßnahmen für Hardware-Redundanz. Der Gedanke dahinter gilt für jeden Speicher, der Prüfsummen bildet: Wird ein Datenblock schon im Arbeitsspeicher verfälscht, bevor die Prüfsumme berechnet ist, schützt die Prüfsumme den verfälschten Inhalt, und die Replikation verteilt ihn korrekt auf alle Kopien. Für einen produktiven Cluster ist ECC deshalb die vernünftige Wahl. Im Lernlabor kannst du darauf verzichten.

Datenträger: HDD, SATA-SSD oder NVMe #

Die Datenträger entscheiden über Kapazität, Leistung und vor allem darüber, wie schnell sich der Cluster von einem Ausfall erholt.

Warum kleine Cluster SSDs bevorzugen #

Die Proxmox-Doku empfiehlt für kleine Setups SSDs statt HDDs, um die Recovery-Zeit zu verkürzen und damit das Risiko eines zweiten Ausfalls während der Wiederherstellung zu senken. Die Ceph-Doku argumentiert ähnlich: SSDs haben keine Rotations- und Suchlatenz, verbessern die Client-Leistung und beschleunigen Umbauten im Cluster deutlich. Sie räumt ein, dass SSDs pro Terabyte mehr kosten als HDDs, betont aber, dass die Kosten pro IOPS bei SSDs viel niedriger seien.

HDDs bleiben eine Option für große, eher sequenziell genutzte Kapazität, etwa Backups oder Archive. Dann empfiehlt Ceph, die Metadaten (die RocksDB-Datenbank „DB“ und das Write-Ahead-Log „WAL“ von BlueStore) auf ein schnelles Medium auszulagern. Die Mindesttabelle nennt dafür eine SSD-Partition pro HDD-OSD, vier bis fünf HDD-OSDs pro SATA-SSD oder bis zu 15 HDD-OSDs pro NVMe-SSD. Zur Größe der DB schreibt die BlueStore-Doku: in der Regel 1 bis 4 Prozent der Datengröße, für RBD-Workloads (Block-Devices für VMs) meist nicht mehr als 1 bis 2 Prozent, für Object Storage (RGW) mindestens 4 Prozent. Läuft die DB voll, landen Metadaten wieder auf der langsamen Platte.

Ein Risiko solltest du kennen: Fällt die gemeinsame DB/WAL-SSD aus, sind alle OSDs betroffen, deren Metadaten darauf liegen. Proxmox weist darauf hin, dass ein schnelles Gerät für mehrere OSDs sonst selbst zum Engpass wird.

Power-Loss-Protection: der häufigste Fehlkauf #

Ein Storage-Cluster schreibt sehr viel synchron: Er wartet, bis der Datenträger bestätigt, dass die Daten dauerhaft gespeichert sind, bevor er weitermacht. Eine SSD ohne Schutz vor Stromausfall muss bei jeder solchen Bestätigung tatsächlich in den Flash-Speicher schreiben. Eine SSD mit Power-Loss-Protection (PLP) hat Kondensatoren an Bord, die bei einem Stromausfall genug Energie liefern, um den Cache noch sicher wegzuschreiben. Sie darf eine Schreibbestätigung deshalb früher geben. Vereinfacht gesagt: PLP macht synchrone Schreibvorgänge schnell und sicher zugleich.

Beide Dokumentationen sind hier eindeutig:

• Die Ceph-Doku nennt günstige Client- oder No-Name-SSDs eine Scheinersparnis: Nach einem ersten Leistungsschub könne die Dauerleistung stark einbrechen, sobald ein begrenzter Cache voll ist („cliffing“). Enterprise-SSDs mit PLP seien für Ceph am besten.Herstellerangabe
• Die Proxmox-Systemanforderungen empfehlen SSDs mit PLP für gute Leistung und raten von Consumer-SSDs ab.

PLP steht im Datenblatt des Herstellers, oft unter Begriffen wie „Power Loss Protection“ oder „Power Loss Data Protection“. Ein Befehl, der PLP zuverlässig aus dem laufenden System ausliest, ist in keiner der hier verwendeten Quellen dokumentiert; das Datenblatt ist deshalb die maßgebliche Quelle.

Haltbarkeit: DWPD und TBW #

SSDs verschleißen durch Schreiben. Hersteller geben die Haltbarkeit als DWPD an (Drive Writes Per Day, wie oft die volle Kapazität pro Tag über die Garantiezeit beschrieben werden darf) oder als TBW (Terabytes Written, Gesamtmenge). Die Ceph-Doku ordnet das so ein: Die meisten OSD-Deployments brauchen keine SSD mit mehr als 1 DWPD; „Mixed-Use“-SSDs mit 3 DWPD seien dafür oft überdimensioniert und deutlich teurer. Eine SSD mit nur 0,3 DWPD könne für OSDs mit überwiegend gelesenen, sequenziell geschriebenen Daten genügen, sei aber keine gute Wahl für einen RBD-Pool, der Hunderte VMs bedient. Für Boot- und Monitor-SSDs empfiehlt sie 1 DWPD oder mehr.

Größe und Anzahl der OSDs #

• Ein OSD pro Datenträger. Proxmox empfiehlt ein OSD pro physischem Datenträger. Ceph schreibt deutlich: Mehrere OSDs auf einer einzelnen SAS- oder SATA-HDD seien „keine gute Idee“; nur sehr große SSDs (über 30 TB) könnten von einer Aufteilung profitieren.
• Mindestgröße. Die Ceph-Doku empfiehlt mindestens 1 TiB pro OSD; Datenträger unter 100 GiB seien „überhaupt nicht effektiv“. cephadm akzeptiert technisch schon Geräte ab 5 GB. Für das Lernlabor mit kleinen virtuellen Disks heißt das: Es funktioniert, ist aber kein Maßstab für Leistung oder Platzverhalten.
• Gleichmäßig verteilen. Proxmox empfiehlt gleich große, gleichmäßig verteilte Datenträger pro Node: Vier Platten mit je 500 GB seien besser als eine 1-TB-Platte und drei 250-GB-Platten. Gleichzeitig gilt: Je größer ein einzelnes OSD, desto mehr Daten muss Ceph bei seinem Ausfall auf einmal wiederherstellen. Proxmox empfiehlt als Tipp mindestens 12 OSDs, gleichmäßig auf mindestens drei Nodes verteilt.
• Vorbedingungen für cephadm. Ein Gerät gilt als verfügbar, wenn es keine Partitionen, keinen LVM-Zustand, kein Dateisystem und kein vorhandenes BlueStore-OSD enthält, nicht eingehängt ist und größer als 5 GB ist.

Boot-Laufwerk und Monitor-Daten getrennt halten #

Die Ceph-Doku empfiehlt ein eigenes, idealerweise gespiegeltes Laufwerk für das Betriebssystem und führt viele „langsame OSD“-Probleme darauf zurück, dass Betriebssystem und OSD sich einen Datenträger teilen. Für Boot- und Monitor-SSDs nennt sie mindestens 256 GB, empfohlen 960 GB. Ein Monitor braucht laut Mindesttabelle 100 GB, eine SSD wird „dringend“ empfohlen. Monitor-Datenbanken, CephFS-Metadaten-Pools und RGW-Index-Pools „erfordern praktisch SSDs“. OSD-Daten und Monitor-Daten auf demselben Datenträger hält die Doku ebenfalls für keine gute Idee.

Bei Mini-PCs mit nur einem M.2-Steckplatz ist genau das die erste Hürde: Wo liegen Betriebssystem und Monitor, wenn der einzige schnelle Steckplatz für das OSD gebraucht wird? Prüfe die Anzahl der Steckplätze, bevor du kaufst.

Schreibcache von HDDs #

Für HDDs beschreibt die Ceph-Doku einen Sonderfall: Der standardmäßig eingeschaltete flüchtige Schreibcache der Platte kann die OSD-Leistung bremsen; ihn abzuschalten, könne IOPS und Commit-Latenz „dramatisch“ verbessern. Die Doku rät, das pro Plattenmodell mit fio zu messen und die beste Einstellung dauerhaft zu setzen. Achtung: Der dort gezeigte fio-Aufruf schreibt direkt auf das Gerät und zerstört vorhandene Daten. Mehr zur Messmethodik steht in IOPS, Durchsatz und Latenz verstehen, Befehle baust du mit dem fio Command Builder.

HBA statt RAID-Controller #

Ein RAID-Controller fasst mehrere Platten zu einem logischen Laufwerk zusammen und kümmert sich selbst um Redundanz. Genau das will ein Storage-Cluster nicht: Ceph verteilt Kopien selbst, über Server hinweg, und muss jeden Datenträger einzeln sehen, um dessen Ausfall zu erkennen.

• Proxmox warnt: RAID-Controller vermeiden, stattdessen einen HBA (Host Bus Adapter, ein Controller, der die Platten einfach durchreicht) verwenden. In den Systemanforderungen steht klar, dass weder ZFS noch Ceph mit einem Hardware-RAID-Controller kompatibel sind.
• Die Ceph-Doku ergänzt: RAID-HBAs können eine höhere Latenz haben als einfache HBAs im „JBOD“- oder „IT“-Modus. Viele RAID-Controller lassen sich in einen solchen Modus umschalten. Ein RAID-fähiger Controller ist nicht nötig, und für NVMe-SSDs braucht man gar keinen HBA.

Einzelne Platten als „RAID 0“ zu konfigurieren, um einen RAID-Controller doch zu nutzen, ist kein gleichwertiger Ersatz: Der Controller steht weiterhin zwischen Ceph und der Platte, verbirgt unter Umständen SMART-Daten und bringt seinen eigenen Cache ins Spiel. Prüfe vor dem Kauf gebrauchter Server, ob der verbaute Controller einen IT- oder JBOD-Modus hat.

Netzwerkkarten: nur das Wichtigste #

Das Netzwerk ist in einem Storage-Cluster so wichtig, dass es einen eigenen Guide bekommt: Netzwerk für Storage-Cluster. Für die Hardwareauswahl genügt hier:

• Ceph empfiehlt mindestens 10 Gbit/s zwischen den Ceph-Hosts und zu den Clients, bei hoher Last 25 Gbit/s, und Bonding über getrennte Switches.
• Proxmox empfiehlt mindestens 10 Gbit/s exklusiv für Ceph, für NVMe-Setups mindestens 25 Gbit/s, und eine eigene physische Netzwerkkarte für die Cluster-Kommunikation (Corosync); dafür genüge in den meisten Fällen 1 Gbit/s.
• Longhorn nennt in seinen Best Practices 10 Gbit/s zwischen den Nodes als Basis für Leistung und betont, Latenz sei für die Stabilität wichtiger als Durchsatz.

Zähle die Ports, bevor du kaufst: Ein Node mit getrenntem Public-, Cluster- und Corosync-Netz braucht mindestens drei Anschlüsse, mit Redundanz mehr. Ein Full-Mesh-Aufbau ohne Switch braucht für drei Nodes laut Proxmox-Wiki mindestens zwei freie Ports pro Server nur für das Mesh (Beispielaufbau im Wiki). Viele Server haben zusätzlich einen BMC (Baseboard Management Controller, eine Fernwartungsschnittstelle wie iDRAC oder iLO); die Ceph-Doku empfiehlt, über ein eigenes Verwaltungsnetz dafür nachzudenken.

Netzteile, Strom und USV #

Die Ceph-Doku zählt ein defektes Netzteil und einen Stromausfall ausdrücklich zu den Fehlerdomänen, also zu den Ereignissen, die den Zugriff auf einen oder mehrere OSDs verhindern. Daraus folgen zwei Planungsfragen:

1. Redundante Netzteile im Server? Sie verhindern, dass ein defektes Netzteil einen ganzen Node lahmlegt. Ein Cluster mit dreifacher Replikation übersteht den Ausfall eines Nodes ohnehin. Redundante Netzteile verkleinern also eine Fehlerdomäne innerhalb des Nodes, sie ersetzen aber nicht die Redundanz über mehrere Nodes. Die Proxmox-HA-Doku fordert für Hochverfügbarkeit „Hardware-Redundanz (überall)“ und zuverlässige Server-Komponenten.
2. Hängen alle Nodes am selben Stromkreis? Dann ist ein Stromausfall eine Fehlerdomäne für den ganzen Cluster, und Replikation hilft nicht. Eine USV (unterbrechungsfreie Stromversorgung) überbrückt kurze Ausfälle und ermöglicht ein geordnetes Herunterfahren. Wie lange eine USV bei deiner Last durchhält, rechnest du mit dem USV-Rechner aus.

PLP in den SSDs und eine USV schützen unterschiedliche Dinge: PLP sichert Daten, die im Moment des Stromausfalls im Cache der SSD stecken; die USV verhindert, dass der Strom überhaupt plötzlich weg ist. Was drei oder mehr Server im Dauerbetrieb an Strom kosten, behandelt der Guide Stromverbrauch und Kosten eines Storage-Clusters.

Besonderheiten je Technologie #

Die bisherigen Zahlen stammen überwiegend aus der Ceph- und Proxmox-Doku. Für die anderen Systeme gelten eigene, teils deutlich kleinere Anforderungen.

Einige Details, die beim Hardwarekauf zählen:

• DRBD/LINSTOR: Der dritte Node, der nur als Schiedsrichter für das Quorum dient, kann laut DRBD-User-Guide schwache Hardware sein; die Doku erwähnt, dass sogar ein Raspberry Pi genügen könnte. DRBD 9 läuft als Kernel-Modul, das LINBIT außerhalb des Standard-Kernels pflegt. Als Unterbau für die Datenträger dienen LVM oder ZFS. Physische Platten soll man in der DRBD-Konfiguration über /dev/disk/by-id/… ansprechen, nicht über wechselnde Namen wie /dev/sda2.
• Longhorn: Die Best Practices empfehlen eine eigene Disk für Longhorn statt der Root-Disk. SSD oder NVMe werden empfohlen, HDDs sind laut Doku „verifiziert“, also grundsätzlich lauffähig. Die V1-Data-Engine braucht ext4 oder XFS auf dem Host-Datenträger. Die V2-Data-Engine verlangt Raw-Block-Disks, empfiehlt lokale NVMe-SSDs dringend und setzt Kernel 6.7 oder neuer voraus.
• GlusterFS: Für neue Deployments ist es nach heutiger Faktenlage nicht mehr empfehlenswert; Details und Alternativen stehen in GlusterFS: Architektur, Status und Alternativen.

Welche Technologie zu deinem Vorhaben passt, vergleicht Ceph vs. Longhorn vs. LINSTOR.

Architekturbeispiele: drei Konfigurationen durchgerechnet #

Die folgenden Beispiele sind Rechenbeispiele auf Basis der Doku-Formeln, keine geprüften Kaufempfehlungen und keine Messwerte. Sie zeigen, wie du von der Anzahl der Datenträger zur Ausstattung pro Node kommst.

Beispiel 1: Lernlabor mit drei VMs #

Drei VMs auf einem Rechner, jede mit einer kleinen Systemdisk und einer zusätzlichen virtuellen Disk als OSD. Ziel: cephadm-Installation üben, ceph -s lesen, eine VM stoppen und zusehen, was passiert.

• RAM: Die Formel ergibt für ein OSD 8 GiB pro VM. Im Labor kannst du darunter bleiben, wenn du akzeptierst, dass der Cluster langsam ist; unter 2 GiB pro OSD rät die Doku ausdrücklich ab.
• Disk: Die virtuelle OSD-Disk muss für cephadm größer als 5 GB sein; unter 100 GiB ist sie laut Doku nicht effektiv. Für Funktionstests reicht das.
• Netz: ein virtuelles Netz genügt. Es gibt keine physische Redundanz.

Was du hier nicht lernst: echte Leistung, echtes Recovery-Verhalten auf Hardware, echte Fehlerdomänen. Eine Schritt-für-Schritt-Anleitung folgt im Praxisprojekt Ceph-Testcluster mit drei VMs.

Beispiel 2: Homelab-Cluster, drei Nodes mit je zwei NVMe-OSDs #

Drei gleiche Rechner, Proxmox VE mit Ceph, je zwei NVMe-SSDs mit PLP als OSD und eine getrennte Boot-SSD, VMs laufen auf denselben Nodes.

Proxmox empfiehlt 12 oder mehr OSDs; mit sechs OSDs liegt dieser Aufbau darunter. Das funktioniert, aber jeder einzelne Datenträger trägt einen größeren Anteil der Daten, und ein Ausfall wiegt schwerer. Wie sich das auf Ausfälle und Kapazität auswirkt, erklärt Zwei, drei oder fünf Nodes?.

Beispiel 3: Produktionsnahe Konfiguration nach Doku #

Ein Aufbau, der die Empfehlungen der Doku vollständig einhält, sieht grob so aus:

• mindestens drei, möglichst identische Server, besser mehr (siehe Node-Guide),
• pro Node mehrere Enterprise-SSDs oder NVMe-SSDs mit PLP, mindestens 1 TiB je OSD, insgesamt mindestens 12 OSDs,
• RAM nach Formel plus 20 Prozent Reserve plus Gäste,
• CPU nach Ceph-Tabelle (bei NVMe 6 Threads je OSD),
• gespiegelte Boot-SSD, Monitor-Daten auf SSD,
• HBA im IT-Modus oder direkt angebundene NVMe,
• mindestens 10, bei NVMe 25 Gbit/s, als aktives Bonding über zwei Switches, dazu ein eigener Corosync-Link,
• ECC-RAM, Fernwartung über BMC in einem eigenen Verwaltungsnetz,
• USV mit geordnetem Herunterfahren.

Den Abgleich deiner geplanten Ausstattung mit diesen Regeln übernimmt der Storage-Cluster-Hardware-Planer: Er rechnet RAM- und CPU-Bedarf aus der Anzahl der Datenträger und nennt zu jedem Hinweis die zugrunde liegende Doku-Stelle.

Praxis: Hardware vor dem Kauf und vor der Installation prüfen #

Ein bewährtes Vorgehen in fünf Schritten:

1. Workload und Technologie festlegen. VM-Disks, Kubernetes-Volumes, Dateien oder Objektspeicher? Davon hängt ab, ob Ceph, LINSTOR oder Longhorn passt. Die Planung dazu beschreibt Storage-Cluster richtig planen.
2. Anzahl Datenträger pro Node festlegen. Daraus folgen RAM und CPU nach den Formeln oben.
3. Datenblätter prüfen. Bei SSDs: PLP und DWPD bzw. TBW. Beim Controller: IT- oder JBOD-Modus. Bei Netzwerkkarten: Anzahl Ports und Geschwindigkeit.
4. Mit dem Planer gegenrechnen. Trage die Werte in den Hardware-Planer ein und prüfe jeden Hinweis.
5. Vorhandene Hardware lesend inventarisieren. Bevor du irgendetwas installierst, prüfst du mit lesenden Befehlen, was tatsächlich verbaut ist (siehe nächster Abschnitt).

So prüfst du, ob die Hardware passt #

Die folgenden Befehle lesen nur. Sie verändern nichts und eignen sich für die Bestandsaufnahme eines frischen Nodes.

Datenträger und vorhandene Dateisysteme anzeigen:

lsblk
lsblk -f

Die Spalte FSTYPE von lsblk -f zeigt, ob auf einem Gerät bereits ein Dateisystem liegt. Ein Gerät, das du als OSD verwenden willst, sollte dort leer sein. Prüfe mit lsblk, welches Gerät leer ist, bevor du irgendein Gerät, etwa /dev/sdb oder /dev/nvme1n1, für einen Storage-Dienst vorsiehst. Verwechslungen an dieser Stelle zerstören Daten.

Arbeitsspeicher und CPU-Threads:

free -h
nproc

Verbindungsgeschwindigkeit einer Netzwerkkarte (der Name der Schnittstelle unterscheidet sich je nach System; ip link listet sie auf):

ip link
ethtool <SCHNITTSTELLE>

Den Gesundheitszustand der Datenträger liest smartctl aus. Den passenden Aufruf für SATA- oder NVMe-Geräte stellst du mit dem smartctl Command Builder zusammen; die dauerhafte Überwachung beschreibt SMART-Monitoring mit smartctl-exporter.

Läuft auf dem Host bereits ein cephadm-Cluster, zeigt Ceph selbst, welche Geräte es als verfügbar erkennt und warum es andere ablehnt (Spalte „REJECT REASONS“):

ceph orch device ls --wide

Nach dem Anlegen der OSDs zeigt ceph osd df, wie gleichmäßig die Daten über die OSDs verteilt sind. Starke Unterschiede in der Belegung können auf ungleich große oder ungleich verteilte Datenträger hindeuten.

Erwarteter Zustand: Jeder Node hat die geplante Anzahl leerer Datenträger, genug RAM nach der Formel, genug Threads nach der Ceph-Tabelle und die geplante Linkgeschwindigkeit auf jeder Netzwerkkarte.

Sicherheitshinweise #

• Gebrauchte Datenträger erst prüfen, dann löschen. Ceph nimmt nur leere Geräte an. Die Doku zeigt Befehle wie ceph orch device zap oder ceph-volume lvm zap … --destroy, die alle Daten auf einem Gerät unwiderruflich löschen. Führe sie nur aus, wenn du mit lsblk geprüft hast, dass es das richtige Gerät ist, und nur in einer Testumgebung oder mit aktuellem Backup.
• Datenträger nicht nach Gerätenamen identifizieren. Namen wie /dev/sdb können sich nach einem Neustart ändern. Nutze für Konfigurationen die stabilen Pfade unter /dev/disk/by-id/, wie es der DRBD-User-Guide empfiehlt.
• Fernwartung abschotten. BMCs (iDRAC, iLO und ähnliche) haben weitreichende Rechte über den Server. Die Ceph-Doku empfiehlt, über ein eigenes Verwaltungsnetz dafür nachzudenken. Ein BMC gehört nie ins Internet.
• Consumer-SSDs nur für unkritische Daten. Im Lernlabor sind sie in Ordnung. Für Daten, die du nicht verlieren willst, nimm SSDs mit PLP und sorge zusätzlich für Backups; Replikation ersetzt kein Backup, siehe Replikation ist kein Backup.
• Firmware-Updates planen. SSD-, Controller- und BMC-Firmware gehören zur Wartung. Spiele sie nie auf allen Nodes gleichzeitig ein, sondern Node für Node, nachdem der Cluster wieder gesund ist.

Typische Fehler bei der Hardwareauswahl #

RAM nur für das Betriebssystem gerechnet. Symptom: OSDs werden unter Last vom Kernel beendet, besonders während einer Recovery. Abhilfe: RAM pro Node nach der Formel „OSDs × 4 GiB × 2“ plus Reserve plus Gäste planen.

Consumer-SSDs mit gutem Datenblatt. Symptom: Am Anfang schnell, unter Dauerlast plötzlich sehr langsame Schreibvorgänge und steigende Latenz. Ursache ist laut Ceph-Doku das „cliffing“ nach vollem Cache sowie fehlende PLP. Abhilfe: Enterprise-SSDs mit PLP; vorhandene Consumer-SSDs ins Lernlabor.

RAID-Controller im RAID-Modus. Symptom: Ceph sieht nur ein großes Laufwerk oder einzelne RAID-0-Volumes, SMART-Werte fehlen, Latenzen sind hoch. Abhilfe: Controller in IT- oder JBOD-Modus umschalten oder durch einen HBA ersetzen.

Ein Node anders ausgestattet als die anderen. Symptom: Ungleich verteilte Belegung in ceph osd df, ein Node ist dauerhaft stärker ausgelastet. Abhilfe: gleich große Datenträger in gleicher Anzahl pro Node, wie Proxmox es empfiehlt.

Betriebssystem und OSD auf derselben Disk. Symptom: sporadisch langsame OSDs ohne Hardwaredefekt. Die Ceph-Doku nennt das als häufige Ursache. Abhilfe: eigene, idealerweise gespiegelte Boot-Disk.

Zu wenige Netzwerkports. Symptom: Ceph-Recovery und Corosync teilen sich eine Leitung; während einer Recovery verliert der Proxmox-Cluster das Quorum. Abhilfe: eigener Corosync-Link, Details im Netzwerk-Guide.

Offizielle Quellen #

• Ceph Docs (Tentacle): Hardware Recommendations: CPU- und RAM-Tabelle, SSD-Auswahl, Controller, Netzwerk, Fehlerdomänen.
• Ceph Docs (Tentacle): BlueStore Configuration Reference: Größe von DB und WAL, osd_memory_target.
• Ceph Docs (Tentacle): cephadm-Installation und OSD-Service: Memory-Autotuning, Anforderungen an verfügbare Geräte.
• Proxmox VE: Deploy Hyper-Converged Ceph Cluster: Mindestanzahl Server, CPU-Faustregel, 8 GiB pro OSD, HBA statt RAID.
• Proxmox VE: System Requirements: PLP-SSDs, keine Consumer-SSDs, kein Hardware-RAID für ZFS und Ceph.
• Proxmox VE: ZFS on Linux, Abschnitt Hardware und High Availability: Empfehlung für ECC-RAM, Hardware-Redundanz.
• Proxmox VE Wiki: Full Mesh Network for Ceph Server: Portbedarf ohne Switch.
• DRBD 9.0 User Guide und LINSTOR User Guide: Quorum mit Diskless-Node, Bitmap-Speicher, Pakete.
• Longhorn 1.13.0: Best Practices und Installation Requirements: Mindest-Hardware, V2-Data-Engine.

Weiterlesen #

• Netzwerk für Storage-Cluster: der nächste Schritt nach der Hardware, mit Segmentierung, Bonding und iperf3-Messmethodik.
• Zwei, drei oder fünf Nodes?: wie viele Server du für Quorum, Ausfallsicherheit und Recovery brauchst.
• Storage-Cluster richtig planen: bringt Hardware, Netz, Kapazität und Betrieb in eine Planungs-Checkliste.
• Stromverbrauch und Kosten eines Storage-Clusters: was drei oder mehr Server im Dauerbetrieb kosten, mit offenem Rechenweg.
• Storage-Cluster-Hardware-Planer: prüft deine geplante Ausstattung gegen die Doku-Empfehlungen.