Guides · Thema

Storage Cluster – Verteilten Speicher verstehen und aufbauen

Lerne, wie mehrere Server zu einem gemeinsamen Speichersystem werden. Von Ceph und verteilten Dateisystemen über Replikation und Quorum bis hin zu Hochverfügbarkeit, Backup und professionellem Cluster-Betrieb.

Guides: 2 von 40 Guides verfügbar
Schwierigkeit: Einsteiger bis Profi
Gesamte Lesedauer: ca. 12,5 Std. Lesezeit

Lernpfad starten →Grundlagen lesen ↓Technologievergleich ↓

Ganz neu im Homelab? Der Einstiegspfad in 8 Schritten ordnet das Thema in den Gesamtaufbau ein.

Grundlagen verteilter Speichersysteme

Was ein Storage-Cluster ist, wie er sich von NAS und SAN unterscheidet und warum Replikation allein noch keine Konsistenz garantiert.

01
GUIDEWas ist ein Storage-Cluster? Einfach erklärt mit BeispielenStorage-Cluster verständlich erklärt: wie mehrere Server gemeinsam Speicher bereitstellen, was Scale-out, SDS und Shared Storage bedeuten, mit Beispiel.Einsteiger · 16 Min. Lesezeit
02
GUIDEStorage-Cluster vs. NAS vs. SAN: Unterschiede und EinsatzNAS, SAN oder Storage-Cluster? Architektur, Ausfallsicherheit, Skalierung, Kosten und Verwaltungsaufwand im Vergleich, für Homelab und kleine Firmen.Einsteiger · 15 Min. Lesezeit · Setzt voraus: Was ist ein Storage-Cluster?
03
DemnächstWie funktioniert verteilte Datenspeicherung? Einfach erklärtEinsteiger · erscheint am 27. Oktober 2026, 09:00 Uhr
04
DemnächstReplikation, Quorum und Split Brain verständlich erklärtFortgeschritten · erscheint am 30. Oktober 2026, 09:00 Uhr

GUIDEUnraid vs. Proxmox vs. TrueNAS: Welches System für deinen Homeserver?Aus Selfhosting: Die drei großen Homeserver-Systeme im ehrlichen Vergleich: Stärken, Schwächen, Storage-Philosophie und eine klare Empfehlung je nach Einsatzzweck.

Technologien im Überblick

Acht Werkzeuge, die oft in einem Atemzug genannt werden — und doch Verschiedenes lösen. Beschrieben nach offizieller Dokumentation, ohne Noten oder Rangliste.

CephBlock-, Datei- und Object-Storage aus einem verteilten Cluster — vom Proxmox-Homelab bis zum Rechenzentrum.Verteilter Objektspeicher (RADOS) · Scale-out · Replikation oder Erasure Coding

Stärken

Ein System für Block (RBD), Datei (CephFS) und S3-kompatiblen Object Storage (RGW)
Selbstheilend: Nach einem Ausfall verteilt der Cluster fehlende Kopien automatisch neu
Skaliert durch zusätzliche Nodes und OSDs; CRUSH berechnet die Datenplatzierung ohne zentrale Tabelle
Failure Domains (Host, Rack, Raum) legen fest, wo Kopien liegen dürfen

Grenzen

Ressourcenhungrig: Die Doku empfiehlt mehr RAM als Anzahl OSDs × 4 GiB × 2 je Server
Mindestens drei Nodes und drei Monitore, sinnvoll erst mit Reserve darüber
Mindestens 10 Gbit/s empfohlen; Wiederherstellungen belasten das Netz stark
Viele Stellschrauben — Fehlkonfigurationen wie min_size 1 gefährden Daten

Betriebsaufwand: Hoch. Die Installation ist mit cephadm oder Proxmox schnell erledigt; der Betrieb verlangt Verständnis von Placement Groups, CRUSH, Recovery und Health-Checks.
Hardware: Laut Doku 10 Gbit/s oder mehr, Enterprise-SSDs mit Power-Loss-Protection und RAM nach Anzahl der OSDs (osd_memory_target 4 GiB je OSD als Default).

Guides zu Ceph erscheinen nach und nach im Lernpfad.

Proxmox VE + CephHyperkonvergente Virtualisierung: VMs und Container laufen auf denselben Servern, die auch den Ceph-Speicher stellen.Ceph integriert in Proxmox VE · Verwaltung per Oberfläche und pveceph

Stärken

Monitore, Manager, OSDs und Pools direkt in der Proxmox-Oberfläche einrichten
Gemeinsamer Speicher für Live-Migration und Hochverfügbarkeit der Gäste
Ceph-Pakete auf die Proxmox-Version abgestimmt — in PVE 9.2 Tentacle als Standard, Squid wählbar

Grenzen

Ceph und Gäste teilen sich CPU, RAM und Netzwerk derselben Server
Proxmox verlangt mindestens drei möglichst identische Server und empfiehlt 10 Gbit/s exklusiv für Ceph
Ceph-Upgrades brauchen eigene, dokumentierte Schritte neben dem Proxmox-Update

Betriebsaufwand: Mittel bis hoch. Die Oberfläche führt durch die Einrichtung; für Betrieb und Fehlersuche gelten dieselben Ceph-Grundlagen.
Hardware: Laut Proxmox mindestens drei Nodes, mindestens 8 GiB RAM pro OSD, ein CPU-Thread je Ceph-Dienst, HBA statt RAID-Controller und 10 Gbit/s (bei NVMe 25 Gbit/s).

Guides: Proxmox VE installieren

Rook-CephCeph als Storage innerhalb von Kubernetes, gesteuert durch einen Operator.Kubernetes-Operator · Ceph-Daemons als Pods · Ceph-CSI

Stärken

Den Ceph-Cluster deklarativ als Kubernetes-Ressource (CephCluster) beschreiben
StorageClasses für Block (RBD), Dateisystem (CephFS) und Object Storage
Rook 1.21 unterstützt laut Projekt Ceph Squid und Tentacle auf Kubernetes v1.32 bis v1.37

Grenzen

Fehlersuche verlangt Wissen über Kubernetes und über Ceph
Braucht auf den Nodes rohe Datenträger oder Partitionen ohne Dateisystem
Der Ressourcenbedarf von Ceph bleibt bestehen

Betriebsaufwand: Hoch. Sinnvoll für Teams, die Kubernetes ohnehin betreiben und Ceph-Funktionen im Cluster brauchen.
Hardware: Wie Ceph, dazu Kubernetes-Nodes mit freien Rohdatenträgern. Für Testumgebungen bringt Rook eine eigene cluster-test.yaml mit.

Guides zu Rook-Ceph erscheinen nach und nach im Lernpfad.

LINSTORVerwaltung replizierter Block-Volumes auf Basis von DRBD — für Proxmox, Kubernetes und klassische Server.Controller und Satellites · DRBD-Replikation · LVM oder ZFS als Unterbau

Stärken

Legt DRBD-Ressourcen automatisch auf passenden Nodes an (Resource Groups mit place-count)
Nutzt vorhandene LVM-Thin- oder ZFS-Pools
Anbindung an Proxmox (linstor-proxmox) und Kubernetes (Piraeus Operator)
Aktiviert Quorum automatisch, sobald genug Nodes beteiligt sind

Grenzen

Reiner Block-Storage — kein gemeinsames Dateisystem, kein Object Storage
Der Controller ist zentral; seine Hochverfügbarkeit braucht einen eigenen Aufbau
DRBD 9 ist nicht im Mainline-Kernel und kommt als zusätzliches Kernelmodul

Betriebsaufwand: Mittel. Weniger Bausteine als Ceph, aber Kernelmodul, Controller und Quorum wollen verstanden sein.
Hardware: Die Doku nennt keine festen Mindestwerte. Für Quorum braucht es drei Nodes; der dritte darf ohne Datenträger laufen.

Guides zu LINSTOR erscheinen nach und nach im Lernpfad.

DRBDSynchrone Spiegelung eines Blockgeräts über das Netzwerk — die Basis klassischer Hochverfügbarkeit mit zwei Daten-Nodes.Blockreplikation im Kernel · Primary und Secondary · Quorum ab drei Nodes

Stärken

Schlank: Repliziert ein Blockgerät, darüber läuft jedes Dateisystem oder jede VM
Protokoll C bestätigt Schreibzugriffe erst, wenn alle Partner sie haben
Quorum mit diskless Tiebreaker: zwei Daten-Nodes plus ein schlanker dritter

Grenzen

Ohne Quorum oder Fencing droht Split Brain
In der Regel ein Primary je Ressource — kein Scale-out wie bei Ceph
Viele Ressourcen von Hand zu pflegen wird unübersichtlich; dafür gibt es LINSTOR

Betriebsaufwand: Mittel. Wenige Konzepte, aber Fehlerfälle wie Split Brain verlangen sorgfältiges manuelles Vorgehen.
Hardware: Keine festen Mindestwerte. Latenz und Bandbreite der Replikationsstrecke bestimmen die Schreibleistung; Bitmaps belegen rund 32 MiB RAM je TiB.

Guides zu DRBD erscheinen nach und nach im Lernpfad.

LonghornVerteilter Block-Storage für Kubernetes: Jedes Volume wird über mehrere Nodes repliziert.Cloud-native · Replikas auf mehreren Nodes · CSI-Treiber

Stärken

Installation per Helm, Verwaltung über eine eigene Weboberfläche
Snapshots und Backups auf S3 oder NFS eingebaut
Default drei Replikas und eine fertige StorageClass

Grenzen

Nur für Kubernetes — kein Speicher für VMs oder Server außerhalb des Clusters
Longhorn 1.13 setzt Kubernetes v1.34 oder neuer voraus
Die V2-Data-Engine braucht dedizierte CPU-Kerne, Huge Pages und Kernel 6.7 oder neuer

Betriebsaufwand: Niedrig bis mittel für Kubernetes-Erfahrene; ohne Kubernetes-Wissen kommt dessen gesamte Komplexität dazu.
Hardware: Laut Best Practices mindestens drei Nodes mit je 4 vCPUs und 4 GiB RAM, SSD oder NVMe empfohlen, eigener Datenträger statt der Root-Disk.

Guides zu Longhorn erscheinen nach und nach im Lernpfad.

GlusterFSVerteiltes Dateisystem aus den lokalen Dateisystemen mehrerer Server (Bricks).Ohne zentralen Metadatenserver · Trusted Storage Pool · Volumes aus Bricks

Status: Für neue Installationen nicht empfehlenswert: Die Entwicklung ist stark verlangsamt, Release-Plan und Paketlisten auf der Projektseite sind veraltet. LabKompass behandelt GlusterFS als Architektur-, Vergleichs- und Migrationsthema.

Stärken

Einfaches Grundprinzip: Verzeichnisse mehrerer Server werden zu einem Volume
Replizierte und dispersed Volumes, Arbiter-Bricks gegen Split Brain

Grenzen

Letzte Release 11.2 vom Juli 2025; 2024 erschien keine
Red Hat Gluster Storage ist seit dem 31. Dezember 2024 am Lebensende
Das eingebaute GlusterFS-Volume-Plugin wurde mit Kubernetes v1.26 entfernt

Betriebsaufwand: Mittel. Selbstheilung und das Auflösen von Split Brain verlangen Erfahrung.
Hardware: Aktuelle, belastbare Angaben des Projekts liegen nicht vor.

Guides zu GlusterFS erscheinen nach und nach im Lernpfad.

OpenZFSDateisystem und Volume-Manager mit Prüfsummen, Snapshots und Replikation per send/receive — auf einem Server.Lokal, kein Cluster-Dateisystem · Pools aus vdevs · asynchrone Replikation

Stärken

Prüfsummen erkennen stille Datenfehler und reparieren sie aus der Redundanz
Snapshots und zfs send/receive für Backup und Replikation zwischen Servern
Deutlich weniger Betriebsaufwand als ein verteiltes System

Grenzen

Ein Pool ist immer nur auf einem Host importiert — mehrere Nodes nutzen ihn nicht gleichzeitig
Replikation zwischen Servern ist asynchron: Beim Umschalten fehlen die Änderungen seit dem letzten Lauf

Betriebsaufwand: Niedrig bis mittel. Für viele Homelabs die passendere Wahl als ein Storage-Cluster.
Hardware: Ein Server; Einzelheiten stehen im ZFS-Lernpfad.

Guides zu OpenZFS erscheinen nach und nach im Lernpfad.

Hardware, Netzwerk und Architektur

Welche Hardware die Projekte empfehlen, warum das Netzwerk oft der Engpass ist — und wie viele Nodes du wirklich brauchst.

05
DemnächstWelche Hardware braucht ein Storage-Cluster? Labor vs. ProduktionEinsteiger · erscheint am 3. November 2026, 09:00 Uhr
06
DemnächstNetzwerk für Storage-Cluster: 1, 2,5, 10 oder 25 Gbit/s?Fortgeschritten · erscheint am 17. November 2026, 09:00 Uhr
07
DemnächstZwei, drei oder fünf Nodes? Die Größe eines Storage-ClustersEinsteiger · erscheint am 6. November 2026, 09:00 Uhr
08
DemnächstStorage-Cluster richtig planen: Anforderungen, Kapazität, BetriebFortgeschritten · erscheint am 10. November 2026, 09:00 Uhr

Ceph im Detail

Von RADOS, OSDs und Monitoren über Placement Groups und CRUSH bis zur Installation mit cephadm oder in Proxmox VE.

09
DemnächstWas ist Ceph? Architektur und Bausteine einfach erklärtEinsteiger · erscheint am 13. November 2026, 09:00 Uhr
10
DemnächstCeph-Architektur im Detail: PGs, CRUSH, Peering und RecoveryFortgeschritten · erscheint am 20. November 2026, 09:00 Uhr
11
DemnächstCeph mit cephadm installieren: Tentacle 20.2.4 Schritt für SchrittFortgeschritten · erscheint am 24. November 2026, 09:00 Uhr
12
DemnächstCeph in Proxmox VE 9.2 installieren: pveceph, GUI und CLIFortgeschritten · erscheint am 27. November 2026, 09:00 Uhr
13
DemnächstCeph-Pools und CRUSH-Regeln konfigurieren: Praxis-GuideProfi · erscheint am 1. Dezember 2026, 09:00 Uhr
14
DemnächstRBD, CephFS oder RGW? Ceph-Speicherarten im VergleichFortgeschritten · erscheint am 4. Dezember 2026, 09:00 Uhr

GUIDEProxmox VE installieren: Schritt für Schritt zum ersten HypervisorAus Proxmox: Proxmox VE von der ISO bis zur ersten VM: Installation, Dateisystem-Wahl, No-Subscription-Repository, Updates und die ersten sinnvollen Einstellungen.

LINSTOR, DRBD und Alternativen

Blockreplikation mit DRBD, ihre Verwaltung mit LINSTOR — und ein ehrlicher Blick auf GlusterFS.

15
DemnächstLINSTOR und DRBD verstehen: Blockreplikation, Quorum, TiebreakerFortgeschritten · erscheint am 22. Dezember 2026, 09:00 Uhr
16
DemnächstDRBD 9 manuell einrichten: Ressource, Quorum und FencingProfi · erscheint am 29. Dezember 2026, 09:00 Uhr
17
DemnächstLINSTOR installieren und verwalten: Controller, Pools, ProxmoxProfi · erscheint am 5. Januar 2027, 09:00 Uhr
18
DemnächstGlusterFS verstehen: Architektur, Wartungsstatus, AlternativenFortgeschritten · erscheint am 22. Januar 2027, 09:00 Uhr

Kubernetes und Cloud Native Storage

Persistent Volumes, CSI und StorageClasses — und wie Longhorn, Rook-Ceph und LINSTOR sie bedienen.

19
DemnächstPersistent Storage in Kubernetes: PV, PVC, StorageClass und CSIFortgeschritten · erscheint am 8. Januar 2027, 09:00 Uhr
20
DemnächstLonghorn installieren und betreiben: Kubernetes-Storage mit HelmFortgeschritten · erscheint am 12. Januar 2027, 09:00 Uhr
21
DemnächstRook-Ceph unter Kubernetes: Installation, RBD, CephFS und S3Profi · erscheint am 15. Januar 2027, 09:00 Uhr
22
DemnächstCeph vs. Longhorn vs. LINSTOR: Storage für Kubernetes im VergleichFortgeschritten · erscheint am 19. Januar 2027, 09:00 Uhr

Hochverfügbarkeit und Datensicherheit

Was Hochverfügbarkeit leistet und was nicht, warum Replikation kein Backup ist und wie du für den Ernstfall planst.

23
DemnächstHochverfügbarkeit im Storage-Cluster: Failover, Quorum, FencingFortgeschritten · erscheint am 8. Dezember 2026, 09:00 Uhr
24
DemnächstReplikation ist kein Backup: Snapshots, Backup, RPO und RTOEinsteiger · erscheint am 11. Dezember 2026, 09:00 Uhr
25
DemnächstErasure Coding vs. Replikation: Platz, Ausfälle, RecoveryFortgeschritten · erscheint am 15. Dezember 2026, 09:00 Uhr
26
DemnächstDisaster Recovery im Storage-Cluster: Runbooks für den ErnstfallProfi · erscheint am 16. Februar 2027, 09:00 Uhr

GUIDEBackup-Strategie für zuhause: Die 3-2-1-Regel praktisch umgesetztAus Security: RAID ist kein Backup: Wie du mit der 3-2-1-Regel, Versionierung und einer Offsite-Kopie deine Daten wirklich absicherst — mit konkretem Setup fürs Homelab.

Performance und Skalierung

IOPS, Durchsatz und Latenz verstehen, Ceph ohne Tuning-Mythen verbessern, den Cluster erweitern — und die Stromrechnung im Blick behalten.

27
DemnächstIOPS, Durchsatz und Latenz: Storage-Performance verstehenFortgeschritten · erscheint am 18. Dezember 2026, 09:00 Uhr
28
DemnächstCeph-Performance optimieren – ohne Tuning-MythenProfi · erscheint am 26. Januar 2027, 09:00 Uhr
29
DemnächstStorage-Cluster erweitern: Nodes und OSDs sicher hinzufügenFortgeschritten · erscheint am 29. Januar 2027, 09:00 Uhr
30
DemnächstStromverbrauch und Kosten eines Storage-Clusters berechnenEinsteiger · erscheint am 19. Februar 2027, 09:00 Uhr

GUIDEProxmox-Stromverbrauch senken: C-States, powertop und ASPMAus Proxmox: Warum Proxmox-Hosts im Idle oft mehr ziehen als nötig — und wie du mit BIOS-Einstellungen, CPU-Governor, powertop --auto-tune und ASPM den Verbrauch drückst.

Administration und Monitoring

Überwachen, aktualisieren, absichern und Fehler systematisch eingrenzen — der Alltag nach der Installation.

31
DemnächstStorage-Cluster überwachen: Dashboard, Prometheus, AlertsFortgeschritten · erscheint am 2. Februar 2027, 09:00 Uhr
32
DemnächstWartung und Updates im Storage-Cluster: sicher und rollierendFortgeschritten · erscheint am 5. Februar 2027, 09:00 Uhr
33
DemnächstStorage-Cluster absichern: Ceph, DRBD, LINSTOR und LonghornFortgeschritten · erscheint am 9. Februar 2027, 09:00 Uhr
34
DemnächstStorage-Cluster-Troubleshooting: Ceph, DRBD, LINSTOR, LonghornFortgeschritten · erscheint am 12. Februar 2027, 09:00 Uhr

Praxisprojekte und Entscheidung

Vier reproduzierbare Testaufbauten in virtuellen Maschinen — und die ehrliche Frage, ob sich ein Storage-Cluster für dich lohnt.

35
DemnächstStorage-Cluster im Homelab aufbauen: Varianten und LernpfadFortgeschritten · erscheint am 23. Februar 2027, 09:00 Uhr
36
DemnächstWann lohnt sich ein Storage-Cluster? EntscheidungshilfeEinsteiger · erscheint am 26. Februar 2027, 09:00 Uhr
37
DemnächstCeph-Testcluster mit drei VMs aufbauen und brechen: PraxisprojektFortgeschritten · erscheint am 2. März 2027, 09:00 Uhr
38
DemnächstProxmox mit Ceph als Shared Storage und HA: PraxisprojektFortgeschritten · erscheint am 5. März 2027, 09:00 Uhr
39
DemnächstDRBD mit zwei Storage-Nodes und Witness testen: PraxisprojektProfi · erscheint am 9. März 2027, 09:00 Uhr
40
DemnächstLonghorn mit Backup und Restore-Test: Kubernetes-PraxisprojektFortgeschritten · erscheint am 12. März 2027, 09:00 Uhr

Offizielle Quellen

Passende Tools

TOOLStorage-Cluster-KapazitätsrechnerNodes, Datenträger und Schutzprofil eingeben: Brutto- und Nutzkapazität bei Replikation oder Erasure Coding, Overhead, Füllgrenze und realistische Reserve für einen Node-Ausfall.TOOLCluster-Hardware-PlanerRAM, 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.TOOLReplikation und Quorum Simulator2 Nodes, 2 Nodes + Witness, 3 oder 5 Nodes: Ausfälle und Netztrennungen durchspielen und getrennt sehen, ob Quorum, Datenkopien und Schreibzugriff erhalten bleiben — für Ceph, DRBD und Proxmox.TOOLStorage-Netzwerk-Rechner1, 2,5, 10 oder 25 Gbit/s: Replikationsverkehr, Last je Node, maximale Schreibrate und Recovery-Dauer nach einem Node-Ausfall überschlagen — mit offenen Annahmen.TOOLCluster-Troubleshooting-AssistentCeph, DRBD, LINSTOR oder Longhorn: Symptom wählen oder Statuszeile einfügen und lesende Diagnosebefehle mit Deutung abarbeiten — Ursachen klar als Hypothesen.

Grundlagen verteilter Speichersysteme

Technologien im Überblick

Stärken

Grenzen

Stärken

Grenzen

Stärken

Grenzen

Stärken

Grenzen

Stärken

Grenzen

Stärken

Grenzen

Stärken

Grenzen

Stärken

Grenzen

Hardware, Netzwerk und Architektur

Ceph im Detail

LINSTOR, DRBD und Alternativen

Kubernetes und Cloud Native Storage

Hochverfügbarkeit und Datensicherheit

Performance und Skalierung

Administration und Monitoring

Praxisprojekte und Entscheidung

Offizielle Quellen

Passende Tools

Verwandte Themen