Managed Proxmox-Cluster mit SAN: was im Betrieb wirklich zählt

/01Was einen Managed-Proxmox-Cluster mit SAN ausmacht

Ein Managed-Proxmox-Cluster mit SAN ist zunächst nichts anderes als mehrere Proxmox-VE-Knoten, die sich denselben Block-Speicher auf einem Storage Area Network teilen — angebunden per Fibre Channel oder iSCSI, meist aus einem vorhandenen SAN, das vorher VMware oder Hyper-V getragen hat. „Managed" heißt in diesem Zusammenhang nicht die Technik selbst, sondern wer sie dauerhaft beobachtet: Quorum-Status, Pfad-Redundanz auf dem SAN, Patch-Stände und das Corosync-Netz sind keine Einmalkonfiguration, sondern eine laufende Aufgabe, die jemand übernehmen muss — im eigenen Haus oder bei einem Dienstleister.

Was dieser Artikel nicht behandelt: einen Cluster, bei dem jeder Knoten nur lokale Platten nutzt, oder Ceph als verteilten Software-Storage ohne zentrales Array. Beide sind legitime Proxmox-Architekturen, aber andere — die Abgrenzung dazu zieht der vorletzte Abschnitt. Hier geht es um die Kombination, die ein bestehendes SAN weiterverwendet: SAN-Anbindung, Shared LVM, Hochverfügbarkeit und der Betrieb, der das zusammenhält.

/02Architektur: mindestens drei Stimmen, ein eigenes Quorum

Die Proxmox-Dokumentation nennt für Hochverfügbarkeit „at least three cluster nodes (to get reliable quorum)" — und präzisiert an anderer Stelle, dass es dabei um Stimmen geht, nicht zwingend um physische Knoten: „For smaller 2-node clusters, the QDevice can be used to provide a 3rd vote." Der Grund liegt im Mehrheitsmodell: Jeder Knoten bekommt eine Stimme, und der Cluster bleibt nur handlungsfähig, solange mehr als die Hälfte aller eingetragenen Stimmen erreichbar ist. Bei zwei bloßen Knoten gibt es rechnerisch nie eine echte Mehrheit — fällt einer aus, hat der verbleibende genau eine von zwei Stimmen, keine Mehrheit, kein automatischer Weiterbetrieb der HA-Dienste. Ein externes Quorum-Device (QDevice) auf einer dritten, beliebigen Linux-Maschine schließt diese Lücke als dritte Stimme, ohne selbst ein vollwertiger Cluster-Knoten zu sein.

In der Praxis empfehlen wir trotzdem meist drei physische Knoten statt zwei plus QDevice: Nur dann lässt sich ein Knoten für Wartung oder einen Defekt vollständig herausnehmen, ohne dass der Rest-Cluster auf eine einzige verbleibende Stimme plus ein separates QDevice angewiesen ist. Unabhängig vom gewählten Weg gilt dieselbe Regel: Die Stimmenzahl ist eine Architekturentscheidung am Anfang, keine, die sich beiläufig im laufenden Betrieb nachziehen lässt, ohne das Quorum-Verhalten neu zu testen.

/03Corosync über getrennte Links: das Nervensystem des Clusters

Das Quorum aus Abschnitt /02 stützt sich auf Corosync, den Dienst, der laufend feststellt, welche Knoten noch Mitglied des Clusters sind. Für diese Mitgliedschaftsprüfung nennt die Proxmox-Dokumentation eine enge Vorgabe: „The Proxmox VE cluster stack requires a reliable network with latencies under 5 milliseconds (LAN performance) between all nodes to operate stably." Das ist kein Bandbreitenproblem — Corosync selbst braucht kaum Durchsatz —, sondern eine Isolationsfrage: Teilt sich Corosync ein Interface mit SAN- oder Backup-Verkehr, reicht eine Lastspitze, um die Latenz kurzzeitig über diese Schwelle zu heben und das Quorum zu kippen.

Corosync selbst ist für Redundanz gebaut: Laut Hersteller unterstützt es „up to 8 links" und wechselt automatisch, wenn einer ausfällt. In der Praxis genügt den meisten Mittelstandsclustern eine zweite, unabhängige Netzwerkkarte auf eigener Hardware als Fallback-Link. Die Proxmox-Dokumentation zeigt dafür ein Vorgehen, bei dem jeder Knoten im Nodelist-Abschnitt von corosync.conf einen zweiten Adresseintrag bekommt:

# /etc/pve/corosync.conf — Ausschnitt, zwei Links je Knoten
nodelist {
  node {
    name: pve01
    nodeid: 1
    quorum_votes: 1
    ring0_addr: 10.10.10.1
    ring1_addr: 10.20.20.1
  }
  node {
    name: pve02
    nodeid: 2
    quorum_votes: 1
    ring0_addr: 10.10.10.2
    ring1_addr: 10.20.20.2
  }
}
totem {
  interface {
    linknumber: 0
  }
  interface {
    linknumber: 1
  }
}

Laut Proxmox-Dokumentation reicht das Eintragen allein: „The new link will be enabled as soon as you follow the last steps to edit the corosync.conf file. A restart should not be necessary." Ob der neue Link tatsächlich geladen wurde, zeigt journalctl -b -u corosync; ob der Cluster auch ohne den ursprünglichen Link stabil bleibt, lässt sich laut Dokumentation gezielt testen, indem man „temporarily disconnecting the old link on one node" und anschließend pvecm status prüft. Wie dieses Netz im laufenden Betrieb überwacht wird, welche Fehler in der Praxis zu nächtlichen Fencing-Vorfällen führen und wie man sie diagnostiziert, behandelt der eigene Artikel zu Corosync und Fencing im Detail — hier zählt nur: Ohne dediziertes, redundantes Cluster-Netz ist jeder weitere Baustein dieses Artikels auf Sand gebaut.

/04SAN-Anbindung: Fibre Channel oder iSCSI, immer mit Multipath

Unter dem Cluster-Netz liegt die zweite Leitung: der Weg zum SAN selbst. Proxmox unterscheidet hier nicht grundlegend zwischen den Transportarten — laut Storage-Dokumentation gilt für beide dieselbe Mechanik: „With iSCSI, FibreChannel (FC), or SAS block storage as shared storage in a cluster, LVM is used to split the LUN into virtual disks." Fibre Channel braucht eigene HBA-Karten und ein eigenes Fabric, dafür eine vorhersagbare, von Ethernet-Last unabhängige Latenz. iSCSI läuft über gewöhnliche Netzwerkkarten und ist günstiger in der Erstausstattung, teilt sich das Netz aber potenziell mit anderem IP-Verkehr — ein Grund mehr, es sauber von Corosync zu trennen.

Beide Wege verlangen dasselbe Fundament: Multipath. Die Proxmox-eigene Anleitung verweist für iSCSI-, FC- und SAS-Umgebungen ausdrücklich darauf, „including multipathing which is usually a requirement in these scenarios" — ohne Multipath sieht Linux dasselbe LUN über mehrere physische Pfade mehrfach, was Datenkorruption statt Redundanz bedeutet. Ein lauffähiges Beispiel für multipath.conf mit Blacklist und WWID-Freigabe sowie die Einrichtung von Zoning und LUN-Masking zeigt der Grundlagenartikel zur FC-SAN-Migration bereits Schritt für Schritt. Ob die Bündelung funktioniert hat, zeigt multipath -ll: Jedes gefundene LUN erscheint dort mit seiner WWID, dem resultierenden /dev/mapper-Gerät und je einer Zeile pro physischem Pfad, deren letztes Feld den aktuellen Zustand trägt — active ready running für einen gesunden Pfad, faulty für einen ausgefallenen. Wie genau diese Ausgabe zu lesen ist und was ein typischer Pfadausfall in der Zeitachse auslöst, zeigt der vertiefende Artikel zur SAN-Multipath-Einrichtung.

/05Shared LVM: der gemeinsame Speicher unter allen Knoten

Über dem per Multipath gebündelten LUN liegt LVM: Das LUN wird als Volume Group eingebunden, jede VM-Disk wird ein eigenes Logical Volume. Damit mehrere Knoten gleichzeitig auf dieselbe Volume Group zugreifen dürfen, ohne sich gegenseitig die Metadaten zu zerschießen, braucht der Storage-Eintrag das Flag shared — die Proxmox-Dokumentation beschreibt die Folge so: Das LVM-Backend implementiert „cluster-wide locking if the storage is marked as shared in the configuration." Ohne dieses Flag hält Proxmox den Speicher für lokal, und zwei Knoten, die gleichzeitig schreiben, würden sich die Volume Group beschädigen.

# /etc/pve/storage.cfg
lvm: san01
    vgname shared-san
    shared 1
    content images,rootdir

Die Koordination, welcher Knoten welches Logical Volume gerade aktiviert hat, übernimmt dabei nicht ein Cluster-Dateisystem wie VMFS bei VMware, sondern die Proxmox-eigene, über Corosync replizierte Konfigurationsdatenbank. Funktional ist das Ergebnis gleichwertig — gemeinsamer Block-Speicher mit Live-Migration und HA —, nur die Mechanik darunter ist eine andere, und sie bringt die Einschränkung mit, die der nächste Abschnitt behandelt.

/06Snapshots auf Shared LVM: eine Besonderheit mit Grenzen

Natives LVM kennt zwar Snapshots, aber nicht brauchbar auf geteiltem Speicher: Die Proxmox-Dokumentation nennt reguläre LVM-Snapshots ausdrücklich ungeeignet, weil sie „interfere with all write operations within the entire volume group while the snapshot is active, which causes significant I/O degradation" — auf einem Cluster-LUN mit mehreren aktiven VMs ist das keine Option. Seit Proxmox VE 9.0 (2025) gibt es dafür einen eigenen Mechanismus, „snapshot-as-volume-chain": eine Kette aus QCOW2-Overlays statt eines echten Storage-Snapshots.

Die Mechanik, der Speicherbedarf und die gemessenen Leistungswerte dieser Kette stehen vollständig in der eigenen Tiefenanalyse zu SAN-Snapshots. Für die Architekturentscheidung an dieser Stelle reicht die Kurzfassung: Ein Snapshot auf dem SAN ist ein Rücksprungpunkt für Testfenster, kein Ersatz für ein Backup.

/07Hochverfügbarkeit: was HA im SAN-Cluster voraussetzt

Genau hier liegt der eigentliche Gewinn eines SAN-Clusters gegenüber lokalem Storage: Die Proxmox-Dokumentation nennt unter den Voraussetzungen für HA ausdrücklich „shared storage for VMs and containers" — ohne geteilten Speicher ist Hochverfügbarkeit im Proxmox-Sinn schlicht nicht vorgesehen, weil eine VM dann nicht ohne Kopieren der Disk auf einem anderen Knoten weiterlaufen kann. Mit SAN ist genau das gegeben: Alle Knoten sehen dasselbe LUN, der HA-Manager muss im Ernstfall nur die VM-Konfiguration und den RAM-Zustand verschieben, nicht die Festplatte.

Dasselbe Prinzip trägt die Live-Migration im Normalbetrieb: Laut Proxmox-Dokumentation pausiert die Quell-VM am Ende des Umzugs nur so lange, bis der Zielknoten „the new running VM in well under a second" übernimmt — deutlich unter einer Sekunde, sofern die Disk bereits auf dem gemeinsamen SAN liegt und nicht mitkopiert werden muss. Wie Fencing, Watchdog und ein sauberer Wartungsablauf dafür sorgen, dass dabei kein versehentliches Failover ausgelöst wird, zeigt der Artikel zu Corosync und Fencing bereits im Detail.

Ein durchgespielter Knotenausfall zeigt, wie die bisher genannten Fristen zusammenwirken. Fällt pve02 unerwartet aus, während HA-Dienste auf ihm liefen: Innerhalb der in Abschnitt /03 beschriebenen 5-Millisekunden-Toleranz bemerkt Corosync den Verlust, und der Cluster rechnet sein Quorum neu — bei drei Knoten bleiben zwei von drei Stimmen, das Quorum besteht weiter. Der verlorene Knoten selbst kann laut Proxmox-Dokumentation das Quorum nicht mehr erreichen und wartet, bis sein Watchdog nach spätestens 60 Sekunden einen Reboot auslöst — die eingebaute Garantie, dass er keine widersprüchlichen Schreibzugriffe auf das gemeinsame LUN mehr ausführt. Parallel dazu übernimmt ha-manager auf den verbleibenden Knoten die Dienste von pve02; laut Dokumentation liegen „typical error detection and failover times of about 2 minutes" dazwischen. Für die betroffenen VMs bedeutet das: keine Downtime von null, aber eine, die auf eine bekannte Obergrenze begrenzt ist — anders als bei einer geplanten Live-Migration, die wie oben beschrieben in deutlich unter einer Sekunde abläuft, weil dort kein Watchdog und keine Quorum-Neubildung nötig sind.

/08Wo es hakt: das SAN als möglicher Single Point of Failure

Alles bisher Beschriebene löst das Problem der Knoten-Redundanz — nicht das Problem der Storage-Redundanz. Ein SAN-Cluster macht den Ausfall eines Proxmox-Knotens unkritisch, weil jeder andere Knoten dasselbe LUN sieht. Was er nicht automatisch löst: den Ausfall des SAN selbst. Ein Array mit einem einzigen Controller, einem einzigen Fabric oder einem einzigen Switch-Pfad ist trotz drei oder fünf Proxmox-Knoten ein einziger Fehlerpunkt — fällt es aus, stehen alle Knoten gleichzeitig still, nicht nacheinander.

Multipath aus Abschnitt /04 mildert genau dieses Risiko, aber nur, wenn es auch echte Redundanz zu bündeln gibt: zwei unabhängige HBA-Ports je Knoten, angeschlossen an zwei getrennte Fabrics, mit einem Array, das selbst über redundante Controller verfügt. Fehlt eine dieser Ebenen — etwa weil nur ein Controller oder nur ein Switch im Spiel ist —, bündelt Multipath technisch korrekt, aber es bündelt Pfade, die am Ende alle am selben Nadelöhr hängen. Das ist der Punkt, an dem „SAN-Cluster" und „hochverfügbarer SAN-Cluster" auseinanderfallen, und er wird bei Migrationsprojekten regelmäßig übersehen, weil die Proxmox-Seite der Architektur meist sorgfältiger geplant wird als die SAN-Seite.

In der Praxis zeigt sich dieser Punkt selten beim Kauf, sondern erst beim Aufbau: Ein Array wird oft mit zwei Controllern bestellt, aber nur über einen davon tatsächlich verkabelt, weil „das zweite Kabel ja noch fehlt" und das Projekt termingebunden ist. Technisch läuft der Cluster dann einwandfrei — bis genau der eine verkabelte Controller ausfällt oder für ein Firmware-Update neu startet. Ein kurzer Funktionstest gehört deshalb zur Abnahme jeder SAN-Anbindung dazu, nicht nur ihre Einrichtung: ein Pfad, ein Switch, im Idealfall ein Controller wird gezielt getrennt, während der Cluster unter Beobachtung bleibt — genau die Prüfung, die die Proxmox-Dokumentation für das Corosync-Netz in Abschnitt /03 ausdrücklich empfiehlt, hier nur auf die Storage-Seite übertragen.

/09Was der Betrieb durch HostSpezial abnimmt

Ein Managed-Proxmox-Cluster mit SAN bleibt ein lebendiges System: Firmware-Stände auf HBAs, Multipath-Konfiguration, Corosync-Ring-Status, Quorum und die Füllstände der Volume Group verändern sich mit jeder neuen VM und jedem Patch. HostSpezial übernimmt dafür im Betrieb konkret: laufendes Monitoring von Ring-Status, Quorum und SAN-Pfaden, Patch-Management in festen Fenstern von Montag bis Freitag statt ad hoc am Wochenende, Rufbereitschaft außerhalb dieser Fenster für echte Störfälle, und den Betrieb aus dem Rechenzentrum Coburg mit Ausweichstandort Neustadt. Die Informationssicherheit dahinter ist nach ISO/IEC 27001:2024 zertifiziert (Zertifikat 202787) — keine Selbstauskunft, sondern ein geprüfter Stand.

/10Wann sich das lohnt — und wann Ceph die bessere Wahl ist

Ein Managed-Proxmox-Cluster mit SAN ist die naheliegende Wahl, wenn ein funktionsfähiges FC- oder iSCSI-SAN bereits vorhanden ist — meist aus einer VMware- oder Hyper-V-Umgebung, die abgelöst wird. Die Investition in Array, Fabric und Lizenzen ist dann bereits getätigt, und Shared LVM nutzt sie unverändert weiter, ohne Umbau der Storage-Seite.

Dagegen spricht

• Kein SAN vorhanden oder eine Neubeschaffung ohnehin fällig: Dann ist die Rechnung offen, und Ceph verdient einen ernsthaften Blick. Die Proxmox-Dokumentation beschreibt Ceph RADOS als „a distributed systems, replicating storage data to different nodes that can be accessed as RBD" — Redundanz entsteht über mehrere Knoten mit lokalen Platten, nicht über ein zentrales Array mit eigener Redundanzpflicht wie in Abschnitt /08 beschrieben.
• Kein Team, das SAN-spezifisches Wissen pflegt: Multipath, Zoning, LUN-Masking und Firmware-Pflege sind eigenes Fachwissen. Ceph bringt dafür eigene Betriebsanforderungen mit (ausreichend Knoten, dediziertes Storage-Netz), aber ohne separate Array-Hardware.
• Wachstum in kleinen, unregelmäßigen Schritten: Ceph skaliert über zusätzliche Knoten mit lokalen Platten vergleichsweise einfach; ein SAN-Array wächst in der Regel über Lizenz- und Hardware-Sprünge, die sich schlechter in kleinen Schritten planen lassen.

In der Praxis ist die Entscheidung selten rein technisch — sie hängt am vorhandenen Investment und am Team, das den Betrieb trägt. Ein Mischbetrieb ist dabei kein Widerspruch: Viele Umgebungen, die wir übernehmen, betreiben ein vorhandenes FC-SAN für den produktiven Kernbestand an VMs weiter und bauen neue Kapazität gezielt auf Ceph auf, statt beide Architekturen gegeneinander auszuspielen. Entscheidend ist dann nur, dass beide Storage-Welten im selben Cluster sauber getrennt administriert werden — nicht, dass man sich für immer auf eine einzige festlegt. Wie Ceph als lizenzfreier Enterprise-Storage im Detail funktioniert, zeigt der eigene Artikel zu Ceph Storage.

/11Häufige Fragen