lpfc + multipath + ubuntu - le chemin continue de changer

Votre configuration semble bizarre ; normalement, vous devriez avoir 4 chemins vers le même périphérique (c'est-à-dire 4 périphériques /dev/sdX par périphérique multipath). Le contrôleur de tableau est généralement capable d'informer l'hôte de la priorité de chaque chemin, de sorte que vous avez 2 chemins avec une priorité élevée et 2 avec une priorité inférieure. Ensuite, dm-multipath multiplexe les entrées-sorties sur les 2 chemins à haute priorité (l'option "selector" avec la valeur par défaut rr_min_io=100). Maintenant, vous avez 2 groupes de chemins ayant tous deux la même priorité, donc peut-être que dm-multipath répartit l'IO sur les deux, ce qui n'est peut-être pas ce que votre administrateur SAN veut que vous fassiez. Une autre chose étrange est que les périphériques sont marqués avec "undef" plutôt que "ready". Enfin, la numérotation de vos chemins d'accès semble étrange (tout suit le même chemin ?). Êtes-vous vraiment sûr que tout est correctement câblé, que le zonage est correct, etc.

Une sortie typique de "multipath -ll" devrait ressembler à ceci

sanarch3 (3600508b4000683de0000c00000a20000) dm-6 HP,HSV200
\[size=2.0T\]\[features=1 queue\_if\_no\_path\]\[hwhandler=0\]\[rw\]
\\\_ round-robin 0 \[prio=100\]\[active\]
 \\\_ 0:0:0:5 sdc 8:32  \[active\]\[ready\]
 \\\_ 1:0:0:5 sdk 8:160 \[active\]\[ready\]
\\\_ round-robin 0 \[prio=20\]\[enabled\]
 \\\_ 0:0:1:5 sdg 8:96  \[active\]\[ready\]
 \\\_ 1:0:1:5 sdo 8:224 \[active\]\[ready\]

Vous y voyez 4 chemins regroupés en 2 groupes de priorité, et les entrées-sorties sont effectuées sur les périphériques sdc et sdk tandis que sdg et sdo sont inactifs et utilisés uniquement en cas de panne.

EDITAR La raison pour laquelle vous devriez voir 4 chemins est que vous avez 2 ports HBA et que la matrice a 2 contrôleurs redondants. Ensuite, vous avez 2 réseaux redondants avec une couche de commutation finale fournissant des connexions inter-réseaux. Ainsi, les deux HBA voient les deux contrôleurs, d'où 4 chemins pour chaque LUN. Vous pouvez voir cela dans mon exemple ci-dessus pour la numérotation SCSI ID, qui va comme [host controller ID] :[channel ID] :[target controller ID] :[LUN ID]. Ce que vous pouvez voir ci-dessus, c'est que les chemins actifs sont tous deux sur le contrôleur n°0, puisque dans ce cas, le contrôleur n°0 est le "propriétaire" du LUN ; l'IO est possible via l'autre contrôleur, mais avec une pénalité de performance puisque l'autre contrôleur (selon l'implémentation du contrôleur) doit transmettre l'IO au contrôleur propriétaire. Le contrôleur signale donc que les chemins qui vont vers le contrôleur n°0 ont une priorité plus élevée.

Donc, d'après votre question, on voit qu'il n'y a pas du tout de chemin vers l'autre contrôleur. Et, dans le cas où vous n'avez pas de contrôleurs et de réseaux redondants, pourquoi s'embêter avec le multipath en premier lieu ?

Les SAN IBM ont généralement des exemples de multipath.conf bien définis dans leurs documentations, n'avez-vous pas commencé par là ? Je vais laisser cette partie comme un exercice pour le lecteur . De plus, l'administrateur de votre SAN vous doit un peu plus de soutien. Quelques points rapides

• Les oscillations de trajectoire comme celles que vous avez décrites sont généralement dues à une mauvaise configuration du path checker, dans vos deux itérations, vous êtes passé de lire le secteur0 a aucun qui prend probablement le chemin multiple par défaut pour cette marque et ce modèle. tur (unité de test prête).

• Pas de contrôleur de priorité défini, pas de contrôleur de priorité, pas de priorités.

• Un gestionnaire de matériel est probablement nécessaire, qui est bien défini dans la documentation.

La meilleure histoire de guerre IBM 1815 que j'ai trouvée était ceci , résumé :

• Installer le pilote rdac, modprobe scsi_dh_rdac et l'ajouter à votre initrd
• Utilisez le fichier multipath.conf suivant :

blacklist {
    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^hd[a-z]"
    devnode "^sda"
    device {
        vendor "Maxtor*"
        product "OneTouch*"
    }
}
blacklist_exceptions {
    device {
            vendor  "IBM"
            product "1815*"
    }
}
defaults {
    failback                immediate
    no_path_retry           queue
    user_friendly_names     no
    path_grouping_policy    failover
}
devices {
    device {
            vendor                  "IBM"
            product                 "1815*"
            failback                manual
            hardware_handler        "1 rdac"
            path_checker            rdac
            prio_callout            "/sbin/mpath_prio_rdac /dev/%n"
    }
}

Faites-nous savoir comment ça se passe. Bonne chance !

Tout d'abord, vous définissez le multibus, êtes-vous sûr que votre stockage le supporte ? Demandez à votre administrateur SAN si votre stockage est réellement actif/actif, un stockage actif passif ne permet pas de changer de contrôleur tout le temps, cela a un coût pour le stockage et vous posera des problèmes du côté client également. Dans la première configuration, ce n'était pas défini dans la configuration, ce qui signifie que vous prenez la configuration par défaut définie dans multipath (vérifiez /usr/share/doc/mulitpath.conf.anotted) ou regardez la sortie de multipathd -k show config pour avoir une meilleure vue (de toute façon, il faut revoir la configuration par défaut avec vos spécifications de stockage, car elles ne sont pas toujours les meilleures : j'ai eu quelques problèmes avec HDS et rhel).

La deuxième chose, vous avez dit qu'il n'y avait pas de problème d'intégrité sur le FS, êtes-vous sûr que votre FS utilise le périphérique multipathed ??? Si je suppose que vous utilisez LVM, avez-vous vérifié les paramètres de filtrage dans lvm.conf ? Si ce n'est pas bien configuré, lvm utilisera le périphérique en direct au lieu d'utiliser MPIO, cela peut être encore plus un problème avec le stockage actif/passif, puisque lvm forcera l'utilisation d'un contrôleur qui peut ne pas être celui préféré..... J'espère que cela vous aidera Regard