iSCSI : créer des disques virtuels en réseau sous Linux

iSCSI permet de présenter un disque distant à un serveur Linux comme s’il était branché localement, en utilisant le réseau IP standard. Contrairement à NFS qui partage des fichiers, iSCSI partage des blocs bruts : le client voit un vrai disque (/dev/sda), le formate et le monte comme un disque local. Ce guide couvre la configuration complète d’un target (serveur) avec targetcli et d’un initiator (client) avec open-iscsi sur Ubuntu 24.04 — toutes les commandes ont été testées en lab KVM.

Ce que vous allez apprendre

• Fonctionnement d’iSCSI : protocole, vocabulaire, architecture
• Target (serveur) : targetcli, backstores block et fileio, IQN, TPG
• LUNs et ACLs : exposer des disques et contrôler les accès
• Initiator (client) : open-iscsi, discovery, login, montage
• Sécurité CHAP : authentification unidirectionnelle et mutuelle
• Montage persistant : /etc/fstab avec _netdev
• Dépannage : erreurs fréquentes et résolutions testées

Qu’est-ce que iSCSI ?

iSCSI (Internet Small Computer Systems Interface) est un protocole qui transporte les commandes SCSI (le langage standard des disques durs) à travers un réseau TCP/IP classique. Il transforme n’importe quel serveur en baie de stockage réseau (SAN) sans matériel spécialisé.

Analogie : imaginez un câble SATA très long qui traverse le réseau. Votre serveur « croit » qu’un disque est branché directement à sa carte mère, alors qu’en réalité les données transitent sur le réseau Ethernet. Le système d’exploitation voit un périphérique bloc (/dev/sda, /dev/sdb…) qu’il peut partitionner, formater et monter exactement comme un disque local.

iSCSI vs NFS : deux approches complémentaires

Critère	iSCSI	NFS
Type de partage	Bloc (disque brut)	Fichiers (répertoire)
Ce que voit le client	/dev/sdX — un disque	/mnt/nfs — un dossier
Filesystem	Choisi par le client (ext4, xfs…)	Géré par le serveur
Multi-client	1 seul client par LUN (sauf clustered FS)	Plusieurs clients simultanés
Performance	Excellente (proche du disque local)	Bonne
Cas d’usage	Bases de données, VMs, stockage bloc	Partages de fichiers, configs, homes
Port	3260/tcp	2049/tcp

Glissez pour voir

Quand choisir iSCSI ?

Choisissez iSCSI quand vous avez besoin d’un disque dédié à un seul serveur : base de données (PostgreSQL, MySQL), machine virtuelle (KVM, VMware), conteneurs avec stockage persistant bloc. Pour du partage multi-clients (fichiers, configs), préférez NFS.

Le vocabulaire iSCSI

Avant de commencer, voici les termes que vous allez rencontrer :

Terme	Définition	Analogie
Target	Le serveur qui expose les disques	La baie de stockage
Initiator	Le client qui se connecte et utilise les disques	Le serveur qui a besoin de stockage
IQN	Identifiant unique (iSCSI Qualified Name), format : iqn.AAAA-MM.domaine:identifiant	Le numéro de série du périphérique
TPG	Target Portal Group — point d’accès réseau (IP:port)	La prise réseau de la baie
LUN	Logical Unit Number — un disque exposé dans un TPG	Un tiroir dans la baie
Backstore	Le stockage physique derrière un LUN (partition, fichier, volume LVM)	Le disque dur physique
ACL	Access Control List — contrôle quel initiator accède à quel LUN	Le badge d’accès
CHAP	Challenge-Handshake Authentication Protocol — authentification par mot de passe	Le code PIN du badge
Portal	Couple IP:port sur lequel le target écoute (défaut : 0.0.0.0:3260)	L’adresse de la baie

Glissez pour voir

Prérequis

• 2 machines Ubuntu 24.04 (physiques ou virtuelles)
• Connectivité réseau entre les deux
• Accès root ou sudo sur les deux machines
• Port 3260/tcp ouvert entre le target et l’initiator
• Sur le target : un disque ou partition supplémentaire à exposer

Pour reproduire ce lab, deux VMs KVM suffisent : un target (192.168.122.50, avec un disque /dev/vdb de 10 Go) et un initiator (192.168.122.225).

Architecture du lab

┌──────────────────────────┐         TCP/3260         ┌──────────────────────────┐
│     storage-srv          │◄────────────────────────►│     storage-cli          │
│     (Target iSCSI)       │                           │     (Initiator iSCSI)    │
│                          │                           │                          │
│  targetcli-fb            │                           │  open-iscsi              │
│  /dev/vdb1 (5 Go block)  │    ──── LUN 0 ────►      │  /dev/sda → /mnt/iscsi   │
│  fichier 1 Go (fileio)   │    ──── LUN 1 ────►      │  /dev/sdb → /mnt/file    │
│                          │                           │                          │
│  IP: 192.168.122.50      │                           │  IP: 192.168.122.225     │
└──────────────────────────┘                           └──────────────────────────┘

Configurer le target (serveur)

Le target est le serveur qui expose ses disques via iSCSI. Sur Linux, on utilise LIO (Linux-IO Target), le framework cible iSCSI intégré au noyau, piloté par la commande targetcli.

Installer targetcli

sudo apt update
sudo apt install targetcli-fb

Le paquet targetcli-fb (« free branch ») est la version maintenue activement du projet. Il fournit la commande targetcli pour configurer les backstores, les targets et les ACLs via un shell interactif.

Activez le service pour que la configuration persiste après redémarrage :

sudo systemctl enable rtslib-fb-targetctl

Préparer le stockage

iSCSI peut exposer différents types de stockage en backend (appelés backstores). Les deux plus courants :

Type	Description	Performance	Cas d’usage
block	Partition, disque ou volume LVM	Excellente	Bases de données, production
fileio	Fichier image sur le filesystem	Bonne	Tests, prototypage

Glissez pour voir

Pour le lab, créez les deux types :

Backstore block — Partitionnez le disque supplémentaire :

sudo parted /dev/vdb mklabel gpt
sudo parted /dev/vdb mkpart iscsi-lun1 ext4 0% 50%
sudo parted /dev/vdb mkpart iscsi-lun2 ext4 50% 100%

Backstore fileio — Créez un fichier image :

sudo mkdir -p /srv/iscsi
sudo dd if=/dev/zero of=/srv/iscsi/lun-file.img bs=1M count=1024

Configurer avec targetcli

Lancez le shell interactif targetcli et créez toute la structure :

sudo targetcli

1. Créer les backstores — Déclarez les supports de stockage physiques :

   /> cd /backstores/block
   /backstores/block> create lun-data /dev/vdb1
   /backstores/block> cd /backstores/fileio
   /backstores/fileio> create lun-file /srv/iscsi/lun-file.img

   Chaque backstore reçoit un nom logique (lun-data, lun-file) qui l’identifie dans la configuration.

2. Créer le target iSCSI — Définissez l’identité du serveur de stockage :

   /> cd /iscsi
   /iscsi> create iqn.2026-03.lab.storage:target01

   L’IQN (iSCSI Qualified Name) suit le format iqn.AAAA-MM.domaine.inversé:identifiant. Il identifie de façon unique le target sur le réseau. Un TPG (Target Portal Group) est créé automatiquement.

3. Créer une ACL pour l’initiator — Autorisez le client à se connecter :

   /> cd /iscsi/iqn.2026-03.lab.storage:target01/tpg1/acls
   /iscsi/.../acls> create iqn.2026-03.lab.storage:client01

   L’ACL contrôle quel initiator peut accéder au target. L’IQN doit correspondre exactement au nom configuré sur le client.

4. Mapper les LUNs — Associez les backstores au target :

   /> cd /iscsi/iqn.2026-03.lab.storage:target01/tpg1/luns
   /iscsi/.../luns> create /backstores/block/lun-data
   /iscsi/.../luns> create /backstores/fileio/lun-file

   Chaque LUN reçoit un numéro automatique (LUN 0, LUN 1…). Les LUNs sont automatiquement mappés aux ACLs existantes.

5. Vérifier et sauvegarder :

   /> ls /
   /> saveconfig
   /> exit

Résultat attendu de ls / :

o- / .............................................................. [...]
  o- backstores ................................................... [...]
  | o- block ........................................... [Storage Objects: 1]
  | | o- lun-data ................ [/dev/vdb1 (5.0GiB) write-thru activated]
  | o- fileio .......................................... [Storage Objects: 1]
  |   o- lun-file . [/srv/iscsi/lun-file.img (1.0GiB) write-back activated]
  o- iscsi ................................................. [Targets: 1]
    o- iqn.2026-03.lab.storage:target01 ........................ [TPGs: 1]
      o- tpg1 ........................................ [gen-acls, no-auth]
        o- acls ............................................... [ACLs: 1]
        | o- iqn.2026-03.lab.storage:client01 ......... [Mapped LUNs: 2]
        o- luns ............................................... [LUNs: 2]
        | o- lun0 .................. [block/lun-data (/dev/vdb1) (default)]
        | o- lun1 .. [fileio/lun-file (/srv/iscsi/lun-file.img) (default)]
        o- portals ........................................ [Portals: 1]
          o- 0.0.0.0:3260 .......................................... [OK]

Vérification — Le port 3260 est bien en écoute :

sudo ss -tlnp | grep 3260

LISTEN  0  256  0.0.0.0:3260  0.0.0.0:*  users:(("targetcli",pid=...))

Configuration persistante

La commande saveconfig écrit la configuration dans /etc/rtslib-fb-target/saveconfig.json. Le service rtslib-fb-targetctl la recharge automatiquement au démarrage. Pensez à activer ce service avec systemctl enable rtslib-fb-targetctl.

Configurer l’initiator (client)

L’initiator est le client qui se connecte au target pour utiliser les disques distants. Sur Linux, le paquet open-iscsi fournit les outils nécessaires.

Installer open-iscsi

sudo apt update
sudo apt install open-iscsi lsscsi

Le paquet lsscsi est optionnel mais très utile pour lister les périphériques SCSI détectés.

Configurer le nom de l’initiator

Chaque initiator a un IQN unique stocké dans /etc/iscsi/initiatorname.iscsi. Ce nom doit correspondre exactement à l’ACL configurée sur le target :

echo "InitiatorName=iqn.2026-03.lab.storage:client01" | sudo tee /etc/iscsi/initiatorname.iscsi
sudo systemctl restart iscsid

Correspondance IQN obligatoire

Si l’IQN de l’initiator ne correspond à aucune ACL sur le target, la connexion sera refusée silencieusement. Utilisez exactement le même IQN que celui déclaré dans targetcli > acls.

Découvrir le target

La discovery interroge le target pour lister les ressources disponibles :

sudo iscsiadm -m discovery -t sendtargets -p 192.168.122.50

192.168.122.50:3260,1 iqn.2026-03.lab.storage:target01

Le target répond avec son IQN et son portail (IP:port). Cette information est stockée localement pour les connexions futures.

Se connecter (login)

sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 --login

Logging in to [iface: default, target: iqn.2026-03.lab.storage:target01, portal: 192.168.122.50,3260]
Login to [...] successful.

Vérification — Listez les sessions actives :

sudo iscsiadm -m session -o show

tcp: [1] 192.168.122.50:3260,1 iqn.2026-03.lab.storage:target01 (non-flash)

Vérifier les disques

Après le login, les LUNs apparaissent comme des disques SCSI classiques :

lsscsi

[0:0:0:0]    cd/dvd  QEMU     QEMU DVD-ROM     2.5+  /dev/sr0
[6:0:0:0]    disk    LIO-ORG  lun-data         4.0   /dev/sda
[6:0:0:1]    disk    LIO-ORG  lun-file         4.0   /dev/sdb

Les deux LUNs sont visibles : lun-data (5 Go, block) sur /dev/sda et lun-file (1 Go, fileio) sur /dev/sdb. Le fabricant LIO-ORG confirme qu’ils proviennent du target LIO.

lsblk /dev/sda /dev/sdb

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda    8:0    0   5G  0 disk
sdb    8:16   0   1G  0 disk

Formater et monter les LUNs

Les LUNs iSCSI sont des disques bruts. Formatez-les et montez-les comme n’importe quel disque local :

# Formater en ext4
sudo mkfs.ext4 /dev/sda
sudo mkfs.ext4 /dev/sdb

# Créer les points de montage
sudo mkdir -p /mnt/iscsi-data /mnt/iscsi-file

# Monter
sudo mount /dev/sda /mnt/iscsi-data
sudo mount /dev/sdb /mnt/iscsi-file

Vérification — Écrivez des données et vérifiez :

echo "Données critiques sur iSCSI block" | sudo tee /mnt/iscsi-data/test.txt
cat /mnt/iscsi-data/test.txt

Données critiques sur iSCSI block

Benchmark de performance

# Écriture (100 Mo, I/O direct)
dd if=/dev/zero of=/mnt/iscsi-data/bench bs=1M count=100 oflag=direct

# Lecture
dd if=/mnt/iscsi-data/bench of=/dev/null bs=1M iflag=direct

Sur notre lab (réseau virtio, même hôte KVM) :

Sens	Débit mesuré
Écriture	~866 Mo/s
Lecture	~1,7 Go/s

Glissez pour voir

Les performances iSCSI en mode block sont supérieures à NFS car le client gère directement le filesystem sans la surcharge du protocole de fichiers.

Montage persistant via /etc/fstab

Pour que les LUNs se montent automatiquement au démarrage :

/etc/fstab

/dev/sda /mnt/iscsi-data ext4 defaults,_netdev 0 0
/dev/sdb /mnt/iscsi-file ext4 defaults,_netdev 0 0

L’option _netdev est indispensable : elle indique au système d’attendre que le réseau (et donc la session iSCSI) soit opérationnel avant de monter.

Identifier les LUNs par UUID

En production, les noms de périphériques (/dev/sda, /dev/sdb) peuvent changer d’un redémarrage à l’autre. Utilisez plutôt l’UUID :

blkid /dev/sda
# /dev/sda: UUID="a1b2c3d4..." TYPE="ext4"

Dans /etc/fstab :

UUID=a1b2c3d4... /mnt/iscsi-data ext4 defaults,_netdev 0 0

Connexion automatique au boot

Pour que l’initiator se reconnecte automatiquement au target au démarrage :

sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 \
  -o update -n node.startup -v automatic

Vérifiez que le paramètre est bien enregistré :

sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 | grep node.startup

node.startup = automatic

Sécuriser avec CHAP

Par défaut, n’importe quel initiator connaissant l’IQN et l’IP du target peut se connecter. Le protocole CHAP (Challenge-Handshake Authentication Protocol) ajoute une authentification par identifiant/mot de passe.

CHAP unidirectionnel (le plus courant)

Le target vérifie l’identité de l’initiator. C’est suffisant dans la majorité des cas.

Côté target (dans targetcli) :

sudo targetcli

/> cd /iscsi/iqn.2026-03.lab.storage:target01/tpg1
/iscsi/.../tpg1> set attribute authentication=1
/iscsi/.../tpg1> cd acls/iqn.2026-03.lab.storage:client01
/iscsi/.../client01> set auth userid=labuser
/iscsi/.../client01> set auth password=S3cur3P4ss!
/> saveconfig
/> exit

Longueur du mot de passe CHAP

Le mot de passe CHAP doit faire entre 12 et 16 caractères. Un mot de passe trop court sera refusé par certaines implémentations. Évitez les caractères spéciaux problématiques (", ', \).

Côté initiator — Déconnectez-vous, configurez CHAP, puis reconnectez-vous :

# Déconnexion
sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 --logout

# Configurer CHAP
sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 \
  -o update -n node.session.auth.authmethod -v CHAP

sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 \
  -o update -n node.session.auth.username -v labuser

sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 \
  -o update -n node.session.auth.password -v S3cur3P4ss!

# Reconnexion avec CHAP
sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 --login

Login to [...] successful.

Vérification — La session est bien active avec authentification :

sudo iscsiadm -m session -o show

tcp: [2] 192.168.122.50:3260,1 iqn.2026-03.lab.storage:target01 (non-flash)

Les disques sont de nouveau disponibles. Remontez-les :

sudo mount /dev/sda /mnt/iscsi-data
sudo mount /dev/sdb /mnt/iscsi-file
cat /mnt/iscsi-data/test.txt

Données critiques sur iSCSI block

Les données sont intactes après la déconnexion/reconnexion.

CHAP mutuel (bidirectionnel)

Pour les environnements où le target doit aussi prouver son identité à l’initiator (prévention de l’usurpation), configurez le CHAP mutuel :

Côté target — Ajoutez les credentials inversés :

/iscsi/.../client01> set auth mutual_userid=target-srv
/iscsi/.../client01> set auth mutual_password=T4rg3tS3cure!

Côté initiator :

sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 \
  -o update -n node.session.auth.username_in -v target-srv

sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 \
  -o update -n node.session.auth.password_in -v T4rg3tS3cure!

Gérer les sessions iSCSI

Lister les sessions actives

sudo iscsiadm -m session -o show

Se déconnecter proprement

Avant de déconnecter, démontez les filesystems :

sudo umount /mnt/iscsi-data /mnt/iscsi-file
sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 --logout

Supprimer un target enregistré

Pour oublier complètement un target (discovery + node) :

sudo iscsiadm -m node \
  -T iqn.2026-03.lab.storage:target01 \
  -p 192.168.122.50 -o delete

Voir la configuration côté target

Sur le serveur, consultez la configuration active :

sudo targetcli ls /

La configuration complète est sauvegardée dans /etc/rtslib-fb-target/saveconfig.json. Sauvegardez ce fichier pour la récupération après incident.

Bonnes pratiques en production

Réseau dédié

En production, isolez le trafic iSCSI sur un réseau ou VLAN dédié :

• Évite la congestion avec le trafic applicatif
• Réduit la surface d’attaque (CHAP n’est pas du chiffrement)
• Permet de configurer des MTU jumbo (9000) pour la performance

Multipath (haute disponibilité)

Pour les serveurs critiques, configurez multipath-tools pour utiliser plusieurs chemins réseau vers le même target :

sudo apt install multipath-tools

Le multipath fournit :

• Redondance : si un chemin tombe, le trafic bascule automatiquement
• Performance : agrégation de bande passante sur les chemins actifs

Dimensionnement

Paramètre	Recommandation
Réseau	10 Gbps minimum pour les bases de données
MTU	9000 (jumbo frames) si le réseau le supporte
Backstores	Block (partition/LVM) pour la production, fileio pour les tests
CHAP	Toujours activé, même en réseau isolé
Sauvegarde config	Copier /etc/rtslib-fb-target/saveconfig.json régulièrement

Glissez pour voir

Dépannage

Symptôme	Cause probable	Solution
Discovery ne retourne rien	Port 3260 filtré	sudo ufw allow 3260/tcp puis `ss -tlnp
Login refusé sans message clair	IQN de l’initiator ne match aucune ACL	Vérifier que l’IQN dans /etc/iscsi/initiatorname.iscsi est identique à l’ACL dans targetcli
Login échoue avec CHAP	Mot de passe incorrect ou trop court (moins de 12 car.)	Vérifier userid/password côté target ET côté initiator
Disques non visibles après login	LUNs non mappés dans le TPG	Dans targetcli : vérifier ls /iscsi/.../tpg1/luns
/dev/sdX change après reboot	Noms de périphériques dynamiques	Utiliser UUID=... dans /etc/fstab au lieu de /dev/sdX
Montage au boot échoue	Session iSCSI pas encore établie	Ajouter _netdev dans fstab + node.startup = automatic
Read-only file system après reconnexion	Filesystem marqué en erreur	sudo fsck /dev/sda puis remonter
Performance lente	MTU 1500 sur réseau dédié	Passer à MTU 9000 (jumbo frames) sur toutes les interfaces
Target ne démarre pas au boot	Service rtslib-fb-targetctl désactivé	sudo systemctl enable rtslib-fb-targetctl

Glissez pour voir

Diagnostic pas à pas

En cas de problème de connexion, suivez cette chaîne :

1. Le target écoute-t-il ? (ss -tlnp | grep 3260 sur le serveur)
2. Le port est-il accessible ? (nc -zv 192.168.122.50 3260 depuis le client)
3. La discovery fonctionne-t-elle ? (iscsiadm -m discovery -t st -p IP)
4. L’IQN correspond-il ? (comparer /etc/iscsi/initiatorname.iscsi et les ACLs)
5. CHAP est-il configuré des deux côtés ? (userid et password identiques)

À retenir

• iSCSI transporte les commandes de disque (SCSI) sur le réseau TCP/IP : le client voit un vrai disque bloc (/dev/sdX)
• Le target (serveur) expose les disques via targetcli, l’initiator (client) s’y connecte via open-iscsi
• Les backstores définissent le stockage physique : block (partition, LVM) pour la production, fileio (fichier) pour les tests
• Chaque target et initiator s’identifient par un IQN unique — la correspondance entre les ACLs et l’initiatorname est obligatoire
• Activez CHAP systématiquement : c’est la seule authentification intégrée au protocole
• L’option _netdev dans /etc/fstab est indispensable pour les montages iSCSI au boot
• En production, dédiez un réseau ou VLAN au trafic iSCSI et utilisez le multipath pour la haute disponibilité

Prochaines étapes

NFS : partage de fichiers en réseau Protocole fichier complémentaire à iSCSI pour les partages multi-clients

Longhorn : stockage Kubernetes via iSCSI Longhorn utilise iSCSI pour répliquer les volumes Kubernetes

OpenEBS : stockage cloud-natif Solution de stockage bloc Kubernetes avec Mayastor (NVMe-oF)

Ceph : stockage distribué unifié Bloc, fichier et objet dans une seule solution distribuée

×

📖 Voir la documentation →