Comparatif de NAS d'entrée de gamme 2 baies

Comme nous l'avons vu, les performances du protocole réseau SMB sont loin d'être exceptionnelles, particulièrement lorsque l'on regarde du côté du transfert des petits fichiers. IOmeter nous a permis d'entrevoir un léger mieux de ce côté en supprimant une partie de la lourdeur du protocole, mais l'on peut se demander ce qu'il en serait avec un autre protocole réseau plus performant. C'est l'occasion pour nous de faire le point sur le iSCSI.

C'est quoi le iSCSI ?

Premier point, iSCSI n'est pas en soit un protocole de transfert de fichiers ! Il s'agit d'une version réseau du protocole SCSI (utilisé de nos jours dans SAS, la version "serveur" du Serial ATA) qui permet de contrôler des disques par le réseau.

C'est un point fondamental à comprendre : si comme nous le verrons iSCSI peut apporter un gros mieux dans les performances, il amène avec lui un grand nombre de contraintes, dont beaucoup repousseront la majorité des utilisateurs potentiels de ces solutions !

Contrairement aux autres protocoles comme SMB (Windows), AFP (MacOS X), NFS (Linux) ou même FTP, le but de iSCSI est de faire croire à un ordinateur qu'un de ses disques locaux est en réalité un disque distant. Pour bien comprendre, regardons en pratique comment cela se configure, nous avons pris pour l'exemple le Synology DS212j.

Un LUN en iSCSI

Il nous faut d'abord créer ce que l'on appelle un LUN, il s'agit en pratique du périphérique SCSI virtuel que l'on adressera par la suite. Deux choix sont alors possibles :
- Niveau bloc : On crée un (ou plusieurs) LUNs directement sur les disques du NAS, de la même manière que l'on créerait un volume RAID. C'est le choix à utiliser pour maximiser les performances.
- Niveau fichier : On crée un (ou plusieurs) LUNs sous la forme d'un fichier disque (de la même manière qu'une image iso ou qu'un disque dur virtuel) qui sera répliqué sur un volume RAID existant. C'est le choix à utiliser pour maximiser la flexibilité, au détriment des performances.

Nous avons choisi pour cet exemple le niveau bloc.



Une fois la procédure terminée, on dispose d'un LUN (un disque virtuel stocké en mode bloc sur l'intégralité de nos disques, protégé par un RAID 1), mais aussi de ce que l'on appelle un Target qui a été crée automatiquement, c'est la cible à laquelle on va se connecter.

Initiateur iSCSI sous Windows

Une fois l'étape réalisée sur le NAS, il faut configurer l'initiateur iSCSI. C'est un pilote qui permettra de monter notre disque distant comme un disque dur. Nous utilisons pour cet exemple le connecteur fourni par Microsoft avec Windows. Au premier lancement, il vous sera demandé de démarrer le service iSCSI.


La configuration sous Windows 7 a été largement simplifiée. Dans le premier onglet, on tape simplement l'IP du NAS qui va détecter automatiquement notre target. Il suffit de cliquer pour se connecter.


C'est là que les choses se complexifient puisqu'il faut maintenant… formater notre disque ! On se dirige alors vers l'outil de "Gestion des disques". Un "disque" de 1.85 To s'est ajouté dans la liste, à côté de vos disques durs locaux. De la même manière que pour un disque local, il faudra l'initialiser, et le formater. Côté serveur, le volume est un RAID 1, mais pour Windows tout ceci est transparent : il ne voit en pratique qu'une partition NTFS de plus.


C'est ici que l'on peut résumer la différence fondamentale entre un protocole comme SMB et iSCSI. SMB, comme d'autres, est une technologie NAS (serveur de fichier réseau). iSCSI est ce que l'on appelle une technologie SAN (serveur de "blocs" disques en réseau).

Performances

Quid des performances alors ? Nous avons comparé les performances en lecture (nous reviendrons en dessous sur le problème de l'écriture) sur nos copies de fichiers via SMB et iSCSI.


Merci d'utiliser un navigateur compatible HTML5 pour voir le graphique.
[ Gros ]  [ Moyens ]  [ Petits ]
Si l'on regarde d'abord les transferts sur de gros fichiers, surprise : SMB est plus efficace ! Encore plus intéressant, le cas des fichiers de taille moyenne : avec peu d'accès simultanés, les performances en iSCSI sont très limitées, ce n'est qu'a 8 threads que l'on dépasse significativement les performances de SMB.

Le cas des petits fichiers est bien sur beaucoup plus parlant. Dans ce cas ou SMB, on vous l'a répété au fil des pages de cet article, est particulièrement désavantagé, on voit d'excellentes performances. Avec 16 threads, iSCSI est 5.3x plus rapide que son concurrent. Avec un seul thread, on est 2.37x plus rapide, ce qui est déjà assez bien ! Vous remarquerez qu'ici, les performances suivent de manière assez proche celles que l'on avait relevées sous Iometer avec les accès séquentiels sur des blocs de 4 Ko. Logique en somme, puisque c'est ce que nous essayions de mettre en avant !

Un choix simple… ou pas

Nous nous sommes pour l'instant retenus de parler des contraintes apportées par iSCSI. Elles sont nombreuses et souvent mal comprises.

Nous avons jusqu'ici considéré les NAS comme des serveurs qui permettent de partager des fichiers entre plusieurs machines. Le cas d'utilisation typique du iSCSI est différent : il s'agit de monter un volume (LUN) sur une… et une seule machine.

En effet, notre NAS agit ici comme un contrôleur RAID en réseau, ni plus ni moins (un SAN). Il n'a aucune idée de ce qui se passe sur les disques au-delà des blocs qu'on lui demande de lire ou d'écrire. Vous ne pourrez donc pas cumuler un protocole "classique" type SMB et iSCSI pour accéder aux mêmes données.

Pourquoi ne peut-on pas monter un volume iSCSI en simultanée sur plusieurs machines ? On le peut, et c'est bien là qu'intervient la confusion ! iSCSI est tout à fait capable de gérer plusieurs machines qui accèdent en simultanée à un disque. Dans notre cas, le problème vient du système de fichier que nous avons choisi. Nous avons formaté notre disque en NTFS qui n'est pas un système de fichiers prévus pour des usages ou plusieurs machines peuvent écrire des données simultanément sur un disque. Si les choses se passeront relativement correctement lorsque l'on ne fait que des accès en lecture, effectuer des accès en écriture va rapidement poser des problèmes avec NTFS qui n'est pas prévu pour ce cas d'utilisation. Un bon exemple est la manière dont Windows peut décider d'écrire les fichiers sur le disque. Vous aurez remarqué que nous n'avons indiqué que les performances en lecture. Voici ce qui se passe en pratique lorsque nous tentons d'écrire 1 Go de données sur notre LUN iSCSI :


Comme vous pouvez le voir avec le logiciel NetMeter que nous utilisons ici, l'initiateur iSCSI de Microsoft et Windows prennent leur temps pour écrire les données de par l'utilisation d'un cache en écriture. Pourtant ce n'est pas exactement ce qui se passe en pratique pour l'utilisateur. En effet, l'opération de copie est ici instantanée. Windows copie les données que nous souhaitons copier en mémoire (le côté instantané venant du fait que nous utilisons, pour rappel, en source un RAMdisk), puis les écrit au rythme qu'il le souhaite. Une stratégie d'optimisation qui ne pose aucun problème. Si l'on essaye de lire un des fichiers copiés, il est accessible. En réalité, on ne le lira pas sur le disque distant, mais on lira en mémoire !

Pour utiliser iSCSI avec de multiples "machines", il faut utiliser un système d'exploitation prévu à cet effet, et un système de fichiers qui l'est aussi. C'est par exemple le cas de l'OS ESX de VMware, qui utilise un système de fichiers gérant la concurrence baptisé VMFS.

En soit iSCSI propose plusieurs cas d'utilisations qui peuvent avoir un intérêt fort, citons en deux :
- Consolider le stockage local de multiples postes sur un serveur. Outre une partition supplémentaire montée sur chaque machine, il est également possible de booter de manière distante sur un volume iSCSI, et donc disposer de machines dépourvues de disque local.
- Relier un serveur de stockage (un NAS qui sera en pratique un SAN dans ce cas) à un serveur de calcul.

Des usages qui ont leur intérêt en entreprise mais qui au final apportent beaucoup plus de contraintes qu'autre chose dans le cas d'une utilisation pour des particuliers, le public avant tout visé par les NAS que nous avons testés ici. Dans notre cas, iSCSI n'est en rien une solution aux problèmes de lenteur de SMB, nous ne nous attarderons donc pas plus sur le sujet !