Pourquoi je vois des erreurs d'I/O sur un système RHEL utilisant un périphérique de stockage en mode actif/passif ?
Environment
- Red Hat Enterprise Linux 4
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Périphériques de stockage en mode actif/passif (voir root cause pour plus de details)
Issue
- Je vois des erreurs d'I/O dans les journaux du système pour certains périphériques de stockages / SAN
- Quand je lance des commandes LVM, j'obtiens des erreurs d'I/O contre certains des dispositifs de stockage
- Message d'erreur "
end_request: I/O error, dev sdb, sector 0" trouvé dans le fichier /var/log/messages - Message d'erreur "
Buffer I/O error on device sdc, logical block 0" trouvé dans le fichier /var/log/messages -
Des messages additionnels "
sense key: Not Ready" peuvent également apparaitre:kernel: end_request: I/O error, dev sdc, sector 0 kernel: sd 0:0:0:3: Device not ready: <6>: Current: sense key: Not Ready kernel: Add. Sense: Logical unit not ready, manual intervention required
Resolution
Note: Ce qui suit ne s'applique qu'aux erreurs d'I/O causés par l'accès aux chemins passifs. Voir les sections Root Cause et Diagnostic Steps pour obtenir plus d'informations afin de déterminer si cela s'applique à votre environnement.
-
Une façon de réduire le nombre d'erreurs I/O "parasites" dans les journaux du système est d'éviter le balayage des chemins passifs avec des commandes de LVM. Cela peut être fait avec un filtre dans /etc/lvm/lvm.conf pour qu'il analyse uniquement les périphériques de device-mapper-multipath, EMC PowerPath, Hitachi HDLM, ou une autre solution multipath, et ainsi éviter les périphériques SCSI sous-jacents.
-
Les erreurs I/O peuvent être causées par un utilitaire ou un programme qui accède des chemins de stockage passif, il peut être nécessaire de les configurer ou de les exécuter de manière à éviter ces périphériques. Par exemple, plutôt que d'utiliser "fdisk-l", spécifiez un périphérique individuel tel que 'fdisk -l /dev/mapper/mpatha'
-
Certaines baies de stockage, tel que EMC CLARiiON, offrent une option pour activer un type de mode actif/actif appelé ALUA. Avec ALUA, les "path groups" sont établis avec des priorités différentes. Les logiciels multipath comme device-mapper-multipath reconnaîtront ces path groups et vont envoyer l'I/O vers les chemins avec une priorité supérieure, mais si l'I/O ne finissent par aller vers un chemin passif, il peuvent ne pas générer une erreur d'I/O. Si votre unité prend en charge ce mode, cela pourrait éviter ces erreurs d'I/O. Cette méthode d'accès différente nécessite généralement une modification de configuration dans multipath.
Note: Les erreurs d'I/O causées par un accès involontaire à des chemins passifs ne sont pas dangereux et ne devrais pas provoquer des problèmes sur un système. Ils peuvent être ignorés en toute sécurité.
Root Cause
-
Les baies de stockage dans un SAN sont généralement mises en place de manière redondante telle que les hôtes peuvent accéder à des unités logiques (LUN) sur l'un des nombreux chemins différents. Généralement, ces réseaux fonctionnent dans l'un des deux modes différents: actif/actif ou actif/passif. Avec un réseau actif/actif, l'I/O peut être envoyé vers n'importe quel chemin d'un LUN et elle sera traitée par ce contrôleur. Avec les baies actives/passives, un contrôleur est considéré comme le principal pour chaque LUN, tandis que l'autre contrôleur est en attente et agit comme plan de secours. Certaines baies vont accepter l'I/O pour un LUN sur le contrôleur de secours(passif), mais cela ne sera pas optimisé (pires performances). Cependant, d'autres baies actives/passives n'accepteront pas d'I/O sur le contrôleur de secours pour un LUN, et donc toutes les commandes qui lui sont adressées se traduiront par une erreur d'I/O.
-
Dans RHEL , il ya un certain nombre de commandes et utilitaires qui peuvent envoyer des I/O à différents périphériques, tels que LVM , udev , fdisk , etc , sans parler des applications telles que les bases de données , serveurs Web , etc.Si l'un d'entre eux devait émettre des I/O à un chemin passif sur une baie qui ne l'accepte pas , cela provoquerait une erreur d'I/O dans les journaux .Les messages sont inoffensifs et n'indiquent pas un problème , mais ils peuvent remplir les journaux ou devenir préoccupantes de façon injustifiée .Par conséquent , certains voudront peut-être essayer d'éviter ces erreurs en empêchant les applications d'accéder aux chemins passifs . En règle générale, le filtrage à partir de LVM fera disparaitre la majorité de ces erreurs.Aussi pour réduire le nombre d'erreurs, éviter les commandes comme 'fdisk-l' qui scannent tous les périphériques. Enfin , la configuration des applications qui scannent ou accède de multiples périphériques afin qu'il accède seulement le chemin actif approprié ou le périphérique multipath logique (/dev/mapper/mpath*, /dev/emcpower*, /dev/sddlma*, etc) peut réduire le nombre d'erreurs.
Diagnostic Steps
Avec les baies actives/passives, il est important de pouvoir faire la distinction entre les erreurs passive-path I/O et celles qui se produisent sur les chemins actifs et indiquent un problème réel. Les étapes suivantes peuvent aider à diagnostiquer si une erreur d'I/O est causée par un chemin passif:
* Déterminez si votre baie est actif/passif, et si oui, si l'I/O sur un chemin passif va générer des erreurs. Cela peut être trouvée dans la documentation du fournisseur, ou peut être déterminée en accédant a un chemin passif en bon état et de voir si elle génère des erreurs d'I/O. Par exemple:
# fdisk -l /dev/sdb
- Déterminer quels chemins pour un LUN sont passifs.
- Si vous utilisez device-mapper-multipath, vous pouvez regarder la sortie de 'multipath -ll [map name]' et regarder quels sont les périphériques contenus dans le path group passif (celui avec le score prio le plus bas):
# multipath -ll mydevicemydevice (16046017086137300787192b56e2fde11) dm-4 DGC,RAID 5
[size=266G][features=1 queue_if_no_path][hwhandler=1 emc][rw]
\_ round-robin 0 [prio=2][active]
\_ 3:0:1:0 sdc 8:32 [active][ready]
\_ 4:0:1:0 sde 8:64 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 3:0:0:0 sdb 8:16 [active][ready]
\_ 4:0:0:0 sdd 8:48 [active][ready]
Dans cet exemple, les périphériques /dev/sdb et /dev/sdd d'un CLARiiON EMC (DGC RAID 5) sont dans le path group passif (désigné par le score de prio inférieur de 0), et donc les erreurs I/O qui pointent vers ces périphériques peut être ignoré en toute sécurité.
- Si vous utilisez EMC PowerPath, vous pouvez regarder la sortie de 'powermt display dev=all' et voir quels périphériques ont une interface de stockage (Stor Interf.) différente de l'actuel 'owner'.
Pseudo name=emcpowera
CLARiiON ID=99-0000-000 [~physical]
Logical device ID=600601F0D057000018FC7845F46FE011 [LUN 0]
state=alive; policy=BasicFailover; priority=0; queued-IOs=0;
Owner: default=SP B, current=SP B Array failover mode: 1
==============================================================================
--------------- Host --------------- - Stor - -- I/O Path -- -- Stats ---
### HW Path I/O Paths Interf. Mode State Q-IOs Errors
==============================================================================
12 qla2xxx sdd SP-A active alive 0 0
11 qla2xxx sdj SP-B active alive 0 0
10 qla2xxx sdg SP-A active alive 0 0
13 qla2xxx sdk SP-B active alive 0 0`
Dans cet exemple, le owner actuel est SP-B, et /dev/sdd et /dev/sdg appartiennent à SP-A. Ainsi, ils sont les chemins passifs.
- Pour les autres logiciels de type multipath, consultez la documentation du fournisseur sur la façon de déterminer quels chemins sont passifs.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments