TrueNAS 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 !

Installer plex sur TrueNAS (SCALE)

Fri, 10 May 2024 18: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 :

Plex sur mon NAS

Un des prérequis quand je construis / achète un NAS, c’est la possibilité d’installer dessus Plex Media Server.

D’expérience, même s’il est possible d’avoir une VM sur un hyperviseur à côté qui gère la médiathèque “à côté” du NAS, ou même de déléguer ce rôle “serveur plex” à la box de l’opérateur ou même notre smartTV, c’est souvent plus pénible qu’autre chose :

je n’ai pas toujours un hyperviseur allumé à la maison et monté la médiathèque sur Internet est hors de question
le volume partagé qui héberge les médias entre le NAS et la VM peut sauter, et c’est pénible à debug / corriger quand ça arrive
les box / smartTV sont souvent trop limitées en hardware (espace disque pour les apps, CPU rachitique, RAM insuffisante…)
je change de box opérateur plus souvent que de NAS

Note : je suis certain qu’on ne sera pas d’accord avec moi sur certains de ces points, et c’est OK. Moi, je trouve que c’est mieux comme ça, mais vous faites bien comme vous voulez ;-P.

J’ai donc envie d’avoir Plex sur mon NAS et de ne pas trop m’embêter pour la gestion au quotidien.

Les “apps” dans TrueNAS

Et ça tombe plutôt bien, car nos amis de chez TrueNAS maintiennent à jour une application Plex pour TrueNAS. Sauf que sur le papier, elle est pas hyper simple à installer, d’où cet article pour vous guider ;-).

Tout cet article part du principe que vous utilisez TrueNAS SCALE et pas TrueNAS Core.

Si vous ne connaissez pas la différence, le mieux est que vous alliez voir par vous-même la documentation officielle - compare TrueNAS software.

TL;DR TrueNAS Core, c’est la version historique basée sur FreeBSD (qui s’appelait d’ailleurs FreeNAS, initialement). Cependant, depuis quelques années, iXsystems, l’entreprise qui développe TrueNAS, met à disposition une version basée sur Debian (donc GNU/Linux).

Pour des raisons que j’expliciterai dans l’article sur le choix du software (oui je viens donc de vous spoiler l’article suivant), j’ai TrueNAS SCALE et pas Core.

Pour faire tourner les “apps”, TrueNAS s’est appuyé sur un standard du marché : Kubernetes. Et oui, n’en déplaise à ses détracteurs, Kubernetes est devenu un standard du marché. Ca ne dit pas si c’est une bonne chose (on peut juger le précédent standard, aka VMware, à l’aune de l’actualité, par exemple). Mais c’est juste un fait.

Activer les apps

Par défaut, TrueNAS n’active pas les “apps”. Ca va être à nous de le faire. En soit, ce n’est pas forcément un mal : si vous n’en avez pas besoin aucune raison de consommer des ressources pour rien.

Et quand on parle de consommation de ressources et de Kubernetes je vois déjà les gens dans le fond qui font les gros yeux. Rassurez-vous (pas sûr que ça vous rassure, mais moi oui), les équipes d’iXsystems ont eu la sagesse de choisir k3s et non un kubernetes vanilla pour héberger Kubernetes sur notre NAS. Les ressources consommées par le control plane seront donc minimales (quelques centaines de Mo au max).

On va donc dans l’onglet “Apps” et on active k3s en l’installant simplement sur un de nos pools. Dans mon cas, j’en ai deux. Un avec mes disques durs classiques, et un avec un (unique) SSD.

Initialement j’avais installé le k3s sur le pool de HDDs, histoire de mutualiser le stockage et de maximiser la disponibilité (j’ai un RAID-Z1). Cependant, le k3s de TrueNAS a tendance à écrire pas mal sur les disques, qui se retrouvaient à gratouiller sous mon bureau pendant une demie seconde toutes les 5 secondes environ. Très énervant.

J’ai donc recréé un pool spécial pour les apps sur un SSD que j’avais en rab.

On clique sur Settings en haut à droite, puis Choose Pool

Installer plex media server via les apps

Au bout de quelques secondes / minutes, k3s est installé et on peut commencer à chercher une app parmi le catalogue (>100). Ici on recherche plex et on clique sur Install

A partir de là, une fenêtre avec plein de paramètres va apparaitre. Mais avant d’aller plus loin, on va aller sur la page www.plex.tv/claim/. Une fois loggué sur votre compte, la page va vous générer un token temporaire, qui va permettre de relier directement le serveur une fois qu’il aura démarré sur votre NAS avec votre compte. Pratique !

Dans la looongue page de configuration, on a que quelques paramètres à changer. D’abord, il faut renseigner le token qu’on vient de générer dans la section Plex Configuration. Si vous avez le Plex pass, vous pouvez aussi changer Image :

Ensuite, dans la partie Storage configuration, il va falloir indiquer le chemin vers le pool qui contient les médias. Moi c’est /mnt/rpool/tank/Vidéos. rpool est le nom de mon pool RAID-Z1, tank est mon volume principal.

Attention : assurez-vous que l’utilisateur unix (local) “apps” a bien accès en lecture/exécution sur toute l’arborescence, sinon vous ne verrez pas le dossier quand Plex sera lancé (très frustrant, il n’y a aucun message d’erreur, juste “rien”).

De manière optionnelle, vous pouvez tuner les “limits” (au sens docker/kubernetes du terme) de votre app. Par défaut, la chart plex de TrueNAS propose 4 CPUs et 8 Go de RAM, ce qui est beaucoup. Mon plex ne consomme que 100 Mo au repos. J’ai baissé à 2 CPUs (avec un risque de throttling, mais là on rentre dans des notions un peu tricky de Kubernetes que je préfère esquiver aujourd’hui dans cet article) et 4 Gio de RAM (j’en ai 16 mais je veux garder le plus de cache possible).

Une fois terminé, l’application se déploie, puis affiche Running. On a alors un cartouche Application Info dans Details qui devrait afficher un bouton Web Portal qui devrait nous rediriger sur l’IP de notre NAS sur le port 32400 (celui habituel de plex).

On peut donc se laisser guider par le wizard de configuration de Plex Media Server, lui donner un nom mignon et aller chercher nos médiathèques dans /data. Normalement, le dossier que vous avez donné lors de l’étape Storage configuration devrait apparaitre.

Bonus

Pour une raison que j’ignore (peut être parce que c’est un container avec un adressage à part), j’ai dû explicitement indiquer le port public (32400 sur ma box, qui redirige sur l’IP de mon NAS et le port 32400) pour que le Control à distance fonctionne et que l’accès direct (sur le réseau local) fonctionne correctement.