ZFS over iSCSI.
Depuis quelques mois maintenant j'utilise ZFS avec satisfaction sur un "serveur" de fichiers qui est un PC à base de Core i5-4400 fonctionnant sous Ubuntu 22.04.4 LTS.
J'utilise du Raidz1 (équivalent Raid5) sur un pool de 3 disques mécaniques (HDD) ainsi qu'un pool de 5 disques M2.Sata sur une carte PCIe.
C'est sur ce dernier pool que je pratique le plus de tests.
Tout se passe correctement si ce n'est les snapshots, j'ai lu qu'ils ne sont pas censés occuper de place sur le système de fichiers, j'ai une expérience contraire mais peut être ai je mal compris, je verrai plus tard, d'autant plus que ces snapshots ne sont pas déplaçables ailleurs, ils sont forcément sur le système de fichier ou pool.
Ce n'est pas le sujet du jour. Aujourd'hui je teste la création d'un pool NFS Raidz1 avec un volume qui sera offert en cible iSCSI à un client Windows.
Pourquoi iSCSI et pas NFS ou SMB ? D'une part parce que c'est déjà testé et que ça fonctionne parfaitement de la façon la plus simple qui soit mais d'autre part je souhaite que côté client l'espace NFS soit en mode bloc afin d'être manipulé comme on veut, par exemple pour un chiffrement.
Première étape voir ce que j'ai en pools ZFS via
zpool list
Le pool visé est nommé Raid5_5x238Go_M2, il est déjà occupé par un dataset que je détruis pour repartir sur un espace disponible maximal.
Ensuite je sais que ce système ne gère pas iSCSI pour l'instant, je l'installe donc
apt install tgt
Ensuite, création de la cible iSCSI qui sera nommée r5m2.vhdx
tgtadm --lld iscsi --op new --mode target --tid 1 --targetname iqn.2024-09.local.server.iscsi:r5m2.vhdx
il faut maintenant faire pointer cette cible vers un volume ZFS, comme j'ai détruit le dataset qui existait j'ai la place pour créer un volume qui occupe les 1.16 To disponibles, cependant je rencontre un problème avec
zfs create -V 1100G Raid5_5x238Go_M2/vhdx
Après une recherche sur internet je trouve un autre utilisateur ayant rencontré le même problème, on lui avait conseillé d'utiliser un commutateur supplémantaire '-s' et effectivement cela fonctionne dans mon cas également
zfs create -s -V 1100G Raid5_5x238Go_M2/vhdx
Je contrôle immédiatement que consécutivement à la création du volume ZFS un /dev est bien créé et c'est le cas. Il est donc possible de lier iscsi au volume ZFS
tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 --backing-store /dev/zvol/Raid5_5x238Go_M2/vhdx
affichage des informations sur la cible
L'étape suivante consiste à fixer la configuration afin que la cible iSCSI soit disponible après un reboot serveur
tgtadm --lld iscsi --op bind --mode target --tid 1 --initiator-address ALL
et on l'exporte dans un fichier de conf
tgt-admin --dump | tee /etc/tgt/targets.conf
un init 6 plus tard on vérifie que le serveur SCSI est bien disponible sur le port 3260
Ok, on va donc passer côté client Windows 10 et monter la cible ainsi offerte
on saisie l'adresse IP du serveur, la découverte et le montage, en l'absence d'authentification, se réalisent en un clic
côté gestionnaire de disques la question posée dès l'ouverture est de bonne augure
Voilà, le "disque" est maintenant connecté :)
A des fins de tests je le formatte en NTFS et effectue quelques mesures afin d'appréhender comment mon infrastructure réseau, antédiluvienne, va conditionner l'ensemble.
Alors ce n'est pas si mal, ça vaut un disque mécanique en SATA. Côté serveur ça mouline pas mal tout de même.
Ok, prochaine étape, supprimer ce volume NTFS et chiffrer l'espace disque
Pour le chiffrement j'utilise Veracrypt avec une clé de 8192 bits et un mot de passe avec plus de 30 caractères
le logiciel annonce 3 heures afin de chiffrer le volume d'1 To
Cependant quand je viens voir le résultat 6h après, étrangement le formatage n'est pas terminé, de plus la durée restante annoncée est grande
Je n'aurais pas à attendre car une micro coupure sur le réseau électrique met fin à cet essai.
De plus il a suffit que je quitte le PC portable où je rédige cet article quelques instants pour qu'une mise à jour Windows se déclenche sans me demander mon avis.
Ca sera donc tout pour ce jour.
Le lendemain matin :
Hier soir j'avais tout de même pris soin de lancer un transfert de données d'approximativement 500 Go afin de voir comment l'espace de stockage se comporterai côté serveur.
Ce matin, 12 heures après, je retourne sur le client, le transfert n'est réalisé qu'à hauteur de 80% et je remarque un schéma dans les transactions réseau : le client inscrit des données pendant une trentaine de secondes puis le taux d'occupation disque sature à 100% sans que le moindre fichier ne soit envoyé.
Côté serveur rien d'anormal côté processus iscsi ou nfs pas plus que de la ram.
Potentiellement le souci est côté réseau ou client ?
Je retire le chiffrement côté client, reformate le disque simplement en NTFS et renvoie un flot de données, à peine mieux, voici comment ça se manifeste :
Sur le graph à droite, en rouge les paquets réseau envoyés en vert les paquets reçus, en jaune la superposition.
On voit que le client envoie des données mais que régulièrement il ne se passe rien, le transfert s'arrête. Grosso modo il y a envoi de données une minute et une phase d'arrêt d'une minute ou Windows considère que le taux d'occupation du périphérique est toujours de 100%
Je vais reprendre les choses à zéro côté serveur.
---
