So lesen Sie den Multipath-Status auf einem Linux-Host

Wenn Ihr Server seine Daten auf einem SAN hält, kommt der wichtigste Gesundheitsbericht der Maschine von einem Befehl, den die meisten nie ausführen. multipath -ll sagt Ihnen, wie viele Wege zu Ihrer Platte führen, welche davon das Array bevorzugt und ob der Host den Verlust eines Weges überleben würde. So lesen Sie die Ausgabe, und das ändern Sie, wenn sie nicht richtig aussieht.

Redundanz, die Sie nicht sehen können, ist keine Redundanz

Wenn ein Pfad still stirbt, bemerkt es niemand. Der Host läuft mit dem weiter, was übrig ist, und das erste Anzeichen von Ärger ist der Tag, an dem auch der zweite Pfad wegfällt und das Volume unter einer Datenbank verschwindet. Ein Server, der mit eingehängtem Multipath-Gerät übergeben und nie wieder angesehen wurde, hat Redundanz nur auf dem Papier. Die Prüfung dauert dreißig Sekunden und sollte Teil jedes Builds, jeder Wartung und jeder Nachbesprechung eines Vorfalls sein.

Die Ausgabe lesen, Zeile für Zeile

Ein generisches Beispiel von einem Host mit zwei HBA-Ports und zwei Array-Ports, pro Fabric gezont:

mpatha (360002ac000000000000000000000abcd) dm-2 3PARdata,VV
size=50G features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
`-+- policy='service-time 0' prio=50 status=active
  |- 1:0:0:1 sdb 8:16 active ready running
  |- 1:0:1:1 sdc 8:32 active ready running
  |- 2:0:0:1 sdd 8:48 active ready running
  `- 2:0:1:1 sde 8:64 active ready running

Die erste Zeile nennt den Anzeigenamen, die WWID sowie die Vendor- und Product-Strings. Die WWID ist die Identität des Volumes, so wie das Array sie meldet. Wenn Sie je beweisen müssen, welches Array-Volume welches Linux-Gerät ist, vergleichen Sie diesen String mit der Volume-Liste des Arrays selbst, nie mit einem Gerätebuchstaben, denn Gerätebuchstaben ändern sich zwischen Neustarts.

Die zweite Zeile enthält die Einstellungen, die das Verhalten im Fehlerfall bestimmen. queue_if_no_path bedeutet, dass das I/O wartet statt fehlzuschlagen, wenn alle Pfade verloren gehen. hwhandler='1 alua' bedeutet, dass das Array ALUA spricht, den Standardweg, auf dem ein Array dem Host mitteilt, welche Ports bevorzugt werden.

Die Zeile der Path Group zeigt die Auswahlrichtlinie und die Priorität. Ein symmetrisches Active/Active-Array wie das oben stellt jeden Pfad in eine Gruppe mit gleicher Priorität. Ein asymmetrisches Array zeigt zwei Gruppen: eine Gruppe höherer Priorität mit optimierten Pfaden, markiert active, und eine Gruppe niedrigerer Priorität, markiert enabled, die nur dann I/O trägt, wenn die erste Gruppe ausfällt. Beide Anordnungen sind gesund. Entscheidend ist, dass die Anordnung dem entspricht, was der Hersteller Ihres Arrays für Ihren Host-Typ dokumentiert.

Jede Pfadzeile liest sich host:channel:target:lun, dann das Gerät, dann drei Zustände. Die erste Zahl ist der SCSI-Host, was auf einem Fibre-Channel-Server den HBA-Port bedeutet. Jedes Volume sollte Pfade über beide HBA-Port-Nummern zeigen. Wenn jeder Pfad eines Volumes dieselbe Host-Nummer trägt, ist das Volume nur über eine Fabric erreichbar, ganz gleich, was der Verkabelungsplan sagt. Die drei Zustände sind der Zustand des Device-Mappers (active oder failed), das Ergebnis des Path Checkers (ready, faulty, ghost) und die Sicht des Kernels auf das Gerät (running oder offline).

Ein gesunder Host, als Checkliste

• Jedes Volume zeigt dieselbe Zahl von Pfaden, und diese Zahl entspricht HBA-Ports mal pro Fabric gezonte Array-Ports.
• Jedes Volume hat Pfade über beide HBA-Host-Nummern.
• Kein Pfad ist failed, faulty, offline oder shaky.
• Vendor-String, Hardware-Handler und Prioritäten entsprechen dem Host-Leitfaden des Array-Herstellers, und der Host ist auf dem Array mit der passenden Host Persona oder dem passenden Host Type registriert.
• Das Verhalten beim Verlust aller Pfade (no_path_retry) wurde bewusst gewählt, nicht geerbt.
• LVM verwendet nur die Multipath-Geräte, nie die darunterliegenden sd-Pfade.

Diese Befehle geben Ihnen das ganze Bild:

multipath -ll
multipathd show paths
multipathd show maps status
cat /sys/class/fc_host/host*/port_state
cat /sys/class/fc_host/host*/port_name

Um die aktiven Pfade pro Volume in einem Durchgang zu zählen:

multipath -ll | awk '/ dm-/{m=$1} /active ready/{c[m]++} END{for (k in c) print k, c[k]}'

Führen Sie das nach jeder Zoning-Änderung, jeder Änderung am Array und jedem Neustart aus. Eine Zahl, die sich zwischen Volumes unterscheidet, lohnt sich noch heute zu verfolgen.

Die Einstellungen, auf die es am meisten ankommt

Die meisten Distributionen liefern eine vernünftige eingebaute Tabelle mit Array-Vorgaben, aber der Host-Leitfaden des Array-Herstellers ist die Autorität. Ein typischer Device-Abschnitt sieht so aus:

defaults {
    user_friendly_names yes
    find_multipaths yes
}
devices {
    device {
        vendor               "3PARdata"
        product              "VV"
        path_grouping_policy group_by_prio
        prio                 alua
        hardware_handler     "1 alua"
        path_checker         tur
        failback             immediate
        no_path_retry        18
    }
}

Der eine Wert, über den Sie selbst nachdenken sollten, ist no_path_retry. Eine Weile zu queuen lässt einen Host ein Controller-Failover oder einen Fabric-Neustart überstehen, ohne dass ein I/O-Fehler die Anwendung erreicht. Für immer zu queuen kann einen Datenbank-Host auf eine Weise einfrieren, die schwerer zu beheben ist als ein sauberer Fehler. Wählen Sie eine Zahl von Wiederholungen, die die dokumentierte Failover-Zeit Ihres Arrays mit Reserve abdeckt, schreiben Sie auf, warum, und wenden Sie sie auf jeden Host dieses Typs an.

Das andere klassische Problem ist LVM, das die rohen Pfade scannt und sich über doppelte Physical Volumes beschwert. Auf aktuellen Systemen regelt das die Geräteliste (lvmdevices) oder ein Filter in lvm.conf, der nur /dev/mapper-Geräte zulässt. Warnungen über doppelte PVs sind nicht kosmetisch: Sie bedeuten, dass LVM einen einzelnen Pfad statt des Multipath-Geräts öffnen kann, und dann ist es nicht mehr geschützt.

Beweisen Sie das Failover, bevor Sie es brauchen

Ein Pfad, der nie umgeschaltet hat, ist eine Theorie. Bevor ein Host Produktion trägt, nehmen Sie einen Pfad weg und sehen Sie zu:

# terminal 1: keep reading from the volume
dd if=/dev/mapper/mpatha of=/dev/null bs=1M iflag=direct status=progress

# terminal 2: take one path offline, watch, then bring it back
echo offline > /sys/block/sdb/device/state
multipathd show paths
echo running > /sys/block/sdb/device/state
journalctl -k -f

Der Lesevorgang im ersten Terminal sollte weiterlaufen, ohne länger als einen Augenblick zu stocken. Wenn der Pfad zurückkommt, sollte multipathd show paths ihn wieder auf active ready setzen. Dann machen Sie den größeren Test, der zählt: Deaktivieren Sie den Port des Hosts in einer Fabric am Switch, bestätigen Sie, dass das Volume allein über die andere Fabric läuft, stellen Sie ihn wieder her, bestätigen Sie, dass jeder Pfad zurückkehrt, und wiederholen Sie das für die zweite Fabric. Wenn Sie ein Schritt überrascht, haben Sie das Problem an einem ruhigen Nachmittag gefunden statt während eines Ausfalls.

Wie wir es machen

Auf unserer Plattform bekommt jeder SAN-angebundene Host, Hypervisor oder Dedicated server, einen HBA-Port in jeder von zwei unabhängigen Fibre-Channel-Fabrics und wird auf unseren All-Flash-Arrays HPE 3PAR mit der Persona registriert, die ALUA genau so verhalten lässt, wie es sein Betriebssystem erwartet. Wenn wir ein laufendes Volume zwischen Arrays verschieben, scannt der Host neu, sieht seine neuen Pfade und macht weiter, und die Zahl der Pfade ist der Beweis, dass der Umzug abgeschlossen ist.

Wenn Ihre Multipath-Ausgabe nicht wie das gesunde Beispiel oben aussieht, oder Sie nicht sicher sind, wie Ihre aussehen sollte, lesen wir sie gern gemeinsam mit Ihnen.

cta: Mit einem Ingenieur sprechen

Related

• /what-we-do/storage-compute/enterprise-san-storage/
• /what-we-do/storage-compute/fibre-channel-fabrics/
• /what-we-do/storage-compute/bare-metal-servers/