I/O-Einbrüche nach Storage-Failover analysieren mit iostat, blktrace und dmsetup

Ein Storage-Failover ist im Idealfall ein kurzer Umschaltmoment: Pfad weg, alternativer Pfad übernimmt, Applikationen laufen weiter. In der Praxis sieht man nach dem Failover aber häufig genau das Gegenteil: I/O-Einbrüche nach Storage-Failover, deutlich höhere Latenzen, „stotternde“ Jobs, Timeouts in Datenbanken oder virtuelle Maschinen, die sich zäh anfühlen. Das Tückische: Die eigentliche Störung ist vorbei, doch die Performance bleibt degradiert – manchmal minutenlang, manchmal bis zum nächsten Reboot.

Dieser Beitrag zeigt eine praxiserprobte Analyse-Kette für Linux-Systeme mit Block-Storage (FC, iSCSI, SAS, NVMe-oF) und Device-Mapper-Stacks (Multipath, LVM, dm-crypt). Im Fokus stehen drei Werkzeuge, die sich gut ergänzen: iostat für das schnelle Lagebild, blktrace für das Block-Layer-Tracing (also das Nachverfolgen einzelner I/O-Anfragen im Kernel) und dmsetup für Transparenz im Device Mapper (die Schicht, die z. B. Multipath- und LVM-Devices bereitstellt). Dazu kommen typische Ursachen, Stolperfallen, Prüfschritte, Tuning-Optionen und eine Rückfallstrategie, die im Betrieb tragfähig ist.

I/O-Einbrüche nach Storage-Failover: Warum Failover oft „überlebt“, aber Performance nicht

Beim Failover ändern sich selten nur „ein Kabel“. Typische Nebenwirkungen, die I/O nach dem Umschalten ausbremsen:

• Pfad-Degradierung statt echter Redundanz: Multipath nutzt nur noch einen aktiven Pfad oder hängt an einem suboptimalen Controller (ALUA-Problem). ALUA („Asymmetric Logical Unit Access“) beschreibt, dass bei Dual-Controller-Arrays nicht jeder Pfad gleich gut ist.
• Queue-/Timeout-Effekte: Während ein Pfad weg ist, stauen sich I/Os. Nach dem Umschalten muss der Rückstau abgearbeitet werden. Gleichzeitig können Timeouts und Retries (Wiederholungen) die Latenz massiv erhöhen.
• Write-Cache-Verhalten: Arrays schalten Caches um, re-synchronisieren Spiegel oder ändern Cache-Policies. Ein Array kann „sicher“ laufen, aber mit konservativerem Cache-Modus.
• Device-Mapper-Schicht ist „alive“, aber falsch parametriert: Multipath/DM kann in einer ungünstigen Policy hängen (z. B. falsche path_selector, min_io, rr_min_io_rq).
• Applikations- und Dateisystem-Folgen: Journaling, Log-Replay, Datenbank-Recovery, VM-Storage-Timeouts – das kann Lastspitzen erzeugen, die fälschlich wie „Storage langsam“ aussehen.

Die wichtigste Betriebsregel: Nach einem Failover ist „System wieder online“ nicht gleich „System wieder normal“. Sie brauchen eine Messkette, die sauber trennt: Gerät/Array, Pfade/Multipath, Kernel-Block-Layer, Dateisystem und Workload.

Voraussetzungen und Sicherheitsrahmen für die Analyse

Bevor Sie tiefer tracen, klären Sie zwei Punkte: (1) Dürfen Sie auf dem betroffenen Host Tools installieren und Kernel-Traces starten? (2) Ist das System in einem Zustand, in dem zusätzliche Diagnose die Lage nicht verschlimmert? blktrace erzeugt overhead, vor allem bei sehr hoher I/O-Rate. Arbeiten Sie daher möglichst kurz, gezielt und – wenn möglich – zuerst in einem Wartungsfenster oder auf einem vergleichbaren Knoten.

Für die folgenden Schritte sind typischerweise Pakete nötig: sysstat (iostat) sowie blktrace/btt. Auf vielen Distributionen sind diese Pakete in den Standard-Repositories verfügbar. Prüfen Sie außerdem, ob Ihr Storage über Multipath angebunden ist (Device Mapper) oder z. B. direkt als /dev/sdX genutzt wird – das beeinflusst, an welcher Stelle Sie messen.

Schnelles Lagebild mit iostat: Was ist wirklich kaputt?

iostat liefert schnell Hinweise, ob Sie ein Latenzproblem, ein Sättigungsproblem oder ein CPU-/Scheduler-Problem haben. Für Failover-Szenarien ist besonders wichtig, zwischen Service-Zeit, Queue und Durchsatz zu unterscheiden. In iostat-Ausgaben treffen Sie typischerweise auf:

• r/s, w/s, rkB/s, wkB/s: IOPS und Durchsatz
• await: durchschnittliche Wartezeit pro I/O (inklusive Queue + Service)
• svctm (je nach Version): Service-Zeit (nicht immer zuverlässig in modernen Kerneln)
• %util: Näherung für Auslastung (bei NVMe/mehreren Queues mit Vorsicht interpretieren)

Baseline aufnehmen: vor allem auf den richtigen Devices

Ein häufiger Stolperstein: Sie beobachten /dev/sdX, aber die Applikation nutzt /dev/mapper/mpathX oder ein LVM-LV darüber. Messen Sie daher sowohl die DM-Devices als auch die unterliegenden Blockgeräte. Starten Sie mit einer Ausgabe, die Geräte, Extended-Stats und kurze Intervalle zeigt:

# 1-Sekunden-Intervalle, 30 Samples, inklusive Device-Stats
iostat -dxm 1 30

Interpretation für Failover:

• await steigt stark, %util bleibt moderat: oft Retries/Timeouts, Pfadprobleme, oder Queueing in einer vorgelagerten Schicht (DM, HBA, Netz).
• %util nahe 100% und Durchsatz niedrig: Sättigung bei kleinen I/Os oder ein „eng“ gewordener Pfad (z. B. nur ein Controller aktiv).
• Nur ein einzelnes Device zeigt Ausreißer: eher Pfad/Device-spezifisch (z. B. ein LUN-Set), nicht generisch.

Typische iostat-Signaturen nach Failover

In der Praxis sieht man nach einem Storage-Failover häufig eine Kombination aus (a) deutlich höherem await und (b) schwankenden IOPS, obwohl die CPU ruhig ist. Das spricht oft für „nicht deterministische“ Latenzen durch Retries, Pfad-Flip-Flops oder ein Array, das intern re-synchronisiert. Wenn Sie im selben Zeitraum Kernel-Meldungen zu SCSI/iSCSI sehen (siehe nächster Abschnitt), ist das ein starkes Indiz, dass die Latenz nicht aus dem Dateisystem kommt, sondern aus der I/O-Kette darunter.

Kontext sichern: Logs und Kernel-Zustand rund um das Failover

Bevor Sie tiefer in blktrace gehen, sichern Sie den Kontext. Gerade im Failover sind Zeitstempel entscheidend, um I/O-Spitzen mit Pfadereignissen zu korrelieren.

# Kernel- und Systemlogs im relevanten Zeitraum (Beispiel: letzte 2 Stunden)
journalctl -k --since "2 hours ago" --no-pager
journalctl --since "2 hours ago" --no-pager | tail -n 300

Achten Sie auf Hinweise wie: link down, target reset, abort task, timed out, recovered error. Bei iSCSI finden sich oft Meldungen zu Session-Reconnects; bei FC eher HBA- oder SCSI-Layer-Resets. Diese Meldungen erklären häufig, warum await hochgeht, obwohl die LUN „da“ ist.

Device-Mapper prüfen mit dmsetup: Was macht Multipath wirklich?

Wenn Sie Multipath nutzen, ist dmsetup ein präzises Werkzeug, um die Device-Mapper-Sicht zu verstehen. Device Mapper ist eine Kernel-Schicht, die virtuelle Blockgeräte aus anderen Blockgeräten zusammensetzt – Multipath, LVM und dm-crypt sind typische Nutzer davon.

Starten Sie mit einer Übersicht, um die Namen und Abhängigkeiten zu sehen:

# Übersicht über DM-Devices und Abhängigkeiten
lsblk -o NAME,KNAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

dmsetup ls --tree

Wichtig ist die Frage: Welches DM-Device ist der Engpass? Ein LV (LVM) kann gesund wirken, während Multipath darunter gerade nur einen Pfad verwendet oder ständig umschaltet.

dmsetup status und table: Policy, Pfade, Fehlerzustände

Mit status und table sehen Sie, wie der Kernel das Gerät aktuell betreibt:

# Beispiel: Status und Tabelle eines Multipath-Devices
dmsetup status /dev/mapper/mpathX
dmsetup table  /dev/mapper/mpathX

Was Sie hier suchen:

• path groups: Wie viele Pfadgruppen gibt es, welche ist aktiv?
• failed/faulty paths: Gibt es Pfade, die als fehlerhaft markiert sind, aber trotzdem „flappen“?
• Policy: Round-robin, queue-length, service-time – je nach Array kann eine Policy sinnvoller sein als eine andere.

Wenn Sie zusätzlich multipath-tools einsetzen, liefert multipath -ll oft die lesbarste Sicht inklusive ALUA-Status. Das ist nicht dmsetup, aber in der Praxis die schnellste Ergänzung:

multipath -ll

Häufige Fehlerbilder im Multipath nach Failover

• Nur noch ein aktiver Pfad: Performance halbiert oder schlechter, plus höhere Latenz bei Spitzen.
• ALUA falsch interpretiert: Host nutzt „non-optimized“ Pfade (suboptimaler Controller), was Latenz und Durchsatz verschlechtert.
• Queueing bei Path-Down: Bei bestimmten Konfigurationen werden I/Os gequeued, wenn alle Pfade kurz weg sind. Das schützt vor Errors, kann aber nach Rückkehr eine lange Abarbeitungsschlange erzeugen.
• Flush/Failback: Zu aggressives Failback kann dazu führen, dass der Host ständig zurückspringt, während das Array noch nicht stabil ist.

Die Brücke zwischen Symptom und Ursache: blktrace richtig einsetzen

Wenn iostat und dmsetup zeigen, dass es ein I/O-Problem gibt, zeigt blktrace oft, wo die Zeit verloren geht. blktrace hängt sich an den Block-Layer und zeichnet Events auf (Queue, Dispatch, Completion). Damit können Sie unterscheiden: Staut sich I/O im Kernel, oder hängt es „draußen“ (Storage/Transport)?

Wichtig: Tracen Sie das richtige Device. Bei Device Mapper kann es sinnvoll sein, sowohl das DM-Device als auch das darunterliegende physische Device zu tracen. In vielen Umgebungen reicht es, am DM-Multipath-Device anzusetzen, weil dort Queueing sichtbar wird.

Kurzer, gezielter Trace während des Problems

Starten Sie mit einem kurzen Trace (z. B. 30–60 Sekunden), um den Overhead klein zu halten:

# 60 Sekunden Trace auf einem Device (Beispiel: dm-Device oder nvme0n1)
# -d: Device, -w: Dauer, -o: Output-Verzeichnis
mkdir -p /var/tmp/blktrace-iofailover
blktrace -d /dev/mapper/mpathX -w 60 -o /var/tmp/blktrace-iofailover/trace

Die Rohdaten sind schwer lesbar. Nutzen Sie anschließend btt (Block Trace Times), um Wartezeiten und Verteilungen zu analysieren:

# Auswertung der Trace-Dateien
btt -i /var/tmp/blktrace-iofailover/trace.* -o /var/tmp/blktrace-iofailover/report

Was Sie typischerweise herauslesen wollen:

• Queue-to-Dispatch: Zeit, die Requests im Kernel warten, bevor sie zum Device gehen. Hohe Werte deuten auf Kernel-/DM-Queueing oder Scheduler-Effekte hin.
• Dispatch-to-Complete: Zeit „auf dem Weg“ zum Storage und zurück. Hohe Werte deuten auf Storage-/Transport-Latenz, Pfadprobleme oder Retries hin.

Wann blktrace scheitert oder täuscht

Es gibt Grenzen: Bei extrem hoher I/O-Last kann der Trace selbst zu groß werden oder Timing verfälschen. Außerdem zeigt blktrace nur, was im Block-Layer passiert – nicht die genaue Ursache im SAN/iSCSI-Netz oder im Array. Wenn Dispatch-to-Complete explodiert, müssen Sie mit HBA-/NIC- und Array-Tools weitergehen (z. B. Switch-Ports, iSCSI-RTT, FC-Counters, Array-Front-End-Ports).

Prüfsequenz als Runbook: Von „Symptom“ zu „Root Cause“

Im Hosting-Betrieb hilft eine feste Reihenfolge, damit Sie unter Druck nichts übersehen. Die folgende Sequenz ist so aufgebaut, dass Sie zuerst mit niedriger Eingriffstiefe starten und erst dann in Traces gehen.

Schritt 1: Betroffene Ebene abgrenzen

• Ist nur ein Host betroffen oder mehrere? Mehrere Hosts sprechen für Array/Transport, ein Host eher für HBA/NIC/Multipath-Konfig.
• Ist nur ein LUN-Set betroffen oder alle LUNs? Nur ein Set kann auf ein Tier/Pool-Problem oder eine falsche LUN-Zuordnung deuten.
• Ist das Problem read- oder write-lastig? Write-Latenzen nach Failover können durch Cache-Umstellungen oder Rebuilds stärker steigen.

Schritt 2: iostat auf DM- und physischer Ebene

# Parallel-Ansatz: iostat laufen lassen und Zeitpunkt notieren
iostat -dxm 1

Notieren Sie die auffälligen Devices (dm-*, mpath*, sdX, nvme*), await-Spitzen und %util-Verhalten. Das ist später der Anker für Log-Korrelation und Traces.

Schritt 3: Pfadstatus und DM-Stack prüfen

dmsetup ls --tree
multipath -ll 2>/dev/null || true
dmsetup status /dev/mapper/mpathX

Wenn Sie hier sehen, dass nur ein Pfad aktiv ist oder Pfade als „faulty“ erscheinen, haben Sie meist schon den Hauptansatzpunkt: Transport stabilisieren, ALUA/Failback prüfen, Path-Checker/Timeouts anpassen.

Schritt 4: Kernel-Logs auf Resets/Timeouts

journalctl -k --since "30 min ago" --no-pager | egrep -i "scsi|iscsi|nvme|timeout|reset|abort|multipath|blk_update_request"

Resets und Timeouts erklären Latenzspitzen oft direkt. Wichtig ist, ob Fehler weiterlaufen (immer wiederkehrend) oder nur im Failover-Fenster waren.

Schritt 5: blktrace kurz und gezielt

mkdir -p /var/tmp/blktrace-iofailover
blktrace -d /dev/mapper/mpathX -w 30 -o /var/tmp/blktrace-iofailover/trace
btt -i /var/tmp/blktrace-iofailover/trace.* -o /var/tmp/blktrace-iofailover/report

Wenn die größte Zeit im Dispatch-to-Complete liegt, eskalieren Sie Richtung Storage/Netz/SAN. Wenn es im Queue-to-Dispatch liegt, schauen Sie stärker auf DM-Queueing, Scheduler, Queue-Parameter und die Interaktion mit dem Workload.

Typische Ursachen nach Failover – und was Sie konkret prüfen

1) ALUA und „falscher Controller“: Optimized vs. Non-Optimized

Bei Dual-Controller-Arrays kann ein Pfad „funktionieren“, aber nicht der bevorzugte sein. Dann sehen Sie Latenz plus geringeren Durchsatz, ohne klare Errors. Prüfen Sie in multipath -ll, ob Pfade als active/optimized markiert sind. Wenn nicht: Host-ALUA-Konfiguration, Array-Pfadzuordnung (Target-Ports), ggf. failback-Einstellungen prüfen. Risiko: Zu aggressives „failback immediate“ kann nach Failover zu einem Ping-Pong führen.

2) Timeout- und Retry-Kaskaden im SCSI/iSCSI-Stack

Failover bedeutet oft: kurzzeitig keine Antworten, dann wieder. Wenn Timeouts und Retries zu lang sind, wird jede I/O-Anfrage „mitgeschleppt“. Sie sehen das als hohe await-Werte, oft mit Burst-Charakter. Prüfen Sie Kernel-Logs und iSCSI-Session-Stabilität (bei iSCSI zusätzlich Netzwerk-Latenzen, Drops, MTU/Path-MTU). Gegenmaßnahmen hängen stark vom Stack ab: Timeouts müssen zu Array-Failover-Zeiten passen, ohne dass die Applikation in Errors läuft.

3) Multipath Queueing: Schutz vor Errors, aber teuer in der Nachwirkung

Multipath kann I/Os „queue_if_no_path“ oder ähnlich puffern, wenn alle Pfade weg sind. Das verhindert I/O-Errors in Applikationen, kann aber nach Rückkehr eine sehr lange Warteschlange erzeugen. iostat zeigt dann lange Zeit hohe await-Werte, obwohl der Pfad wieder da ist. Hier ist die Betriebsentscheidung entscheidend: Ist es akzeptabler, kurz Errors zu haben (und Applikations-Retry), oder ist Queueing zwingend, weil sonst Dateien/VMs korrupt werden könnten? Es gibt keine pauschale Antwort – aber Sie sollten es bewusst entscheiden und dokumentieren.

4) Scheduler- und Queue-Parameter nach Device-Wechsel

Nach einem Failover kann sich das sichtbare Device ändern (z. B. anderer HBA-Pfad) oder Parameter greifen anders. Bei NVMe und modernen SCSI-Geräten ist der klassische I/O-Scheduler weniger dominant, aber Queue-Settings, nr_requests und Device-Queue-Limits können dennoch limitieren. Prüfen Sie, ob sich Block-Queue-Parameter zwischen „normal“ und „degradiert“ unterscheiden. Stolperfalle: udev-Regeln oder Tuning-Profile werden nur beim Boot angewendet, nicht beim Path-Event.

5) Dateisystem und Applikation: „Nacharbeit“ nach I/O-Stop

Wenn während des Failovers kurz nicht geschrieben werden konnte, holen Applikationen danach auf: Journals werden abgearbeitet, Caches gefüllt, Datenbank-Logs gespült. Das sieht wie „Storage langsam“ aus, ist aber oft schlicht eine Lastspitze. Die Differenzierung gelingt über blktrace (Queue vs. Device-Latenz) und über Applikationsmetriken (z. B. DB-Checkpoint-Zeiten). Prüfen Sie hier auch, ob auf dem Host zusätzlich Memory-Pressure oder CPU-Steal (Virtualisierung) vorliegt – das kann I/O indirekt bremsen.

Stolperfallen in der Praxis

• Falsches Device getraced: Trace auf /dev/sdX, obwohl /dev/mapper/mpathX genutzt wird (oder umgekehrt). Ergebnis: scheinbar „nichts Auffälliges“.
• Messungen ohne Zeitbezug: Ohne exakte Zeitstempel (Failover-Event, Log-Meldungen, iostat-Intervalle) wird Ursache/Wirkung schnell verwechselt.
• Einmalige Ausreißer überinterpretiert: Nach Failover sind kurze Peaks normal. Relevant sind dauerhafte Degradierung oder wiederkehrende Peaks.
• Änderungen unter Last: Multipath-Policy oder Timeout-Tuning mitten im Incident kann die Lage verbessern oder verschlechtern. Planen Sie eine Rückfalloption.

Umsetzung: Stabilisieren, dann optimieren

Wenn Sie die Ursache eingegrenzt haben, priorisieren Sie in dieser Reihenfolge:

1. Stabilität herstellen: Pfade stabil, keine Flaps, keine wiederkehrenden Resets/Timeouts.
2. Richtige Pfade nutzen: ALUA/Controller-Zuordnung korrekt, Failback-Strategie passend.
3. Queueing bewusst entscheiden: Queueing schützt vor Errors, kann aber RTO (Recovery Time Objective) verlängern.
4. Performance-Tuning: Erst wenn stabil, an Queue-Depth, Scheduler und Policies arbeiten.

Dokumentieren Sie die getroffenen Entscheidungen im Runbook: Welche multipath.conf-Parameter sind gesetzt? Welche Failover-Zeiten sind auf Storage-Seite realistisch? Welche Applikationen vertragen kurzfristige I/O-Errors und welche nicht?

Rückfallstrategie: Änderungen sicher zurücknehmen

Gerade bei Multipath- und Timeout-Änderungen brauchen Sie eine saubere Rückfallstrategie. Praxisnah bedeutet:

• Konfiguration versionieren: multipath.conf, udev-Regeln, sysctl/Kernel-Parameter in Git oder einem Konfigurationsmanagement.
• Rollback-Schritt definieren: Wie kehren Sie auf den letzten bekannten Stand zurück? Wer darf das freigeben?
• Wartungsfenster einplanen: Manche Änderungen brauchen einen Dienst-Neustart oder wirken erst nach Re-Scan. Planen Sie das, bevor Sie „on the fly“ drehen.
• Nachkontrolle: iostat-Baseline, Pfadstatus, Logs auf neue Errors, und ein kurzer blktrace-Stichprobencheck, falls die Symptome vorher eindeutig waren.

Best Practices für den Betrieb: Damit der nächste Failover kein Performance-Incident wird

• Failover proben und messen: Nicht nur „geht/geht nicht“, sondern Latenz/IOPS vor, während, nach Failover erfassen.
• Monitoring auf Pfadebene: Nicht nur LUN erreichbar, sondern Anzahl aktiver Pfade, ALUA-Zustand, wiederkehrende Resets.
• Runbook mit klaren Messpunkten: iostat-Pattern, dmsetup/multipath-Ausgaben, blktrace-Window, Log-Filter.
• Applikationsseitige Timeouts abstimmen: Datenbank-, VM- und Filesystem-Timeouts müssen zur Storage-Failover-Realität passen.

Fazit

I/O-Einbrüche nach Storage-Failover sind selten „einfach Pech“, sondern meist das Zusammenspiel aus Pfadstatus, Device-Mapper-Verhalten, Timeouts/Retries und der Last, die nach dem Umschalten aufläuft. Mit einer konsequenten Diagnosekette aus iostat (Symptom und Umfang), dmsetup (Stack und Pfade) und blktrace (wo die Zeit verloren geht) bekommen Sie in kurzer Zeit belastbare Aussagen, statt im Nebel zu raten.

Wenn Sie die Ergebnisse als Runbook festhalten und Failover-Tests nicht nur funktional, sondern performancebezogen bewerten, reduzieren Sie das Risiko, dass ein erfolgreiches Failover trotzdem zum Betriebsincident wird.

Für dieses Thema sind auch Storage-Failover Troubleshooting und Iostat Analyse wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.