Comment lire l'état multipath sur un hôte Linux

Si votre serveur garde ses données sur un SAN, le rapport de santé le plus important sur la machine vient d'une commande que la plupart des gens ne lancent jamais. multipath -ll vous dit combien de routes mènent à votre disque, lesquelles la baie préfère, et si l'hôte survivrait à la perte de l'une d'elles. Voici comment le lire, et quoi changer quand il n'a pas l'air correct.

Une redondance que vous ne pouvez pas voir n'est pas une redondance

Quand un chemin meurt en silence, personne ne le remarque. L'hôte continue de tourner avec ce qui reste, et le premier signe de problème est le jour où le second chemin s'en va et où le volume disparaît sous une base de données. Un serveur livré avec le périphérique multipath monté et jamais regardé depuis n'a de redondance que sur le papier. Le contrôle prend trente secondes et doit faire partie de chaque build, de chaque maintenance et de chaque revue d'incident.

Lire la sortie, ligne par ligne

Un exemple générique d'un hôte avec deux ports HBA et deux ports de baie zonés par fabric :

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

La première ligne donne le nom convivial, le WWID et les chaînes vendor et product. Le WWID est l'identité du volume telle que la baie la rapporte. Si vous devez un jour prouver quel volume de la baie est quel périphérique Linux, comparez cette chaîne avec la liste des volumes de la baie elle-même, jamais avec une lettre de périphérique, parce que les lettres de périphérique changent d'un démarrage à l'autre.

La deuxième ligne contient les réglages qui décident du comportement en cas de panne. queue_if_no_path signifie que si tous les chemins sont perdus, les I/O attendent au lieu d'échouer. hwhandler='1 alua' signifie que la baie parle ALUA, la façon standard pour une baie de dire à l'hôte quels ports sont préférés.

La ligne du groupe de chemins montre la politique de sélection et la priorité. Une baie actif/actif symétrique comme celle ci-dessus place chaque chemin dans un seul groupe à priorité égale. Une baie asymétrique montre deux groupes : un groupe de priorité supérieure de chemins optimisés marqués active, et un groupe de priorité inférieure marqué enabled qui ne transporte des I/O que si le premier groupe échoue. Les deux dispositions sont saines. Ce qui compte, c'est que la disposition corresponde à ce que le constructeur de votre baie documente pour votre type d'hôte.

Chaque ligne de chemin se lit host:channel:target:lun, puis le périphérique, puis trois états. Le premier nombre est l'hôte SCSI, ce qui sur un serveur Fibre Channel signifie le port HBA. Chaque volume doit montrer des chemins par les deux numéros de port HBA. Si tous les chemins d'un volume partagent le même numéro d'hôte, ce volume n'est joignable que par un seul fabric, quoi qu'en dise le schéma de câblage. Les trois états sont l'état device-mapper (active ou failed), le résultat du path checker (ready, faulty, ghost) et la vue du noyau sur le périphérique (running ou offline).

Un hôte sain, sous forme de checklist

• Chaque volume montre le même nombre de chemins, et ce nombre est égal aux ports HBA multipliés par les ports de baie zonés par fabric.
• Chaque volume a des chemins par les deux numéros d'hôte HBA.
• Aucun chemin n'est failed, faulty, offline ou shaky.
• La chaîne vendor, le hardware handler et les priorités correspondent au guide hôte du constructeur de la baie, et l'hôte est enregistré sur la baie avec le host persona ou le type d'hôte correspondant.
• Le comportement quand tous les chemins sont perdus (no_path_retry) a été choisi délibérément, pas hérité.
• LVM n'utilise que les périphériques multipath, jamais les chemins sd sous-jacents.

Ces commandes vous donnent toute l'image :

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

Pour compter les chemins vivants par volume d'un coup :

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

Lancez-le après chaque changement de zoning, chaque changement sur la baie et chaque redémarrage. Un compte qui diffère entre volumes vaut d'être poursuivi aujourd'hui.

Les réglages qui comptent le plus

La plupart des distributions livrent une table intégrée raisonnable de valeurs par défaut par baie, mais le guide hôte du constructeur de la baie fait autorité. Une section device typique ressemble à ceci :

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
    }
}

La seule valeur qui mérite votre propre réflexion est no_path_retry. Mettre en file pendant un moment permet à un hôte de traverser un failover de contrôleur ou un redémarrage de fabric sans qu'une erreur d'I/O atteigne l'application. Mettre en file pour toujours peut figer un hôte de base de données d'une façon plus difficile à récupérer qu'une panne franche. Choisissez un nombre de tentatives qui couvre le temps de failover documenté de votre baie avec de la marge, notez pourquoi, et appliquez-le à chaque hôte de ce type.

L'autre problème classique est LVM qui scanne les chemins bruts et se plaint de volumes physiques en double. Sur les systèmes actuels, la liste de périphériques (lvmdevices) ou un filtre dans lvm.conf qui n'accepte que les périphériques /dev/mapper règle la question. Les avertissements de PV en double ne sont pas cosmétiques : ils signifient que LVM peut ouvrir un seul chemin au lieu du périphérique multipath, et il n'est alors plus protégé.

Prouvez le failover avant d'en avoir besoin

Un chemin qui n'a jamais basculé est une théorie. Avant qu'un hôte porte la production, retirez un chemin et observez :

# 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

La lecture dans le premier terminal doit continuer sans s'interrompre plus d'un instant. Quand le chemin revient, multipathd show paths doit le ramener à active ready. Puis faites le test plus large qui compte : désactivez le port de l'hôte sur un fabric au niveau du switch, confirmez que le volume tourne sur l'autre fabric seul, rétablissez-le, confirmez que chaque chemin revient, et répétez pour le second fabric. Si une étape vous surprend, vous avez trouvé le problème un après-midi calme plutôt que pendant une panne.

Comment nous le faisons

Sur notre plateforme, chaque hôte raccordé au SAN, hyperviseur ou serveur dédié, reçoit un port HBA dans chacun de deux fabrics Fibre Channel indépendants et est enregistré sur nos baies HPE 3PAR all-flash avec le persona qui fait se comporter ALUA exactement comme son système d'exploitation l'attend. Quand nous déplaçons un volume en marche entre baies, l'hôte rescanne, voit ses nouveaux chemins et continue, et le nombre de chemins est la preuve que le déplacement est terminé.

Si votre sortie multipath ne ressemble pas à l'exemple sain ci-dessus, ou si vous n'êtes pas sûr de ce à quoi la vôtre devrait ressembler, nous serons heureux de la lire avec vous.

cta: Parler à un ingénieur

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/