iSCSI : un stockage en bloc pour les VM Proxmox

iSCSI (Internet Small Computer Systems Interface) est un protocole qui transporte des commandes de disque SCSI dans des paquets TCP/IP : un serveur, l'initiateur, accède à un disque distant fourni par une baie, la cible, comme s'il était branché en local. C'est la façon la plus répandue de construire un SAN sur un réseau Ethernet ordinaire. Ce chapitre présente le vocabulaire d'iSCSI, crée une cible sur un zvol de srv-nas, isole le trafic dans un VLAN de stockage, puis connecte le cluster Proxmox VE de Sorbier et y crée un stockage LVM partagé pour les disques des VM.

Le vocabulaire d'iSCSI

Le préfixe iqn.2005-10.org.freenas.ctl est le nom de base par défaut des cibles TrueNAS, hérité de FreeNAS ; il se change dans la configuration globale iSCSI. Côté Debian et Proxmox, l'IQN de l'initiateur est généré à l'installation d'open-iscsi, dans /etc/iscsi/initiatorname.iscsi.

Préparer le réseau de stockage

Le trafic iSCSI est lourd et sensible à la latence : une VM qui attend son disque se fige. On l'isole dans le VLAN 80 créé au chapitre 4, non routé, avec une carte réseau dédiée sur chaque hôte.

Les hôtes s'administrent par leurs adresses du VLAN 99 (192.168.10.213 à .215, cours Virtualisation) ; leur carte de stockage n'a pas de passerelle. Proxmox Backup Server (192.168.10.245) partage ce VLAN pour recevoir les sauvegardes, mais il n'est pas un initiateur de la cible.

Les trames jumbo. Un MTU de 9000 octets réduit le nombre de paquets et la charge des processeurs pour les gros transferts. Il faut que tous les équipements du chemin l'acceptent : les cartes du NAS et des hyperviseurs, et les ports du switch (sur un Catalyst, system mtu jumbo 9198 en configuration globale, selon le modèle). Vérifie de bout en bout depuis pve1, en interdisant la fragmentation (8972 octets de données ICMP + 28 octets d'en-têtes = 9000) :

ping -M do -s 8972 -c 3 192.168.10.241

Si un équipement du chemin est resté à 1500, la commande échoue avec un message du type « message too long » : mieux vaut rester à 1500 partout qu'avoir un MTU incohérent, qui produit des blocages difficiles à diagnostiquer.

Pourquoi pas de CHAP ? CHAP authentifie l'initiateur par un secret partagé (12 à 16 caractères sur TrueNAS), mais ne chiffre rien, et l'interface de Proxmox ne le gère pas : il faut le configurer dans /etc/iscsi/iscsid.conf sur chaque nœud. Dans un VLAN de stockage isolé où seuls le NAS et les hyperviseurs sont branchés, le groupe d'initiateurs suffit à filtrer. Dès que le réseau de stockage est partagé avec d'autres machines, active CHAP (voire CHAP mutuel, où la cible s'authentifie aussi).

Créer la cible sur TrueNAS

Relever les IQN des hyperviseurs. Sur chaque nœud :

cat /etc/iscsi/initiatorname.iscsi

## DO NOT EDIT OR REMOVE THIS FILE!
## If you remove this file, the iSCSI daemon will not start.
## If you change the InitiatorName, existing access control lists
## may reject this initiator.  The InitiatorName must be unique
## for each iSCSI initiator.  Do NOT duplicate iSCSI InitiatorNames.
InitiatorName=iqn.1993-08.org.debian:01:5f3a2b1c9d8e

L'assistant de TrueNAS. Shares, widget Block (iSCSI) Shares Targets, bouton Wizard :

1. Target : Create New, nom pve-vms (minuscules, chiffres, points, tirets et deux-points ; 64 caractères au plus).
2. Extent : nom pve-vms, Extent Type Device, Device Create New ; choisir le dataset parent vms, nommer le zvol pve-vms, Size 1.5 TiB. Pour la plateforme, choisir celle d'un système moderne (blocs de 4 Kio), adaptée à Linux et donc à Proxmox.
3. Protocol Options : créer un portail avec l'adresse 192.168.10.241 seulement (pas l'interface du VLAN 20), port 3260 par défaut.
4. Initiator : saisir les trois IQN de pve1, pve2 et pve3, en validant chacun par Entrée. Laisser ce champ vide autoriserait tous les initiateurs.
5. Save, puis accepter le démarrage du service iSCSI (System > Services, iSCSI, Start Automatically).

L'écran Configure du même widget détaille ensuite chaque élément créé : la configuration globale (nom de base des cibles), les portails, les groupes d'initiateurs, les accès autorisés (CHAP), les cibles, les extents et les associations entre cibles et extents.

Connecter Proxmox VE

Étape 1 : le stockage iSCSI. Datacenter > Storage > Add > iSCSI :

En ligne de commande, la découverte se teste avec pvesm scan iscsi 192.168.10.241. Une fois le stockage ajouté, chaque nœud ouvre une session vers la cible :

iscsiadm -m session

tcp: [1] 192.168.10.241:3260,1 iqn.2005-10.org.freenas.ctl:pve-vms (non-flash)

Le LUN apparaît comme un nouveau disque sur chaque nœud (lsblk affiche un disque de 1.5T, c'est-à-dire 1,5 TiB, soit environ 1,65 To, de modèle iSCSI Disk).

Étape 2 : le groupe de volumes LVM partagé. On n'utilise pas le LUN directement : la documentation de Proxmox recommande d'y créer un groupe de volumes LVM, dans lequel chaque disque de VM devient un volume logique. Datacenter > Storage > Add > LVM :

Le fichier /etc/pve/storage.cfg contient alors :

iscsi: nas-iscsi
        portal 192.168.10.241
        target iqn.2005-10.org.freenas.ctl:pve-vms
        content none

lvm: nas-lvm
        vgname vg_nas
        base nas-iscsi:0.0.0.scsi-36589cfc000000a1b2c3d4e5f60718293
        content images,rootdir
        shared 1

La ligne base désigne le LUN par son identifiant, généré par la baie : le tien sera différent. content none sur le stockage iSCSI signifie qu'on ne range rien directement dessus.

Pourquoi LVM « partagé » ne casse rien ? Le chapitre 1 l'a dit : deux serveurs qui écrivent sur le même disque le détruisent. Ici, chaque disque de VM est un volume logique distinct, utilisé par un seul nœud à la fois, celui où tourne la VM ; et c'est le cluster Proxmox qui verrouille les modifications du groupe de volumes (création, suppression, redimensionnement d'un volume). Les nœuds partagent le disque sans jamais écrire au même endroit.

Ce qu'on gagne. Une VM dont le disque est sur nas-lvm peut migrer à chaud de pve1 vers pve2 sans copier son disque, en quelques secondes ; et si pve1 tombe, la haute disponibilité de Proxmox la redémarre sur pve2 ou pve3. Elle le peut parce que les deux nœuds restants gardent la majorité des votes du cluster, le quorum (2 sur 3). Avec deux nœuds seulement, il faut un troisième vote (QDevice) pour garder le quorum ; sans lui, la HA ne redémarre rien (cours Haute disponibilité et Virtualisation).

Les limites. Le LVM partagé est « épais » : chaque disque de VM occupe toute sa taille dès sa création. Les snapshots de VM sur LVM existent depuis Proxmox VE 9 sous forme de chaînes de volumes (option Allow Snapshots as Volume-Chain du stockage), mais la fonction est toujours en aperçu technologique dans Proxmox VE 9.2 : ne la mets pas en production. Pour protéger les VM, on s'appuie sur les sauvegardes de Proxmox Backup Server et sur les snapshots du zvol, côté TrueNAS (chapitre 9).

Plusieurs chemins : le multipath

Avec une seule carte et un seul switch, la panne du câble, du port ou du switch coupe l'accès des VM à leurs disques. Le multipath (MPIO) utilise deux chemins indépendants, deux cartes sur chaque hôte, deux switchs, deux adresses de portail sur le NAS, et bascule de l'un à l'autre, voire répartit la charge entre eux. Sur Proxmox VE, il s'appuie sur le paquet multipath-tools. C'est l'étape suivante de la redondance du stockage, une fois le reste en place ; la redondance du NAS lui-même relève de la haute disponibilité (deux contrôleurs, dans l'édition Enterprise) ou de la réplication.

NFS ou iSCSI pour les disques des VM ?

Les deux sont des choix défendables à l'examen, à condition de les justifier. Chez Sorbier, Antoine choisit iSCSI pour les disques des VM (performances sur SSD, chemin vers le multipath) et NFS pour les ISO, les modèles et la copie de secours des sauvegardes (fichiers, simplicité). Le cours Virtualisation part de l'autre choix, les disques des VM en qcow2 sur NFS : les deux stockages coexistent sans difficulté sur le même TrueNAS, et la comparaison ci-dessus sert justement à défendre l'un ou l'autre.

Exercices