Storage-Konnektivität und Pfade

Ein sichtbarer Datastore kann trotzdem nur einen kranken Pfad besitzen

Die Managementoberfläche meldet einen Datastore als erreichbar. Diese Aussage kann wahr sein, obwohl ein redundanter Pfad fehlt, ein verbleibender Pfad Fehler wiederholt oder nur ein Teil der Hosts dieselbe LUN beziehungsweise dasselbe Export sieht. Sichtbarkeit ist ein Zwischenzustand, kein Nachweis des I/O-Vertrags. Zwischen VM und Storage liegen mehrere Identitäten und Zustände: virtuelles Blockziel oder Image, Host-Volume beziehungsweise Mount, Multipath-Map, einzelne SCSI-Pfade, Initiator, Netz- oder Fabricpfad, Targetport und freigegebene LUN. Bei NFS lautet die Kette anders: Image-Datei, lokaler Mountpunkt, Export, Serveridentität und Netzwerkpfad. Ein Alarm an einer Stufe darf nicht ohne Evidenz der nächsten zugeschrieben werden. Die Betriebsfrage dieses Moduls ist daher: Welche konkrete Workload benutzt über welche Hostidentität welchen Storageendpunkt, und welches Verhalten bleibt beim Verlust eines vorgesehenen Pfads übrig? Die Antwort verbindet Zugriff, Verfügbarkeit und Leistung. Eine zusätzliche Verbindung ist nicht automatisch ein unabhängiger Pfad; zwei Links können denselben Switch, dieselbe Netzkarte, denselben Targetport oder dieselbe Stromdomäne teilen. Wir verwenden Linux Multipath, Open-iSCSI, NFS und Fibre-Channel-Begriffe als konkrete Beispiele. Plattformen konfigurieren diese Schichten unterschiedlich. Bevor du einen Pfad änderst, liest du deshalb die aktive Plattform- und Betriebssystemkonfiguration und ordnest sie einer dokumentierten physischen Fehlerdomäne zu.

File Storage und Block Storage setzen die Grenze an anderer Stelle

NFS

Der Host mountet ein exportiertes Dateisystem. VM-Disks liegen typischerweise als Dateien im Mount; Export, Mountoptionen und Dateisemantik gehören zum Pfad.

iSCSI

Ein Initiator transportiert SCSI-Kommandos über TCP/IP zu einem Target. Der Host erhält eine LUN als Blockgerät; Volume- oder Dateisystemverwaltung liegt darüber.

Fibre Channel

SCSI läuft über eine FC-Fabric. Lokale und entfernte Ports besitzen WWPNs; sichtbare LUNs erscheinen dem Host als SCSI-Geräte.

RFC 7143 beschreibt SCSI als Client-Server-Architektur: Ein Initiator sendet Kommandos an logische Einheiten eines Targets; iSCSI transportiert diese SCSI-Pakete über TCP/IP. Ein iSCSI-Portal ist der Netzwerkendpunkt, über den ein Target erreicht wird. Targetname, Portal und LUN sind deshalb keine Synonyme. Ein erreichbarer TCP-Port belegt noch keine erfolgreiche Session und eine Session noch kein freigegebenes Blockgerät. NFS liefert dagegen einen Dateisystemnamensraum. Eine Zeile in /etc/fstab benennt Server, Exportpfad, lokalen Mountpunkt, Dateisystemtyp und Mountoptionen. Der Host kann darin Raw-, qcow2- oder andere Image-Dateien halten. Snapshotfähigkeit kann dann aus dem Imageformat statt aus NFS selbst kommen; die Proxmox-Dokumentation nennt beispielsweise qcow2 als Snapshot- und Clone-Schicht auf seinem NFS-Backend. Diese Unterscheidung entscheidet die Diagnose. Bei iSCSI oder FC fragst du nach LUN, SCSI-Gerät, WWID und Multipath-Map. Bei NFS fragst du nach Mount, Export, NFS-Version, Recoveryoptionen und Serverzustand. Ein Befehl für Blockgeräte kann keine fehlgeschlagene NFS-Mountsemantik erklären; ein erfolgreicher NFS-Mount sagt nichts über einen FC-Pfad. Shared Storage ermöglicht, dass mehrere Clusterknoten dieselben VM-Diskdaten erreichen. Daraus folgt nicht, dass jeder Host dieselbe Zugriffskonfiguration oder dieselbe Pfadgesundheit besitzt. Der Vergleich mehrerer Hosts ist daher eine starke Diagnose: Welche Identität, LUN, Map, Export- und Mountoption weicht auf genau dem betroffenen Host ab?

iSCSI und Fibre Channel brauchen eine Identitätskette

Open-iSCSI trennt Discoverydatensätze, Node-Datensätze und aktive Sessions. iscsiadm -m session -P 3 zeigt die laufenden Sessions detailliert; iscsiadm -m node zeigt gespeicherte Target-Portal-Datensätze. Die Manpage weist darauf hin, dass eine Session-ID nicht persistent ist und teilweise von der Einrichtungsreihenfolge abhängt. Verwende für Inventar und Changes daher Initiatorname, Targetname, Portal und erwartete LUN statt nur einer Sessionnummer. ``bash iscsiadm -m session -P 3 iscsiadm -m node ` Bei Fibre Channel stellt Linux entfernte Ports unter /sys/class/fc_remote_ports/ dar. Dort sind unter anderem WWNN, WWPN, Port-ID, Rolle, Portzustand und Linkgeschwindigkeit sichtbar. Ein Remote Port ist typischerweise ein Storageziel, das SCSI-Kommandos über den FC-Transport beantwortet. Diese Hostsicht verbindet den lokalen HBA-Pfad mit dem Zielport, ersetzt aber nicht die Fabric- und Arraykonfiguration. `bash cat /sys/class/fc_host/host*/port_name cat /sys/class/fc_remote_ports/rport-*/port_name cat /sys/class/fc_remote_ports/rport-*/port_state `` Eine belastbare Zuordnung enthält beide Richtungen. Vom Host aus: Initiator → Targetport → LUN → WWID → Map. Vom Array aus: Hostobjekt beziehungsweise Initiatorgruppe → freigegebene LUN → erwartete Hosts. Stimmen nur Anzeigenamen überein, kann ein falsch zugeordnetes Initiatorobjekt trotzdem Daten eines anderen Clusters sichtbar machen.

Erreichbarkeit, Authentisierung und LUN-Freigabe sind getrennte Kontrollen

Ein Storagepfad besitzt mehrere Filter. Netzwerksegment oder FC-Zone bestimmt, welche Endpunkte grundsätzlich miteinander kommunizieren können. iSCSI-Authentisierung kann einen Initiator gegenüber einem Target prüfen. Die Zielseite bestimmt, welche LUNs diesem Initiator beziehungsweise Hostset sichtbar werden. Der Hypervisor entscheidet anschließend, welches Gerät als Datastore oder Volume verwendet wird. Keine dieser Kontrollen ersetzt die anderen. Least Privilege bedeutet hier nicht „genau ein Port“, sondern nur die für den dokumentierten Dienst und seine Redundanz benötigten Initiator-Target-Beziehungen und LUNs. Ein zweiter unabhängiger Pfad ist notwendiger Scope, keine unnötige Berechtigung. Ein fremdes Target oder eine LUN eines anderen Clusters ist dagegen zusätzliche Daten- und Fehlerfläche, auch wenn der Host sie aktuell nicht mountet. NIST SP 800-209 nennt Authentisierung, Autorisierung, Konfigurationskontrolle, Isolation, Datenschutz und Recovery als miteinander verbundene Storagekontrollen. Das ist für Virtualisierung wichtig, weil eine zu breite Storagefreigabe nicht nur Vertraulichkeit betrifft. Falsches Rescan, Signaturkonflikte, versehentliche Initialisierung oder ein Automationsfehler können fremde Blockgeräte verändern. Ein Change beginnt daher mit einer Sollmatrix: Host- oder Initiatoridentität, benötigte Targetports, LUN beziehungsweise Export, erwartete Pfadzahl, Fehlerdomänen und Owner. Nach der Änderung wird nicht „mehr sichtbar als vorher“ als Erfolg gewertet, sondern exakt der freigegebene Scope. Unerwartete Geräte oder Exporte sind ein Befund, kein praktischer Vorrat für spätere Migrationen.

Multipath fasst mehrere Wege zu einem Blockgerät zusammen

Linux Device Mapper Multipath erkennt mehrere Pfade zum selben Gerät und fasst sie für Failover oder Leistung in einer Map zusammen. Die Zuordnung folgt dem World Wide Identifier. Einzelne Pfadgeräte wie /dev/sdb und /dev/sdc dürfen von der darüberliegenden Storagekonfiguration nicht unabhängig als zwei Datenträger behandelt werden, wenn sie dieselbe LUN darstellen. Die Workload verwendet die Multipath-Map. multipath -ll zeigt die aktuelle Topologie aus Sysfs, Device Mapper und Path Checkers. multipathd show paths zeigt überwachte Pfade und ihren Zustand; multipathd show maps status zeigt die überwachten Maps. Sichere WWID, Mapalias, Pfadgeräte, Pfadgruppen, Zustände und die darüberliegende Nutzung gemeinsam: ``bash multipath -ll multipathd show paths multipathd show maps status lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS ` Ein grüner Pfadchecker ist noch kein End-to-End-I/O-Test. Die Manpage sagt ausdrücklich, dass multipath -C` prüft, ob eine Map nutzbare Pfade besitzt, aber selbst keinen I/O auf dem Gerät ausführt. Dasselbe gilt für eine Topologieanzeige: Sie belegt Erkennung und momentanen Zustand, nicht ausreichende Leistung oder den erfolgreichen Wechsel unter Workload. Pfadgruppen und Auswahlregeln bestimmen, welcher Pfad aktiv genutzt wird. Manche Arrays besitzen aktive und optimierte Zielpfade, andere verteilen Last. Die passende Policy kommt aus der Supportmatrix des Arrays und Betriebssystems. Ein blind erzwungenes Round Robin kann eine asymmetrische Controllerarchitektur falsch behandeln; eine reine Active-Passive-Nutzung kann verfügbare Lastverteilung ungenutzt lassen. Die korrekte Entscheidung ist hersteller- und modellabhängig, nicht aus der Pfadzahl ableitbar.

Kein Pfad ist ein eigener Fehlervertrag

Wenn alle Pfade ausfallen, muss die Plattform entscheiden, ob I/O sofort mit Fehler endet oder für eine Zeit in einer Queue wartet. Device Mapper Multipath kennt dafür unter anderem no_path_retry; der ältere Mechanismus queue_if_no_path kann I/O weiter anstehen lassen. Die Manpage warnt, dass unbegrenztes Queueing Prozesse in nicht unterbrechbaren Schlaf versetzen kann, wenn alle Pfade offline sind. Beide Verhaltensweisen haben einen Preis. Sofortige Fehler machen den Ausfall sichtbar und erlauben einer Anwendung möglicherweise kontrolliertes Recovery, können aber Dateisystem oder Datenbank unmittelbar mit I/O-Fehlern konfrontieren. Queueing kann einen kurzen Pfadausfall überbrücken, verlängert bei einem dauerhaften Ausfall jedoch Hänger und erschwert Shutdown oder Failover. Dieser Vertrag muss mit Anwendung, Cluster und Storage-Recoveryzeit abgestimmt sein. Prüfe wirksame statt nur geschriebene Konfiguration. multipath -t zeigt die aktuell verwendete Konfiguration; multipathd show config local begrenzt die Ausgabe auf vorhandene Geräte. Ein Eintrag in /etc/multipath.conf kann durch gerätespezifische Defaults, eine falsche Matchregel oder fehlendes Reload anders wirken als erwartet. Path Checker erkennen ausgefallene Wege und multipathd rekonfiguriert betroffene Maps, um Leistung und Redundanz wiederherzustellen. Das bedeutet nicht, dass jeder Ausfall verlustfrei bleibt. Timeoutketten aus HBA beziehungsweise TCP, SCSI, Multipath, Dateisystem und Anwendung können sich addieren. Miss beim Test daher nicht nur „I/O geht weiter“, sondern maximale Latenz, Fehler, Queuezeit und Recovery bis zum stabilen Normalzustand.

NFS-Recovery wird über Mountsemantik an die Anwendung weitergegeben

Bei NFS gibt es keine Multipath-Map derselben Form. Server, Export, NFS-Version, Netzwerkpfad und Mountoptionen bestimmen das Clientverhalten. findmnt -t nfs,nfs4 zeigt die aktiven Mounts; nfsstat -m zeigt Mountparameter. Vergleiche den realen Mount mit der freigegebenen Konfiguration, bevor du eine Option änderst. ``bash findmnt -t nfs,nfs4 nfsstat -m ` Die Linux-Manpage nfs(5) beschreibt hard als Standard: Nach einem Timeout werden Anfragen grundsätzlich weiter wiederholt. soft beziehungsweise softerr beendet eine Anfrage nach der konfigurierten Zahl von Wiederholungen und liefert EIO oder ETIMEDOUT an die Anwendung. Dieselbe Manpage warnt, dass Soft Timeouts in bestimmten Fällen stille Datenkorruption verursachen können und nur gewählt werden sollen, wenn Reaktionsfähigkeit wichtiger als Datenintegrität ist. Für beschreibbare VM-Images ist das eine zentrale Designentscheidung. soft ist kein allgemeiner Schutz gegen einen hängenden NFS-Server; es tauscht Warten gegen Fehlersemantik in einer tieferen Storageoperation. hard` ist umgekehrt kein Hochverfügbarkeitsnachweis, weil ein nicht erreichbarer Server I/O unbegrenzt aufhalten kann. Der eigentliche Resilienzpfad muss Server-, Netzwerk- und Plattformfailover sowie die Anwendungstoleranz umfassen. Ändere Timeout- oder Recoveryoptionen nicht während eines Incidents als Versuch-und-Irrtum. Sichere Mountoptionen, betroffene Datei beziehungsweise VM, offene I/O-Wirkung und Serverzustand. Teste die vorgesehene Semantik in einer isolierten oder repräsentativen Pilotumgebung. Ein erfolgreicher Remount ohne verifizierte VM-Schreib- und Flushoperation beweist keine sichere Datenwirkung.

Diagnose folgt einer Treppe statt einem Sprung

1. Workload

Betroffene VMs, Dienstwirkung, Startzeit und gemeinsame Host- oder Storagegrenze bestimmen.

2. Datastore oder Volume

Ist die erwartete Quelle aktiv, beschreibbar und auf allen vorgesehenen Hosts gleich zugeordnet?

3. Multipath oder Mount

WWID, Map, Pfadstatus beziehungsweise NFS-Export und wirksame Optionen lesen.

4. Session und SCSI

iSCSI-Session, Target, Portal, LUN und Geräteerkennung beziehungsweise FC Remote Ports prüfen.

5. Transport

NIC oder HBA, VLAN, Route, Switch/Fabric, Fehlerzähler, MTU und Targetport gegen die Baseline vergleichen.

6. Backend

Controller, Port, LUN, Pool und Arrayereignisse mit demselben Zeitfenster korrelieren.

Die Reihenfolge ist kein starres Lehrbuch, sondern verhindert breite Änderungen. Ist nur ein Host betroffen, während andere Hosts dieselbe LUN gesund nutzen, liegt die nächste Vergleichsgrenze zwischen Hostkonfiguration und seinen Pfaden. Sind alle Hosts und mehrere LUNs desselben Controllers betroffen, wird die gemeinsame Target- oder Backendgrenze wahrscheinlicher. Bei iSCSI beweist ein erfolgreicher Ping weder TCP-Erreichbarkeit des Portals noch Targetlogin. Eine aktive Session beweist wiederum nicht, dass die erwartete LUN freigegeben, als derselbe WWID erkannt und korrekt in eine Map aufgenommen wurde. Prüfe jede Stufe und notiere das erste abweichende Signal. Bei FC ist ein HBA-Link nur die lokale Verbindung zur Fabric; Remote-Port-, Zoning- und LUN-Sicht folgen danach. Vermeide Rescans oder Dienstneustarts als ersten Schritt. Sie verändern Geräte- und Sessionzustand und können die Spur verwischen. Sichere vorher iscsiadm -m session -P 3, multipath -ll, relevante Kernelmeldungen, FC-Portzustände, Mounts und die Plattformzuordnung. Danach lässt sich eine eng begrenzte Hypothese testen. Eine breite Storagefreigabe ist keine Diagnose. Wenn ein Pfad nach einem Switchchange fehlt, behebt das Sichtbarmachen zusätzlicher Targets weder Linkfehler noch falsche Zone des vorgesehenen Ports. Es vergrößert lediglich den Blast Radius und erschwert die Zuordnung.

Redundanz wird durch kontrollierten Verlust bewiesen

Ein Redundanztest beginnt mit der physischen Pfadmatrix. Zwei erkannte Pfade sind nur dann zwei Fehlerdomänen, wenn ihr Verlauf nicht an derselben kritischen Komponente zusammenläuft. Dokumentiere lokalen HBA oder NIC, Switch beziehungsweise Fabric, Targetport und Controllerzuordnung. Prüfe außerdem, dass der Ersatzpfad genügend Leistung für die repräsentative Last besitzt. Vor dem Test werden Workload-SLO, I/O-Baseline, erwartete Pfadzahl, aktive Policy, No-Path-Verhalten und Abbruchsignal festgelegt. Wähle einen nichtkritischen oder abgestimmten Pilotworkload. Entferne genau einen vorgesehenen Pfad über das dokumentierte Verfahren und beobachte Map, Pfadchecker, VM-I/O, Fehler und maximale Latenz. Bleibt nur die Anzeige grün, fehlt der eigentliche Dienstnachweis. Stelle den Pfad kontrolliert wieder her und beobachte, ob multipathd ihn reintegriert. Sofortiges Failback kann erneut Latenz erzeugen; manche Designs bleiben bewusst auf der aktuellen Pfadgruppe, andere kehren nach Verzögerung zurück. Die konfigurierte failback-Semantik muss zur Supportmatrix und zum Testplan passen. Teste anschließend – wenn freigegeben – den anderen Fehlerpfad. Der Test endet erst im stabilen Normalzustand: erwartete Pfadzahl, keine neuen I/O-Fehler, akzeptable Dienstlatenz, keine hängenden Jobs und dokumentierte Recoveryzeit. Ein Test, der nach erfolgreichem Failover auf einem Einzelpfad endet, hat Verfügbarkeit gezeigt und Redundanz zurückgelassen.

Arbeitsbeispiel: Nach dem SAN-Change bleibt genau ein schlechter Pfad

Storageänderungen werden pfadweise und mit Rückkehrnachweis ausgeführt

Vor Wartung oder Zoningänderung wird die Sollmatrix gegen den Istzustand geprüft: Host, Initiator, Target, LUN oder Export, WWID, Map, Pfadzahl, physische Route und Workloads. Ein vermeintlich redundantes Design darf nicht während des Changes erstmals verstanden werden. Offene Pfadfehler, laufende Storagejobs oder fehlende N-1-Leistung blockieren den Eingriff. Ändere nur eine Fehlerdomäne zur Zeit. Nach jedem Teilschritt werden Erreichbarkeit, Session beziehungsweise Remote Port, LUN, Map und VM-I/O beobachtet. Erst wenn der verbleibende Pfad den Dienstvertrag trägt, folgt die nächste Komponente. Eine parallele Wartung beider Fabrics verwandelt Redundanz in einen gemeinsamen Change-Radius. Die Rückkehr ist ein eigener Vorgang. Ein wieder sichtbarer Port muss als erwarteter Pfad derselben WWID erkannt, von multipathd überwacht und nach Policy reintegriert werden. Prüfe auf unerwartete zusätzliche Geräte, fehlerhafte Maps und neue Kernelmeldungen. Danach folgt ein kontrollierter Failovernachweis, sofern der Changeplan ihn vorsieht. Schließe erst, wenn Plattform, Host und Workload übereinstimmen. Ticket oder Runbook enthält Vorher- und Nachherpfadzahl, Identitäten, Testlast, maximale Latenz, Fehler, Recoveryzeit und verbleibende Ausnahmen. So wird aus „Fabric B ist wieder grün“ die belastbare Aussage „die vorgesehene VM-I/O lief über beide getrennten Pfade und kehrte ohne offene Abweichung in den Normalzustand zurück“.

• Vorbedingung: Sollmatrix, Supportpolicy, gesunder Ersatzpfad und messbare N-1-Leistung.
• Scope: genau eine NIC/HBA-, Switch/Fabric-, Targetport- oder Zoninggrenze pro Schritt.
• Beobachtung: Session beziehungsweise Remote Port, WWID-Map, VM-I/O, Dienstlatenz und Fehler gemeinsam.
• Rückkehr: Pfad reintegrieren, Normalpolicy prüfen und Redundanz nach kontrolliertem Test erneut belegen.
• Abschluss: unerwartete Sichtbarkeit, temporäre Freigaben und Alarmunterdrückungen vollständig behandeln.