Rechner · Storage Cluster
Storage-Cluster-Kapazitätsrechner
Wie viel Platz bleibt von deinen Datenträgern übrig, wenn ein Cluster jede Information dreifach speichert oder per Erasure Coding verteilt — und wie viel davon kannst du wirklich verplanen? Der Rechner trennt die reine Rechnung von dem, was mit Reserve für einen Node-Ausfall realistisch nutzbar ist.
Schutzprofil übernehmen:
Theoretisch — reine Rechnung
Bruttokapazität
32 TB
= 29,1 TiB, wie das Betriebssystem sie anzeigt
Rechnerisch nutzbar
10,7 TB
33 % der Bruttokapazität
Overhead
21,3 TB
für zusätzliche Kopien
Realistisch — mit Reserve
Planbar nutzbar
6,8 TB
= 6,2 TiB · Platz für Wiederherstellung nach einem Node-Ausfall, unter 85 % Füllstand
Bis 85 % Füllgrenze
9,1 TB
ohne Reserve für einen Node-Ausfall
Node-Ausfälle ohne Datenverlust
2
gleichzeitig; schreibbar bleibt es nur oberhalb von min_size
Die Rechnung nimmt gleich bestückte Nodes und den Host als Failure Domain an. Nicht enthalten sind Metadaten, BlueStore-DB/WAL, Dateisystem- und Allokations-Overhead sowie Kompression — die reale Nutzkapazität liegt darunter. Einzelne Datenträger füllen sich ungleichmäßig; maßgeblich ist im Betrieb der vollste, nicht der Durchschnitt. Replikation und Erasure Coding sind kein Backup.
Warum „realistisch“ so viel weniger ist
Ein Storage-Cluster heilt sich selbst: Fällt ein Node aus, legt er die fehlenden Kopien auf den übrigen Nodes neu an. Das klappt nur, wenn dort Platz ist — und wenn es überhaupt einen weiteren Node gibt, auf dem die Kopie landen darf. Bei drei Nodes und dreifacher Replikation ist das nicht der Fall: Der Cluster läuft nach einem Ausfall weiter, aber degradiert, bis der Node zurück ist.
Dazu kommt die Füllgrenze. Ceph meldet per Default ab 85 % Füllstand eines Datenträgers eine Warnung, stoppt ab 90 % das Umverteilen auf ihn und blockiert ab 95 % Schreibzugriffe. Weil sich Datenträger nie ganz gleichmäßig füllen, erreicht der vollste die Grenze früher als der Durchschnitt.
Replikation und Erasure Coding sind kein Backup
Beide schützen vor dem Ausfall von Hardware. Gegen versehentliches Löschen, Ransomware oder einen Bedienfehler am ganzen Cluster helfen sie nicht — jede Änderung wird sofort auf alle Kopien übertragen. Ein Backup außerhalb des Clusters bleibt Pflicht.
Häufige Fragen
Wie viel Speicher bleibt bei dreifacher Replikation nutzbar?
Rechnerisch ein Drittel der Bruttokapazität: Aus 48 TB in vier Nodes werden 16 TB. Planbar ist weniger, weil der Cluster unterhalb seiner Füllgrenze bleiben und nach einem Node-Ausfall Platz für die Wiederherstellung haben muss — im Beispiel rund 10 TB.
Ist Erasure Coding immer die bessere Wahl, weil es Platz spart?
Nein. Erasure Coding verteilt Daten- und Paritätschunks auf k + m Nodes und braucht entsprechend viele Failure Domains. Es kostet CPU, erhöht die Schreiblatenz und liest bei der Wiederherstellung deutlich mehr Daten. Für Block-Storage virtueller Maschinen in kleinen Clustern ist Replikation meist die einfachere Wahl, für große Archive Erasure Coding.
Warum zeigt der Rechner TB und TiB?
Hersteller rechnen dezimal (1 TB = 10¹² Byte), Ceph und die meisten Betriebssysteme binär (1 TiB = 2⁴⁰ Byte). Eine 4-TB-Platte erscheint deshalb als rund 3,64 TiB — ohne dass etwas verloren ginge.
Was passiert bei ungleich großen Nodes?
Der Rechner nimmt gleich bestückte Nodes an. Bei ungleichen Nodes begrenzt mit Failure Domain „host“ oft der kleinste Node: Jede Kopie muss auf einem anderen Host liegen, und ein großer Host kann nicht beliebig viele Kopien aufnehmen. Rechne in diesem Fall konservativ mit dem kleinsten Node.
Passende Tools
Storage-Netzwerk-Rechner →
1, 2,5, 10 oder 25 Gbit/s: Replikationsverkehr, Last je Node, maximale Schreibrate und Recovery-Dauer nach einem Node-Ausfall überschlagen — mit offenen Annahmen.
Cluster-Hardware-Planer →
RAM, CPU, Netzwerk, SSD-Klasse und Controller für Ceph, Proxmox + Ceph, LINSTOR oder Longhorn gegen die offizielle Doku prüfen — Bedarf, Engpass und Checkliste, jede Regel mit Quelle.
RAID- & ZFS-Rechner →
Nutzbare Kapazität und Ausfalltoleranz für RAID 0/1/5/6/10 und ZFS RAIDZ1/2/3 — inklusive TB-vs-TiB-Umrechnung.