Analyser les baisses d'E/S après un basculement de stockage avec iostat, blktrace et dmsetup

Un basculement de stockage est idéalement un bref instant de commutation : le chemin disparaît, un chemin alternatif prend le relais, les applications continuent de fonctionner. En pratique, on observe souvent exactement l’inverse après un failover : chutes d’I/O après un failover de stockage, latences nettement plus élevées, tâches « saccadées », timeouts dans les bases de données ou machines virtuelles qui paraissent lentes. Le piège : la perturbation initiale est terminée, mais les performances restent dégradées — parfois pendant des minutes, parfois jusqu’au prochain redémarrage.

Ce billet présente une chaîne d’analyse éprouvée pour les systèmes Linux avec stockage en mode bloc (FC, iSCSI, SAS, NVMe-oF) et piles Device-Mapper (Multipath, LVM, dm-crypt). L’accent est mis sur trois outils complémentaires : iostat pour un état rapide, blktrace pour le traçage au niveau du bloc (c’est‑à‑dire le suivi des requêtes I/O individuelles dans le noyau) et dmsetup pour la transparence dans le Device Mapper (la couche qui fournit, par ex., les devices Multipath et LVM). S’y ajoutent causes typiques, pièges, étapes de vérification, options de tuning et une stratégie de repli opérationnelle.

Chutes d’I/O après basculement de stockage : pourquoi le failover « survit » souvent, mais pas les performances

Lors d’un basculement, il est rare que seule « une coupure de câble » intervienne. Effets secondaires typiques qui freinent les I/O après la commutation :

• Dégradation des chemins au lieu d’une redondance réelle : Multipath n’utilise plus qu’un seul chemin actif ou est connecté à un contrôleur sous‑optimal (problème ALUA). ALUA (« Asymmetric Logical Unit Access ») décrit que, sur des baies à double contrôleur, tous les chemins ne sont pas équivalents.
• Effets de file d’attente / timeout : lorsqu’un chemin disparaît, les I/O s’accumulent. Après la commutation, le retard doit être traité. En parallèle, les timeouts et les retries (réessais) peuvent augmenter massivement la latence.
• Comportement du cache d’écriture : les baies basculent leurs caches, resynchronisent des miroirs ou modifient les politiques de cache. Une baie peut fonctionner de manière « sûre », mais avec un mode de cache plus conservateur.
• La couche Device Mapper est « alive », mais mal paramétrée : Multipath/DM peut rester bloqué dans une politique inadaptée (p. ex. mauvais path_selector, min_io, rr_min_io_rq).
• Conséquences pour les applications et les systèmes de fichiers : journaling, replay de journaux, recovery des bases de données, timeouts de stockage des VM — cela peut générer des pics de charge qui donnent à tort l’impression que le stockage est « lent ».

La règle opérationnelle principale : Après un failover, « système en ligne » n’est pas synonyme de « système revenu à la normale ». Vous avez besoin d’une chaîne de mesure qui sépare clairement : périphérique/baie, chemins/Multipath, couche bloc du kernel, système de fichiers et charge de travail.

Prérequis et cadre de sécurité pour l’analyse

Avant d’approfondir le traçage, clarifiez deux points : (1) êtes‑vous autorisé à installer des outils sur l’hôte concerné et à lancer des traces noyau ? (2) le système est‑il dans un état où un diagnostic supplémentaire n’aggravera pas la situation ? blktrace génère un overhead, surtout à très haut débit d’I/O. Travaillez donc de manière aussi courte et ciblée que possible et, si possible, d’abord pendant une fenêtre de maintenance ou sur un nœud comparable.

Pour les étapes suivantes, les paquets typiques nécessaires sont : sysstat (iostat) ainsi que blktrace/btt. Sur de nombreuses distributions, ces paquets sont disponibles dans les dépôts standards. Vérifiez également si votre stockage est connecté via Multipath (Device Mapper) ou par exemple utilisé directement comme /dev/sdX — cela influe sur l’endroit où vous mesurez.

Vue rapide avec iostat : qu’est‑ce qui est réellement défaillant ?

iostat fournit rapidement des indications pour savoir si vous avez un problème de latence, un problème de saturation ou un problème CPU/scheduler. Pour les scénarios de failover, il est particulièrement important de distinguer entre temps de service, file d’attente et débit. Dans les sorties iostat, vous rencontrerez typiquement :

• r/s, w/s, rkB/s, wkB/s : IOPS et débit
• await : temps d’attente moyen par I/O (incluant file d’attente + service)
• svctm (selon la version) : temps de service (pas toujours fiable dans les noyaux modernes)
• %util : approximation de l’utilisation (à interpréter avec prudence pour NVMe/plusieurs files d’attente)

Prendre la baseline : surtout sur les périphériques corrects

Un piège fréquent : vous observez /dev/sdX, mais l’application utilise /dev/mapper/mpathX ou un LV LVM au-dessus. Mesurez donc à la fois les DM-Devices et les périphériques bloc sous-jacents. Démarrez avec une sortie qui montre les périphériques, les statistiques étendues et des intervalles courts :

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

Interprétation pour le failover :

• await augmente fortement, %util reste modéré : souvent des retries/timeouts, des problèmes de chemin, ou du queueing dans une couche en amont (DM, HBA, réseau).
• %util proche de 100% et débit faible : saturation lors de petits I/O ou un chemin devenu « étroit » (p. ex. un seul contrôleur actif).
• Un seul périphérique montre des valeurs aberrantes : plutôt spécifique au chemin/périphérique (p. ex. un ensemble de LUN), pas générique.

Signatures iostat typiques après un failover

En pratique, après un failover de stockage on observe souvent une combinaison de (a) await sensiblement plus élevé et (b) des IOPS fluctuantes, alors que le CPU reste calme. Cela indique souvent des latences « non déterministes » dues aux retries, aux basculements de chemin (flip-flops) ou à un array qui se resynchronise en interne. Si vous voyez dans la même période des messages du noyau concernant SCSI/iSCSI (voir section suivante), c’est un fort indice que la latence ne provient pas du système de fichiers, mais de la chaîne I/O en dessous.

Sauvegarder le contexte : logs et état du noyau autour du failover

Avant d’aller plus loin avec blktrace, sauvegardez le contexte. Particulièrement lors d’un failover, les horodatages sont cruciaux pour corréler les pics I/O avec les événements de chemin.

# 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

Faites attention à des indications telles que : link down, target reset, abort task, timed out, recovered error. Avec iSCSI on trouve souvent des messages de reconnexion de session ; avec FC plutôt des resets au niveau HBA ou SCSI. Ces messages expliquent souvent pourquoi le await augmente, alors que la LUN « présente » est disponible.

Vérifier le Device Mapper avec dmsetup : que fait réellement Multipath ?

Si vous utilisez Multipath, dmsetup est un outil précis pour comprendre la vue du Device Mapper. Le Device Mapper est une couche du noyau qui compose des périphériques de bloc virtuels à partir d’autres périphériques de bloc – Multipath, LVM et dm-crypt en sont des utilisateurs typiques.

Commencez par une vue d’ensemble pour voir les noms et les dépendances :

# Vue d'ensemble des devices DM et de leurs dépendances
lsblk -o NAME,KNAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS

dmsetup ls --tree

L’important est la question : Quel device DM est le goulot d’étranglement ? Un LV (LVM) peut sembler sain alors que Multipath utilise sous-jacent un seul chemin ou bascule en permanence.

dmsetup status et table : politique, chemins, états d’erreur

Avec status et table vous voyez comment le noyau exploite actuellement le périphérique :

# Exemple : status et table d'un device Multipath
dmsetup status /dev/mapper/mpathX
dmsetup table  /dev/mapper/mpathX

Ce que vous devez rechercher ici :

• groupes de chemins : combien de groupes de chemins existe-t-il, lequel est actif ?
• failed/faulty paths : y a‑t‑il des chemins marqués comme défaillants mais qui continuent d’osciller ?
• politique : round-robin, queue-length, service-time — selon l’array, une politique peut être plus appropriée qu’une autre.

Si vous utilisez en complément multipath-tools, multipath -ll fournit souvent la vue la plus lisible, incluant le statut ALUA. Ce n’est pas dmsetup, mais en pratique c’est le complément le plus rapide :

multipath -ll

Scénarios d’erreur fréquents sur Multipath après bascule

• Un seul chemin actif : performance divisée par deux ou pire, avec une latence accrue lors des pics.
• ALUA mal interprété : l’hôte utilise des chemins « non-optimized » (contrôleur sous-optimal), ce qui dégrade latence et débit.
• Mise en file lors d’un Path-Down : dans certaines configurations, les I/O sont mis en file si tous les chemins disparaissent brièvement. Cela évite les erreurs, mais peut créer une longue file d’exécution après le rétablissement.
• Flush/Failback : un failback trop agressif peut amener l’hôte à basculer en permanence alors que l’array n’est pas encore stable.

Le pont entre symptôme et cause : utiliser blktrace correctement

Lorsque iostat et dmsetup indiquent qu’il y a un problème d’I/O, blktrace montre souvent où le temps est perdu. blktrace s’attache au block layer et enregistre des événements (Queue, Dispatch, Completion). Cela vous permet de distinguer : les I/O se bloquent-elles dans le noyau, ou le retard se produit‑il « à l’extérieur » (storage/transport) ?

Important : tracez le bon device. Pour Device Mapper, il peut être pertinent de tracer à la fois le device DM et le device physique sous‑jacent. Dans de nombreux environnements, il suffit de commencer par le device DM‑multipath, car c’est là que le queueing devient visible.

Trace court et ciblé pendant le problème

Démarrez par un trace court (p. ex. 30–60 secondes) pour limiter l’overhead :

# 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

Les données brutes sont difficiles à lire. Utilisez ensuite btt (Block Trace Times) pour analyser les temps d’attente et les distributions :

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

Ce que vous voulez typiquement en retirer :

• Queue-to-Dispatch : temps que les requêtes passent en attente dans le kernel avant d’être envoyées au device. Des valeurs élevées indiquent du queueing au niveau kernel/DM ou des effets du scheduler.
• Dispatch-to-Complete : temps « en chemin » vers le storage et retour. Des valeurs élevées indiquent une latence storage/transport, des problèmes de chemin ou des retries.

Quand blktrace échoue ou induit en erreur

Il y a des limites : sous une charge I/O extrêmement élevée, le trace peut devenir trop volumineux ou fausser les timings. De plus, blktrace ne montre que ce qui se passe au niveau du block layer — pas la cause exacte dans le SAN/iSCSI‑réseau ou dans l’array. Si Dispatch‑to‑Complete explose, il faudra poursuivre avec des outils HBA/NIC et array (p. ex. ports de switch, iSCSI‑RTT, compteurs FC, ports front‑end de l’array).

Séquence de vérification comme runbook : du « symptôme » à la « root cause »

En exploitation hosting, une séquence fixe aide à ne rien oublier sous pression. L’ordre ci‑dessous est conçu pour démarrer avec une faible profondeur d’intervention et n’entrer dans les traces qu’ensuite.

Étape 1 : délimiter le niveau concerné

• Un seul hôte est‑il affecté ou plusieurs ? Plusieurs hôtes pointent vers l’array/transport, un seul hôte plutôt vers une config HBA/NIC/Multipath.
• Un seul ensemble de LUN est‑il affecté ou tous les LUNs ? Un seul ensemble peut indiquer un problème de tier/pool ou un mauvais mapping de LUN.
• Le problème est‑il à prédominance lecture ou écriture ? Les latences en écriture après un Failover peuvent augmenter fortement à cause de changements de cache ou de Rebuilds.

Étape 2 : iostat au niveau DM et physique

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

Notez les périphériques remarquables (dm-*, mpath*, sdX, nvme*), les pics d’await et le comportement de %util. Cela servira plus tard d’ancre pour la corrélation des logs et les traces.

Schritt 3: Pfadstatus und DM-Stack prüfen

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

Si vous voyez ici qu’un seul chemin est actif ou que des chemins apparaissent comme „faulty“, vous avez généralement déjà le principal point d’action : stabiliser le transport, vérifier ALUA/Failback, ajuster les 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"

Les réinitialisations et timeouts expliquent souvent directement les pics de latence. Il est important de savoir si les erreurs se poursuivent (récurrentes) ou si elles ont eu lieu uniquement pendant la fenêtre de 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

Si la majeure partie du temps est passée en Dispatch-to-Complete, escaladez vers le stockage/le réseau/le SAN. Si elle est en Queue-to-Dispatch, concentrez-vous davantage sur le DM-Queueing, le scheduler, les paramètres de la queue et l’interaction avec la charge de travail.

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

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

Sur des arrays à double contrôleur, un chemin peut « fonctionner » mais ne pas être le préféré. Vous verrez alors de la latence et un débit réduit, sans erreurs évidentes. Vérifiez avec multipath -ll si les chemins sont marqués active/optimized. Sinon : vérifiez la configuration Host-ALUA, l’affectation des chemins sur l’array (Target-Ports) et, le cas échéant, les paramètres de failback. Risque : un « failback immediate » trop agressif peut provoquer un ping-pong après un Failover.

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

Un Failover signifie souvent : pas de réponse pendant un court instant, puis reprise. Si les Timeouts et Retries sont trop longs, chaque requête I/O sera « traînée ». Vous le verrez sous forme d’attentes await élevées, souvent par rafales. Vérifiez les logs du noyau et la stabilité des sessions iSCSI (pour iSCSI, examinez aussi les latences réseau, les pertes, MTU/Path-MTU). Les mesures correctives dépendent fortement de la pile : les Timeouts doivent correspondre aux durées de basculement de l’array, sans que l’application n’entre en erreur.

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

Multipath peut mettre en tampon les I/Os avec « queue_if_no_path » ou un mécanisme similaire lorsque tous les chemins sont perdus. Cela évite des I/O-Errors côté application, mais peut générer une très longue file d’attente au retour des chemins. iostat montrera alors pendant longtemps des await élevés, alors que le chemin est revenu. La décision opérationnelle est cruciale : vaut-il mieux accepter des erreurs temporaires (et des retries applicatifs), ou le Queueing est-il indispensable car sinon des fichiers/VMs risquent la corruption ? Il n’y a pas de réponse universelle — mais vous devez décider et documenter en connaissance de cause.

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

Après un failover, le device visible peut changer (p. ex. un autre chemin HBA) ou des paramètres peuvent agir différemment. Avec NVMe et les périphériques SCSI modernes, l’I/O-scheduler classique est moins dominant, mais les paramètres de queue, nr_requests et les Device-Queue-Limits peuvent néanmoins limiter. Vérifiez si les paramètres de la file-bloc diffèrent entre « normal » et « dégradé ». Piège : les règles udev ou les profils de tuning ne sont appliquent qu’au démarrage, pas lors d’un événement de changement de chemin.

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

Si, pendant le failover, il a été impossible d’écrire pendant un court instant, les applications rattrapent ensuite : les journaux sont traités, les caches remplis, les logs de base de données vidés. Cela ressemble à un « stockage lent », mais il s’agit souvent simplement d’un pic de charge. La différenciation s’effectue via blktrace (queue vs latence du device) et via les métriques applicatives (p. ex. temps de checkpoint DB). Vérifiez aussi si l’hôte subit de la memory-pressure ou du CPU-steal (virtualisation) — cela peut freiner l’I/O indirectement.

Pièges dans la pratique

• Mauvais device tracé : trace sur /dev/sdX alors que /dev/mapper/mpathX est utilisé (ou inversement). Résultat : apparemment « rien d’anormal ».
• Mesures sans référence temporelle : sans horodatage précis (événement de failover, messages de log, intervalles iostat) cause et effet sont vite confondus.
• Suralimentation d’un incident isolé : après un failover, des pics courts sont normaux. Ce qui compte, ce sont les dégradations persistantes ou les pics récurrents.
• Modifications sous charge : changer la multipath-policy ou les timeouts en plein incident peut améliorer ou aggraver la situation. Prévoyez une option de retour arrière.

Mise en œuvre : stabiliser, puis optimiser

Une fois la cause circonscrite, priorisez dans cet ordre :

1. Rétablir la stabilité : chemins stables, pas de flaps, pas de reset/timeout récurrents.
2. Utiliser les bons chemins : assignation ALUA/contrôleur correcte, stratégie de failback adaptée.
3. Choisir consciemment le queueing : le queueing protège contre les erreurs, mais peut allonger le RTO (Recovery Time Objective).
4. Optimisation de performance : seulement une fois stable, intervenez sur la queue-depth, le scheduler et les policies.

Documentez les décisions prises dans le Runbook : quels paramètres de multipath.conf sont définis ? Quels temps de failover sont réalistes côté stockage ? Quelles applications tolèrent des erreurs d’I/O temporaires et lesquelles non ?

Stratégie de repli : annuler les changements en toute sécurité

Particulièrement pour les modifications liées au multipath et aux timeouts, vous avez besoin d’une stratégie de repli claire. En pratique cela signifie :

• Versionner la configuration : multipath.conf, règles udev, paramètres sysctl/du noyau dans Git ou un outil de gestion de configuration.
• Définir l’étape de rollback : comment revenir au dernier état connu ? Qui peut valider le retour ?
• Planifier une fenêtre de maintenance : certaines modifications nécessitent un redémarrage de service ou prennent effet seulement après un re-scan. Planifiez cela avant d’opérer « on the fly ».
• Contrôle post-changement : baseline iostat, état des chemins, journaux pour erreurs nouvelles, et un contrôle ponctuel blktrace si les symptômes étaient auparavant clairs.

Bonnes pratiques pour l’exploitation : pour que le prochain Failover ne devienne pas un incident de performance

• Tester et mesurer les Failovers : pas seulement « ça marche/ça ne marche pas », mais relever latence/IOPS avant, pendant et après le Failover.
• Monitoring au niveau des chemins: pas seulement que le LUN soit joignable, mais le nombre de chemins actifs, l’état ALUA, les réinitialisations récurrentes.
• Runbook avec des points de mesure clairs: motifs iostat, sorties dmsetup/multipath, fenêtre blktrace, filtres de logs.
• Coordonner les timeouts côté application: les timeouts de base de données, de VM et de système de fichiers doivent correspondre à la réalité des basculements de stockage.

Conclusion

Les chutes d’E/S après un basculement de stockage sont rarement « un simple coup de malchance », mais résultent généralement de l’interaction entre l’état des chemins, le comportement du Device Mapper, les timeouts/réessais et la charge qui se met à courir après le basculement. Avec une chaîne de diagnostic cohérente composée de iostat (symptôme et ampleur), dmsetup (pile et chemins) et blktrace (où le temps est perdu), vous obtenez en peu de temps des conclusions fiables, au lieu de deviner à l’aveugle.

Si vous consignez les résultats dans un Runbook et que vous évaluez les tests de basculement non seulement sur le plan fonctionnel mais aussi en termes de performances, vous réduisez le risque qu’un basculement réussi devienne malgré tout un incident opérationnel.

Pour ce sujet, le dépannage des Storage-Failover et l’analyse iostat sont également importants. L’article replace ces aspects de manière compréhensible et montre ce qui compte au quotidien.