Analizzare i cali di I/O dopo un failover dello storage con iostat, blktrace e dmsetup

Un failover dello storage è idealmente un breve momento di commutazione: percorso assente, percorso alternativo subentra, le applicazioni continuano a funzionare. Nella pratica, però, dopo il failover si osserva spesso esattamente il contrario: Calate di I/O dopo un failover dello storage, latenze significativamente più alte, job che „balbettano“, timeout nei database o macchine virtuali che risultano lente. L’inghippo: l’interruzione vera e propria è terminata, ma le prestazioni restano degradate – a volte per minuti, a volte fino al prossimo reboot.

Questo contributo mostra una catena di analisi collaudata per i sistemi Linux con storage a blocchi (FC, iSCSI, SAS, NVMe-oF) e stack Device Mapper (Multipath, LVM, dm-crypt). In primo piano ci sono tre strumenti che si completano bene: iostat per il quadro rapido, blktrace per il tracciamento a livello di blocco (cioè il tracciamento delle singole richieste I/O nel kernel) e dmsetup per la trasparenza nel Device Mapper (lo strato che fornisce, per esempio, device Multipath e LVM). A ciò si aggiungono cause tipiche, insidie, passaggi di verifica, opzioni di tuning e una strategia di fallback che sia praticabile in esercizio.

Calate di I/O dopo un failover dello storage: perché il failover spesso „sopravvive“, ma le prestazioni no

In un failover raramente cambia solo „un cavo“. Effetti collaterali tipici che rallentano gli I/O dopo la commutazione:

• Degrado dei percorsi invece di vera ridondanza: Multipath usa attivamente solo un percorso oppure è collegato a un controller subottimale (problema ALUA). ALUA („Asymmetric Logical Unit Access“) indica che in array a doppio controller non tutti i percorsi hanno la stessa qualità.
• Effetti di coda/timeout: mentre un percorso è assente, gli I/O si accumulano. Dopo la commutazione l’arretrato deve essere smaltito. Contemporaneamente timeout e retry (ripetizioni) possono aumentare in modo massiccio la latenza.
• Comportamento della write-cache: gli array commutano le cache, risincronizzano mirror o modificano le policy di cache. Un array può funzionare in modalità „sicura“, ma con una politica di cache più conservativa.
• Lo strato Device Mapper è „attivo“, ma parametrizzato in modo errato: Multipath/DM può restare incastrato in una policy sfavorevole (p.es. path_selector sbagliato, min_io, rr_min_io_rq).
• Conseguenze per applicazioni e file system: journaling, replay dei log, recovery del database, timeout di storage delle VM – tutto ciò può generare picchi di carico che a torto vengono interpretati come „storage lento“.

La regola operativa più importante: Dopo un failover „sistema di nuovo online“ non equivale a „sistema di nuovo normale“. Serve una catena di misurazione che separi in modo netto: device/array, percorsi/multipath, kernel block layer, file system e workload.

Prerequisiti e quadro di sicurezza per l’analisi

Prima di approfondire il tracing, chiarite due punti: (1) Avete il permesso sul host interessato di installare strumenti e avviare kernel-trace? (2) Il sistema è in uno stato in cui una diagnostica aggiuntiva non peggiorerebbe la situazione? blktrace genera overhead, soprattutto a tassi I/O molto elevati. Operate quindi in modo il più breve e mirato possibile e – se possibile – iniziate in una finestra di manutenzione o su un nodo comparabile.

Per i passaggi seguenti sono tipicamente necessari i pacchetti: sysstat (iostat) e blktrace/btt. Su molte distribuzioni questi pacchetti sono disponibili nei repository standard. Verificate inoltre se il vostro storage è collegato tramite Multipath (Device Mapper) o, per esempio, usato direttamente come /dev/sdX – questo influisce sul punto in cui effettuare le misurazioni.

Quadro rapido con iostat: cosa è realmente compromesso?

iostat fornisce rapidamente indicazioni se avete un problema di latenza, di saturazione o di CPU/scheduler. Per scenari di failover è particolarmente importante distinguere tra tempo di servizio, coda e throughput. Nelle uscite di iostat incontrerete tipicamente:

• r/s, w/s, rkB/s, wkB/s: IOPS e throughput
• await: tempo medio di attesa per I/O (inclusi coda + servizio)
• svctm (a seconda della versione): tempo di servizio (non sempre affidabile nei kernel moderni)
• %util: approssimazione dell’utilizzo (interpretare con cautela per NVMe/multiple code)

Rilevare la Baseline: soprattutto sui dispositivi corretti

Un errore comune: si monitora /dev/sdX, ma l’applicazione usa /dev/mapper/mpathX o un LV LVM sovrastante. Misurate quindi sia i device DM sia i block device sottostanti. Iniziate con un’uscita che mostri i dispositivi, le statistiche estese e intervalli brevi:

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

Interpretazione per scenari di failover:

• await aumenta molto, %util rimane moderato: spesso retry/timeout, problemi di percorso o accodamento in uno strato a monte (DM, HBA, rete).
• %util vicino al 100% e throughput basso: saturazione con I/O piccoli o un percorso che è diventato „ristretto“ (es. solo un controller attivo).
• Solo un singolo device mostra valori anomali: piuttosto specifico del percorso/dispositivo (es. un set di LUN), non un problema generale.

Pattern tipici di iostat dopo un failover

Nella pratica, dopo un failover di storage si osserva spesso una combinazione di (a) await significativamente più alto e (b) IOPS oscillanti, mentre la CPU resta tranquilla. Questo indica spesso latenze „non deterministiche“ dovute a retry, flip-flop del percorso o a un array che si resincronizza internamente. Se nello stesso intervallo vedete messaggi del kernel relativi a SCSI/iSCSI (vedi il paragrafo successivo), è un forte indizio che la latenza non origina dal file system, ma dalla catena I/O sottostante.

Raccogliere il contesto: log e stato del kernel intorno al failover

Prima di approfondire con blktrace, acquisite il contesto. Proprio in caso di failover le marcature temporali sono decisive per correlare i picchi di I/O con gli eventi sul percorso.

# 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

Prestate attenzione a indicazioni come: link down, target reset, abort task, timed out, recovered error. In iSCSI si trovano spesso messaggi relativi a session-reconnect; in FC piuttosto reset a livello HBA o SCSI. Questi messaggi spiegano spesso perché await aumenta, anche se la LUN è ‚presente‘.

Verificare il Device-Mapper con dmsetup: cosa fa realmente Multipath?

Se utilizzate Multipath, è dmsetup uno strumento preciso per comprendere la vista del Device Mapper. Device Mapper è uno strato del kernel che compone dispositivi a blocchi virtuali a partire da altri dispositivi a blocchi – Multipath, LVM e dm-crypt sono tipici utilizzatori.

Avviate una panoramica per vedere nomi e dipendenze:

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

dmsetup ls --tree

Importante è la domanda: qual è il DM-Device che rappresenta il collo di bottiglia? Un LV (LVM) può apparire sano, mentre Multipath sottostante sta usando solo un percorso o sta commutando continuamente.

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

Con status e table vedete come il kernel sta attualmente gestendo il dispositivo:

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

Cosa cercare qui:

• path groups: quanti gruppi di percorso esistono e quale è attivo?
• failed/faulty paths: ci sono percorsi contrassegnati come difettosi ma che comunque manifestano flapping?
• Policy: Round-robin, queue-length, service-time – a seconda dell’array una policy può essere più adeguata di un’altra.

Se utilizzate inoltre multipath-tools, multipath -ll spesso fornisce la vista più leggibile, incluso lo stato ALUA. Non è dmsetup, ma nella pratica il complemento più rapido:

multipath -ll

Häufige Fehlerbilder im Multipath nach Failover

• Solo un percorso attivo: prestazioni dimezzate o peggiori, oltre a latenze più elevate durante i picchi.
• ALUA interpretato in modo errato: l’host utilizza percorsi „non-optimized“ (controller subottimale), peggiorando latenza e throughput.
• Accodamento in caso di Path-Down: in alcune configurazioni le I/Os vengono accodate quando tutti i percorsi sono momentaneamente assenti. Questo protegge dagli errori, ma al ritorno può generare una lunga coda di elaborazione.
• Flush/Failback: un failback troppo aggressivo può causare continui rimbalzi dell’host mentre l’array non è ancora stabile.

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

Quando iostat e dmsetup mostrano che c c un problema di I/O, blktrace spesso indica dove si perde tempo. blktrace si aggancia al block layer e registra eventi (Queue, Dispatch, Completion). Questo consente di distinguere: l I/O si accumula nel kernel, oppure il problema esterno allo storage/transport?

Importante: tracciare il device corretto. Con il Device Mapper può essere utile tracciare sia il DM-Device sia il device fisico sottostante. In molte infrastrutture sufficiente puntare al DM-Multipath-Device, perch lì il queueing diventa visibile.

Trace breve e mirato durante il problema

Avviate un trace breve (es. 3060 secondi) per mantenere basso loverhead:

# 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

I dati grezzi sono difficili da leggere. Utilizzate poi btt (Block Trace Times) per analizzare i tempi di attesa e le distribuzioni:

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

Cosa si vuole tipicamente risalire:

• Queue-to-Dispatch: tempo durante il quale le richieste restano in attesa nel kernel prima di essere inviate al device. Valori elevati indicano queueing nel kernel/DM o effetti del scheduler.
• Dispatch-to-Complete: tempo „sulla strada“ verso lo storage e ritorno. Valori elevati indicano latenza dello storage/transport, problemi di percorso o retry.

Quando blktrace fallisce o pu ingannare

Ci sono dei limiti: sotto carico I/O estremamente elevato il trace stesso pu diventare troppo grande o alterare il timing. Inoltre blktrace mostra solo ci che avviene al block layer, non la causa precisa nello SAN/iSCSI-net o nellarray. Se il valore Dispatch-to-Complete esplode, occorre proseguire con strumenti HBA/NIC e dellarray (es. porte dello switch, iSCSI-RTT, FC-Counters, porte front-end dellarray).

Sequenza di verifica come Runbook: dal „Symptom“ alla „Root Cause“

In gestione hosting aiuta seguire un ordine fisso, cos da non trascurare nulla sotto pressione. La sequenza seguente  strutturata in modo da partire con interventi a bassa invasivit e passare ai trace solo se necessario.

Passo 1: delimitare il livello interessato

• È interessato un solo host o pi host? Pi host suggeriscono problema su array/transport, un singolo host pi per HBA/NIC/configurazione multipath.
• È interessato solo un set di LUN o tutte le LUN? Solo un set pu indicare un problema di tier/pool o una mappatura LUN errata.
• Il problema  prevalente in lettura o scrittura? Le latenze di scrittura dopo un failover possono aumentare pi a causa di cambi di cache o rebuild.

Passo 2: iostat su livello DM e fisico

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

Annotate i dispositivi anomali (dm-*, mpath*, sdX, nvme*), i picchi di await e il comportamento di %util. Questo sarà in seguito l’ancora per la correlazione dei log e le tracce.

Schritt 3: Pfadstatus und DM-Stack prüfen

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

Se qui vedete che è attivo un solo percorso o che i percorsi appaiono come „faulty“, avete di norma già il punto principale di intervento: stabilizzare il trasporto, verificare ALUA/Failback, adattare Path-Checker/Timeouts.

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"

Reset e timeout spiegano spesso direttamente i picchi di latenza. Importante è se gli errori proseguono (ricorrenti) o se erano presenti solo nella finestra di failover.

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

Se la maggior parte del tempo è in Dispatch-to-Complete, scalate il problema verso storage/rete/SAN. Se è in Queue-to-Dispatch, concentratevi su DM-Queueing, scheduler, parametri di coda e sull’interazione con il workload.

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

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

Su array dual-controller un percorso può „funzionare“ ma non essere quello preferito. In quel caso vedrete latenza e throughput ridotto senza errori evidenti. Controllate con multipath -ll se i percorsi sono segnati come active/optimized. In caso contrario: verificare la configurazione Host-ALUA, l’assegnazione dei percorsi sull’array (Target-Ports) e, se necessario, le impostazioni di failback. Rischio: un failback troppo aggressivo come „failback immediate“ può provocare un effetto ping-pong dopo il failover.

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

Il failover spesso significa: assenza temporanea di risposte, poi ripresa. Se timeout e retry sono troppo lunghi, ogni richiesta I/O viene „trascinata“. Lo si osserva come elevati valori di await, spesso a carattere burst. Verificate i log del kernel e la stabilità delle sessioni iSCSI (per iSCSI controllate inoltre latenze di rete, packet drops, MTU/Path-MTU). Le contromisure dipendono fortemente dallo stack: i timeout devono essere adeguati ai tempi di failover dell’array, senza che l’applicazione entri in errori.

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

Multipath può bufferizzare le I/O con „queue_if_no_path“ o meccanismi simili quando tutti i percorsi sono assenti. Questo evita I/O-Errors nelle applicazioni, ma al ritorno può generare una coda molto lunga. iostat mostrerà per lungo tempo valori elevati di await anche se il percorso è tornato. Qui la decisione operativa è cruciale: è più accettabile avere brevi errori (e retry applicativi), oppure il queueing è obbligatorio perché altrimenti file/VM potrebbero corrompersi? Non esiste una risposta universale — ma la decisione va presa e documentata consapevolmente.

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

Dopo un Failover il device visibile può cambiare (es. altro path HBA) o i parametri possono comportarsi diversamente. Con NVMe e dispositivi SCSI moderni lo scheduler I/O classico è meno dominante, ma Queue-Settings, nr_requests e Device-Queue-Limits possono comunque imporre limiti. Verificate se i parametri della Block-Queue differiscono tra „normal“ e „degradiert“. Stolperfalle: le regole udev o i profili di tuning vengono applicati solo al boot, non al Path-Event.

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

Se durante il Failover per un breve periodo non è stato possibile scrivere, le applicazioni recuperano in seguito: i journal vengono smaltiti, le cache ricaricate, i log del database flushati. Questo può apparire come “storage lento”, ma spesso è semplicemente un picco di carico. La distinzione si ottiene con blktrace (Queue vs. Device-Latenz) e con metriche applicative (p.es. tempi di DB-Checkpoint). Controllate inoltre se sull’host è presente Memory-Pressure o CPU-Steal (virtualizzazione) — questo può rallentare l’I/O in modo indiretto.

Stolperfallen in der Praxis

• Falsches Device getraced: Trace su /dev/sdX, mentre viene utilizzato /dev/mapper/mpathX (o viceversa). Risultato: apparentemente „nichts Auffälliges“.
• Messungen ohne Zeitbezug: Senza timestamp precisi (Failover-Event, messaggi di log, intervalli di iostat) causa ed effetto si confondono rapidamente.
• Einmalige Ausreißer überinterpretiert: Dopo un Failover brevi picchi sono normali. Rilevanti sono le degradazioni durature o i picchi ricorrenti.
• Änderungen unter Last: Modificare la Multipath-Policy o il timeout-tuning nel bel mezzo dell’incidente può migliorare o peggiorare la situazione. Pianificate un’opzione di rollback.

Umsetzung: Stabilisieren, dann optimieren

Una volta circoscritta la causa, date priorità in questo ordine:

1. Stabilität herstellen: Ripristinare la stabilità: percorsi stabili, nessun flap, nessun reset/timeout ricorrente.
2. Richtige Pfade nutzen: Usare i path corretti: assegnazione ALUA/controller corretta, strategia di failback adeguata.
3. Queueing bewusst entscheiden: Decidere consapevolmente il queueing: il queueing protegge dagli errori, ma può allungare l’RTO (Recovery Time Objective).
4. Performance-Tuning: Tuning delle prestazioni: solo quando è stabile, intervenire su Queue-Depth, scheduler e policy.

Documentate le decisioni prese nel runbook: quali parametri di multipath.conf sono impostati? Quali tempi di Failover sono realistici lato storage? Quali applicazioni tollerano errori I/O a breve termine e quali no?

Rückfallstrategie: Änderungen sicher zurücknehmen

Soprattutto per modifiche a multipath e timeout serve una strategia di rollback chiara. In pratica significa:

• Konfiguration versionieren: multipath.conf, regole udev, sysctl/parametri del Kernel in Git o in un sistema di gestione delle configurazioni.
• Rollback-Schritt definieren: Definire il passaggio di rollback: come tornate all’ultimo stato noto? Chi può autorizzarlo?
• Wartungsfenster einplanen: Pianificare una finestra di manutenzione: alcune modifiche richiedono il riavvio di servizi o hanno effetto solo dopo un re-scan. Pianificatelo prima di intervenire „on the fly“.
• Nachkontrolle: Controllo post-intervento: baseline iostat, stato dei path, log per nuovi errori, e un rapido controllo a campione con blktrace se i sintomi erano chiari in precedenza.

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

• Failover proben und messen: Testare e misurare i Failover: non solo „geht/geht nicht“, ma raccogliere latenza/IOPS prima, durante e dopo il Failover.
• Monitoraggio a livello di percorsi: Non solo LUN raggiungibile, ma numero di percorsi attivi, stato ALUA, reset ricorrenti.
• Runbook con punti di misurazione chiari: iostat-Pattern, output di dmsetup/multipath, blktrace-Window, filtri dei log.
• Allineare i timeout lato applicazione: i timeout di database, VM e filesystem devono essere coerenti con la realtà dei failover dello storage.

Conclusione

I cali di I/O dopo failover dello storage sono raramente «semplicemente sfortuna», ma di solito il risultato dell’interazione tra stato dei percorsi, comportamento del device mapper, timeout/retry e il carico che si accumula dopo lo switch. Con una catena diagnostica coerente composta da iostat (sintomo e portata), dmsetup (stack e percorsi) e blktrace (dove si perde tempo) otterrà in breve tempo valutazioni attendibili, invece di azzardare ipotesi al buio.

Se registra i risultati come Runbook e valuta i test di failover non solo funzionalmente, ma anche in termini di prestazioni, ridurrà il rischio che un failover riuscito si trasformi comunque in un incidente operativo.

Per questo argomento sono importanti anche il troubleshooting dei Storage-Failover e l’analisi di iostat. Il contributo inquadra questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.