Multipath ist erst fertig, wenn der Pfadverlust getestet wurde.
Fibre Channel und iSCSI sind unterschiedlich angebunden, aber im Betrieb stellen sie ähnliche Fragen: Wie viele Pfade gibt es? Welcher Pfad ist aktiv? Was passiert bei Switch-Wartung, Controller-Failover oder Linkverlust? Wir planen Multipath-Architekturen für Proxmox so, dass Storage nicht nur erreichbar ist, sondern auch bei Wartung und Teilfehlern kontrolliert weiterläuft.
Fibre Channel
Wir planen FC-Fabrics, Zoning, WWPN-Zuordnung, redundante HBAs und saubere Pfadtrennung. Ziel ist ein SAN-Design, bei dem kein einzelner Switch oder Controller den Cluster aus dem Tritt bringt.
iSCSI
Für iSCSI prüfen wir getrennte Netze, MTU, VLANs, Bonding-Entscheidungen, Session-Design und Target-Zuordnung. iSCSI braucht bewusstes Netzwerkdesign, nicht nur eine zusätzliche IP auf dem Host.
DM Multipath
multipathd, WWIDs, Alias-Namen, Prioritäten, Queueing und Pfadgruppen müssen nachvollziehbar konfiguriert sein. Wir vermeiden Setups, die nur zufällig funktionieren.
ALUA und Controller-Failover
Bei Storage-Systemen mit asymmetrischem Zugriff ist ALUA entscheidend. Wir prüfen aktive und optimierte Pfade, Failover-Verhalten und die Frage, wie Proxmox während Controller-Wartung reagiert.
Proxmox Storage Mapping
LVM, LVM-thin, Directory, ZFS auf Blockdevice oder andere Varianten haben unterschiedliche Betriebsfolgen. Wir wählen bewusst, wie LUNs in Proxmox genutzt werden.
Monitoring und Tests
Pfadverlust, Degraded-Zustände, Latenz, Queueing und Fehlerzähler gehören ins Monitoring. Zusätzlich testen wir Switch-, Link-, HBA- und Controller-Szenarien vor der produktiven Freigabe.
Multipath-Risiken, die man nicht erraten sollte
Sind die Pfade wirklich unabhängig?
Zwei Pfade über denselben Switch, dieselbe Netzkarte oder denselben Controller sehen redundant aus, helfen aber im falschen Ausfallszenario nicht.
Wie reagiert das System bei Queueing?
Queueing kann VMs schützen oder lange Hänger verursachen. Wir prüfen Timeouts, Failover-Dauer und das Verhalten kritischer Workloads.
Sind WWIDs und LUNs dokumentiert?
Ohne klare Zuordnung zwischen Storage, Hosts und Proxmox-Namen wird Fehlersuche riskant. Wir dokumentieren Pfade und Geräte so, dass Wartung möglich bleibt.
Wurde Failover praktisch getestet?
Ein funktionierender Multipath-Status im Normalbetrieb reicht nicht. Entscheidend ist, was bei Kabelziehen, Switch-Reboot oder Controller-Failover passiert.
Multipath belastbar einführen
Topologie prüfen
Wir erfassen Storage, Controller, Switches, Fabrics, VLANs, HBAs, NICs, Targets und vorhandene Proxmox-Storage-Konfiguration.
Pfadmodell planen
Wir definieren Pfadtrennung, Zoning, iSCSI-Netze, Multipath-Policy, Alias-Namen und Monitoring-Signale.
Konfiguration umsetzen
Hosts, multipathd, Storage-Mapping und Proxmox-Storage werden eingerichtet oder korrigiert.
Ausfälle testen
Wir testen Linkverlust, Switch-Wartung, Controller-Failover und Restore-/Migration-Szenarien mit dokumentierten Ergebnissen.
Technologien
Weitere Detailseiten
Cluster-Planung
Quorum, Corosync, Netzwerk, HA und Betriebsmodell.
Ceph-Storage
OSD-Design, CRUSH, Recovery-Verhalten und Kapazität.
VMware-Migration
Bestandsaufnahme, Testmigration, Cutover und Fallback.
Proxmox Backup Server
Datastores, Retention, Offsite-Sync und Restore-Tests.
Automatisierung
API, Ansible, OpenTofu, Templates und cloud-init.
Monitoring & Wartung
Health Checks, Updates, Firmware und Kapazitätstrends.
3-Tier Architekturen
Compute, SAN, Shared Storage und klare Betriebsgrenzen.
Proxmox Workshops
Beratung, UI-Durchgang, Betriebspraxis und Team-Enablement.
FC- oder iSCSI-Multipath sauber aufbauen?
Wir prüfen deine Storage-Pfade, richten Multipath nachvollziehbar ein und testen echte Failover-Szenarien.
Proxmox-Projekt besprechen