FreeNAS on Zwindler's Reflection

Mon NAS en 2024 - Jonsbo N2 × Intel N100 - stress tests et conclusion

Thu, 04 Jul 2024 12:00:00 +0200

Cet article fait partie d’une série dans laquelle je parle de mon nouveau NAS que j’ai construit moi-même :

On le teste, ce NAS ?

Après 1 mois et demi de confs et aussi de préparation de ma fin d’emploi (lien mort, je ne suis plus sur Twitter), je reprends ma plume numérique pour finir le dernier article de cette série, que certain⋅es attendent avec impatience (à minima, un australien :-P)

On s’était arrêté dans l’article précédent à l’installation de notre NAS sous TrueNAS SCALE (la version Linux) et nous nous étions juste logué sur l’interface d’administration.

La première opération que vous voudrez faire, c’est très certainement de créer un pool de disques et un volume.

Dans mon cas, après avoir testé un premier pool avec 4 disques que j’avais en spare, ZFS m’a très rapidement prévenu que quelque chose n’allait pas avec mes disques. Après un SMART approfondi, je me suis retrouvé avec 2 disques HS… J’en ai acheté un de plus et créé un pool avec “seulement” 3 disques (au lieu des 4 prévus initialement).

Une fois le pool créé, on peut commencer à créer des volumes et à ajouter différents types de partages. J’ai créé un share NFS à part, car il me servira pour la virtualisation et mon homelab, et un share CIFS pour tout ce qui est partage de fichiers.

Température

Le premier test que j’ai voulu faire, avant de commencer quoique ce soit, c’était un test de température.

Un des problèmes que j’avais avec les NAS maison, c’est que les CPUs grand public (hors Atom) sont souvent surdimensionnés pour les besoins d’un NAS. On se retrouve avec un CPU soit bruyant, soit un ventirad volumineux. Ou alors dans le cas de l’Atom, un CPU totalement bridé par le throttling et les perfs déjà pas terribles, comme mon tout premier NAS maison de 2011 (voir NAS/MediaCenter : Do It (the hardware part) Yourself!).

Ce qui m’a fait craquer pour le Intel N100 c’est que, sur le papier, il a la consommation et la dissipation thermique d’un Atom mais les fonctionnalités d’un CPU classique, tout en gardant des perfs acceptables. Et on a le support de la virtualisation, 4 cores, etc.

Un des points noirs d’une des cartes mères “siglée NAS” sur Aliexpress, significativement moins chère que celle que j’ai achetée, mais dont les retours étaient unanimes pour dire que le ventilateur était clairement audible (et très aigu). Le NAS étant à côté de mon bureau (où je télétravaille) c’était évidemment hors de question.

Pour rappel, j’avais opté pour un ventirad jonsbo low profile, qui s’avère à l’usage plutôt silencieux, d’autant que je lui ai rajouté un réducteur de vitesse (en gros un fil avec une résistance) que j’avais en stock d’un build précédent.

VM de stress test pour faire chauffer tout ça

La philosophie de TrueNAS c’est de t’empêcher de faire des trucs dans ton coin histoire de limiter les erreurs de débutant. Donc même s’il existe un shell pour aller faire des trucs en lignes de commandes, il est très limité et on n’a pas de gestionnaire de paquets pour installer des choses.

Pour faire mes tests, ça va être pénible. J’ai donc commencé par créer une VM (puisque je peux le faire, autant en profiter). Première boulette, créer une VM Ubuntu avec 512 Mo de RAM (la valeur par défaut dans ). Avec un environnement graphique, ça plante dès l’installation… Mais ça se corrige vite.

Deuxième coup d’arrêt, les droits… libvirt n’a pas le droit d’accéder à l’ISO. C’est dommage…

Toute la gestion des partages et notamment des droits sur les fichiers et assez peu “user friendly” sur TrueNAS. C’est vraiment une déception personnelle de ce côté là, j’ai dû bidouiller pas mal pour que les utilisateurs ET les apps puissent accéder correctement à mon stockage. J’ai même dû corriger quelques permissions à la main à coup de chmod. Bref.

Une fois installée, j’installe stress-ng et je lui demandé de me saturer les 4 CPUs histoire de faire monter la température.

Pour que les tests soient les plus représentatifs possibles, j’ai laissé tourner 45 minutes le temps que ça se stabilise :

Ici, on voit que ça se stabilise autour de 46°C avec un air ambiant à 23°C, ce qui me parait parfait (les conditions de stress tests avec tous les CPUs à 100% pendant plusieurs dizaines de minutes sont déjà peu réalistes).

Côté disques, même sur des longues phases d’écritures pendant plusieurs heures, on est sous les 50°C (40 en idle)

On est bon pour la température.

Bonus fanless

Note : il est possible d’acheter des minis PC format NUC totalement fanless avec des N100 (avec des performances parfois erratiques).

On m’a donc mis au défi (sur Twitter) de tester sans ventilateur pour le CPU. Après tout pourquoi pas, j’avais bien mon premier NAS vendu avec une carte mère avec un Atom et une carte graphique NVidia fanless (mais les perfs étaient catastrophiques).

Après quelques tests, oui, ça fonctionne, mais c’est pas dingue. On tape les 90° et très probablement un throttling assez intense (pas vérifié).

C’est pas complètement un échec, puisque ça marcherait surement mieux avec un radiateur plus gros et que ce test n’est pas représentatif d’une charge réellement.

Mais retirer le ventilateur du CPU ne rend pas le NAS beaucoup plus silencieux (il reste les disques et le ventilateur des disques). J’ai donc remis le ventilateur et c’est très bien comme ça :-P.

Consommation électrique

Deuxième point important quand on choisit un NAS, la consommation électrique. C’est un point que vous êtes nombreux⋅ses à attendre aussi ;-).

Clairement, il est impossible de faire aussi bien que mon QNAP avec du matériel généraliste de particulier. La carte mère et le CPU sont certainement gourmands, l’alimentation n’est que “bronze plus” (et donc induit des pertes). Le but de jeu, ça va être de voir à quel point je vais moins bien.

J’ai donc pris des mesures sans disques, avec 3 disques idle et avec 3 disques en charges sur mon NAS QNAP que je remplace, puis je fais les mêmes mesures sur mon NAS.

Modèle	Sans disques	3 disques idle	3 disques en charge
QNAP	9w*	23w	36w
Jonsbo × N100	19w	33w	42w

* sans disques, le QNAP est inutilisable car on doit installer l’OS sur les HDD !

Grosso modo, je me prends entre 6 et 10w de plus dans la vue. 10w, surtout sur une machine qui reste allumée toute l’année, c’est significatif. Mensuellement, ça représente 7,31 kWh (~ 1,17 €) de consommation en plus par rapport à l’ancien modèle.

Je sais déjà qu’une partie de la Twittosphère techs / bidouilleurs barbus va me tomber dessus (c’est déjà fait). Mais si on y réfléchit un peu, ce n’est pas très étonnant, car les deux machines ne sont pas du tout comparables. Je ne peux pas faire les mêmes choses avec le QNAP qu’avec ce build.

Ce “Jonsbo × N100” me donne la possibilité d’avoir jusqu’à 6 disques (5 hotswap) là où j’étais limité à 4 avec le QNAP, avec l’OS et la data séparée proprement. J’ai la possibilité de faire des machines virtuelles si je le souhaite (pas le cas avec le QNAP) et j’ai le support de Chart helm pour installer des applications containerisées (là où QNAP ne supporte que Docker et plus LXC, cf l’article pour contourner le problème).

Et j’ai surtout bien plus de puissance, entre les débits et le réseau en 2.5 Gbps (on y reviendra sur les tests de transferts). Donc je ne me mets pas martel en tête et je vais continuer à cordialement ignorer les commentaires négatifs que j’ai pu avoir sur ce choix.

Tests de réseau

L’achat de ce NAS a été l’occasion pour moi de passer sur du 2.5 Gbps sur mon réseau éthernet (achat d’un switch 2.5 et d’une carte pcie pour mon PC).

J’ai donc fait des tests avec iperf3 (et aussi speedtest cli)

admin@truenas[~]$ iperf3 -c 192.168.aaa.pc
Connecting to host 192.168.aaa.pc, port 5201
[ 5] local 192.168.aaa.nas port 57256 connected to 192.168.aaa.pc port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 284 MBytes 2.38 Gbits/sec 0 814 KBytes
[ 5] 1.00-2.00 sec 280 MBytes 2.35 Gbits/sec 0 814 KBytes
[ 5] 2.00-3.00 sec 281 MBytes 2.36 Gbits/sec 0 854 KBytes
[ 5] 3.00-4.00 sec 280 MBytes 2.35 Gbits/sec 0 854 KBytes
[ 5] 4.00-5.00 sec 281 MBytes 2.36 Gbits/sec 0 854 KBytes
[ 5] 5.00-6.00 sec 280 MBytes 2.35 Gbits/sec 0 854 KBytes
[ 5] 6.00-7.00 sec 280 MBytes 2.35 Gbits/sec 0 854 KBytes
[ 5] 7.00-8.00 sec 281 MBytes 2.36 Gbits/sec 0 854 KBytes
[ 5] 8.00-9.00 sec 280 MBytes 2.35 Gbits/sec 0 854 KBytes
[ 5] 9.00-10.00 sec 281 MBytes 2.36 Gbits/sec 0 854 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 2.74 GBytes 2.36 Gbits/sec 0 sender
[ 5] 0.00-10.04 sec 2.74 GBytes 2.34 Gbits/sec receiver

Fun fact : c’est aussi la première fois que j’ai pu tester la vitesse de ma fibre free 5 gbps au delà du gigabit (mais je peux toujours pas aller jusqu’aux 5 gbps théoriques de la ligne).

Là aussi, tout est OK. Côté réseau, la promesse du NAS maison est tenue !

Test des disques

Le test le plus trivial à faire quand on veut tester un stockage, c’est d’écrire dessus et de voir ce que ça donne. C’est pas toujours très représentatif mais ça donne une base de départ.

root@truenas[/mnt/rpool]# dd if=/dev/urandom of=test1g bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.07779 s, 349 MB/s
root@truenas[/mnt/rpool]# dd if=/dev/urandom of=test10g bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 41.9781 s, 256 MB/s
root@truenas[/mnt/rpool]# dd if=/dev/urandom of=test40g bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB, 40 GiB) copied, 204.116 s, 210 MB/s
root@truenas[/mnt/rpool]# dd if=/dev/zero of=test10gzero bs=1M count=10240
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 3.37509 s, 3.2 GB/s

Ici, j’ai essayé de copier des données aléatoires sur le pool avec mes 3 disques. Tant qu’on est sur des fichiers de 1 Go, il reste le risque que tout soit mis en cache RAM (rappel : sauf indication contraire, ZFS utilise par défaut la moitié de votre RAM). Au-delà de 10 Go, on voit une dégradation de perfs. Quoiqu’on fasse, on ne fera pas mieux que cette base-là (baseline).

Des copies de fichiers en local (depuis le disque NVMe du système vers le pool ZFS) donnent des résultats similaires.

Note : on voit aussi que je dépasse très largement la vitesse physique de mes disques sur la copie de /dev/zero. 3.2 Go/s est évidemment impossible avec 3 HDDs. Ce sont les optimisations de ZFS (cache + compression) qui permettent ça et ça sera utile pour les fichiers contenant beaucoup de zéro (comme certains disques de machines virtuelles, par exemple).

Tests de transferts NFS/CIFS

Pour ces tests là, je ne suis pas hyper satisfait. Quand j’utilise les outils du marché permettant de désactiver les caches, les performances sont très en deça (< 50 Mo/s) des performances en utilisation réelle.

voici une petite liste des outils que j’ai testés :

fio (depuis un client linux sur CIFS)
diskpd (depuis un client Windows sur CIFS)
Copie de fichiers depuis un client Linux en NFS en ligne de commande
Copie de fichiers depuis un client Ubuntu dans Nautilus en CIFS [via gvfsd (Gnome virtual file system)]
Copie de fichiers depuis un client Windows en CIFS

Ce qu’il est ressort, c’est que le NAS est suffisamment puissant pour saturer un port Ethernet gigabit mais galère un peu plus pour le 2.5Gbps (les fluctuations sont dues au cache qui se vide pas assez vite sur les disques). Sous windows, on peut tirer au moins 150 Mo/s en écriture sur de gros fichiers sans problèmes avec des pics à 280 Mo/s.

La copie NFS et CIFS sous Ubuntu affichait des chiffres étonnants (70 Mo/s en lecture mais 120 en écriture !?). Il faudra que je fasse des tests depuis une autre machine Linux.

Les performances sans caches avec fio sont très en deça (40-50 Mo/s) mais comme je l’ai expliqué juste avant, ces tests ne sont pas représentatifs des performances que j’obtiens en conditions réelles (plutôt autour du gigabit), même sur des copies très longues (>3 To).

Sous Windows, les performances trouvées avec diskspd sont plus proches de la réalité, avec 80 Mo/s en écriture (mais il écrit d’abord des données aléatoires beaucoup plus rapidement sur le NAS et lit dedans) et 280 Mo/s en lecture.

Je n’ai pas encore fait de tests en iSCSI.

Conclusion

Le but était d’avoir un NAS silencieux et qui ne consomme pas trop, plus puissant que mon NAS précédent (QNAP), avec un support du 2.5 Gbps, du ZFS, des containers, des apps et des machines virtuelles.

Avec cette suite d’articles, je pense avoir coché toutes les cases. Je suis donc content de mon investissement. Pour rappel, j’en ai eu pour environ 500€, upgrade de la maison en 2.5 Gbps inclu.

En termes de boitiers, le Jonsbo N2 est vraiment LE boitier qui me fallait. Il est bien conçu, bien fini, pratique.

Côté carte mère, on sent que le N100 est suffisant mais est quand même aux limites de ce que je lui demande. Une partie des “bottlenecks” que j’ai rencontré viennent très probablement du CPU, les autres venant du pool de 3 vieux disques “red” peu performants.

Côté consommation et chauffe, c’est un peu moins bien que ce que j’avais avant mais rien de catastrophique. C’est en tout cas largement mieux que ce que j’aurais pu faire avec un CPU grand public.

Le plus gros point noir serait peut-être TrueNAS, un peu trop rigide sans pour autant être user friendly. Fonctionnellement, tout y est, c’est juste “pas super agréable” à utiliser.

Pour l’usage que j’en fais et les objectifs que j’avais, c’est un réel succès, si on met de côté l’OS. Je n’ai pas forcément envie de retourner sur un OS Linux nu avec lequel je fais tout moi-même…

Il faudra peut-être explorer des alternatives à TrueNAS, ou m’en contenter ?

Bonus : quelques commandes utilisées pour mes tests

diskspd

# Tests en lecture / écriture sur des blocs de 4 Ko
.\DiskSpd\amd64\diskspd.exe -c10G -d30 -b4k -h -o32 -t4 -r -w0 \\192.168.aaa.nas\tank\test
.\DiskSpd\amd64\diskspd.exe -c10G -d30 -b4k -h -o32 -t4 -r -w100 \\192.168.aaa.nas\tank\test
# Tests en lecture / écriture sur des blocs de 4 Mo
.\DiskSpd\amd64\diskspd.exe -c10G -d30 -b4M -h -o32 -t4 -r -w0 \\192.168.aaa.nas\tank\test
.\DiskSpd\amd64\diskspd.exe -c10G -d30 -b4M -h -o32 -t4 -r -w100 \\192.168.aaa.nas\tank\test

fio

cat > seq_rw_test.fio <<EOF
[global]
ioengine=libaio
direct=1
sync=1
size=10G
[sequential_read]
filename=/mnt/rpool/nfs/seqreadwrite
rw=read
bs=4M
[sequential_write]
filename=/mnt/rpool/nfs/seqreadwrite
rw=write
bs=4M
EOF
fio seq_rw_test.fio

Mon NAS en 2024 - Jonsbo N2 × Intel N100 - software

Sun, 19 May 2024 12:00:00 +0200

Cet article fait partie d’une série dans laquelle je parle de mon nouveau NAS que j’ai construit moi-même :

Les critères software

Dans la partie précédente, j’avais listé mes critères hardware (et un à mi-chemin hard/soft, le fait de pouvoir faire des VMs). Ici, passons donc aux critères software :

Mon critère principal est de pouvoir utiliser ZFS. Je suis fan inconditionnel de ce système de stockage qui sait tout faire. Je ferai peut-être un article rien que pour en parler d’ailleurs (et j’ai déjà plusieurs articles dont c’est le sujet secondaire).
Le second critère est la possibilité d’avoir une interface pour gérer facilement les fonctions principales du NAS. J’ai géré mon NAS avec un OS linux et tout géré “à la main” pendant des années
Dans les must have, il y a évidemment la possibilité de faire tout ce qu’on fait habituellement avec un NAS, à savoir la possibilité de faire du NFS, du Samba, du iSCSI, un serveur rsync, gérer des droits d’accès, monter des tunnels VPN…, Mais est-ce vraiment un critère ? N’importe quel OS linux peut le faire. Je note quand même 😉.
La possibilité de lancer des apps, pour étendre les fonctions de base, de façon simple (comme un serveur Plex par exemple)
La possibilité de lancer des containers ET des machines virtuelles

Aparté sur ZFS et les prérequis en termes de RAM

J’en ai ma claque de lire sur le net ou sur Twitter que ZFS n’est pas adapté pour les petits besoins / petites machines.

Je lisais encore hier un article qui disait qu’il ne fallait pas choisir un OS qui ne gère que ZFS car ZFS serait hyper gourmand , en particulier en RAM, et que cela empêcherait de l’utiliser sur des machines avec moins de 32 Go de RAM, et ECC en plus ! 😒

Il y a une extrêmement mauvaise compréhension des fonctionnalités de ZFS.

Oui, ZFS nécessite effectivement 1 Go de RAM (et vous avez réellement intérêt à ce que ce soit de l’ECC) par To d’espace disque… SEULEMENT SI VOUS ACTIVEZ LA DÉDUPLICATION !. Et autant dire que ce n’est recommandé que si vous savez ce que vous faites et les risques que cela implique. Je ne rentre pas dans les détails ici, on en reparlera dans l’article sur ZFS.

Et deuxième erreur, effectivement aussi, par défaut, ZFS réserve pour son cache la moitié de la RAM. Sauf que ce paramètre est… un paramètre ! S’il est déconseillé de le mettre à 0, ça fonctionne extrêmement bien, même si vous le réduisez fortement.

#Limiter la taille du cache RAM de ZFS à 4 Go
echo 4294967296 |sudo tee -a /sys/module/zfs/parameters/zfs_arc_max
cat /proc/spl/kstat/zfs/arcstats|grep -e "^size"
size 4 4119613272

Je l’ai mis à 512 Mo sur des serveurs Proxmox VE qui n’ont que 4 Go de RAM, par exemple, et je sais qu’on peut encore descendre.

The minimum amount of memory needed to install a Solaris system is 768 MB. However, for good ZFS performance, use at least one GB or more of memory. ZFS Hardware and Software Requirements and Recommendations

La philosophie derrière ce choix et que de la RAM inutilisée est de la RAM gâchée, et en tant qu’ingénieur, je recherche l’efficience. L’apparente gourmandise de ZFS pour la RAM n’est pas un bug, c’est une feature.

Choisir l’OS

Avec de rapides recherches, on trouve les usual suspects des NAS maison :

OpenMediaVault
TrueNAS (anciennement FreeNAS), historiquement basé sur FreeBSD (Core), mais qui dispose maintenant d’une version Linux (SCALE)
Depuis quelques années, on parle aussi pas mal de UnRAID, un OS orienté NAS sous Linux. Le produit est payant.

En plus confidentiel, il y a aussi :

XigmaNAS (ex NAS4Free, un fork de FreeNAS)
RockStor (base CentOS + btrfs)
Xpenology, un projet qui récupère le DSM de Synology, dont j’ai un gros doute sur la légalité
ou même, l’OS QNAP qu’on peut installer sur n’importe quel matériel moyennant un coût mensuel

La tribu réunifiée a décidé de vous éliminer

Mes critères éliminent directement Windows (ce n’est pas vraiment comme si ça avait été un candidat sérieux 🤣). Quoique, j’avais fait brièvement du Windows Media Server à l’époque où ça existait encore, et aujourd’hui avec ReFS, on aurait presque (presque ?) un candidat pour un NAS de hobbyist.

J’élimine aussi Xpenology, projet que je connais depuis très longtemps, et dans lequel je n’ai strictement aucune confiance. Et je pars de l’écosystème QNAP en partie à cause de son OS, donc ce n’est pas pour y retourner 😅

RockStor est trop confidentiel à mon goût, et je suis pas fan de btrfs qui a été trop instable pendant de nombreuses années.

XigmaNAS (ex NAS4Free) a sûrement des arguments, mais c’est TrueNAS qui a tiré son épingle du jeu et raffle le gros de la communauté.

UnRAID m’intéresse, mais le côté payant du projet est un problème. La version d’essai est très courte, et je n’avais pas spécialement le temps pour le tester de fond en comble au point de pouvoir décider si j’étais prêt à lâcher 49$ par an (tout de même !).

Le choix final

OpenMediaVault et TrueNAS (Core et SCALE) sont les alternatives les plus crédibles par rapport à mes critères.

TrueNAS Core (sous FreeBSD) était mon premier choix, pour son support naturel du ZFS et aussi le fait que je voulais apprendre à utiliser l’univers BSD que je n’ai jamais exploré.

C’était d’ailleurs FreeNAS que j’avais voulu choisir à l’époque (pour les mêmes raisons) de mon NAS de 2011, mais j’avais finalement choisi Ubuntu, car cette machine me servait aussi de mediacenter. TrueNAS dispose bien d’une interface web, de containers et de VMs (pour les deux versions).

Cependant, plusieurs personnes m’ont alerté sur la possibilité que la version TrueNAS Core disparaisse à terme au profit de la version Linux (SCALE). Et le critère “gestion facile d’apps” n’est pas disponible sur Core (ce sont des charts helm, et Core n’a pas la fonction Kubernetes qu’à SCALE)

Restait donc TrueNAS SCALE et OpenMediaVault, qui sont très similaires en termes de fonctionnalités et qui cochent toutes les cases. Et même si OpenMediaVault supporte ZFS, le fait que ce ne soit pas l’option par défaut m’a fait opter TrueNAS SCALE (mais ça aurait très bien pu être OMV).

Installation

Rien d’incroyable ici, il suffit d’installer l’OS comme n’importe quel autre linux.

On suit la doc : on récupère l’ISO sur le site, on l’écrit sur une clé USB bootable et on suit ensuite le processus d’installation.

TrueNAS SCALE demande 8 Go de RAM ou mieux. A mon avis, c’est surestimé (pour être large) et on doit pouvoir lancer SCALE dans de bonnes conditions avec moins, mais je suis content d’avoir pris 16 Go.

TrueNAS SCALE is very flexible and can run on any x86_64 compatible (Intel or AMD) processor. SCALE requires at least 8GB of RAM (more is better) and a 20GB Boot Device.

“Bêtement”, j’ai acheté un NVMe avec pas mal de patate de 512 Go, sauf que TrueNAS utilise tout l’espace par défaut. J’ai donc un NVMe quasiment inutile… Un peu rageant.

Une fois installé, on redémarre la machine et on peut se connecter sur l’UI :

Le dashboard principal est customisable : on peut modifier les tuiles qu’on veut afficher. Sur la gauche, les menus avec toutes les opérations courantes à réaliser sur le NAS apparaissent.

Conclusion

Je m’arrête là-dessus, on créera notre pool et les premiers partages lors des tests de performance dans le prochain article.

D’ici là, have fun !

NAS/MediaCenter : Do It (the software part) Yourself!

Thu, 04 Aug 2011 21:02:24 +0000

NAS + Mediacenter : Vous voulez toujours le faire vous même ?

[EDIT]Depuis que j’ai écris cet article, de l’eau a coulé sous les ponts (plus pour la partie NAS que Mediacenter). Maintenant à l’aide de ZFSonLinux il est possible de faire du ZFS sous Linux sans passer par le portage en userland qu’est ZFS Fuse, alors qu’il manque toujours d’importants composants dans Btrfs.[/EDIT]

Si vous avez lu le dernier article, vous aurez remarqué que j’avais découpé mon article en deux parties : le hardware vs le software. Voici donc la partie software tant attendue (ou pas vu la fréquence à laquelle j’écris… On n’a qu’à dire que c’est pour faire mûrir la réflexion!)

Ça y est! Tout est monté! Le premier choix crucial est évidemment celui de l’OS, mais celui ci est dicté par les fonctionnalités qu’on attend de l’OS en question…

Car aujourd’hui, si tout le monde essaye de copier les fonctionnalités des autres pour prouver à quel point tel OS fait tourner le plus de choses, tout le monde fait aussi de son mieux pour se démarquer avec telle ou telle FEATURE INEDITE…

Ce que j’attendais de la bécane était relativement simple, mais les implications ont rendues le choix plutôt compliqué…

Un espace de stockage, avec des données redondées, si possible pas tout car je n’ai que deux disques et ne voudrait pas gaspiller de l’espace
Un mediacenter connecté à ma télé, si possible qui puisse être contrôlé depuis mon canapé

Le Media Center

S’il avait juste s’agit de choisir un MediaCenter, le choix était tout trouvé : Ubuntu avec XBMC est l’un des MediaCenter les plus plébicités, avec une foultitude de fonctionnalités et une large communauté. Il propose par exemple :

une interface fluide, totalement customisable à l’aide de nombreux thèmes/scripts
une gestion de périphériques comme la wiimote ou les smartphone pour faire office de télécommande dans son canapé
la lecture de la plupart des formats images/audio/vidéo (avec sous titres)
la gestion de fichiers médias déportés sur le réseau (partage SMB, UPnP et truc de MACeux aussi si j’ai bien lu)
une « distrib » toute faite basée sur un Ubuntu, pour ceux qui n’auraient même pas envie de s’embêter à installer un linux puis installer un paquet tout fait… Dur la vie!

Ce Media Center s’est même imposé comme la condition sine qua non dans le choix de l’OS et donc du FS.

Le STOCKAGE

S’il avait juste s’agit de faire du stockage, un boitier plus grand m’aurait permis de faire du RAID5 logiciel, et ainsi disposer de perfs correctes sans utiliser trop d’espace disque pour la tolérance aux pannes. Ce n’est pas le cas, je n’avais la place que pour 3 disques si jamais je souhaitais conserver l’emplacement DVD, bien utile pour tout ce qui est installation de distrib et lecture de films…

Quand j’ai commencé à faire mes recherches par rapport au stockage à la maison, je suis tombé sur plusieurs articles alarmistes qui m’ont dissuadé d’utiliser du RAID5, qui souffrirait, couplé à des FS actuels à des risques de corruption silencieuse pouvant entraîner la perte de toute les données malgré la présence d’un disque de parité (google « silent corruption » ou des articles comme http://www.zdnet.com/blog/storage/50-ways-to-lose-your-data/168). Même si il faut faire la part des choses avec ce que disent ces Cassandres du stockage et la réalité, je me suis donc tourné vers des solutions réputées plus sures.

Aujourd’hui, la plupart des filesystems utilisent des journaux des opérations et des checksum permettant de vérifier que les données n’ont pas été corrompues par les ondes électromagnétiques générées par le battement d’ailes d’un papillon ou que sais-je encore! Malheureusement, cela ne suffit pas toujours et il est possible qu’un hardware défaillant pourrisse l’intégralité de vos données sans que personne ne s’en aperçoive.

Heureusement, des filesystems NextGen nous promettent monts et merveilles!!!

Le FILESYSTEM

A l’époque, BTRFS n’était pas encore vraiment « standard » (encore moins qu’aujourd’hui en fait…). La seule « solution » fonctionnelle à ma connaissance était ZFS.

J’ai probablement autant été convaincu par le nombre de FEATURE INÉDITES de ce filesystem que par la description un peu loufoque de ses limites :

ZFS est un système de fichiers 128 bits, ce qui signifie qu’il peut fournir 16 milliards de milliard de fois ce que fournissent les systèmes de fichiers 64 bits actuels.
Les limitations de ZFS sont tellement inaccessibles qu’il n’y aura jamais d’opérations pratiques qui puissent les atteindre. Selon Bonwick

Remplir un système de fichiers 128 bits dépasserait les limites quantiques de stockage de données. Vous ne pourriez pas remplir un espace de données 128 bits sans faire bouillir les océans.

Voilà qui laisse rêveur… Pour le calcul ayant permis de parvenir à cette conclusion je vous laisse aller feuilleter la page de wikipedia dédiée.

Ce qui est vraiment intéressant à savoir c’est que ZFS propose actuellement :

Du « copy on write ». Les données ne sont réellement modifiées qu’une fois que tout a bien été écrit sur le disque. Pas de risque de se retrouver avec des blocs corrompus suite à un reboot intempestif.
Un FS où chaque bloc possède un checksum 256bits, et ou les checksums possèdent eux mêmes des checksums (et ainsi de suite), au cas où les données ET les checksums seraient corrompus.
Un FS qui se répare de lui même en vérifiant les blocs lus avec les checksums de toute la chaîne.
Gestion de « snapshots » permettant des retours arrière de façon quasi instantanée.
Compression, déduplication, partages NFS/CIFS/iSCSI, quotas activables en une commande
Une gestion facilité des volumes pour l’administrateur système
RAIDZ, un RAID logiciel particulièrement optimisé pour être à la fois plus efficace et plus sûr qu’un RAID classique
Une capacité risible comme on l’a vu plus haut
…

(Ceux qui auront suivi BTRFS auront remarqué des promesses similaires, même si tout n’est pas encore terminé, côté développement)

Mes données en sont tombées amoureuses :-)

l’OS

J’ai donc du trouver une solution pour pouvoir concilier ZFS et XBMC. Et ça n’a pas été guimauve…

Pour des raisons de guéguerre de licence (ZFS est en CDDL), ZFS ne peut pas être intégré au noyau Linux. ZFS a été porté sur :

Solaris 10 et OpenSolaris
Les BSD (notamment FreeBSD)
Les MAC
En userspace sous Linux avec zfs-on-fuse (hors du kernel et donc dégradé niveau performances)

Après quelques tentatives échouées d’installer FreeBSD (désolé, mais on est loin des installs Debian/Redhat… Je ne demande pas un Ubuntu, mais y a des limites quand même!) correctement, je me suis résolu à utiliser zfs-on-fuse, pour voir. Bon ok, j’ai aussi fais quelques boulettes…

Quand le port de gnome ne marche pas, n’essayez de le compiler vous même, surtout sur un Atom dual core. J’ai du abandonner au bout du 3ème jour de compilation…

Je me suis donc rabattu sur un bon vieux Ubuntu : Linux je connais mieux, je fais moins de conneries. La bonne nouvelle, c’est que ZFS-on-fuse, ça fonctionne très bien! Les fonctionnalités sont pour la plupart au rendez vous, et c’est très agréables à utiliser. Pour les données, j’ai créé deux partitions sur chacun de mes deux disques dédiés aux données, de manière à créer

un zpool « safe » en miroir (2*300 Go = 300 Go)
un zpool « normal » non redondé (2*700 Go = 1400 Go)

Je ne « perd » l’espace du miroir que sur une partie de mon espace total de stockage.

La déception est arrivée après quelques benchs… Loin des résultats catastrophiques que j’avais pu trouver sur le net qui commençaient à dater (des vitesses de 3-4 Mo/secondes!), je n’ai pas pu faire beaucoup mieux que 16-17 Mo/s, aussi bien sur le pool mirroré que sur le pool simple. J’aurai attendu un peu mieux de mes disques, surtout la partie mirrorée en lecture.

Conclusion

Si vous souhaitez faire un NAS également capable de supporter un MediaCenter, le hardware et le software que j’ai choisi sont tout à fait à même de remplir la tâche.

Sans ventilation, j’arrive à lire des films 720/1080p, et l’interface de XBMC est magique… et avoir une télécommande pour son mediacenter, c’est juste indispensable…

Mes données sont bien plus à l’abris de la corruption silencieuse qu’avec un FS classique en ext3 voire même en ext4, et même si les performances ne sont pas mirobolantes, c’est tout à fait raisonnable pour toute personne qui souhaite disposer d’un NAS à la maison.

Cependant, si c’était à refaire, je ne sais pas si je resterai sur l’architecture MediaCenter/Nas combiné, et si je devais rester sur cette idée, j’essayerai peut être de voir comment se comporte Btrfs, maintenant intégré à tous les Linux.