SAN oder Ceph: eine Entscheidung mit Trade-offs, keine Glaubensfrage

/01Was SAN und was Ceph in einer Proxmox-Umgebung sind

Ein SAN ist in einer Proxmox-Umgebung praktisch immer dasselbe: ein externes Storage-Array, per Fibre-Channel oder iSCSI angebunden, auf dem Proxmox ein oder mehrere LUNs als Shared-LVM-Storage einbindet. Die Intelligenz — Caching, RAID, meist auch die Snapshot-Funktion — sitzt im Controller des Arrays, nicht im Proxmox-Cluster. Ceph ist das Gegenteil: ein softwaredefinierter, über mehrere Knoten verteilter Storage, der in Proxmox-Umgebungen üblicherweise hyperkonvergent betrieben wird — auf denselben Servern, auf denen auch die VMs laufen. Die Daten liegen repliziert über die lokalen Platten mehrerer Knoten, verwaltet durch einen Platzierungsalgorithmus, nicht durch eine zentrale Steuereinheit.

Was beide nicht sind, lohnt sich vorab zu klären. Ceph ist kein Drop-in-Ersatz für VMFS auf Dateisystemebene — es bringt ein eigenes Blockspeichermodell mit, auf das Proxmox über RBD-Images zugreift. Und ein SAN ist nicht automatisch die schlechtere Wahl, nur weil Ceph im Proxmox-Ökosystem die technisch jüngere Option ist: Für ein bestehendes Array mit Restlaufzeit und eingespieltem Multipath-Setup ist die Fortführung häufig die wirtschaftlich wie betrieblich ruhigere Entscheidung. Wer gerade von VMware wegmigriert und das SAN ohnehin weiterbetreiben will, findet den konkreten Migrationspfad im zweiten Teil dieser Reihe.

/02Die Grundentscheidung: zentraler Speicher oder verteilter Cluster

Die eigentliche Weichenstellung liegt nicht bei Features, sondern bei der Architektur. Ein SAN zentralisiert den Speicher in einem Gerät außerhalb der Rechenknoten — fällt ein Proxmox-Knoten aus, bleiben die Daten unberührt, weil sie gar nicht auf ihm lagen. Ceph verteilt den Speicher über dieselben Knoten, auf denen auch gerechnet wird, und schützt stattdessen durch Replikation über mehrere Hosts hinweg. Beide Modelle funktionieren, aber sie stellen unterschiedliche Mindestanforderungen an die Clustergröße.

Für Ceph nennt die Proxmox-Dokumentation eine klare Untergrenze: „To build a hyper-converged Proxmox + Ceph Cluster, you must use at least three (preferably) identical servers for the setup." Konkret empfiehlt sie „a Ceph cluster with at least three nodes and at least 12 OSDs, evenly distributed among the nodes", dazu mindestens drei Monitore, denn „At least three Monitors are needed for quorum". Ein Zwei-Knoten-Cluster mit Ceph ist damit zwar technisch möglich, bewegt sich aber außerhalb dessen, was Proxmox selbst als stabile Grundkonfiguration beschreibt. Ein SAN kennt diese Untergrenze nicht: Zwei Proxmox-Knoten plus Quorum-Device und ein redundant angebundenes Array reichen bereits für einen funktionierenden, HA-fähigen Cluster — das Quorum-Device übernimmt dabei die Stimme, die einem dritten vollwertigen Knoten fehlt.

/03Snapshots: die Schwachstelle der SAN-Seite

Hier liegt der Punkt, an dem viele VMware-Umsteiger stolpern. Unter VMFS war ein VM-Snapshot eine Zeile im Kontextmenü, unabhängig davon, wie viele VMs auf demselben Datastore lagen. Natives LVM auf geteiltem SAN-Storage kann das nicht: Die Proxmox-Dokumentation beschreibt reguläre LVM-Snapshots als ineffizient: Sie „interfere with all write operations within the entire volume group while the snapshot is active, which causes significant I/O degradation" — ein Snapshot betrifft also nicht nur die eine Disk, sondern beeinträchtigt alle Schreibvorgänge der gesamten Volume Group und bremst die I/O deutlich, solange er aktiv ist. Thin Provisioning per LVM-thin scheidet auf geteiltem Storage ebenfalls aus, weil mehrere Knoten dort nicht gleichzeitig sicher in dieselben Metadaten schreiben können.

Seit Proxmox VE 9 gibt es mit den „snapshots as volume chains" einen nativen Workaround: eine Kette aus QCOW2-Overlays statt eines echten Storage-Snapshots. Der Mechanismus funktioniert, trägt aber weiterhin den Status Technologie-Vorschau und kostet spürbar Leistung — Details, Speicherbedarf und Messwerte dazu stehen im eigenen Artikel zur Snapshot-Kette auf Shared LVM. Für die Entscheidung SAN gegen Ceph zählt an dieser Stelle vor allem: Wer häufige, performante, produktionsreife VM-Snapshots ohne Zusatzschicht braucht, bekommt das bei Ceph nativ. Ceph bringt RBD-Snapshots als Grundfunktion des Speicherformats mit, ohne die hier beschriebenen Einschränkungen.

/04Was Ceph an Hardware und Netz tatsächlich braucht

Die Proxmox-Dokumentation ist bei der Hardware ungewöhnlich konkret. CPU: „you should assign at least one CPU core (or thread) to each Ceph service" — bei einem Knoten mit einem Monitor, einem Manager und sechs OSDs rechnet sie mit „8 CPU cores purely for Ceph when targeting basic and stable performance". Arbeitsspeicher: „The current recommendation is to configure OSDs with at least 8 GiB of memory for good performance", wobei der OSD-Daemon selbst standardmäßig 4 GiB belegt. Die Ceph-eigene Dokumentation ergänzt das um Werte je Daemon: ein Monitor braucht mindestens 5 GB RAM und 100 GB SSD-Speicher, ein OSD mit NVMe-Unterbau vier bis sechs CPU-Threads.

Beim Netz wird es noch deutlicher: „We recommend a network bandwidth of at least 10 Gbps, or more, to be used exclusively for Ceph traffic." Für anspruchsvolle Setups empfiehlt Proxmox ein dediziertes, sehr schnelles Netz allein für den internen Cluster-Verkehr — „25 Gpbs" oder mehr — zusätzlich zu einem „10+ Gbps" schnellen öffentlichen Netz für den Zugriff der VMs auf den Storage, getrennt vom Corosync-Netz. Drei eigenständige Netze also, nicht eines. Bei den Pools gilt ohne eigene Angabe ein Standard von „128 PGs, a size of 3 replicas and a min_size of 2 replicas" — Replikationsfaktor 3 bedeutet: Ein Terabyte Nutzdaten belegt drei Terabyte Rohkapazität auf den Platten. Wer das senken will, kann Erasure Coding einsetzen; bei einem gängigen 4+2-Profil liegt der Kapazitätsfaktor laut Ceph-Dokumentation bei 1,5 statt 3,0 — allerdings „uses more RAM and CPU than replication when it accesses or recovers objects".

# Minimaler Ceph-Cluster einrichten (auf jedem der mind. 3 Knoten)
pveceph install
pveceph init --network 10.10.10.0/24
pveceph mon create

# Pro Knoten mehrere OSDs aus Rohdisks anlegen
pveceph osd create /dev/sdb
pveceph osd create /dev/sdc

# Pool mit Proxmox-Storage-Anbindung erstellen
pveceph pool create vm-pool --add_storages

# Status pruefen
pveceph status

Für einen Mittelstandscluster mit vier bis sechs Servern ist das kein unlösbares Budget — aber es ist ein Budget, das bei der Kalkulation eines SAN-Vergleichs nicht unter den Tisch fallen darf: dediziertes 10-Gbit/s-Netz, genug CPU-Reserve neben der VM-Last, und bei kleineren Clustern eine Kapazitätsplanung, die mit Replikationsfaktor 3 rechnet, nicht mit der Rohgröße der Platten.

/05Was ein klassisches SAN an Hardware und Netz braucht

Die Rechnung auf der SAN-Seite sieht anders aus, weil der größte Teil der Intelligenz bereits im Array steckt und nicht neu aufgebaut werden muss. Proxmox selbst stellt an das Storage-Backend kaum Anforderungen: Die LVM-Dokumentation verlangt lediglich, dass der Storage als „shared" markiert wird, damit „the backend implements proper cluster-wide locking", und dass bei mehreren Zugriffspfaden Multipath sauber konfiguriert ist — „usually a requirement in these scenarios", wie es in der Dokumentation zum Storage-Backend heißt. Ein zusätzliches, dediziertes 10- oder 25-Gbit/s-Netz allein für den Speicherverkehr, wie Ceph es verlangt, ist bei einem SAN mit vorhandener Fibre-Channel- oder iSCSI-Infrastruktur in der Regel bereits vorhanden, nicht neu zu beschaffen.

Die Einrichtung selbst bleibt knapp, gerade im Vergleich zur Ceph-Befehlsfolge aus dem vorigen Abschnitt — der größte Teil der Arbeit steckt in der Multipath-Konfiguration, nicht im Storage-Eintrag selbst:

# /etc/multipath.conf — Pfade zum SAN-LUN buendeln
defaults {
    find_multipaths yes
    user_friendly_names yes
}
multipaths {
    multipath {
        wwid    3600a098038303333795d4a5869675835
        alias   san01-lun0
    }
}

# Dienst neu laden, Pfadstatus pruefen
systemctl reload multipathd
multipath -ll

# /etc/pve/storage.cfg — LUN als Shared LVM einbinden
lvm: san01
    vgname shared-san
    shared 1
    content images,rootdir

Erst wenn multipath -ll für jeden Pfad active ready running meldet, ist das LUN bereit für die Volume-Group-Anlage — ein Pfad im Zustand failed oder faulty ist an dieser Stelle ein Abbruchkriterium. Diese Einrichtung ist pro Knoten einmalig, nicht wiederkehrend wie das Hinzufügen weiterer OSDs bei Ceph.

Was ein SAN stattdessen kostet, ist weniger sichtbar: Lizenz- oder Wartungskosten für die Array-Software, gegebenenfalls eine separate Snapshot- oder Replikationslizenz des Herstellers, und eine Abhängigkeit vom jeweiligen Hersteller-Ökosystem. Ceph ist in diesem Sinn lizenzfrei — der Preis wird stattdessen in Serverhardware, CPU-Reserve und Netzausbau bezahlt, nicht in einer Rechnung vom Storage-Hersteller.

/06Latenz, Durchsatz und was bei Recovery passiert

Bei der Latenz lohnt sich Ehrlichkeit statt Pauschalurteil. Ein SAN mit dedizierter Fibre-Channel-Anbindung liefert in der Regel niedrige, vorhersagbare Latenzen, weil der Pfad vom Host zum Controller kurz und für genau diesen Zweck gebaut ist. Ceph legt eine zusätzliche Netzwerk- und Softwareschicht zwischen VM und Platte — jeder Schreibvorgang muss laut Replikationsfaktor auf mehrere Knoten verteilt und dort bestätigt werden, bevor er als abgeschlossen gilt. Das kostet strukturell mehr Zeit als ein Schreibvorgang, der innerhalb eines einzelnen Controllers verarbeitet wird. Belastbare Millisekundenwerte für die eigene Umgebung liefert aber nur eine Messung vor Ort, keine pauschale Angabe aus der Dokumentation — zu viele Faktoren wie NVMe- gegen SATA-Backend, Netzauslastung und Clustergröße spielen hinein.

Was die Proxmox-Dokumentation dagegen ausdrücklich warnt, ist Recovery-Verhalten: „The volume of traffic, especially during recovery, will interfere with other services on the same network, especially the latency sensitive Proxmox VE corosync cluster stack can be affected, resulting in possible loss of cluster quorum." Fällt bei Ceph ein Knoten oder eine Platte aus, beginnt ein Rebalancing, das spürbar Netzlast erzeugt — bei unzureichender Netztrennung kann das im schlechtesten Fall die Cluster-Kommunikation selbst stören. Ein SAN kennt diesen Effekt in dieser Form nicht: Fällt eine Platte im Array aus, übernimmt der RAID-Rebuild innerhalb des Controllers, ohne dass der Proxmox-Cluster davon betroffen ist.

Für die Praxis folgt daraus eine klare Konsequenz bei der Netzplanung: Wer Ceph einsetzt, trennt das Speichernetz vom Corosync-Netz physisch, nicht nur per VLAN — genau das warnt die Dokumentation an, wenn sie von „possible loss of cluster quorum" durch überlasteten gemeinsamen Netzverkehr spricht. Ein separates, auch nur 1-Gbit/s schnelles Netz allein für Corosync kostet wenig zusätzliche Hardware, verhindert aber genau das Szenario, in dem ein Storage-Problem zu einem Cluster-Problem wird. Diese Trennung ist bei einem SAN-Aufbau kein Thema, weil der Storage-Verkehr dort ohnehin über eigene Fibre-Channel- oder iSCSI-Adapter läuft, nicht über dasselbe Ethernet-Netz wie der Cluster-Verkehr.

/07Das Teamwissen, das selten eingepreist wird

Die größte unterschätzte Kostenstelle ist nicht Hardware, sondern Betriebswissen. Ein SAN-Administrator braucht vor allem drei Dinge im Griff: Zoning und Multipath auf der Fibre-Channel- oder iSCSI-Seite, die herstellereigene Verwaltungssoftware des Arrays, und das Verständnis, wann ein LUN voll läuft oder ein Pfad flattert. Das ist spezialisiertes, aber eng begrenztes Wissen — wer es einmal beherrscht, wendet es über Jahre nahezu unverändert an, weil sich Array-Firmware seltener grundlegend ändert als Software-Storage.

Ceph verlangt ein anderes, breiteres Wissen: Placement Groups und deren Anzahl richtig dimensionieren, CRUSH-Regeln verstehen und bei Bedarf anpassen, OSD-Ausfälle und das anschließende Rebalancing einordnen können, und im Ernstfall eine Pool- oder PG-Fehlkonfiguration unter Zeitdruck reparieren. Das lässt sich lernen, braucht aber kontinuierliche Pflege — Ceph-Versionen bringen regelmäßig Änderungen am empfohlenen Vorgehen, anders als ein über Jahre stabiles Array-Interface. Für ein IT-Team, das ohnehin schon mit Proxmox, Linux und Netzwerktechnik vertraut ist, ist das kein Hindernis. Für ein kleines Team ohne diese Vorerfahrung ist es ein echter Einarbeitungsaufwand, der in keiner Hardware-Kalkulation auftaucht.

/08Wo es bei beiden Wegen hakt

Dagegen spricht SAN

• Snapshots bleiben ein Kompromiss: Native, produktionsreife VM-Snapshots fehlen; der Workaround über die QCOW2-Volume-Kette ist mit Stand Proxmox VE 9.2 weiterhin Technologie-Vorschau und kostet Leistung.
• Herstellerabhängigkeit bleibt bestehen: Firmware-Updates, Supportverträge und gegebenenfalls Lizenzkosten für Snapshot- oder Replikationsfunktionen hängen weiterhin am Array-Hersteller, nicht an Proxmox.
• Kapazität wächst nur über neue Hardware: Ein SAN lässt sich selten beliebig granular erweitern — meist in Schritten von Shelf oder Controller, nicht Platte für Platte wie bei Ceph.

Dagegen spricht Ceph

• Die Einstiegshürde ist real: Mindestens drei identische Knoten als Pflicht, dazu empfohlene 12 OSDs und ein dediziertes 10-Gbit/s-Netz sind für einen Zwei- oder Drei-Server-Mittelstandscluster oft überdimensioniert.
• Latenz ist strukturell höher: Die Netzwerk- und Replikationsschicht kostet Zeit gegenüber einem Schreibvorgang, der innerhalb eines SAN-Controllers verarbeitet wird — bei latenzkritischen Datenbanken ist das spürbar.
• Recovery kann den Cluster selbst belasten: Ohne sauber getrennte Netze kann Rebalancing-Traffic laut Proxmox-Dokumentation die Corosync-Kommunikation stören und im schlechtesten Fall das Quorum gefährden.

/09Wann SAN die ruhigere Wahl ist — und wann Ceph

Ehrlich: Es gibt keine pauschal richtige Antwort, nur eine, die zur jeweiligen Ausgangslage passt. SAN ist die ruhigere Wahl, wenn ein funktionierendes Array mit Restlaufzeit vorhanden ist, der Cluster klein bleibt (zwei bis drei Knoten), das Team bereits mit Fibre-Channel oder iSCSI vertraut ist, und native VM-Snapshots verzichtbar sind oder über eine Array-eigene Snapshot-Funktion gelöst werden. Ceph lohnt sich, wenn ohnehin vier oder mehr identische Server angeschafft werden, native Snapshots für den Betrieb wichtig sind, kein SAN-Invest mehr gebunden werden soll, und das Team Kapazität hat, sich in CRUSH, Placement Groups und Recovery-Verhalten einzuarbeiten.

In der Praxis sehen wir bei HostSpezial beide Wege regelmäßig produktiv — und raten von Pauschalempfehlungen ab, die unabhängig von Clustergröße und Vorwissen „immer Ceph" oder „immer SAN" sagen. Managed durch uns heißt bei beiden Wegen dasselbe Leistungsversprechen: kontinuierliches Monitoring von Storage und Cluster, abgestimmte Patch-Fenster statt Überraschungsupdates, Rufbereitschaft bei kritischen Ausfällen, und Betrieb aus dem Rechenzentrum Coburg mit Ausweichstandort Neustadt, ISO/IEC 27001:2024-zertifiziert. Die Storage-Architektur entscheiden wir mit Ihnen anhand Ihrer tatsächlichen Clustergröße und Ihres Teams, nicht anhand eines Trends.

/10Häufige Fragen