Comment déporter le stockage de votre PC sur un NAS via iSCSI

Comment déporter le stockage de votre PC sur un NAS via iSCSI

Plus besoin de multiplier les HDD !

Avatar de l'auteur
David Legrand

Publié dans

Hardware

22/05/2020 10 minutes
22

Comment déporter le stockage de votre PC sur un NAS via iSCSI

Lorsque l'on veut placer des données dans un NAS, le plus courant est d'utiliser un protocole de partage réseau, comme SMB/CIFS (via Samba). Mais cela ne couvre pas tous les besoins, n'est pas toujours la solution la plus adaptée. On peut ainsi opter pour iSCSI si on veut déporter un périphérique de stockage.

Les serveurs vendus comme des NAS permettent de stocker des données et les partager sur un réseau local, d'où leur nom : photos, musique, documents, vidéos, sauvegardes, etc. Nous vous avons d'ailleurs déjà expliqué comment configurer un tel appareil dans ce but.

Ce que l'on sait moins, c'est qu'ils peuvent également être utilisés comme des SAN tout-en-un, pouvant héberger des volumes de stockage déportés, que l'on peut connecter à n'importe quelle machine. Il n'y a alors plus qu'à les formater et ils sont utilisables comme un disque local. Pour cela, on utilise en général le protocole iSCSI, simple et peu coûteux.

iSCSI, késako ?

Ceux qui sont dans l'informatique depuis longtemps auront sans doute déjà entendu ce nom, ou celui de sa version « locale », SCSI (Small Computer System Interface). Créé à la fin des années 80 et très populaire dans les 20 ans qui suivirent, il a progressivement été remplacé (S-ATA, SAS, etc.), donnant naissance à de nombreux dérivés.

iSCSI en est un, pensé pour exécuter les commandes de ce standard sur un réseau IP (d'où le « i », pour Internet). Il permet de déporter un périphérique de stockage dans un serveur. Il s'agit d'une solution de type Block Storage, qui est donc à mettre en œuvre au sein d'un SAN (Storage Area Network). Des notions détaillées dans un précédent article.

Pour expliquer cela plus simplement : c'est comme si vous ajoutiez un HDD/SSD à votre ordinateur, mais plutôt qu'il ne soit relié avec un câble S-ATA ou USB, il l'est à travers le réseau local. Vous le voyez néanmoins comme un périphérique de stockage normal, que vous devez formater et où vous allez placer des données. 

Une solution efficace en termes de latence et de débit, permettant de mettre un chiffrement côté client, ce qui peut avoir ses avantages. Le tout en continuant à gérer les sauvegardes et instantannés côté serveur. Bien entendu, les performances dépendront de la qualité de votre réseau. Privilégiez donc une connexion filaire, à 1 Gb/s ou plus.

Si iSCSI est souvent utilisé dans le cadre de plateformes virtualisées comme manière de centraliser un stockage déporté, c'est simple à mettre en place pour un usage des plus basiques. Voyons ce qu'il en est sur un DS3018xs de Synology, ce qui sera identique à d'autres modèles de la marque ou d'Asustor et QNAP par exemple.

Stockage iSCSI SMB
SMB/CIFS ou iSCSI : deux méthodes différentes pour stocker des donnés sur un serveur

LUN, initiateur, cible, IQN et CHAP

Pour cette série d'essais, nous partirons du principe que vous disposez d'un NAS configuré et que vous avez déjà quelques notions de base concernant le fonctionnement d'un réseau local. Mais iSCSI a ses propres termes qu'il faut apprendre à comprendre avant de commencer, rien de bien compliqué : 

  • Initiateur : C'est le client, qui initie les commandes SCSI à exécuter
  • LUN : Logical Unit Number, identifiant d'un espace de stockage déporté
  • Cible (Target) : C'est le serveur, qui recevra les commandes à exécuter
  • IQN : iSCSI Qualified Name, adresse de la cible iSCSI

Dans le cadre d'un NAS comme nous allons le pratiquer ici, il est possible de créer une ou plusieurs cibles, pouvant elle-même contenir un ou plusieurs LUN. On dit alors que ces LUN sont « mappés » à une cible. L'initiateur est, lui, en général une application permettant de se connecter aux LUN.

Il est tout à fait possible que plusieurs initiateurs se connectent à une cible en même temps. Il s'agit du MultiPath I/O (MPIO), qui doit être activé tant pour le serveur que le client et supporté par le système de fichiers utilisé. C'est notamment possible avec ESXi de VMWare. Mais aussi des serveurs Windows qui gèrent également le Multiple Connections per Session (MC/S). Des solutions surtout utilisées pour des besoins professionnels.

L'IQN est composé de la sorte :

iqn.date.autorité:identifiant

La RFC 3720 précise que l'autorité doit être référencée comme un nom de domaine inversé devant être lié à la cible. L'identifiant peut être une suite de plusieurs éléments séparés d'un point. La date, elle, doit être au format yyyy-mm et correspondre à une période pendant laquelle l'autorité détenait le nom de domaine. Plus exactement le premier mois où elle l'a possédé au 1er jour du mois à 00:01 GMT. 

Dans la pratique, et sur un réseau local, vous pouvez utiliser un peu ce que vous voulez. Voici un exemple type d'IQN généré par notre NAS Synology :

iqn.2000-01.com.synology:ds3018xs.Target-1.2486547234

Pour notre premier exemple du jour, nous utiliserons :

iqn.2020-05.local.nas:fichiers-de.test

Enfin, notez qu'iSCSI dispose de sa propre méthode d'authentification, assurant que seuls certains initiateurs peuvent se connecter à une cible : CHAP  (Challenge Handshake Authentication Protocol). La vérification peut être mutuelle ou non. Si oui, la cible doit également s'identifier auprès de l'iniateur.

Création d'une cible, avec ou sans CHAP

L'application iSCSI Manager est installée par défaut au sein des NAS de Synology. Elle propose un tableau de bord, une liste de vos cibles, LUN, un log (journal) et des paramètres. Il n'est pas nécessaire d'y toucher, nous ne les détaillerons pas ici. On trouve également une gestion des snapshots (instantanés).

Ce dernier point est d'importance, car il permet de capturer (via Replication Service) des images régulières des données des LUN pour les restaurer en cas de problème. Le client connecté n'ayant accès qu'au contenu du LUN, il ne peut modifier les autres données du serveur, ce qui est pratique pour se prémunir d'attaques de type ransomware. Vous pouvez également effectuer des sauvegardes via Synology HyperBackup, ou son équivalent chez les autres constructeurs de NAS. 

Dans la section dédiée aux cibles, cliquez sur Créer. Un IQN sera généré par défaut, ainsi qu'un nom que vous pouvez modifier à votre guise. Si vous voulez disposer d'une authentification via CHAP, vous pouvez indiquer un nom d'utilisateur et un mot de passe (de 12 à 16 caractères).

Ils seront nécessaires à l'initiateur pour se connecter.

iSCSI Création Target Synology

Une fois la cible créée vous aurez accès à des paramètres complémentaires : mapper des LUN, définir quels initiateurs peuvent se connecter ou non, quels sont les connexion réseau pouvant être utilisées, etc. Vous pouvez par exemple utiliser un port à 10 Gb/s pour vos accès iSCSI et garder ceux à 1 Gb/s pour des besoins plus courants.  

Mappage d'un LUN

L'interface vous propose ensuite de créer un LUN, d'en mapper un existant ou de procéder plus tard. Dans notre cas, nous choisissons la première option. Il faut là aussi choisir un nom à cet espace de stockage.

N'oubliez pas que plusieurs LUN peuvent être mappés sur une même cible, trouvez donc une dénomination qui convient à l'usage visé. Choisissez le volume sur lequel vous voulez créer votre LUN, sa capacité, le type d'allocation d'espace. Le Thick provisioning est sélectionné par défaut, car plus performant, celui que nous utiliserons.

Pour faire simple : tout l'espace demandé est préalloué au LUN même s'il ne contient pas de données. Le Thin Provisionning permet à l'inverse d'effectuer cette allocation au fur et à mesure. C'est plus flexible (et nécessaire pour les instantanés), mais aussi moins performant et plus risqué : si vous allouez 10 Go à dix LUN sur un espace de 50 Go, dès que cette limite sera dépassée... vous aurez un problème.

Les options avancées permettent de gérer ces cas, elles sont détaillées par ici

iSCSI LUN SynologyiSCSI LUN Synology
Il faudra trouver un meilleur nom à notre LUN pour s'y retrouver facilement

Une fois le LUN créé, vous aurez accès à des paramètres et fonctionnalités complémentaires. Vous pouvez ainsi cloner un LUN, gérer sa réplication et ses instantanés (snapshots) etc. 

Connexion à une cible depuis l'initiateur iSCSI de Windows

Windows est livré par défaut avec un initiateur iSCSI. Il suffit de se rendre dans le menu Démarrer, taper « iSCSI » et l'interface de l'application (iscsicpl.exe) apparait. 

Son utilisation est assez simple : tapez l'adresse IP de votre NAS dans le champ « Cible » et toutes les cibles iSCSI qu'il contient devraient s'afficher. Il vous suffit de choisir laquelle connecter. Dans l'onglet Découverte, vous pourrez décider si vous voulez que l'IP soit mise de côté pour plus tard, considérée comme un portail connu.

Cet initiateur contient de nombreux paramètres : de l'initiateur (nom, CHAP, etc.) ou des cibles pour la connexion (authentification par exemple). Vous pourrez également y indiquer un serveur RADIUS. Une fois la cible connectée, elle apparaîtra comme un espace de stockage à formater.

Vous pourrez le faire avec l'outil de gestion des disques de l'application Gestion de l'ordinateur (clic droit sur Ce PC dans l'Explorateur de fichiers, puis Gérer). 

Initiateur iSCSI Windows 10
Vous pouvez vous connecter directement à une cible ou cliquer sur Terminer pour accéder à ses propriétés

Connexion à une cible depuis l'initiateur iSCSI de Debian/Ubuntu

Si vous êtes sous Linux, il faudra le plus souvent installer l'initiateur iSCSI. Reportez-vous donc à la documentation de votre distribution. Sur Debian et ses dérivés tels qu'Ubuntu ou Rasbpian (que nous avons utilisé dans notre cas depuis un Raspberry Pi), cela donne :

sudo apt install open-iscsi
sudo service iscsi start

La procédure est la même que sous Windows, mais en ligne de commandes plutôt que via une interface graphique. Il faut donc là encore lister les cibles (en adaptant à votre adresse IP :

sudo iscsiadm -m discovery -t sendtargets -p 192.168.1.168

Vous pouvez vous y connecter :

sudo iscsiadm -m node -T iqn.2020-05.local.nas:fichiers-de.test --login

Vérifier la connexion avec la commande suivante :

sudo iscsiadm -m session

Et que le volume distant est accessible : 

sudo fdisk -l

Disk /dev/sda: 10 GiB, 10737418240 bytes, 20971520 sectors
Disk model: iSCSI Storage
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

Vous déconnecter :

sudo iscsiadm -m node -T iqn.2020-05.local.nas:fichiers-de.test --logout

Vous pouvez alors formater le volume, monter ses partitions et l'utiliser là encore comme s'il était présent au sein de la machine. Les paramètres de l'initiateur se trouvent dans un fichier à éditer :

sudo nano /etc/iscsi/iscsid.conf 

Vous pouvez par exemple demander le démarrage automatique des connexions :

node.startup = automatic

Mais aussi les paramètres CHAP, les délais d'attente, etc. Notez que certaines distributions permettent même une installation sur une cible iSCSI, nous en reparlerons dans un prochain article.

Écrit par David Legrand

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

iSCSI, késako ?

LUN, initiateur, cible, IQN et CHAP

Création d'une cible, avec ou sans CHAP

Mappage d'un LUN

Connexion à une cible depuis l'initiateur iSCSI de Windows

Connexion à une cible depuis l'initiateur iSCSI de Debian/Ubuntu

Fermer

Commentaires (22)


Merci pour cet article, j’apprends des trucs sur mon NAS avec ça !



Par contre, je comprends assez moyennement l’utilité ou les usages que des particuliers pourraient avoir d’une telle situation et d’ailleurs, est-ce possible au delà du seul réseau local ? Peut-on imaginer un ordinateur portable en mobilité avec ce disque qui est atteignable sur internet ?



Thoscellen a dit:





ça doit être possible (le port par défaut d’iSCSI est 3260), mais entre la latence et le débit il vaudra mieux être en fibre de bout en bout. L’usage pour le particulier dépend du particulier ;) C’est simplement une autre manière de déporter les données dans le NAS. Le partage Samba est classique, mais quand on veut surtout étendre le stockage d’une machine (sans forcément de partage) ce n’est pas la bonne solution. Le cas du Raspberry Pi évoqué dans la section Linux est un exemple courant notamment.


Très pratique le iSCSI, je m’en sers sur des Serveurs Windows pour dédié un “disque” à la sauvegarde, et comme Windows Server préfère dédier tout un disque, je passe via iSCSI pour que Windows croit utiliser un disque dur dédié alors qu’en réalité c’est juste une partie du stockage du NAS ^^



Thoscellen a dit:


Merci pour cet article, j’apprends des trucs sur mon NAS avec ça !Par contre, je comprends assez moyennement l’utilité ou les usages que des particuliers pourraient avoir d’une telle situation et d’ailleurs, est-ce possible au delà du seul réseau local ? Peut-on imaginer un ordinateur portable en mobilité avec ce disque qui est atteignable sur internet ?




C’est du protocole qui envoie du bloc et pas du fichier. T’as plus de perf’ avec ce genre de chose. Par contre c’est conseillé d’utiliser ça avec un réseau performant et si possible dédié avec des MTU de 9000. C’est quand même plutôt orienté SAN.



La grosse différence c’est que du iSCSI tu peux pas l’utiliser avec plusieurs machines contrairement a un protocole de “partage”. Sauf exception avec des systèmes qui gère le multipath iscsi sous réserve d’avoir un filesystem montable sur plusieurs systèmes à la fois comme VMFS de VMWare ou CSV de M$… donc les hyperviseur en cluster au final. C’est une sorte d’attachement direct via réseau. C’est une brique de l’hyperconvergeance.



Thoscellen a dit:


Merci pour cet article, j’apprends des trucs sur mon NAS avec ça !Par contre, je comprends assez moyennement l’utilité ou les usages que des particuliers pourraient avoir d’une telle situation et d’ailleurs, est-ce possible au delà du seul réseau local ? Peut-on imaginer un ordinateur portable en mobilité avec ce disque qui est atteignable sur internet ?
Bien utiliser ça apporte de la sécurité : Si chaque PC monte son iSCSI au démarrage :




  • En sauvegardant le NAS tu sauvegardes tous les PCs,

  • si on te vole un PC tu changes le mdp iSCSI et tes données sont tranquilles.

  • Si tu as chiffré ta partition lors du formatage le vol du NAS seul ne permet pas d’accéder aux données (ça ce n’est pas possible avec un partage réseau),

  • si tu n’enregistres pas le mdp iSCSI et le saisi à chaque démarrage le vol du NAS et des PC ne suffit pas pour accéder aux données.



Salut David, la manip Ubuntu / debian est adaptable sur MacOs ?



the_Grim_Reaper a dit:





De mémoire il n’y a pas d’initiateur natif, mais il y a des applications qui le proposent (a voir dans le Mac App Store je ne peux pas verif8er tout de suite là)


Sur Linux, pour tous les volumes iSCSI, je vous invite à configurer le MPIO en mode “un chemin” avec le paramètres “queue if no path”.
Ca évite que le système de fichiers passe en lecture seule sur une IO un peu molle du genou (problème courant sous vSphere pour RHEL6, mais en fait le problème arrive aussi sur les RHEL 8 par exemple).



https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/dm_multipath/queueifnopath_issues




Thoscellen a dit:


Merci pour cet article, j’apprends des trucs sur mon NAS avec ça !Par contre, je comprends assez moyennement l’utilité ou les usages que des particuliers pourraient avoir d’une telle situation et d’ailleurs, est-ce possible au delà du seul réseau local ? Peut-on imaginer un ordinateur portable en mobilité avec ce disque qui est atteignable sur internet ?




Non. T’as moins de performance qu’une clef usb. Le iSCSI a besoin d’un réseau prédictif en terme de latence et de débit.
Par contre, tu peux imaginer un pc portable qui se sauvegarde sur le disque dur iSCSI quand tu es chez toi, et il ne le fait pas quand tu es à l’extérieur parce qu’il ne trouve pas le disque.
L’énorme avantage du iSCSI, c’est que le volume est local. Si tu as un bon SAN, tu as de meilleures performances qu’un disque physique, et en plus tu peux le répliquer en temps réel ou en faire des instantanés qui soient indépendants du système: en cas de virus, le virus ne peut pas atteindre l’interface de gestion pour péter tes instantanés.


(skyzocomm’)



patos a dit:


Si tu as un bon SAN, tu as de meilleures performances qu’un disque physique, et en plus tu peux le répliquer en temps réel ou en faire des instantanés qui soient indépendants du système: en cas de virus, le virus ne peut pas atteindre l’interface de gestion pour péter tes instantanés.




Bien vu, créer des snapshots côté Serveur NAS c’est bien pratique (je le fais avec des NAS Synology pour sauvegarder les LUN et avoir x copies)


Mais où sont mes fichiers ?
Ah oui, iSCSI.



Merci pour l’article, très intéressant comme solution.


Pourrais t-on avoir un comparatif de perf entre les 2, Samba vs iSCSI ?
Et aussi si on pouvais avoir avec différent MTU ?
merci :)



ashlol a dit:


Pourrais t-on avoir un comparatif de perf entre les 2, Samba vs iSCSI ? Et aussi si on pouvais avoir avec différent MTU ? merci :)




Non, ce n’est pas pareil…
Les NAS et les SAN sont souvent différents dans leur traitement (pas de gestion des droits d’accès en iSCSI ou de la concurrence, pas de gestion de TRIM en NAS ni de multipath explicite, …). Tu peux faire un test de copie et un d’accès aléatoire, mais ça ne voudra rien dire, car le iSCSI, pour y accéder, tu auras besoin de toute une configuration, alors que le NAS, t’aura besoin d’un utilisateur mot de passe, point.



Tout comme le MTU, ce n’est pas nécessaire de comparer: tu fais du stockage réseau? Tu mets 9000, point. Parce que quand tu lis un bloc de 4K sur ton SAN comme tu le ferais sur ton disque dur, tu ne traites qu’un paquet et non 34 avec un MTU classique à 1500: ta charge processeur te diras merci.



patos a dit:


Non, ce n’est pas pareil… Les NAS et les SAN sont souvent différents dans leur traitement (pas de gestion des droits d’accès en iSCSI ou de la concurrence, pas de gestion de TRIM en NAS ni de multipath explicite, …). Tu peux faire un test de copie et un d’accès aléatoire, mais ça ne voudra rien dire, car le iSCSI, pour y accéder, tu auras besoin de toute une configuration, alors que le NAS, t’aura besoin d’un utilisateur mot de passe, point.Tout comme le MTU, ce n’est pas nécessaire de comparer: tu fais du stockage réseau? Tu mets 9000, point. Parce que quand tu lis un bloc de 4K sur ton SAN comme tu le ferais sur ton disque dur, tu ne traites qu’un paquet et non 34 avec un MTU classique à 1500: ta charge processeur te diras merci.




Alors déjà pas la peine de m’agresser pour répondre hein…
L’article parle ici de stockage icsi dans un NAS donc pas question d’usage spécifique type server SAN en entreprise et au final la comparaison iscsi à du sens car pour un utilisateur il s’en fou que ce soit iscsi ou partage samba pour du stockage.
Un utilisateur ne fais jamais que du stockage avec son réseau donc de mettre un MTU à 9000 peux avoir d’autre implications comme une augmentation du ping sur les jeux en réseau…



tinc a dit:


Mais où sont mes fichiers ? Ah oui, iSCSI




J’ai mis un petit temps à comprendre, bien vu :francais:


Salut, pour utilisation de stockage et sauvegarde (en RAID) de photos RAW avec traitement directement sur le NAS, c’est conseillé ?



babeuloula a dit:





Ce sera dans tous les cas plus performant que via un partage Samba classique, ça peut être une bonne solution si tu n’utilises que depuis une machine (avec la possibilité de déconnecter la cible de la machine et la connecter à un autre PC si tu veux par exemple).



patos a dit:


Non, ce n’est pas pareil… Les NAS et les SAN sont souvent différents dans leur traitement (pas de gestion des droits d’accès en iSCSI ou de la concurrence, pas de gestion de TRIM en NAS ni de multipath explicite, …). Tu peux faire un test de copie et un d’accès aléatoire, mais ça ne voudra rien dire, car le iSCSI, pour y accéder, tu auras besoin de toute une configuration, alors que le NAS, t’aura besoin d’un utilisateur mot de passe, point.Tout comme le MTU, ce n’est pas nécessaire de comparer: tu fais du stockage réseau? Tu mets 9000, point. Parce que quand tu lis un bloc de 4K sur ton SAN comme tu le ferais sur ton disque dur, tu ne traites qu’un paquet et non 34 avec un MTU classique à 1500: ta charge processeur te diras merci.




Mais dans ce cas, il faut le switch/routeur qui va bien ce qui ne se trouve pas dans les petits switchs/routeurs grand public.


Je sais même pas comment ça se passe pour router des trames de 9000… C’est possible au moins ?



Mais faut garder a l’esprit que c’est un protocole taillé pour du SAN. C’est pas user friendly et pas fait pour être coupé quand on veut. Ya un ordre d’allumage ou d’arrêt a prendre en compte selon la configuration. Ça vaut pas le coup de basculer sur ce genre de chose si c’est juste pour grappiller 10mo/s en crête.



ashlol a dit:


Alors déjà pas la peine de m’agresser pour répondre hein… L’article parle ici de stockage icsi dans un NAS donc pas question d’usage spécifique type server SAN en entreprise et au final la comparaison iscsi à du sens car pour un utilisateur il s’en fou que ce soit iscsi ou partage samba pour du stockage. Un utilisateur ne fais jamais que du stockage avec son réseau donc de mettre un MTU à 9000 peux avoir d’autre implications comme une augmentation du ping sur les jeux en réseau…




Je t’agresse pas, désolé que tu le lises ainsi.
Sauf que nous sommes plus évolués que des utilisateurs, donc les nuances ont du sens: le ISCSI est nu, alors que Samba est habillé.
Et une augmentation du ping, non, désolé, y’a pas de rapport avec un MTU à 9000. Par contre, il faut que tous les équipements le gèrent et soient dimensionnés pour… Si ton ping augmente, c’est que ton routeur s’agenouille. En général, on mets une carte réseau spéciale iSCSI et celle-ci est en MTU 9000, alors que la carte réseau PC reste en 1500 par défaut. Au moins nous sommes sur que le iSCSI ne sorte pas par erreur (et même ça fini très souvent dans un vlan).




(quote:47187:Fab’z)
Je sais même pas comment ça se passe pour router des trames de 9000… C’est possible au moins ?Mais faut garder a l’esprit que c’est un protocole taillé pour du SAN. C’est pas user friendly et pas fait pour être coupé quand on veut. Ya un ordre d’allumage ou d’arrêt a prendre en compte selon la configuration. Ça vaut pas le coup de basculer sur ce genre de chose si c’est juste pour grappiller 10mo/s en crête.




Ca passe mais on le fait pas. Les fous qui ont les moyens de payer des interlans pour du iSCSI font du VxLAN, qui est une sorte de VLAN over UDP. Ce sont des switchs à 5000€ les plus mauvais, pour des liaisons qui te coutent 2 ou 3000€/mois donc bon ^^; Un autre monde….


(skyzocom le retour)