SAN an Proxmox anbinden: Multipath ist die Pflicht, nicht die Kür

/01Was Multipath ist — und warum ein SAN es braucht

Ein SAN-LUN ist über mehr als einen physischen Weg erreichbar, sobald ein Knoten in einem Proxmox-Cluster zwei HBA-Ports oder zwei Netzwerkkarten für den Storage-Zugriff hat — das ist der ganze Sinn der Redundanz. Ohne weitere Software sieht Linux dieses eine LUN dabei aber als zwei, drei oder vier verschiedene Blockgeräte, je nach Zahl der Pfade. Schreibt eine Anwendung über zwei dieser vermeintlich getrennten Geräte gleichzeitig auf dasselbe LUN, entsteht keine Redundanz, sondern Datenkorruption.

Multipath löst das: multipathd erkennt, dass mehrere Blockgeräte dieselbe World Wide Identifier (WWID) tragen, bündelt sie zu einem einzigen logischen Gerät unter /dev/mapper/ und entscheidet selbst, über welchen Pfad geschrieben wird und was bei einem Pfadausfall passiert. Die Proxmox-Proxmox-Dokumentation stellt das für iSCSI-, Fibre-Channel- und SAS-Anbindungen nicht zur Wahl: „With iSCSI, FibreChannel (FC), or SAS block storage as shared storage in a cluster, LVM is used to split the LUN into virtual disks", und das zugehörige Multipath-Kapitel beschreibt die Einrichtung als etwas, das „is usually a requirement in these scenarios" — Multipath ist der Normalfall, kein Sonderfall für besonders kritische Umgebungen.

/02iSCSI oder Fibre Channel: zwei Transportarten, dieselbe Aufgabe

Für die LVM-Schicht aus Managed Proxmox-Clustern macht Proxmox keinen grundlegenden Unterschied zwischen den beiden Transportarten — am Ende steht in beiden Fällen ein Blockgerät, auf dem LVM eine Volume Group anlegt, anders als bei VMFS unter VMware, das direkt ein Cluster-Dateisystem auf das LUN legt. Der Unterschied zwischen den Transportarten liegt in der Infrastruktur darunter: Fibre Channel braucht eigene HBA-Karten, eigene Switches (das „Fabric") und eigenes Zoning, dafür eine Latenz und Bandbreite, die von keinem anderen Netzwerkverkehr beeinflusst wird. iSCSI kapselt SCSI-Kommandos in IP-Pakete und läuft über gewöhnliche Netzwerkkarten — günstiger in der Erstausstattung, aber nur so gut wie die Trennung vom restlichen Netzwerkverkehr, die man ihm selbst verordnet. Ein dritter Weg, NVMe-oF, taucht auf neueren Arrays auf, ändert an der Multipath-Mechanik selbst aber nichts — Proxmox bindet auch dieses Protokoll unterhalb von LVM ein.

Wer von Hyper-V oder VMware auf ein bestehendes SAN migriert, übernimmt Fabric und Zoning in aller Regel unverändert — Proxmox tauscht nur die Schicht darüber. Voraussetzung auf SAN-Seite ist in beiden Fällen dieselbe: ein Zoning, das jeden Proxmox-Knoten mit dem SAN-Target verbindet, und eine LUN-Maskierung, die dasselbe LUN an alle Knoten ausreicht — identisch für jeden Knoten, sonst sieht ein Teil des Clusters ein Blockgerät, das die übrigen Knoten nicht sehen, und Shared LVM aus dem Grundlagenartikel zum Managed-Proxmox-Cluster funktioniert nicht zuverlässig.

Bei iSCSI kommt eine Einstellung hinzu, die in der Praxis regelmäßig vergessen wird: Jumbo-Frames. Werden sie nur auf einem Teil der Strecke aktiviert — etwa auf den Servern, aber nicht konsequent auf jedem beteiligten Switch-Port —, werden größere Pakete fragmentiert oder verworfen, was sich zunächst als unauffällige Fehlerrate zeigt und unter Last zu Timeouts führt. Dasselbe Muster kennt auch das Corosync-Netz, wie der Artikel zu Corosync und Fencing an anderer Stelle beschreibt — bei iSCSI trifft es nicht das Cluster-Netz, sondern direkt die Storage-Performance.

Diese Trennung ist keine Kleinigkeit: Ein iSCSI-Pfad, der sich ein Interface mit Corosync oder normalem VM-Verkehr teilt, verhält sich unter Last instabil — dieselbe Problematik, die auch beim Cluster-Netz selbst zu nächtlichen Fencing-Vorfällen führt. In der Praxis bekommt iSCSI deshalb am besten eigene, VLAN-getrennte Netzwerkkarten, genau wie Fibre Channel ein eigenes Fabric bekommt.

/03multipath.conf: Pflichtfelder und ein lauffähiges Beispiel

Die Einrichtung beginnt mit dem Paket: Laut Proxmox-Wiki genügt für die meisten Fälle apt install multipath-tools; wer FC- oder SAS-LUNs mit LVM bootet, braucht zusätzlich multipath-tools-boot, damit Multipath früh genug in die initramfs eingebunden wird. Danach folgt die Konfigurationsdatei. Bleibt sie leer, greift laut Hersteller-Dokumentation eine „default configuration and a predefined list of device-specific defaults" — für den Produktivbetrieb reicht das selten, weil Array-spezifische Profile fehlen.

# /etc/multipath.conf — Grundgeruest, identisch auf allen Knoten
defaults {
    user_friendly_names yes
    find_multipaths     strict
}
blacklist {
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
}
multipaths {
    multipath {
        wwid  "3600144f028f88a0000005037a95d0001"
        alias mpath0
    }
}

Das Proxmox-Wiki empfiehlt ausdrücklich, find_multipaths auf dem Standardwert strict zu belassen: Dann legt multipathd „multipath devices ... only ... for LUNs whose WWIDs are listed in /etc/multipath/wwids" an — zufällig erkannte Geräte werden nicht automatisch gebündelt, was verhindert, dass eine einzelne lokale Platte versehentlich als Multipath-Kandidat auftaucht. Die WWID selbst liefert /lib/udev/scsi_id -g -u -d /dev/sdc, der Status danach multipath -ll.

hostspezial@pve01:~$ multipath -ll
mpath0 (3600144f028f88a0000005037a95d0001) dm-3 vendor,product
size=2.0T features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:1 sdc 8:32  active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:1 sdd 8:48  active ready running

Die Ausgabe liest sich von oben nach unten: Die erste Zeile zeigt den Alias mpath0, die WWID aus multipath.conf und das resultierende Gerät /dev/mapper/mpath0 unter dem Device-Mapper-Namen dm-3. Darunter stehen zwei Pfadgruppen — hier ein Ausdruck von path_grouping_policy failover: Die Gruppe mit status=active und höherer Priorität (prio=50) trägt den produktiven I/O-Verkehr über den Pfad sdc, die zweite Gruppe mit status=enabled steht bereit, übernimmt aber erst, wenn die erste komplett ausfällt. Jede einzelne Pfadzeile endet mit dem laut path_checker tur ermittelten Zustand — active ready running heißt: Pfad aktiv, Zielgerät antwortet, Betrieb normal. Fällt ein Pfad aus, wechselt genau dieses letzte Feld auf faulty, bevor multipathd die Gruppen neu bewertet.

Eine Einschränkung nennt der Proxmox-Wiki offen: Für array-spezifische Werte wie Pfad-Priorisierung oder Timing gibt es keine Proxmox-eigene Empfehlung — „The optimal multipath configuration highly depends on the SAN you're using. Please check your SAN vendor's documentation for recommendations." Die folgenden drei Abschnitte erklären, welche Parameter das betrifft und was ihre Standardwerte bedeuten.

/04ALUA und Pfad-Priorität: wer „besser" entscheidet

Viele Enterprise-Arrays beantworten dieselbe SCSI-Anfrage über jeden Pfad, aber nicht gleich schnell: Bei Dual-Controller-Systemen ist oft nur ein Controller der „Owner" eines LUN, der andere leitet intern weiter. Asymmetric Logical Unit Access (ALUA) macht diesen Unterschied für den Host sichtbar, statt ihn zu verschweigen. Laut multipath-tools-Dokumentation generiert der Prioritizer alua „the path priority based on the SCSI-3 ALUA settings" und akzeptiert optional den Zusatzparameter exclusive_pref_bit.

Relevant wird das über path_grouping_policy: Der Standardwert ist laut Dokumentation failover — ein Pfad aktiv, alle anderen Reserve. Die Alternative group_by_prio bildet „one priority group per priority value" und schaltet sich laut Dokumentation automatisch scharf, „If set to yes and all path devices are configured with either the alua or sysfs prioritizer" — dann nutzt der Host bevorzugte Pfade aktiv, bevor ein Ausfall sie überhaupt nötig macht, statt blind auf den ersten konfigurierten Pfad zu setzen.

/05Failover und Failback: welcher Parameter was bewirkt

Dass ein Pfad bei einem Ausfall automatisch umgeschaltet wird, ist die eine Hälfte der Geschichte — die andere ist, was passiert, wenn der ausgefallene Pfad zurückkommt. Hierfür ist failback zuständig, mit vier möglichen Werten laut Dokumentation: immediate schaltet sofort zurück auf die höchstpriorisierte Pfadgruppe, manual — der Standard — schaltet gar nicht automatisch zurück, followover nur unter bestimmten Bedingungen, und eine Zahl größer null verzögert den Rücksprung um die angegebene Sekundenzahl. Der konservative Standard manual verhindert ein Flattern zwischen Pfaden, wenn ein Pfad instabil ist und wiederholt kurz ausfällt und zurückkommt — kostet dafür aber einen manuellen Eingriff nach jeder Störung.

Noch grundsätzlicher ist no_path_retry: Es entscheidet, was bei einem vollständigen Verlust aller Pfade passiert — nicht nur eines einzelnen. Der Standard fail lässt I/O-Anfragen sofort mit einem Fehler zurückkommen. Die Alternative queue entspricht laut Dokumentation dem Verhalten von queue_if_no_path: „For never stop I/O queueing" — Schreibvorgänge warten, statt zu scheitern, bis mindestens ein Pfad zurückkehrt. Für VM-Disks auf Proxmox ist das keine akademische Entscheidung: Mit fail merkt eine VM einen kompletten SAN-Ausfall sofort als I/O-Fehler, mit queue hängt sie — manchmal überlebensnotwendig lange genug, bis das SAN zurückkommt, manchmal unbegrenzt, wenn das SAN nicht zurückkommt.

Ein durchgespielter Pfadausfall macht die Fristen greifbar. Angenommen, ein Techniker zieht versehentlich das Kabel von Fabric A, während VMs über mpath0 aus Abschnitt /03 laufen:

T+0s    Fabric A faellt aus, sdc verliert die Verbindung
T+0–5s  multipathd wartet den naechsten path_checker-Zyklus ab
        (polling_interval, Standard 5 Sekunden laut multipath-tools)
T+~5s   path_checker tur erhaelt keine Antwort mehr von sdc,
        Pfad wird als "faulty" markiert
T+~5s   I/O wechselt zur zweiten Pfadgruppe (sdd, Fabric B,
        prio=10) -- laufende VMs merken ausser einer kurzen
        Latenzspitze nichts
T+?     Fabric A kommt zurueck: mit failback=manual (Standard)
        bleibt sdd fuehrend, bis ein Administrator den
        Rueckwechsel bewusst anstoesst

Die einzige harte Zahl in diesem Ablauf ist der Standardwert für polling_interval: Laut multipath-tools-Dokumentation beträgt er „5" Sekunden, mit der Tendenz, sich bei dauerhaft stabilen Pfaden laut Dokumentation schrittweise bis zu einem konfigurierbaren Maximalwert zu verlängern. Alles danach — wie lange die VM die Latenzspitze spürt, ob überhaupt etwas auffällt — hängt am Array, an der aktuellen Last und daran, ob path_grouping_policy und no_path_retry wie in diesem Artikel beschrieben konfiguriert sind. Ohne zweite Pfadgruppe wäre derselbe Ausfall kein Latenzthema, sondern ein harter I/O-Fehler auf allen betroffenen VMs gewesen.

/06Queue-Depth: die Stellschraube, die sich nicht pauschal beziffern lässt

Queue-Depth ist die Zahl der gleichzeitig ausstehenden I/O-Anfragen, die ein Pfad zu einem LUN annehmen darf, bevor weitere Anfragen warten müssen. Zu niedrig eingestellt, bremst sie parallele Workloads künstlich aus; zu hoch eingestellt, kann sie den Controller eines Arrays überlasten, das für weniger gleichzeitige Anfragen ausgelegt ist. Der Wert wird nicht in multipath.conf gesetzt, sondern je HBA-Treiber oder iSCSI-Initiator konfiguriert und hängt am Controller-Modell des Arrays.

Hier gilt ausdrücklich, was das Proxmox-Wiki allgemein für die Multipath-Konfiguration sagt: „The optimal multipath configuration highly depends on the SAN you're using." Für Queue-Depth gibt es keinen branchenweit gültigen Standardwert, den man ungeprüft übernehmen könnte — ein belastbarer Wert kommt nur aus der Herstellerdokumentation des jeweiligen Arrays, mit anschließendem Lasttest in der eigenen Umgebung. Wer hier eine feste Zahl aus einem Forenbeitrag kopiert, übernimmt ein Risiko, das er nicht beziffern kann.

Zwei Symptome deuten in der Praxis auf eine falsch eingestellte Queue-Depth hin, unabhängig vom konkreten Array: Ist sie zu niedrig, bleiben parallele Workloads — etwa mehrere VMs, die gleichzeitig schreiben — merklich unter der Leistung, die das SAN eigentlich liefern könnte, obwohl weder Netzwerk noch Multipath-Konfiguration eine Grenze zeigen. Ist sie zu hoch für den jeweiligen Controller, zeigt sich das eher als steigende Latenz unter Last bis hin zu vereinzelten Timeouts, weil der Controller mehr gleichzeitige Anfragen annimmt, als er intern bedienen kann. Beide Symptome lassen sich nur mit einem eigenen Lasttest von einer falsch eingestellten Multipath-Policy unterscheiden — ein Grund mehr, Änderungen an der Queue-Depth nicht nebenbei, sondern mit Vorher-Nachher-Messung vorzunehmen.

/07Typische Fehler beim Einrichten

find_multipaths unbedacht geändert

Wer vom empfohlenen strict auf einen großzügigeren Wert wechselt, bekommt unter Umständen Multipath-Geräte für LUNs, die das gar nicht sein sollten — etwa für lokale Platten, die nur zufällig mehrfach erkannt werden. Das Proxmox-Wiki nennt strict bewusst als Empfehlung, nicht nur als Voreinstellung.

Ein Fabric statt zwei

Zwei HBA-Ports, aber beide am selben Switch oder im selben Fabric angeschlossen, sind formal zwei Pfade und praktisch ein einziger Fehlerpunkt. Fällt der Switch, fallen beide Pfade gleichzeitig — Multipath kann das nicht ausgleichen, weil es die physische Unabhängigkeit der Pfade voraussetzt, nicht herstellt.

Blacklist vergessen

Ohne eine Blacklist für lokale Boot- und Systemplatten versucht multipathd mitunter, auch diese zu bündeln — mit unvorhersehbaren Folgen für Boot-Reihenfolge und /etc/fstab-Einträge. Der devnode-Filter aus dem Beispiel in Abschnitt /03 ist deshalb kein optionaler Zusatz.

failback auf immediate ohne stabile Pfade

Ein Pfad, der wiederholt kurz ausfällt und zurückkommt — ein sogenannter „flapping path" —, erzeugt mit failback immediate ständige Umschaltungen, jede mit kurzer Latenzspitze. Der Standard manual ist für instabile Umgebungen deshalb kein Kompromiss, sondern die robustere Wahl, bis die eigentliche Pfadursache behoben ist.

Alle vier Muster lassen sich schneller finden, wenn die Einrichtung selbst als Runbook dokumentiert ist — mit den genauen Befehlen aus Abschnitt /03 und der erwarteten Ausgabe je Schritt. Das verkürzt die Fehlersuche spürbar und senkt die MTTR, wenn ein Pfadausfall tatsächlich eintritt.

/08Wo es hakt: iSCSI und Fibre Channel im ehrlichen Vergleich

Beide Transportarten haben einen echten Nachteil, den Marketingmaterial gern verschweigt.

• Fibre Channel bindet an eigene Hardware: HBA-Karten, Fabric-Switches und Zoning-Wissen sind ein eigenes Fachgebiet, das in vielen kleineren IT-Teams schlicht nicht vorhanden ist. Fällt der einzige Mitarbeiter mit FC-Kenntnissen aus, steht ein Teil der Infrastruktur ohne internes Know-how da.
• iSCSI ist nur so gut wie seine Netztrennung: Ohne eigene VLANs oder physisch getrennte Karten teilt es sich Bandbreite und Latenzbudget mit allem anderen IP-Verkehr — inklusive der Gefahr, dass ein Backup-Fenster oder ein Netzwerk-Sturm die Storage-Performance spürbar einbrechen lässt.
• Multipath selbst ersetzt keine Array-Redundanz: Wie im Grundlagenartikel zum Managed-Proxmox-Cluster beschrieben, bündelt Multipath nur, was an echten Pfaden vorhanden ist. Ein Array mit einem Controller bleibt ein Single Point of Failure, egal wie sauber multipath.conf konfiguriert ist.

Die Proxmox-Roadmap selbst räumt ein, dass die Einrichtungserfahrung noch nicht rund ist: Für kommende Versionen ist vorgesehen, „Improve multipath integration and setup experience for Fibre Channel and iSCSI deployments" — ein Hinweis darauf, dass die manuelle, vendor-abhängige Konfiguration aus den Abschnitten /03 bis /06 mit Stand Oktober 2026 noch der Normalfall ist, nicht ein Workaround für eine Übergangszeit.

/09Wann iSCSI reicht — und wann Fibre Channel nötig ist

Für die meisten Mittelstandsumgebungen mit überschaubarer Zahl an VMs und einer IT-Mannschaft, die kein dediziertes Storage-Netzwerk-Team hat, ist iSCSI auf sauber getrennten VLANs oder eigenen Netzwerkkarten die pragmatischere Wahl: Die Hardware ist Standard-Ethernet, die Fehlersuche folgt bekannten Netzwerk-Werkzeugen, und die Lernkurve ist flacher als bei Fibre Channel.

Fibre Channel verdient den Mehraufwand, wenn eines zutrifft: ein vorhandenes FC-SAN aus einer VMware- oder Hyper-V-Ablösung, bei dem Array und Fabric bereits bezahlt sind; eine Workload mit durchgängig hohen, wenig kompressiblen I/O-Lasten, bei der ein dediziertes Storage-Fabric ohne IP-Overhead spürbar ruhiger läuft; oder eine Umgebung, in der vorhandenes FC-Fachwissen im Haus bereits steht und nicht neu aufgebaut werden müsste. Fehlt alle drei, ist der Umweg über ein neues FC-Fabric selten zu rechtfertigen.

Unabhängig von der Transportart bleibt die Pfad- und Firmware-Pflege eine laufende Aufgabe, kein Abschlussprojekt: HBA- und Switch-Firmware, Patch-Management auf den Knoten und die Multipath-Konfiguration selbst verändern sich mit jedem größeren Update.

/10Häufige Fragen