iSCSI sous Linux : exposer du bloc avec LIO et targetcli

Un cluster Proxmox réclame un datastore partagé entre trois hyperviseurs, ou une base réclame un volume que deux nœuds montent à tour de rôle. Avec NFS, on partage des fichiers. Le client voit une arborescence, pose ses verrous applicatifs, et le serveur arbitre. Avec iSCSI, on partage un disque brut. Le client reçoit un périphérique bloc, le partitionne, y pose le système de fichiers de son choix, et il croit avoir une grappe locale. La différence de niveau change tout : qui formate, qui verrouille, qui gère la cohérence.

Côté Linux, la cible iSCSI ne demande aucun appliance propriétaire. Elle est dans le noyau depuis 2011.

NFS expose un système de fichiers. Le serveur garde la main sur l'arborescence, les permissions, les snapshots ZFS sous-jacents. Plusieurs clients lisent et écrivent les mêmes fichiers en même temps, et le protocole gère le partage. C'est le bon outil pour des home directories, un dépôt de médias, des backups.

iSCSI travaille un cran plus bas. Le serveur (la cible, ou target) publie un LUN : un numéro de volume logique qui, vu du client, est un disque SCSI ordinaire transporté sur TCP. Le client (l'initiateur) fait son discovery, se connecte, et voit apparaître un /dev/sdX. À partir de là, c'est son disque. Il le formate en ext4, en XFS, il y crée un PV LVM, il en fait un datastore Proxmox. Le serveur ne sait rien du contenu : il sert des blocs, point.

Le piège classique : ce disque est brut, donc deux initiateurs qui montent le même LUN en lecture-écriture sans système de fichiers cluster-aware le corrompent en quelques secondes. Un ext4 n'est pas fait pour deux écrivains simultanés. Le bloc partagé n'est sûr en accès concurrent qu'avec une couche par-dessus qui le sait : un système de fichiers cluster (GFS2, OCFS2), ou un orchestrateur qui garantit qu'un seul nœud monte le LUN à un instant donné (c'est le cas d'un datastore de VM où chaque machine possède son volume).

Pour le détail du compromis et des cas où l'appliance dédié garde du sens, on a déjà posé la comparaison dans le match NAS contre SAN. Ici on construit la cible, à la main, sur du Linux standard.

LIO (LinuxIO) est la cible SCSI de référence du noyau Linux. Son cœur, target_core_mod, a fusionné dans la branche principale avec le noyau 2.6.38, sorti le 14 mars 2011. Depuis, c'est le sous-système cible standard : pas de module tiers à compiler, pas de licence à acheter. Il pilote iSCSI, mais aussi Fibre Channel, FCoE, iSER ou SRP avec le bon fabric module.

La configuration vit dans configfs, montée sous /sys/kernel/config/target/. On pourrait écrire dans cette arborescence à la main, mais personne ne le fait. L'outil de pilotage, c'est targetcli : un shell hiérarchique qui ressemble à un système de fichiers, où chaque répertoire correspond à un objet de la cible. Sur Debian ou Ubuntu, apt install targetcli-fb ; sur RHEL ou Rocky, dnf install targetcli.

Une chose à retenir tout de suite : targetcli ne sauvegarde pas l'état au fil de l'eau. Tant qu'on n'a pas tapé saveconfig, la configuration ne survit pas au reboot. Elle est rejouée au démarrage par le service target (ou rtslib-fb-targetctl), qui relit /etc/rtslib-fb-target/saveconfig.json. Oublier le saveconfig, c'est perdre toute la conf au premier redémarrage.

Le modèle LIO empile quatre objets : un backstore (le stockage réel), une cible identifiée par son IQN, un LUN qui rattache le backstore à la cible, et un portail réseau qui dit sur quelle IP et quel port la cible écoute (3260 par défaut). On y ajoute des ACL pour filtrer les initiateurs autorisés.

Le backstore : fileio ou block

Deux types principaux. fileio sert un fichier régulier comme s'il était un disque : pratique, souple, on provisionne un fichier de la taille voulue sur n'importe quel système de fichiers. block (IBLOCK dans le noyau) expose directement un périphérique bloc déjà présent sous /sys/block : un disque physique, une partition, un volume LVM, une grappe mdadm. Pour de la production sérieuse, c'est block sur un volume LVM ou un device RAID qu'on veut, parce qu'on garde le contrôle de la couche stockage en dessous et on évite le double système de fichiers.

targetcli
# backstore sur un volume LVM existant
/> /backstores/block create name=lun0 dev=/dev/vg_data/lv_iscsi0
# ou un backstore sur fichier de 200 Gio
/> /backstores/fileio create name=lun0 file_or_dev=/srv/iscsi/lun0.img size=200G

Le choix block sur LVM se marie bien avec un thin pool et des snapshots côté serveur. On revient sur ce montage dans le guide LVM avancé, et sur la grappe sous-jacente dans la configuration mdadm en RAID logiciel.

La cible, le LUN, le portail

L'IQN (iSCSI Qualified Name) identifie la cible de façon unique. Format conventionnel : iqn.AAAA-MM.reverse-domaine:identifiant. La date est celle d'enregistrement du domaine, le reste sert au nommage interne.

# créer la cible
/> /iscsi create iqn.2026-07.fr.example.storage:datastore01
# rattacher le backstore en LUN 0
/> /iscsi/iqn.2026-07.fr.example.storage:datastore01/tpg1/luns create /backstores/block/lun0
# le portail s'autocrée sur 0.0.0.0:3260 ; on le restreint au réseau de stockage
/> /iscsi/iqn.2026-07.fr.example.storage:datastore01/tpg1/portals delete 0.0.0.0 3260
/> /iscsi/iqn.2026-07.fr.example.storage:datastore01/tpg1/portals create 10.20.0.10

Restreindre le portail à l'IP du réseau de stockage, pas à 0.0.0.0. Une cible iSCSI qui écoute sur toutes les interfaces, c'est un disque brut offert au premier venu qui passe sur le LAN.

Verrouiller : ACL par initiateur et CHAP

Par défaut, LIO en mode démo accepterait n'importe quel initiateur. À proscrire. On déclare l'IQN de chaque client autorisé dans une ACL, et on l'authentifie en CHAP.

# ACL pour l'initiateur autorisé
/> /iscsi/iqn.2026-07.fr.example.storage:datastore01/tpg1/acls create iqn.2026-07.fr.example.client:node1
# authentification CHAP sur cet initiateur
/> /iscsi/iqn.2026-07.fr.example.storage:datastore01/tpg1/acls/iqn.2026-07.fr.example.client:node1 set auth userid=node1 password=UnSecretLong42
# couper le mode démo : pas d'accès sans ACL
/> /iscsi/iqn.2026-07.fr.example.storage:datastore01/tpg1 set attribute generate_node_acls=0 demo_mode_write_protect=1
/> saveconfig

Le CHAP authentifie, il ne chiffre pas. Le trafic iSCSI circule en clair sur le réseau. La règle qu'on applique : iSCSI tourne sur un VLAN de stockage dédié, isolé du trafic général, jamais routé vers l'extérieur. Si le transport doit traverser un segment non fiable, on l'encapsule (IPsec), mais le bon design reste un réseau de stockage séparé physiquement ou logiquement.

Le client Linux utilise open-iscsi et son outil iscsiadm. Trois temps : on règle son propre IQN, on découvre les LUN de la cible, on s'y connecte.

# l'IQN local de l'initiateur
cat /etc/iscsi/initiatorname.iscsi
# InitiatorName=iqn.2026-07.fr.example.client:node1

# renseigner le CHAP dans /etc/iscsi/iscsid.conf
# node.session.auth.authmethod = CHAP
# node.session.auth.username = node1
# node.session.auth.password = UnSecretLong42

# discovery des cibles sur le portail
iscsiadm -m discovery -t sendtargets -p 10.20.0.10:3260

# login
iscsiadm -m node -T iqn.2026-07.fr.example.storage:datastore01 -p 10.20.0.10:3260 --login

Après le login, lsblk montre un nouveau /dev/sdX. C'est le LUN. On le formate, on le monte, on l'ajoute comme PV LVM, on en fait un datastore. Vu du client, c'est un disque local.

Un seul chemin réseau entre l'initiateur et la cible, c'est un point de panne unique et un plafond de débit fixé par un lien. La parade, c'est le multipath : deux interfaces réseau côté serveur, deux côté client, deux portails, et dm-multipath qui agrège les chemins.

multipathd détecte les deux routes vers le même LUN (identifié par son WWID), les regroupe et bascule en cas de coupure d'un lien. Selon la politique configurée dans /etc/multipath.conf, il fait du failover pur ou répartit les I/O en round-robin sur les deux chemins. Deux liens à 10 GbE en multipath, c'est de la redondance et du débit cumulé.

Le détail du montage multipath sur Proxmox est documenté côté éditeur, on en donne le lien plus bas. Trois réglages qui comptent en prod :

• Réseau de stockage dédié, isolé du trafic applicatif. iSCSI et la production qui se disputent la même carte, c'est de la latence garantie sous charge.
• Jumbo frames (MTU 9000) de bout en bout : carte serveur, switch, carte client. Une MTU 9000 d'un seul côté casse silencieusement le débit, c'est le piège récurrent.
• File d'attente et scheduler I/O adaptés au backstore. Sur SSD ou NVMe derrière, mq-deadline ou none.

Quand le besoin dépasse le LUN partagé, qu'on vise du stockage distribué et auto-réparant à l'échelle de plusieurs nœuds, iSCSI montre ses limites et on bascule sur une autre brique. C'est le terrain de Ceph en stockage distribué, un modèle différent où le bloc (RBD) est répliqué nativement sur le cluster.

Datastore bloc pour des VM : chaque hyperviseur monte ses propres LUN, ou un LUN partagé sous un système de fichiers cluster, et iSCSI sert de SAN logiciel sans Fibre Channel. Disque partagé d'un cluster Pacemaker : un volume basculé d'un nœud à l'autre, avec fencing pour garantir qu'un seul nœud écrit. Cible de sauvegarde présentée comme disque brut à un serveur de backup. Dans tous les cas, le point commun, c'est le besoin de bloc, pas de fichier.

Pour du bloc partagé maîtrisé sur Linux, LIO et targetcli suffisent. Pas d'appliance, pas de licence, une cible dans le noyau depuis quatorze ans, pilotée par un outil propre. On garde la couche stockage sous contrôle (LVM, mdadm, ZFS dessous), on verrouille avec ACL et CHAP, on redonde avec multipath sur un VLAN de stockage dédié. Le seul vrai garde-fou : un disque brut n'arbitre rien, c'est à la couche au-dessus de garantir qu'un seul écrivain touche un LUN, sauf système de fichiers cluster explicite.

Pour du fichier partagé entre plusieurs clients qui écrivent en même temps, ce n'est pas iSCSI qu'il faut, c'est NFS. Le bon réflexe : on choisit le protocole sur le niveau d'accès réel, pas sur l'habitude. Mettre en place une cible iSCSI propre, multipathée et supervisée, c'est de l'ops, et l'erreur de design coûte cher en corruption silencieuse. Si une architecture de stockage partagé doit être conçue, déployée et tenue dans la durée, on opère ce type d'infrastructure au quotidien.

• LIO (SCSI target) : Wikipedia : historique de LIO, fusion dans le noyau 2.6.38 et liste des fabric modules supportés
• Configuring an iSCSI target : Red Hat Enterprise Linux 9 : procédure targetcli officielle : backstores, IQN, LUN, portail, ACL
• ISCSI/LIO : ArchWiki : détail des backstores fileio, block et pscsi et de la persistance configfs
• Open-iSCSI : ArchWiki : initiateur iscsiadm : discovery, login, configuration CHAP dans iscsid.conf
• ISCSI Multipath : Proxmox VE : montage dm-multipath sur deux chemins pour un datastore iSCSI redondé