Retrouvez cet article dans : Linux Magazine 97

Découvrez iSCSI et soyez prêt à interconnecter votre système favori avec les équipements de stockage supportant ce protocole.

1. Introduction

Sous le vocable iSCSI (à prononcer i-skeuzi, i-skozi, aïe-skeuzi ou aïe-skozi selon que vous adoptez une prononciation française ou anglophone), se cache un protocole réseau qui encapsule le protocole SCSI dans des paquets TCP. TCP/IP est alors utilisé comme protocole de transport ce qui permet à une machine d’accéder à des périphériques distants connectés à l’infrastructure réseau existante. Le protocole iSCSI (voir [RFCA]) utilise l’architecture client/serveur, mais possède sa propre terminologie :

• le client est appelé " initiator "
• le serveur est appelé " target "

L’initiator peut être une carte Ethernet spécialisée, munie d’un composant supplémentaire qui va gérer le protocole iSCSI. Cette carte sera appelée un " iSCSI-HBA ". Mais, on peut aussi déployer une solution logicielle pure qui nécessite seulement un driver spécifique dont le rôle sera de traduire les ordres SCSI en paquets réseau. C’est cette solution que nous allons mettre en œuvre dans cet article. La target (cible) est normalement un périphérique de stockage doté d’une interface iSCSI. Qu’est-ce-qu’une interface iSCSI ? Eh bien en fait, les constructeurs proposent, outre la connectivité Fibre Channel, un ou plusieurs ports Ethernet avec support au niveau de l’OS et éventuellement des cartes réseau, du protocole iSCSI. Mais pour ceux qui ne disposent pas d’un tel matériel, nous verrons comme émuler une target avec Linux ! Initiator et target sont considérés comme les nœuds d’un réseau iSCSI. Le driver iSCSI transporte les commandes SCSI sur le réseau plutôt que d’utiliser un bus SCSI directement connecté ou bien une connexion en FC. Le routeur de stockage transporte ces commandes SCSI vers le périphérique de stockage (conversion). Les distributions Linux à vocation " serveur " proposent un initiator iSCSI. Il existe aussi un projet libre pour Windows, mais ceci est probablement le sujet d’un article pour un autre numéro !

2. Question de vocabulaire

2.1 Petite mise en garde

Avant de réaliser nos premiers tests, il faut être conscient des contraintes liées au protocole iSCSI :

• L’espace de stockage étant accédé en mode bloc à travers le réseau, le noyau Linux considère cet espace disque comme s’il était local. Il n’est pas question de partager le même espace physique entre plusieurs initiators (à moins d’utiliser un système de fichiers distribué comme GFS).
• On appliquera alors les mêmes règles qu’avec un SAN : si vous avez " n " initiators, alors il faut découper l’espace physique en " n " portions logiques pour faire en sorte que chaque initiator accède seul à son espace logique.

2.2 Format des adresses iSCSI

Vous êtes déjà conscients que chaque protocole entraîne son lot de conventions, en particulier concernant les adresses des différents nœuds communiquant avec ces protocoles. Ainsi, il en va des adresses IP pour TCP/IP, des LUN pour SCSI, des WWN (World-Wide-Number) pour FC. L’iSCSI ne déroge pas à cette règle : targets et initiators doivent posséder des adresses uniques. Les adresses iSCSI peuvent avoir deux formats (voir [RFCB]) :

• Le format iqn (iSCSI Qualified Name) : c’est une chaîne préfixée par " iqn. " et suivie d’une date (au format AAAA-MM), du nom de l’autorité qui a attribué le nom (c’est le nom de domaine à l’envers), puis une chaîne unique qui identifie le nÅ“ud. Par exemple : iqn.2007-07.org.zereso:serveur1:123456789ABCDEF.12345.
• Le format eui (Enterprise Unique Identifier) : c’est une chaîne préfixée par " eui. " et suivie de 16 chiffres hexadécimaux. Par exemple : eui.00803A4B887A8D05.

Chaque nœud iSCSI peut aussi disposer d’Alias. Ce sont des noms logiques qui peuvent être utilisés uniquement après la connexion (qui utilise donc toujours le nom unique officiel) et permettent de proposer des comptes-rendus plus lisibles pour les administrateurs. Toujours suivant le bon vieux principe qu’une vision logique est préférable à une vision physique...

2.3 " Portals "

Lorsque l’initiator souhaite établir une session TCP avec la target, il a besoin de connaître le port TCP de la target. L’association (adresse IP, port TCP) est appelé un " portal ". Il y a donc un portal sur l’initiator et la target. Le port par défaut sur la target est le 3260. Notons qu’un initiator peut établir plusieurs connexions TCP avec la même cible. L’ensemble de ces connexions définit une " session iSCSI ".

2.4 Découverte automatique

Lorsque l’initiator est activé, il peut découvrir automatiquement les targets associées à une adresse IP donnée. Ce processus est appelé auto-découverte (auto-discovery). Le standard iSCSI définit trois modes de découverte :

• Le mode SendTargets qui est réalisé à la demande de l’initiator et qui utilise une commande native du protocole iSCSI pour cela.
• Le mode SLP (Service Location Protocol) – aussi utilisé par CUPS pour annoncer ses imprimantes par exemple - qui est utilisé par la machine cible pour annoncer sur le réseau la liste des ressources disponibles. L’initiator peut aussi émettre une requête SLP en unicast pour récupérer ces informations.
• Le mode iSNS (Internet Storage Name Service) qui est une sorte de service DNS pour le monde du stockage. iSNS n’est pris en charge que dans les environnements Windows iSCSI. iSNS offre la même fonction que le service SNS (Simple Name Server) dans un fabric Fibre Channel – recherche, gestion et configuration automatisées des périphériques iSCSI. Grâce à ce service, il n’est plus nécessaire de configurer manuellement chaque système de stockage à partir de sa propre liste d’initiateurs et de cibles.

À l’heure actuelle, seul le mode SendTargets est implémenté sur Linux. Il peut être résumé ainsi :

• L’initiator connaît (via un fichier de configuration) la liste des targets.
• Il effectue alors des requêtes de découverte (SendTargets) ;
• Chaque target iSCSI retourne les noms des cibles disponibles au driver ;
• Le driver essaye de se connecter et reçoit les ID des cibles ;
• Le driver iSCSI demande des infos pour chaque périphérique ;
• Puis, il crée une table des périphériques disponibles ;
• Les périphériques sont alors montables et utilisables.

 

3. Installation

Nous supposons que tout le monde ne dispose pas d’un véritable périphérique compatible iSCSI. Aussi, nous vous proposons de réaliser ces tests à l’aide de deux machines Linux. L’une doit disposer d’un espace disque disponible (une partition spécifique sera l’idéal). Elle agira en tant que target. L’autre machine sera l’initiator. Les deux machines doivent disposer d’un noyau 2.6.16+. Dans notre cas, nous avons testé les distributions suivantes : Debian 4-Etch, RedHat Enterprise 5, OpenSuSE 10.1 – mais nous recommandons la 10.2.

3.1 Installation de la cible

Comme indiqué en préambule, pour ceux qui ne disposent pas d’un équipement compatible iSCSI, nous proposons d’installer l’application iSCSI-target disponible à l’adresse http://sourceforge.net/projects/iscsitarget/ sur la machine cible. Dans le cas présent, nous téléchargeons l’archive iscsitarget-0.4.15.tar.gz, puis :

# tar xvfz iscsitarget-0.4.15.tar.gz
# cd iscsitarget-0.4.15

Ce logiciel contient les composants suivants :

• iscsi_trgt.ko : un module noyau qui émule une cible iSCSI et implémente le protocole ;
• un démon ietd (IET = iSCSI Enterprise Target) ;
• une commande de contrôle ietadm ;
• quelques fichiers de configuration (voir §4.1).

Avant de compiler les sources, il vous faut vérifier que vous disposez :

• du compilateur gcc (je plaisante) ;
• des sources et des en-têtes de compilation de votre noyau ;
• des fichiers d’en-têtes de la bibliothèque OpenSSL.

NOTE Si le répertoire /lib/modules/`uname –r`/build n’existe pas, il faudra créer un lien symbolique ainsi : # ln –s /usr/src/linux-source-2.6.18 /lib/modules/`uname –r`/build (en supposant dans l’exemple, que /usr/src/linux-source-2.6.18 est bien le répertoire contenant les sources de votre noyau). Puis, il faudra préparer les en-têtes des fichiers ainsi que compiler certains utilitaires (dont modpost) ainsi :

# cd /usr/src/linux-source-2.6.18
# make oldconfig
# make prepare
# make

Puis revenez dans le répertoire contenant les sources de iscsitarget. Pour compiler et installer le logiciel, les commandes :

# make
# make install

feront l’affaire. Toutefois, si les sources de votre noyau ne sont pas sous /lib/modules/`uname –n`/build, vous devrez ajouter l’option suivante, lors du lancement de la commande make :

# make KSRC=/chemin/vers/les/sources/du/noyau
# make install

L’installation a copié les fichiers iscsi_trgt.ko, ietd et ietadm " aux bons endroits ". Elle a aussi ajouté un script de démarrage nommé iscsi-target sous /etc/init.d comme il se doit ! La commande précédente a aussi reconstruit le fichier des dépendances entre les modules en lançant la commande depmod –aq. Tout est prêt !

3.2 Installation de l’initiator

Sur la machine qui va devenir l’initiator, il faut installer le logiciel open-iscsi disponible à l’adresse http://www.open-iscsi.org. Toutes ces distributions citées en préambule utilisent le logiciel open-iscsi. Cependant, il existe une autre implémentation mise en œuvre par exemple avec la RedHat 4 [RED4]. Cette implémentation est disponible à l’adresse http://linux-iscsi.sourceforge.net. Même si les principes restent identiques, les commandes et la configuration sont différentes. En avril 2005, les projets linux-iscsi et open-iscsi ont fusionné, donc RedHat s’est tourné depuis vers open-iscsi. Nous n’étudierons que cette version ici. Certaines distributions commerciales proposent les packages au format RPM. Pour RedHat, il vous faudra installer les packages iscsi-initiator-utils. Pour OpenSuSE (version 10.1+), le package se nomme open-iscsi. Cette distribution propose aussi une interface de configuration graphique via le package yast2-iscsi-client (voir [SUSE] pour une description de l’implémentation sur OpenSuSE). Sur Debian [DEB], nous allons utiliser les commandes suivantes :

    # apt-get install open-iscsi

Quel que soit le nom du package, vous disposez maintenant des commandes et fichiers de configuration suivants :

4. Configuration de base

4.1 Configuration de la cible

Tout d’abord, il vous faut choisir une partition qui sera donc rendue accessible via iSCSI. Le contenu de cette partition, appelons-la /dev/sdb2, sera effacé dans la suite de nos manipulations, donc, attention à ce que vous faites... Toutefois, si vous ne disposez pas de partition sacrifiable, il est possible d’utiliser un fichier:

target # dd if=/dev/zero of=/tmp/itarget bs=1024 count=102400

et voilà un fichier de 100 mo qui peut servir de test. La liste des cibles est définie dans le fichier /etc/ietd.conf. Pour l’instant, nous allons faire en sorte que seules les lignes suivantes soient décommentées :

Target iqn.2007-07.org.zereso:storage.disk1
          ...
          Lun 0 Path=/dev/sdb2,Type=blockio

Notez bien l’indentation de la seconde ligne, c’est ce qui la rattache à la définition de la cible. Le nom de la cible est au format iqn. Ce nom est arbitraire (voir §2.2). Vous pouvez vous aider de la commande iscsi-iname pour en générer un (voir §4.2). Si vous choisissez d’utiliser en plus le fichier /tmp/itarget créé plus haut, ajoutez la ligne suivante :

          Lun 1 Path=/tmp/itarget,Type=fileio

L’accès à la cible est contrôlé par les fichiers /etc/initiators.{allow,deny}, ceci dans le même esprit que les fichiers /etc/hosts.{allow,deny} des fameux TCP Wrappers. Nous allons autoriser l’initiator à accéder cette target. Donc, dans le fichier /etc/initiators.allow, nous ajoutons la ligne :

          iqn.2007-07.org.zereso:storage.disk1 a.b.c.d*

(où a.b.c.d est l’adresse IP de l’initiator). Nous pouvons charger le module iscsi_trgt et lancer le démon ietd par la commande :

target # /etc/init.d/iscsi-target start
Starting iSCSI enterprise target service: OK/succeeded
target # /etc/init.d/iscsi-target status
ietd (pid 4576) is running...

On peut vérifier la liste des cibles exportées par la commande :

target # cat /proc/net/iet/volume
tid:1 name:iqn.2007-07.org.zereso:storage.disk1
	lun:0 state:0 iotype:blockio iomode:wt path:/dev/sb2
	lun:1 state:0 iotype:fileio iomode:wt path:/tmp/itarget

4.2 Configuration de l’initiator

Sur l’initiator, nous allons éditer le fichier initiatorname.iscsi et y placer le nom unique de l’initiator, au format iqn. Par exemple, notre nom de domaine étant zereso.org, nous plaçons dans ce fichier la ligne suivante :

InitiatorName=iqn.2007-07.org.zereso:client.babbe4e54ab

La chaîne client.babbe4e54ab est arbitraire. Vous pouvez utiliser la commande iscsi-iname pour générer un nom unique et valide. Par exemple, en fonction des différentes distributions, on obtient

• sur Debian et OpenSuSE :

# iscsi-iname
iqn.1987-05.com.cisco:01.faef8938857c

• sur RedHat :

# iscsi-iname
iqn.2005-03.com.redhat:01.babbe4e54ab

Test de bon chargement des modules

Avant de continuer, nous allons vérifier que le démon iscsid peut être lancé correctement et que les modules noyau sont correctement chargés :

# /etc/init.d/open-iscsi start

ou

# /etc/init.d/iscsi start

Les logs doivent montrer les deux lignes suivantes :

...iscsid: Loading iSCSI transport class...: registered transport (tcp)
...iscsid: iscsi: registered transport (iser)

La commande lsmod doit montrer que de nouveaux modules ont été chargés dont : ib_iser, rdma_cm, ib_addr, ib_cm, ib_sa, ib_mad, ib_core, iscsi_tcp, libiscsi, scsi_transport_iscsi (Ouf !) On reconnaîtra, par leur nom, les modules qui interceptent les requêtes SCSI et les traduisent en iSCSI sur TCP. Les modules dont le nom débute par ib_ constituent une couche supplémentaire apte à gérer les réseaux Infiniband [INFI].

Tests de découverte

Pour connecter l’initiator à la cible, nous éditons le fichier /etc/iscsid.conf ou /etc/iscsi/iscsid.conf selon les distributions (voir §3.2 – et dorénavant, nous appellerons ce fichier iscsid.conf !). Dans le fichier iscsid.conf, il faut vérifier que pour l’instant les lignes discovery.sendtargets et node.session.auth sont en commentaire, puis il faut directement utiliser la commande iscsiadm qui va construire la base (voir §3.2) utiilisée par le démon iscsid :

initiator # iscsiadm –-mode discovery –-type sendtargets –-portal=x.y.z.t:3260

(où x.y.z.t est l’adresse IP de la cible) ou bien, en abrégé :

initiator # iscsiadm –m discovery –t st –p x.y.z.t

et qui affiche :

	x.y.z.t:3260, 1 iqn.2007-07.org.zereso:storage.disk1

Ce qui a créé le fichier x.y.z.t,3260 sous le répertoire /etc/iscsi/nodes/iqn.2007-07.org.zereso:storage.disk1, sur une Debian (voir le §3.2 pour la localisation avec les autres distributions). Note Sur OpenSuSE, les commandes iscsiadm précédentes retournent en outre un identifiant (un Resource ID) qui permet d’accéder au contenu des bases de données nodes.db et discovery.db. Par exemple :

initiator # iscsiadm –m discovery –t st –p x.y.z.t
[8bf963] x.y.z.t:3260, 1 iqn.2007-07.org.zereso:storage.disk1

Le Resource ID est ici 8bf963 et peut s’employer dans des commandes telles que :

initiator # iscsiadm –m node –r 8bf963

qui affiche le contenu des bases pour la ressource. L’équivalent sur Debian et RedHat est d’utiliser la syntaxe suivante :

initiator # iscsiadm –m node -T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t

En d’autres termes, dans les exemples de commandes suivantes, si vous utilisez une distribution OpenSuSE, il vous faudra remplacer les arguments -T.... -p ... par un simple -r suivi du Resource ID.

Tests de connexion et établissement de session

Pour l’instant, les modes d’authentification entre initiator et target ont été désactivés (les directives appropriées sont mises en commentaires dans les fichiers de configuration si vous avez respecté les consignes !). La connexion à la cible s’effectue par la commande suivante :

    initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t -l

Aucun diagnostic n’est affiché : c’est bon signe. Vérifions la connectivité de part et d’autre. Sur l’initiator, on peut vérifier la détection des nouveaux périphériques SCSI ainsi :

initiator # cat /proc/scsi/scsi
...
Host: scsi1 Channel: 00 Id: 00 Lun: 00
Vendor: IET     Model: VIRTUAL-DISK     ANSI SCSI revision: 04
Host: scsi1 Channel: 00 Id: 00 Lun: 01
Vendor: IET     Model: VIRTUAL-DISK     ANSI SCSI revision: 04

Ce qui montre clairement que l’initiator est connecté à une autre machine Linux qui a mis en œuvre le package iscistarget (le vendeur est IET et le modèle VIRTUAL-DISK). Si vous avez mis en œuvre le package iscsitarget, vous pouvez obtenir la liste des sessions actives sur la target :

target # cat /proc/net/iet/session
tid:1 name:iqn.2007-07.org.zereso:storage.disk1
  sid:844424934130176 initiator:iqn.2007-07.org.zereso:client.babbe4e54ab
    cid:0 ip:a.b.c.d state:active hd:none dd:none

Test fonctionnel

La commande fdisk –l vous permet d’obtenir les caractéristiques des nouveaux disques SCSI disponibles. On suppose que /dev/sdc est le nom d’un nouveau périphérique vu par l’initiator. Créez à l’aide de la commande fdisk une partition unique sur /dev/sdc et qui prend la totalité du disque, puis créez un système de fichiers :

initiator # fdisk /dev/sdc
...
(créez ici la 1ère partition primaire dont la taille est la taille du disque)
...
initiator # mke2fs -j /dev/sdc1
initiator # mkdir /iscsi
initiator # mount /dev/sdc1 /iscsi

Test de déconnexion

La déconnexion d’une cible s’effectue par la commande suivante :

	initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t -u

Vous pouvez vérifier de part et d’autre que les disques SCSI ne sont plus visibles de l’initiator et que la session courante a disparu sur la cible.

L’appel au script de démarrage permet de déconnecter toutes les sessions :
	# /etc/init.d/open-iscsi stop

ou

	# /etc/init.d/iscsi stop

5. Finalisation de la configuration de l’initiator

5.1 Connexion automatique au démarrage

L’objectif est de faire en sorte qu’au démarrage du démon iscsid, on puisse décider des cibles sur lesquelles il faut se connecter automatiquement. Pour cela, il faut modifier la valeur des paramètres contenus dans la base des nœuds (voir §3.2 pour la localisation de ces fichiers). Sur OpenSuSE, la base est constituée de fichiers au format Berkeley DB. Il faut donc utiliser la commande iscsiadm. Avec Debian et RedHat, ces bases sont des fichiers texte. On pourrait donc les modifier " à la main ". Néanmoins, nous allons aussi nous servir de iscsiadm. Pour afficher les paramètres courants pour la cible :

initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t
node.name = iqn.2007-07.org.zereso:storage.disk1
node.transport_name = tcp
...
node.conn[0].address = x.y.z.t
node.conn[0].port = 3260
node.conn[0].startup = manual
...

Pour changer le paramètre de démarrage (startup) et le passer en mode automatique, exécutons la commande :

 initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t \
             -o update –n "node.conn[0].startup" –v automatic

et testons :

# /etc/init.d/open-iscsi stop
# /etc/init.d/open-iscsi start

ou

# /etc/init.d/iscsi stop
# /etc/init.d/iscsi start

Vous pouvez alors vérifier que votre système accède aux périphériques iSCSI.

5.2 Connexion avec authentification

La spécification iSCSI propose une authentification via la méthode CHAP (Challenge Handshake Authentication Protocol – [RFCC]) et nécessite donc de définir un couple (utilisateur,mot_de_passe) sur l’initiator et la cible. Mais la spécification précise aussi qu’il existe deux modes d’authentification : Avec le mode in, c’est la cible qui doit s’authentifier auprès de l’initiator. Avec le mode out, c’est l’initiator qui doit s’authentifier auprès de la cible. NOTE Notons qu’en pratique les produits de constructeurs (EMC, NetApp, NASStor...) proposent le mécanisme CHAP en mode out et un mécanisme d’authentification mutuelle utilisant aussi CHAP. Ce mode n’est toutefois pas (ou mal, ça dépend des versions et des bug’s) supporté par l’implémentation open-iscsi. Chaque cas utilise un couple (utilisateur,mot_de_passe) différent. Pour illustrer ce mécanisme, nous allons mettre en œuvre l’authentification out. Si vous utilisez un périphérique de constructeur, configurez-le avec les outils proposés par ce constructeur. Si vous avez mis en œuvre le package iscsitarget, procédez comme suit :

• Sur la cible, éditez le fichier /etc/ietd.conf et décommentez la ligne IncomingUser dans la rubrique relative à la cible et indiquez le nom d’utilisateur et le mot de passe que vous souhaitez. Par exemple :

Target iqn.2007-07.org.zereso:storage.disk1
IncomingUser iscsi_u monsecret

• Déconnectez les initiators qui ont encore des sessions ouvertes sur la cible, puis relancez la cible :

    target # /etc/init.d/iscsi-target restart

Plaçons-nous sur l’initiator et vérifions que nous ne pouvons plus nous connecter à la cible :

initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t –l
iscsiadm: initiator reported error (5 – encountered iSCSI login failure)

Si nous avions placé la déclaration IncomingUser avant la déclaration de la cible (ligne Target) dans le fichier /etc/ietd.conf, nous ne pourrions même plus lancer la commande de découverte des cibles :

initiator # iscsiadm –m discovery –t st –p x.y.z.t
iscsiadm: Login failed to authenticate with target

Bien ! Nous allons maintenant configurer l’initiator pour qu’il puisse s’authentifier correctement auprès de la cible. Nous avons vu au §5.1 comment configurer les paramètres sur l’initiator (avec la petite différence de ligne de commande entre OpenSuSE et les autres distributions). Nous allons donc changer la méthode d’authentification :

 initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t \
                             -o update –n node.session.auth.authmethod –v CHAP

et donner la valeur aux paramètres username et password :

initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t \
                             -o update –n node.session.auth.username –v iscsi_u
initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t \
                             -o update –n node.session.auth.password –v monsecret

Vous pouvez à nouveau vous connecter à la cible :

initiator # iscsiadm –m node –T iqn.2007-07.org.zereso:storage.disk1 –p x.y.z.t –l
initiator # cat /proc/scsi/scsi
...

Note Pour activer l’authentification inverse, c’est-à-dire en mode in, il faudrait définir la valeur du paramètre OutgoingUser dans le fichier /etc/ietd.conf sur la cible, et définir les valeurs des paramètres username_in et password_in sur l’initiator (en lieu et place des paramètres username et password).

5.3 Montage automatique

Notre besoin est simple : on veut faire en sorte qu’au démarrage, les périphériques iSCSI soient montés automatiquement. Le réflexe de tout administrateur est de rajouter une ligne dans le fichier /etc/fstab. Mais, c’est sans prendre en compte le problème de la poule et de l’œuf ! En effet, l’accès aux périphériques iSCSI s’effectue à travers le réseau, or le montage des ressources listées dans /etc/fstab est effectué avant le lancement du réseau ! La solution consiste à ajouter l’option _netdev sur la ligne correspondant au montage des périphériques iSCSI (man mount(8)) dans le fichier /etc/fstab. Par exemple :

    /dev/sdc1    /point/de/montage    ext3    defaults,_netdev    0    2

Cette technique fonctionne correctement sur Debian et RedHat, mais pas sur OpenSuSE qui ne traite pas (plus) le paramètre _netdev. Comment faire dans ce cas ? Nous allons adopter la solution décrite dans le paragraphe suivant.

5.4 Montage automatique (suite !)

Si vous avez l’habitude d’utiliser des périphériques SCSI et en particulier si vos serveurs Linux se connectent à des SAN, vous avez vraisemblablement déjà été confrontés au problème de non-persistance des noms de périphériques SCSI. C’est-à-dire qu’entre deux redémarrages les mêmes périphériques physiques peuvent être associés à des noms logiques différents. Comment est-ce possible ? Le noyau Linux affecte un nom de périphérique logique SCSI (/dev/sda, /dev/sdb, etc.) aux périphériques physiques, dans l’ordre dans lequel ils sont détectés. Imaginez le scénario suivant :

• Dans la configuration courante, votre serveur dispose de deux disques SCSI en RAID 1 matériel : ils sont accessibles via /dev/sda.
• Le serveur accède à deux espaces de stockage disponibles sur le SAN : ces espaces sont accessibles via /dev/sdb et /dev/sdc.
• Maintenant, l’administrateur du SAN masque, pour des raisons de maintenance, l’espace qui était " vu " comme /dev/sdb : au prochain redémarrage, le deuxième espace sera associé, non plus à /dev/sdc, mais à /dev/sdb ! Le même phénomène peut arriver suite à des temps de latence soudain trop élevés sur le réseau, au démarrage.

C’est pour ces raisons que, depuis longtemps, certaines distributions vous incitent fortement à ne pas référencer les systèmes de fichiers par leur nom physique, de la forme /dev/XXX, mais soit par un label, soit par un UUID (Universal Unique IDentifier). Chaque système de fichiers dispose déjà d’un UUID. Pour l’obtenir, vous pouvez employer blkid, /ulib/udev/vol_id ou udevinfo par exemple:

initiator # blkid
...
/dev/sdc1: UUID="637b46fe-c1bb-4080-b21a-042116976ae6" TYPE="ext3"
...
initiator # udevinfo –q symlink –n /dev/sdc1
disk/by-id/scsi-1458585000000000000.....-part1
disk/by-path/ip-x.y.z.t:3260-iscsi-iqn.2007-07.org.zereso:storage.disk1-lun-1-part1
disk/by-uuid/637b46fe-c1bb-4080-b21a-042116976ae6

Les deux commandes donnent la même valeur d’UUID (qui en eût douté ?), à savoir 637b46fe-c1bb-4080-b21a-042116976ae6 ici. La ligne du fichier /etc/fstab ne doit donc plus faire référence à /dev/sdc1 dans notre exemple. Elle doit utiliser la valeur de l’UUID. Vous pouvez utiliser l’une des deux syntaxes suivantes :

	UUID=637b46fe-c1bb-4080-b21a-042116976ae6 /pt/montage ext3 defaults,_netdev 0 2

ou

	/dev/disk/by-uuid/637b46fe-c1bb-4080-b21a-042116976ae6 /pt/montage ext3 defaults,_netdev 0 2

Pour finir, vous allez me rétorquer que je n’ai pas montré comment régler le problème posé par OpenSuSE et décrit au §5.3 ! La réponse est simple : il suffit de remplacer l’option de montage _netdev par hotplug, signalant ainsi que le périphérique peut être absent au démarrage et ne sera monté que sur événement reçu par le sous-système hotplug. La ligne devient donc :

	UUID=637b46fe-c1bb-4080-b21a-042116976ae6 /pt/montage ext3 defaults,hotplug 0 2

5.5 Suivi des sessions

Il est possible d’obtenir la liste des toutes les sessions iSCSI actives, à l’aide de la commande :

initiator # iscsiadm –m session
tcp: [0] x.y.z.t:3260,1 iqn.2007-07.org.zereso:storage.disk1

L’affichage diffère selon les distributions, mais il est important de repérer l’identifiant de Session : c’est toujours la valeur entre crochets. On peut alors obtenir des statistiques réseau sur cette session :

initiator # iscsiadm –m session –r 0 –-stats
[00]
iSCSI SNMP:
  txdata_octets: 4492
  rxdata_octets: 311088
  ...

Bien que la mention iSCSI SNMP soit affichée, les informations retournées ne correspondent pas exactement à la MIB définie pour iSCSI (voir http://www.oidview.com/mibs/0/ISCSI-MIB.html), mais un " petit " script devrait permettre d’étendre l’agent SNMP pour qu’il retourne la valeur de ces compteurs. À l’heure actuelle, ce petit script n’existe pas....alors à vos claviers !

6. Cas concret : accès à un matériel propriétaire

Maintenant que nous en savons un peu plus sur le protocole iSCSI, sommes-nous suffisamment autonomes pour interconnecter notre machine Linux avec un matériel propriétaire ? Nous pensons que cette question apporte une réponse positive et nous allons l’illustrer brièvement en mettant en œuvre un produit de la gamme NASSTOR.

6.1 Description du matériel

Nous disposons donc d’un produit NASStor Bronze muni de 3 disques de 256 Go en RAID 5, 1 Go de RAM, 2 ports Ethernet Gigabit. L’O.S hôte est un Windows Server 2003 SP2 et le support iSCSI est assuré par un logiciel supplémentaire édité par la société FalconStor Software. Les fonctionnalités iSCSI assurées par cette configuration vont nous permettre d’exporter des partitions de disques, des fichiers, des volumes logiques... Le logiciel permet aussi – moyennant des licences supplémentaires (dommage !) – de réaliser, entre autres, de la réplication de volumes iSCSI, des clichés, des sauvegardes, des clusters, de l’équilibrage de charge avec gestion des priorités. La capture d’écran ci-dessous montre les possibilités de configuration de iSCSI :

6.2 Configuration

iSNS est désactivé par défaut – laissons-le ainsi. Notre machine Linux n’en a cure de toute façon. Le choix "Modèle de portail par défaut" permet de définir les adresses IP et les ports utilisés pour l’écoute des connexions entrantes sur la cible.

Dans notre exemple, le serveur NASStor dispose de deux adresses IP, et accepte les connexions sur le port par défaut: 3260/tcp. Une fois cette configuration effectuée, il est possible d’effectuer une " découverte " à partir de l’initiator:

    initiator # iscsiadm -m discovery -t st -p 10.0.0.107

La commande n’affiche pas de cible, mais la connexion n’a pas été refusée. Il faut ensuite définir les unités logiques qui seront exportées via iSCSI. On ne peut pas prendre des unités logiques déjà existantes (C:, D:, etc.), car, rappelez-vous, que, d’une part, iSCSI ne gère pas les accès concurrents par des clients multiples et que, d’autre part, nous allons recréer un système de fichiers de type ext3 à partir de l’initiator. Le logiciel de FalconStor vous permet néanmoins d’exporter des disques bruts (RD), des volumes bruts (RV), des pools, des disques de fichiers virtuels (VFD), comme le montre la figure suivante qui montre la création d’une unité logique de 100 Go prise sur l’espace disque non alloué :

Note Dans notre exemple, nous avons créé un deuxième volume exporté de taille identique, soit 100 Go.

Nous pouvons aussi créer un fichier qui sera exporté comme un périphérique iSCSI. Ici, nous créons un fichier de 100 Mo sur l’unité logique C: (le résultat est très similaire à ce que nous avons fait au §4.1 en créant un fichier avec la commande dd) :

Il faut maintenant déclarer l’initiator, ce que nous faisons, sans authentification pour commencer :

La cible a trouvé le nom iqn de l’initiator ! Le prochain écran nous permet ensuite de définir les droits de l’initiator nouvellement créé sur chacun des volumes exportés :

Ici, la première ressource (vol1) est exportée pour linux1 en lecture/écriture. Il en va de même pour le fichier de 100 Mo (vol3). Par contre, la deuxième ressource (vol2) est accessible en lecture seule. Il ne reste plus qu’à valider ce dernier écran puis... à tester !

6.3 Tests

Nous avons précédemment déclaré l’initiator comme s’appelant linux1, la commande de découverte montre bien les cibles disponibles pour notre initiator (regardez le nom iqn qui contient le nom du serveur et de l’initiator linux1) :

initiator # iscsiadm -m discovery -t st -p 10.0.0.107:3260
192.168.9.229:3260,0 iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1
10.0.0.107:3260,1 iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1

Allons-y pour une tentative de connexion :

initiator # iscsiadm -m node \
                -T iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1 \
                -p 10.0.0.107 –l
initiator # cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: HTS721010G9SA00  Rev: MCZO
  Type:   Direct-Access                    ANSI SCSI revision: 05
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: FALCON   Model: iSCSI DISK       Rev: V1.0
  Type:   Direct-Access                    ANSI SCSI revision: 04
Host: scsi1 Channel: 00 Id: 00 Lun: 01
  Vendor: FALCON   Model: iSCSI DISK       Rev: V1.0
  Type:   Direct-Access                    ANSI SCSI revision: 04
Host: scsi1 Channel: 00 Id: 00 Lun: 02
  Vendor: FALCON   Model: iSCSI DISK       Rev: V1.0
  Type:   Direct-Access                    ANSI SCSI revision: 04

initiator # mkfs -t ext3 /dev/sdb
...

Sur l’interface Web d’administration du NASStor, on peut vérifier l’état des connexions actives :

On se déconnecte pour ajouter le mode d’authentification CHAP :

    initiator # iscsiadm -m node \
          -T iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1 \
          -p 10.0.0.107 -u

Sur l’interface Web, on sélectionne la machine linux1 dans la liste des hôtes pour iSCSI et on sélectionne authentification CHAP. Il faut alors indiquer un nom d’utilisateur ainsi qu’un mot de passe (compris entre 12 et 16 caractères) :

Le mode découverte fonctionne, mais il est impossible d’établir une session :

initiator # iscsiadm -m discovery -t st -p 10.0.0.107:3260
192.168.9.229:3260,0 iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1
10.0.0.107:3260,1 iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1
initiator # iscsiadm -m node \
           -T iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1 \
               -p 10.0.0.107 -l
iscsiadm: initiator reported error (5 - encountered iSCSI login failure)

On modifie les paramètres de connexion à la cible, comme indiqué au §5.2 :

    initiator # iscsiadm -m node \
           -T iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1 \
           -p 10.0.0.107 -o update \
           -n node.session.auth.authmethod -v CHAP
initiator # iscsiadm -m node \
           -T iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1 \
           -p 10.0.0.107 -o update \
           -n node.session.auth.username -v falconusr
initiator # iscsiadm -m node \
           -T iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1 \
           -p 10.0.0.107 -o update \
           -n node.session.auth.password -v azertyuiop31
initiator # iscsiadm -m node \
           -T iqn.2000-03.com.falconstor:iss.nasstorbronze.linux1 \
           -p 10.0.0.107 -l

Nous pouvons alors re-tester l’établissement de session et accéder aux ressources. La commande fdisk -l nous montre 3 nouveaux disques /dev/sd{b,c,d} de tailles respectives 104.8 Go, 104.8 Go et 513 Mo. Nous pouvons les partitionner, créer des systèmes de fichiers... ça roule ! Eh non ! Attention, nous avons exporté le deuxième volume (donc /dev/sdc pour nous) en mode lecture seule (voir §6.2) : nous ne pourrons pas écrire dessus et, donc, il est impossible de le partitionner ou y créer un système.

7. Comparaison avec d’autres technologies

Il existe d’autres technologies sous Linux, qui permettent d’accéder, via le réseau, à des périphériques de type bloc. Le GNBD (voir [HS18]) en est un exemple. Le protocole iSCSI, sans carte Ethernet spécialisée, charge la CPU d’environ 20 à 30% selon les bancs de tests. En ce sens, il est moins performant que GNBD. Néanmoins, il est promu par un grand nombre d’acteurs qui souhaitent " vendre " du stockage et non pas du Fibre Channel, toujours très coûteux. Même si les prix baissent continuellement, les équipements Fibre Channel restent 2 à 3 fois plus chers que des équipements basiques pour iSCSI. Toutefois, si vous avez réellement besoin de performances et si vous optez pour iSCSI, il vous faudra acquérir des cartes Ethernet spécialisées (celles incluant des puces dédiées aux calculs de checksum IP, TCP et d’autres fonctionnalités telles le " zero-copy ", capables ainsi de décharger la CPU centrale). Des bancs de tests publiés en début d’année montrent en outre des performances supérieures au Fibre Channel si on dispose d’un réseau Ethernet 10 Gigabits. Mais le coût de ces cartes reste très élevé (environ 2500 euros). Vous pouvez aussi conserver une infrastructure Gigabit et réaliser une agrégation de ports (avec le protocole 802.3ad), puis vous pouvez séparer les flux à l’aide de VLAN. Vous disposez alors d’une solution à haute-disponibilité pour un coût abordable. Un grand merci à Franck Podenas de Boston Storage pour ses précieux conseils, sa disponibilité et sa connaissance du marché. Références [RFCA] http://www.ietf.org/rfc/rfc3720.txt [RFCB] http://www.ietf.org/rfc/rfc3721.txt [RFCC] http://www.ietf.org/rfc/rfc1334.txt [WIR] http://www.wireshark.org (anciennement Ethereal) [HS18] http://www.ed-diamond.com/ [SUSE] http://en.opensuse.org/Open-iSCSI_and_SUSE_Linux [RED4] http://people.redhat.com/mchristi/iscsi/RHEL4/doc/readme [RED5] http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/release-notes/RELEASE-NOTES-x86-en.html [DEB] http://packages.debian.org/unstable/net/open-iscsi [INFI] http://fr.wikipedia.org/wiki/InfiniBand