Le multipathing, ou comment un hôte parle à une baie par plusieurs chemins à la fois

Un LUN présenté à un hôte, c'est bien. Encore faut-il que le chemin entre les deux ne dépende pas d'un seul câble, d'un seul port ou d'un seul contrôleur. Le multipathing, c'est cette couche qu'on configure une fois et qu'on oublie ensuite, jusqu'au jour où elle est mal réglée.

Un hôte qui accède à un LUN ne le fait jamais par un chemin unique, du moins pas dans une architecture bien conçue. Entre le serveur et la baie, on trouve en général plusieurs cartes HBA ou plusieurs interfaces réseau côté hôte, plusieurs switches, et plusieurs ports côté baie. Chacune de ces combinaisons forme un chemin distinct vers le même LUN. Le multipathing, c'est la couche logicielle qui gère cette pluralité de chemins : elle assure la bascule automatique si l'un d'eux tombe, et peut répartir la charge entre ceux qui restent disponibles.

Le principe paraît simple, mais deux questions viennent immédiatement le compliquer. Combien de chemins sont réellement utilisables en même temps, et parmi ceux-ci, lesquels offrent la meilleure performance.

Tous les chemins ne se valent pas

Sur une baie active-active pure, chaque contrôleur peut servir un LUN avec la même performance, et le multipathing n'a qu'à répartir la charge. Mais sur la plupart des baies modernes, y compris PowerStore, ce n'est pas tout à fait le cas.

PowerStore fonctionne selon un modèle où chaque volume a une affinité de nœud. Concrètement, quand un LUN est mappé à un hôte, la baie choisit l'un des deux nœuds de l'appliance comme chemin optimal, pour équilibrer la charge entre les nœuds à l'échelle de l'appliance. Les chemins qui passent par ce nœud sont dits actifs-optimisés, tandis que ceux qui passent par l'autre nœud restent utilisables mais avec une pénalité de performance, car ils impliquent un aller-retour supplémentaire entre les deux contrôleurs. Cette distinction porte un nom standardisé : Asymmetric Logical Unit Access, ou ALUA, pour les LUN accédés en SCSI, et son équivalent en NVMe, Asymmetric Namespace Access, ou ANA, pour les LUN accédés en NVMe/TCP.

Un multipathing correctement configuré sait faire la différence entre ces deux catégories de chemins. Il privilégie systématiquement les chemins actifs-optimisés, et ne bascule vers les chemins actifs-non-optimisés qu'en dernier recours, lorsque plus aucun chemin optimal n'est disponible. C'est un point sur lequel il vaut la peine d'insister, parce que l'erreur inverse est fréquente et rarement diagnostiquée immédiatement : configurer le multipathing en mode actif-actif pur, en répartissant la charge indifféremment sur tous les chemins, y compris ceux qui traversent l'autre nœud.

Sur PowerStore en particulier, cette erreur a un effet direct sur la performance. La baie protège la cohérence des données par un mécanisme de verrouillage par plage de blocs logiques, qui garantit qu'un seul nœud accède à une même zone à un instant donné. Si le multipathing envoie des écritures sur les deux nœuds indifféremment pour un même volume, il multiplie les prises et libérations de verrous entre les deux contrôleurs, ce qui dégrade la performance au lieu de l'améliorer. Le mode recommandé côté hôte est donc ALUA, et non actif-actif, précisément pour laisser le multipathing respecter la hiérarchie des chemins que la baie a définie.

ALUA et ANA, un même principe pour deux mondes

ALUA existe depuis longtemps dans le monde SCSI, porté par le protocole Fibre Channel et iSCSI. ANA reprend la même logique pour le monde NVMe, avec les mêmes états de chemin : optimal et non-optimal. La différence tient surtout à l'endroit où vit l'intelligence. Avec ALUA, une bonne partie de la configuration se fait historiquement côté hôte, dans les paramètres du multipathing. Avec ANA, la charge repose presque entièrement côté baie, qui expose directement l'état de chaque chemin à l'initiateur, laissant beaucoup moins de réglages fins à faire côté hôte.

Ce glissement n'est pas anodin pour les environnements NVMe/TCP, de plus en plus courants sur les déploiements PowerStore récents. Les politiques de sélection de chemin qui existaient en SCSI, comme le tour de rôle pondéré ou le chemin le plus récemment utilisé, n'ont pas toutes leur équivalent en NVMe. Sur la plupart des piles NVMe natives, seules des politiques simples comme le round-robin ou le failover pur sont supportées, ce qui change les habitudes de configuration pour qui vient d'un environnement historiquement SCSI.

Ce que ça donne concrètement, côté vSphere

Sur un hôte ESXi, le protocole de stockage détermine quel plug-in de multipathing prend en charge les volumes PowerStore. En SCSI, c'est le Native Multipathing Plug-in, ou NMP, qui s'en charge, via une claim rule qui associe PowerStore au module ALUA et à une politique de sélection de chemin en round-robin. Depuis vSphere 7.0, cette règle est présente nativement. Pour la vérifier :

esxcli storage nmp satp rule list

Le résultat attendu associe PowerStore à VMW_SATP_ALUA comme module SATP et à VMW_PSP_RR comme politique de sélection de chemin, avec l'option iops=1, ce qui signifie que l'hôte bascule de chemin actif toutes les I/O plutôt que toutes les 1000 I/O par défaut. Cette valeur agressive répartit mieux la charge entre les chemins actifs-optimisés d'un même nœud.

Si cette règle a disparu ou n'a jamais été créée, elle se recrée avec la commande suivante, exécutée en root, suivie d'un redémarrage de l'hôte :

esxcli storage nmp satp rule add -c tpgs_on -e "PowerStore" -M PowerStore -P VMW_PSP_RR -O iops=1 -s VMW_SATP_ALUA -t vendor -V DellEMC

Dell recommande ce réglage en round-robin avec iops=1 par défaut, mais admet aussi une variante en latence, équivalente au mode LB-Latency utilisé côté NVMe-oF avec le High Performance Plug-in. Cette variante a du sens sur des réseaux sujets à une congestion intermittente sur certains chemins, où la latence observée devient un meilleur indicateur que le simple comptage d'I/O.

Ce que ça donne concrètement, côté Hyper-V

Sur Windows Server, MPIO n'est pas installé par défaut. Il faut ajouter la fonctionnalité, par exemple via PowerShell :

powershell

Install-WindowsFeature -Name Multipath-IO

Une fois la fonctionnalité en place, PowerStore est pleinement pris en charge par le module DSM natif de Microsoft, sans nécessiter de composant tiers. C'est la bonne pratique recommandée par Dell ; PowerPath reste réservé aux cas où un contrôle plus fin sur le comportement du multipathing est nécessaire.

Par défaut, un hôte Windows Server ou Hyper-V face à PowerStore adopte la politique Round Robin with Subset, adaptée à la grande majorité des environnements Hyper-V sans intervention supplémentaire. Une fois un volume PowerStore mappé, il se configure pour MPIO via la gestion des disques ou le module MPIO natif, et cette étape doit être répétée pour chaque transport si l'hôte combine Fibre Channel et iSCSI.

Côté dimensionnement, la recommandation Dell reste la même que pour vSphere dans son principe : deux à quatre chemins front-end par nœud vers le fabric de stockage, soit quatre à huit chemins au total, sans dépasser quatre chemins front-end par nœud vers un même fabric, au risque de dégrader la performance plutôt que de l'améliorer. Et comme pour toute couche de multipathing, mieux vaut laisser les timeouts registre à leur valeur par défaut, sauf indication explicite de la documentation PowerStore ou du support Dell.

Ce que le multipathing apporte, au-delà de la panne

Le premier réflexe est de voir le multipathing comme une protection contre la panne d'un chemin, ce qui est vrai mais incomplet. Il apporte trois choses distinctes.

La tolérance de panne, d'abord : la perte d'un câble, d'un port HBA, d'un switch ou d'un nœud de contrôleur ne doit jamais se traduire par une perte d'accès au LUN, tant qu'un chemin sain reste disponible.

La répartition de charge, ensuite, mais seulement entre chemins de même niveau, comme on l'a vu plus haut. Répartir la charge entre un chemin optimal et un chemin non-optimal n'a rien d'une optimisation.

La cohérence de nommage, enfin, un aspect souvent sous-estimé. Sur un hôte qui voit un même LUN à travers quatre, six ou huit chemins physiques différents, le multipathing présente un seul et même périphérique logique au système d'exploitation, avec un nom persistant. Sans cette couche, chaque chemin physique apparaîtrait comme un disque distinct, rendant impossible toute gestion cohérente au niveau applicatif ou du cluster.

Ce qu'il faut retenir en configuration

Sur un déploiement PowerStore, la bonne pratique consiste à prévoir au moins deux chemins par nœud pour chaque hôte, soit un minimum de quatre chemins par appliance en environnement Ethernet, avec au moins deux switches pour éviter qu'une panne réseau unique ne coupe l'ensemble des chemins d'un coup. Le multipathing côté hôte doit être configuré pour respecter l'état des chemins renvoyé par la baie, ALUA en SCSI et ANA en NVMe, et non forcé en actif-actif indifférencié. Et un hôte ne devrait jamais accéder au même LUN via deux protocoles différents en parallèle, par exemple à la fois en iSCSI et en NVMe/TCP, ce qui introduirait une source de confusion pour la gestion des chemins sans aucun bénéfice réel.

Le multipathing reste une de ces briques qu'on configure une fois au déploiement, et qu'on ne revisite plus jamais, jusqu'au jour où une baisse de performance inexpliquée ramène tout le monde à la case départ : vérifier, chemin par chemin, ce que l'hôte croit vraiment savoir de la topologie qui le relie à son stockage.