Présentation

Préambule

Le « Multipath » est comme son nom l’indique, une des solutions apportées par Linux pour gérer l’accès à une ressource via des chemins multiples. Les ressources concernées par le multipath l’accès à des volumes de stockage distants.

Redondance matérielle

Lorsqu’un environnement est un minimum sécurisé, celui-ci bénéficie de redondance matérielle minimum, celle-ci var du serveur et des différences pièces critiques et fragiles qui le compose, pour le moins :

• Alimentations redondantes
• Disques locaux en RAID (1 ou 5 minimum)
• Cartes réseaux doublées (au moins)

Note) Lorsqu’un composant est trop cher à redonder sur un serveur, on choisit plustot alors de redonder le serveur tout entier pour pallier à une panne matérielle, doubler le matériel coute souvent moins cher que d’acheter du matériel compatible avec une redondance (les contrôleurs de stockage par exemple, ou les cartes mères)

La plupart du temps, l’OS et les ressources systèmes sont disposées sur du stockage local protégé par une configuration RAID, tandis que les données applicatives sont elles disposées sur des baies de stockage disposant par défaut de tout l’environnement qu’il faut en terme de redondance (doubles contrôleurs de stockage, etc).

Note) On peut parfois opter également pour des OS et des ressources systèmes disposées sur du stockage distant, mais cela fait l’objet de techniques particulières (« BOOT ON SAN« ) qui ne font pas l’objet de cet article.

Même s’il parait inutile de le préciser, les chemins physiques d’un réseau doivent être également doublés (d’où le minimum de deux contrôleurs Ethernet physiques sur le serveur) afin de pallier à la perte d’un port physique sur une carte Ethernet ou d’une NIC toute entière, voire d’une coupure d’un câble réseau entre le stockage distant (la baie) et le serveur.

Redondance logicielle

Les ressources systèmes devront prendre en compte la redondance Ethernet avec la technique du Bonding (création d’un Port Ethernet logique basé sur plusieurs ports Ethernet physiques qui ne fait pas l’objet de cet article) pour le réseau applicatif et pour le réseau de stockage et du Multipath (création d’un périphérique de stockage Virtuel basé sur plusieurs périphériques de stockages physiques) pour le réseau de stockage.

Nous partirons du principe pour le reste de cet article que notre serveur dispose de deux réseaux Ethernet, un dédié au stockage, que nous nommerons SAN (Storage Area Network), et l’autre dédié au transport des applicatives données de production, que nous nommerons LAN (Local Area Network).

LUN : De la baie de stockage au Serveur

Préambule

Le protocole de stockage utilisé dans cet exemple et dans cet article est iSCSI, mais tout le raisonnement est valable avec un autre protocole sur un SAN.

Problématique

Présentation d’une LUN par la baie de stockage

L’opération consiste en la création d’un volume de stockage sur notre Baie de disque puis en la présentation de ce volume à notre serveur par l’intermédiaire des réseaux de stockages redondants. Ce volume aura un numéro unique LUN0 provenant de cette baie de stockage (LUN / Logical Unit Number), et sera présenté dans à notre serveur en utilisant le protocole iSCSI encapsulé dans TCP/IP.

Comme nous l’évoquions plus haut, ce réseau de stockage est matériellement sécurisé et utilise deux chemins physiques. Contrairement à la baie de stockage, notre serveur dispose de deux ports Ethernets en Bonding disposés sur ces deux réseaux physiques, ne présentant au serveur qu’un seul réseau logique, un réseau de stockage, avec une seule adresse IP P0. La Baie de stockage généralement ne fait pas de Bonding, mais dispose d’une patte sur tous les chemins des réseaux de stockages, donc ici deux réseaux, deux contrôleurs, deux ports Ethernet, deux adresses IP P1 (chemin n°1) et P2 (chemin n°2).

Découverte d’une LUN par le serveur

Donc, une seule LUN (donc un seul volume au final) n’est présenté par la baie de stockage, hors, l’annonce du volume est possible via le chemin permettant d’accéder à IP1 ou par le chemin permettant d’accéder à IP2 : Le serveur voit deux façons d’accéder à un volume, il pense qu’il a donc à faire à deux volumes différents, même si au final, il s’agit du même volume, celui de la LUN LUN0 annoncée par la baie de stockage.

Pour aller chercher ses volumes, le client iSCSI du serveur lui, dispose d’une cible (TARGET) représentée par une adresse IP : Nous en avons ici deux, le client va demander à chacune de ces adresses si les baies de stockages qui sont en face ont un volume à lui mettre à disposition (à lui « présenter« ). C’est donc au client iSCSI présent sur le serveur que revient la gestion des accès à la LUN de la baie, par l’intermédiaire de IP1 ou de IP2, en fonction de ses besoins, de sa charge, de ses pannes matérielles potentielles, etc.

Etant donné que la baie répond sur IP1 positivement et sur IP2 également, via les deux chemins, le volume représenté par LUN0 est donc retourné par la baie, mais le serveur ne sait pas que ce volume est au final le même, et en voit deux différents, le volume 1 (par exemple /dev/sda) et le volume 2 (/dev/dbb).

Donc, si on écrit sur /dev/dda des données, ont peut les lire sur /deb/sdb, et inversement. Evidement, à un instant « t », une partition présente sur l’un des deux volumes ne peut être « montée » (au sens du filesystem de l’OS) que via l’un ou l’autre des deux volumes, pas les deux en même temps, sous réserve de casser le filesystem qui n’est pas prévu pour gérer deux accès simultané sur le même filesystem du même volume (car celui de la LUN LUN0 de la baie est bien un volume unique au final même s’il est accessible par deux chemins possibles et présente deux volumes potentiels à l’OS) simultanément.

C’est le MULTIPATH qui va nous apporter une solution en présentant à l’OS un volume « virtuel » qui point sur /dev/sda OU sur /dev/sdb et qui est capable, dynamiquement, d’emprunter un chemin plustot qu’un autre si celui-ci est inaccessible, sans aucune incidence sur l’OS et les applicatifs, permettant d’apporter la redondance cherchée à l’OS pour son stockage de données.

MULTIPATH

Préambule

Une fois connecté aux targets iSCSI de vos baies de stockage, celles-ci annoncent dans un premier temps l’ensemble des adresses IPs sur lesquelles elles sont joignables, et le pilote iSCSI se connecte alors sur chacune d’entre elle pour connaitre les volumes qui lui sont présentés.

La liste des volumes est alors présente dans la liste des périphériques de stockage au même titre qu’un volume sur un périphérique de stockage local :

root@serveur : ~ > ls /dev/sd*
sda   sdg   sdj

La différence entre les disques locaux SCSI et les volumes distants iSCSI peut se faire par la commande « lsblk » ou par « lsscsi » tel que :

root@serveur:~$ lsscsi 
[0:2:0:0]    disk    DELL     PERC H730P Mini  4.30  /dev/sda  
[17:0:0:2]   disk    HPE      MSA 2060 iSCSI   I210  /dev/sdg 
[18:0:0:2]   disk    HPE      MSA 2060 iSCSI   I210  /dev/sdj   

Dans notre cas, nous disposons d’un serveur DELL avec deux disques sur lequel volume RAID 1 est créé puis vu par l’OS en tant que /dev/sda. Les autres périphériques étant des disques découverts sur une baie de stockage distante de type MSA (HPE) accédée en iSCSI. Celle-ci ci dispose de 2 IPs sur le réseau de stockage, on voit donc que le serveur à bien « découvert » la même LUN annoncée par 2 chemins différents et voit donc au final 2 volumes OS, qui pointent tous vers l’unique volume coté baie de disques bien sur, /dev/sdg et /dev/sdj.

Les disques /dev/sdg et /dev/sdj sont donc des volumes découverts sur notre baie de disques, par deux chemins différents dans notre exemple (il y aurait pu en avoir plus), nous avons donc.

Il appartiendra au démon MULTIPATH de fabriquer un périphérique virtuel (DEVICE MAPPER) pointant sur ces deux volumes.

Installation

Pour installer le démon Multipath, tapez :

root@serveur:~$ apt -y install "*multipath*"
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances... Fait
Lecture des informations d'état... Fait      
Les NOUVEAUX paquets suivants seront installés :
  kpartx-boot multipath-tools-boot multipath-tools
...
...

Et voilà, c’est fait, il faut dire que c’était délicat et complexe …

N’oublions pas de le mettre en démarrage auto et de le démarrer :

root@serveur:~$ systemctl enable multipathd
root@serveur:~$ systemctl start multipathd
root@serveur:~$ systemctl status multipathd
● multipathd.service - Device-Mapper Multipath Device Controller
     Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled; preset: enabled)
     Active: active (running) since Thu 2024-11-14 16:06:12 CET; 13min ago
TriggeredBy: ● multipathd.socket
   Main PID: 486 (multipathd)
     Status: "up"
      Tasks: 7
     Memory: 21.8M (peak: 22.1M)
        CPU: 120ms
     CGroup: /system.slice/multipathd.service
             └─486 /sbin/multipathd -d -s
nov. 14 16:06:12 TEMPLATE-UBUNTU-24-04 multipathd[486]: multipathd v0.9.4: start up
nov. 14 16:06:12 TEMPLATE-UBUNTU-24-04 multipathd[486]: reconfigure: setting up paths and maps

Configuration

Par défaut il n’y a pas grand chose à configurer pour une utilisation standard de multipah, généralement cela se limité au maximum à

• Prérequis d’une baie de stockage
• Liste de périphériques à exclure de la gestion du multipath (blackList)

Prérequis d’une baie de stockage

Multipath connait déjà la plupart des comportements à avoir en fonction de votre baie de stockage, cependant si celle-ci sort vraiment de la norme, ou que des prérequis sont considérés comme fondamentaux, vous devez modifier la configuration pour cela et ajouter une section « device » dans le fichier « /etc/multipah.conf« .

Par exemple pour notre exemple , une HPE MSA 2040 voici le contenu de /etc/multipath.conf :

devices {
        device {
        vendor "HP"
        product "MSA 2040 SAN"
        path_grouping_policy group_by_prio
        getuid_callout "/lib/udev/scsi_id --whitelisted --device=/dev/%n"
        prio alua
        path_selector "round-robin 0"
        path_checker tur
        hardware_handler "0"
        failback immediate
        rr_weight uniform
        rr_min_io_rq 1
        no_path_retry 18
        }
}

Exclusion de périphériques (blacklist)

Parfois il se peut que l’on doive masquer certains périphériques au démon multipath pour éviter un problème de configuration ou pour éviter de voire polluer visuellement une liste de périphérique dont on ne se servira jamais.

C’est encore dans le fichier « /etc/multipah.conf » que nous allons ajouter les exclusions de périphériques de plusieurs façons telles que:

blacklist {

       # exclusion des disques locaux
       devnode "/dev/sda"

       # exclusion des volumes particuliers via wildcard (ici contenant le mot NETAPP par exemple)
       devnode "*NETAPP*"

       # exclusion d'un LUN d'ID particulier (WWID=ID Unique International de périphérique)
       wwid 26122433f02466761

       # etc ...
}

Pour plus d’informations: consulter la documentation RedHat à ce sujet.

Utilisation

Liste des périphériques DeviceMapper

Lister les Device Mappers créés dynamiquement par le démon multipath lorsque celui-ci a constaté que plusieurs volumes présentés à l’OS présentent les même signatures uniques (WWID) :

root@serveur:~$ multipathd -k
multipathd> show topology
mpathb (3600c0ff000f76fa72707296701000000) dm-6 HPE,MSA 2040 iSCSI
size=9.1T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=enabled
| `- 18:0:0:2 sdj 8:144 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 17:0:0:2 sdg 8:96  active ready running

Dans cet exemple, nous constatons que les volumes physiques « /dev/sdg » et « /dev/sdj » découverts par l’OS ont fait l’objet d’une reconnaissance par le démon multipath de volumes identiques et un périphérique virtuel nommé (DM / DeviceMapper) « mpathb » a été nommé pour pointer dessus.

Le chemin d’accès complet au device mapper est : « /dev/mapper/mpathb« 

Dorénavant c’est toujours le périphérique « mpathb » qu’il faudra utiliser dans les configurations OS, et jamais sdg ou sdj : En cas de panne (perte d’un port Ethernet, d’un chemin réseau, etc), le DM saura toujours pointer par un chemin valide sur le périphérique et l’OS ne sera pas gêné.

Partitionnement et Formatage

Si vous avez bien compris le concept, les manipulations ne doivent plus s’effectuer au niveau des périphériques de type disques reconnus par l’OS mais bien sur les Device Mapper créés par le démon multipah, à savoir la création et le formatage des partitions par exemple :

root@serveur:~$ parted /dev/mapper/mpathb mkpart p1 ext4 5MiB 100%
Information: You may need to update /etc/fstab.
root@serveur:~$ mkfs.ext4 /dev/mapper/mpathb1
mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 1309184 4k blocks and 327680 inodes
Filesystem UUID: 03f2abec-2bb5-4fb5-9b92-78c3868aeffe
Superblock backups stored on blocks: 
...
Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 
root@serveur:~$ mount /dev/mapper/mpathb /mnt
root@serveur:~$ 

Ne pas oublier de renseigner la fstab comme dans un cas classique bien évidement …