QNAP on Zwindler's Reflection

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.

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

Fri, 03 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 :

Mon NAS, quatrième itération ?

Depuis 2011, je change de NAS régulièrement.

2011, c’était de la récup’ (un vieux Qbic Soltek, une carte mère avec un Atom fanless).

2014, c’était encore plus bidouille, car j’avais juste posé une carte mère dans mon Red Helmer.

2018, j’en avais marre de gérer moi-même l’OS, les problèmes d’upgrades de l’OS, etc. J’étais donc passé sur un NAS du commerce (un QNAP).

Après 6 ans de bons et pas très loyaux services (QNAP désactive des features au fur et à mesure), j’ai décidé de m’en reconstruire un nouveau, moi-même.

Pourquoi construire son propre NAS en 2024 ?

Construire son propre NAS présente plusieurs avantages par rapport aux solutions commerciales :

Contrôle total sur le matériel et le logiciel
Rapport performance/prix souvent meilleur
Évolutivité : possibilité d’upgrader facilement
Pas de vendor lock-in : liberté de changer d’OS
Apprentissage : comprendre le fonctionnement interne

Cependant, cela demande du temps, des connaissances techniques et implique de gérer soi-même la maintenance.

Les critères hardware

À force d’itérations, je commence à savoir ce que je veux / ne veux pas pour mon NAS. En voici la liste :

quatre emplacements
un ou plusieurs ports ethernet 2.5 Gbps
un beau boitier, qui fasse un peu sérieux, relativement compact (pas une tour)
pas de bruit, peu de chauffe
une consommation électrique raisonnable
possibilité de hotswap les disques

Ces critères sont surtout hardware, mais j’en rajoute qui est plutôt software, tout en restant lié au hard :

la possibilité de faire des machines virtuelles (si jamais j’en ai l’envie) et des containers

Le choix des composants

C’est l’étape la plus compliquée quand on fait un NAS DIY.

Le problème principal est de trouver un boitier qui convient. Ça fait des années que je cherche (même en 2011 / 2014) et souvent les boitiers sont rares, chers, volumineux et/ou moches. Le côté hotswap est fréquemment absent.

Heureusement, j’ai trouvé un boitier qui coche toutes les cases, même s’il est difficile à trouver en France : le Jonsbo N2. J’avais entendu parler de cette marque sur Next Inpact avec le Jonsbo N1, plus compact, mais qui n’avait pas de hotswap.

Le Jonsbo N2 corrige ce défaut. C’est grosso modo un cube de 22 cm de côté, il est plutôt beau même si un peu gros à mon goût.

Niveau compatibilité, on peut l’alimenter avec une PSU au format SFX et une carte mère au format Mini ITX. C’est relativement attendu, vu la compacité, mais ça nous rajoute tout un tas de problématiques complémentaires.

Budget et coût total du projet

Avant de détailler chaque composant, voici un aperçu du budget total :

Boîtier Jonsbo N2 : ~120€
Carte mère Intel N100 avec ports 2.5GbE et de nombreux SATA : ~200€
Alimentation SFX 300W : ~80€
RAM DDR5 16Go : ~60€
SSD NVMe 500Go : ~40€
Switch 2.5 Gbps + carte réseau : ~80€

Total : environ 580€ (hors disques de stockage)

Alimentation SFX

D’abord, les alimentations SFX sont plus rares, plus chères et moins efficaces. Trouver un modèle peu puissant, économe, bon marché et semi-passif (pour le bruit) est impossible.

Le mieux que j’ai trouvé est une alimentation Be Quiet SFX Power 3 de 300w. Elle n’est pas semi-passive (donc fait continuellement du bruit, même si c’est raisonnable) et seulement 80Plus Bronze (donc il y a des pertes significatives d’énergie). En alternative, j’aurais pu prendre (à vérifier, la taille n’est pas claire) les SFX-L de Be Quiet, qui ont l’avantage d’être 80 Plus Gold et modulaires.

Conseils pour choisir son alimentation SFX

Pour un NAS, les critères importants sont :

Efficacité énergétique (80 Plus Gold ou l’équivalent avec les nouvelles normes cybenetics)
Niveau sonore (ventilateur semi-passif idéal)
Puissance adaptée (300W largement suffisant pour ce type de build)
Câbles modulaires pour faciliter le câblage dans l’espace restreint du JONSBO

Carte mère Intel N100

Ensuite, les cartes mères mini-ITX ont souvent peu de ports SATA, ce qui ne colle pas avec mon besoin de quatre disques. À partir de là, il y a 3 solutions, aucune n’étant vraiment “ouf”.

La plupart des cartes Mini ITX ont 2 (voire 1) ports SATA, mais certaines ont aussi des ports M.2 pour NVMe et/ou un port PCIe :

Il existe des adaptateurs 1 NVMe => 6 SATA
Il existe des cartes d’extension PCIe => SATA

Mais je n’ai absolument pas confiance dans la qualité de ces machins, donc j’ai abandonné l’idée. D’autant que j’aurais peut-être besoin du port PCI-e pour ajouter une carte d’extension pour avoir le 2.5 Gbps.

J’avais trouvé une carte avec quatre ports SATA et le support du socket AM4 (exemple ASRock B550M-ITX/AC). Si je rajoute un Ryzen 5 5600G, je coche la case “possibilité de faire des VMs”, mais c’est relativement cher (~260€ au total) et surtout le CPU consomme beaucoup d’électricité (TDP 22w).

Dernière solution, il existe aussi quelques OVNI comme la carte ASRock Rack X570D4I-2T avec des ports OCuLink permettant de gérer 4 SATA chacun, mais c’est quasiment impossible à trouver et très cher.

En fouillant AliExpress, je suis assez vite tombé sur ce genre de modèles de cartes “noname” :

Il existe plein de modèles et de variations du même genre de cartes. Grosso modo, c’est un chipset Intel compatible Atom de différentes générations avec 4 ports Ethernet 2.5 Gbps, 6 SATA, parfois fanless, parfois non.

Sur le papier, c’est pile ce que je cherche. J’ai une carte mère et son N100 (seulement 6w de TDP) + ventirad qui coche tous mes critères. Il faut juste ne pas trop avoir peur du côté “carte mère noname”.

Pourquoi choisir l’Intel N100 ?

Le processeur Intel N100 présente de nombreux avantages pour un NAS :

Très faible consommation : TDP de seulement 6W
Performance suffisante : 4 cœurs jusqu’à 3.4 GHz
Support hardware : décodage vidéo H.264/H.265, VT-x et VT-d pour la virtualisation
Connectivité moderne : DDR5, PCIe 4.0
Prix abordable : rapport performance/prix excellent

J’ai pris le risque, j’ai choisi cette carte, que j’ai réussi à avoir autour de 200€ (ici 250 sur la capture d’écran).

Composants complémentaires

Pour installer l’OS de mon NAS, j’ai ajouté un SSD NVMe de 500 Go (le moins cher de marque que j’ai trouvé).

J’ai aussi ajouté 16 Go de RAM DDR5, dans l’idée que j’aurais peut-être besoin de ça pour des containers / VMs.

Comme je n’ai pas encore de réseau en 2.5 Gbps chez moi, j’ai donc dû faire l’upgrade. J’ai choisi un switch “noname” sur AliExpress (là encore), une carte PCIe pour mon PC perso.

Pour les disques, j’ai fait l’erreur (on en reparlera) de récupérer des vieux disques Western Digital Red de 4 To que j’avais en stock…

Liste des achats complémentaires

Montage

Le boîtier est très beau, bien conçu, semble être de bonne qualité / bonne facture. La carte mère est en haut, l’alimentation se positionne sur le bas + côté et les disques de l’autre.

Côté carte mère, elle est livrée avec une grosse surface de contact en cuivre sur laquelle j’ai ajouté le ventirad low profile.

Pour être parfaitement honnête, je me demande si le ventilateur est réellement nécessaire. On en reparlera dans le prochain article.

Installation du système de refroidissement

Le système de refroidissement du NAS est conçu pour être silencieux tout en restant efficace :

le N100 devrait être simple à refroidir du fait de son faible TDP
la ventilation des disques est assurée par le ventilateur à l’arrière

Pour pouvoir être hotswap, les disques durs sont connectés à un backplane, aéré par un ventilateur low profile (15 mm d’épaisseur) que j’ai remplacé par un 25mm (classique) car j’ai lu qu’il était bruyant. Le souci, c’est qu’il y a très peu d’espace, pas assez pour un 25mm, mais ça rentre au chausse-pied.

Note : il existe des plans d’impression 3D pour corriger ce problème, si nécessaire. Mais je n’en ai pas eu besoin.

Conclusion

Une fois le montage fini, je trouve ça plutôt clean :)

Bilan de cette première partie

Cette première étape du projet NAS 2024 s’achève sur un bilan globalement positif :

Boîtier Jonsbo N2 : excellent compromis design/fonctionnalité
Intel N100 : performance/consommation remarquable
Assemblage : relativement simple malgré l’espace restreint
Budget maîtrisé : ~580€ pour une base solide

Quelques points d’attention tout de même :

la carte mère “noname” est un véritable pari
la compacité pourrait rendre l’ensemble difficile à refroidir (en tout cas silencieusement)

Dans le prochain article, on parlera des différents tests de performance que j’ai réalisés et du choix du système d’exploitation.

QNAP débranche LXC sur les NAS ARM : comment contourner ?

Mon, 13 Jun 2022 08:00:00 +0200

Si vous le suivez sur Twitter ou Masto, vous m’avez très probablement lu râler contre la sortie ~~de QTS 5~~ Container Station v2.4.0.2316, l’été dernier.

Ou plus particulièrement, contre une décision prise lors de ce passage : enlever LXC pour l’administration des containers, au profit de LXD. LXD étant juste une couche d’administration, LXC est toujours présent et fonctionnel, juste caché.

Pourquoi je râle ?

J’ai un NAS QNAP TS431P2 depuis 2018 dont je suis pleinement satisfait, et qui m’a permis de passer moins de temps à administrer et ajouter des fonctionnalités à mon NAS ZFS maison, monté initialement en 2011 (merci Dworak_of_sky pour les souvenirs).

Sauf que mon QNAP est un NAS milieu de gamme, fonctionnant avec un processeur ARM et pas x86 ! Et ces charmantes personnes (grrrr) de chez QNAP n’ont pas porté LXD sur les NAS ARM (segmentation artificielle de l’offre ? Flemme ?).

Nous, propriétaires de NAS QNAP ARM, nous retrouvons donc sans solution puisque LXC est désactivé et LXD pas disponible.

Une fonction hyper pratique pour héberger de petits services à bas coût (autant en performance qu’en prix) disparaît. C’était un réel différenciant pour ce modèle et je me sens vraiment trahi (ou alors c’est ma faute, car je n’aurais pas dû leur faire confiance ?).

Je ne suis pas près de recommander QNAP comme j’ai pu le faire par le passé. #PasContent

Nuance

HEUREUSEMENT, les containers LXC ne se sont pas mis à ne plus marcher du jour au lendemain.

Enfin, encore heureux ! Je n’ose imaginer les dégâts en prod !

C’est d’autant plus vicelard que le message d’information pour expliquer qu’il n’y a plus LXC indique que c’est pas grave puisque vous avez LXD à la place. Aucune mention du fait qu’en fait, sous ARM, non…

Il est toujours possible (pour l’instant) de démarrer, arrêter, utiliser et supprimer les containers existants. Mais il n’est plus possible d’en créer de nouveaux.

Ça veut donc dire que tout est encore présent pour faire fonctionner la fonctionnalité, ce n’est “juste” plus disponible en UI.

En avoir le coeur net

En farfouillant, je me suis aussi rendu compte qu’il était toujours possible d’exporter des containers existants et d’importer les exports.

On peut donc contourner la limitation arbitraire de QNAP via des export / import. J’ai l’habitude de ce genre de bidouilles, puisque je faisais déjà ça il y a plus de 10 ans avec les hyperviseurs VMware en licence gratuite…

A l’usage, ça fonctionne mais c’est pas satisfaisant. D’abord parce que si on a pas, ou plus, de containers sur le NAS, on ne peut pas le faire trivialement.

Ensuite, parce que le processus et long (l’export et l’import) et pénible (plusieurs étapes).

Enfin, parce que les images LXC mises à disposition par QNAP étaient antédiluviennes !

Ubuntu 14.04 !!! Sauf si vous avez pris le temps de faire le processus d’upgrade complet de 14.04 à 20.04 ou 22.04 (et vous devriez), il est probable que vous n’ayez pas envie de repartir de ces vieux machins.

“Faites mieux”

Si vous êtes admin, vous avez probablement déjà activé SSH pour vous connecter directement à l’OS de votre NAS. (Et sinon vous pouvez aller ici pour l’activer)

Une fois connecté, on peut sortir du menu TUI et bidouiller l’OS comme on en a envie.

[~] # id
uid=0(admin) gid=0(administrators)

Je n’ai pas fait beaucoup d’administration LXC/LXD directement, car j’avais toujours une interface à ma disposition pour me “cacher” la façon dont ça fonctionne vraiment, que ce soit dans le cas de QNAP ou de Proxmox VE (que j’utilise beaucoup pour ça).

En lisant rapidement la doc sur ubuntu-fr, j’ai compris qu’il existait en fait chez Canonical un genre de dépôt d’images officielles de pleins d’OS, notamment compatible armhf.

Avec LXC, on peut accéder directement à ces images en ligne de commande avec lxc-download. Pas de bol, la commande n’est pas dispo sur QTS :

[~] # lxc-download
-sh: lxc-download: command not found

(En fait elle n’est juste pas dans le PATH, mais je ne le savais pas à ce moment-là)

Sauf qu’on peut aussi appeler directement la commande pour créer des containers lxc-create avec un flag “download”. Et ça tombe bien parce que lxc-create est disponible. Mais la joie sera de courte durée…

lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf

/usr/local/container-station/lxc/share/lxc/templates/lxc-download: line 237: getopt: command not found

Hack…

Note : si vous trouviez que ce qu’on était en train de faire n’était déjà pas très propre, je tiens à vous prévenir, la suite est vraiment immonde… Pas merci QNAP de me forcer à faire ça !

Le script /usr/local/container-station/lxc/share/lxc/templates/lxc-download est moisi. Il manque la moitié des binaires dans la busybox.

Pire encore, la procédure que je donne ici semble être écrasée à chaque mise à jour de l’application Container Station. Mais, ça fonctionne…

La première chose qu’on va faire, c’est faire une sauvegarde du script lxc-download par sécurité.

cp /usr/local/container-station/lxc/share/lxc/templates/lxc-download{,.old}

Le premier message d’erreur qu’on a getopt: command not found indique juste que de nombreux binaires “classiques” ne sont pas disponibles directement dans le shell de QTS.

Sauf qu’en fait, ils sont là, ces binaires. Pas besoin de les télécharger ou de les compiler. Ils ne sont juste “pas visibles”.

QTS tourne, comme beaucoup de serveurs Linux minimalistes, avec l’aide de Busybox.

On peut donc “magiquement activer” les binaires qui nous manquent simplement avec des liens symboliques.

for binary in getopt xz seq; do
 ln -s /share/CACHEDEV1_DATA/.qpkg/container-station/bin/busybox /share/CACHEDEV1_DATA/.qpkg/container-station/bin/${binary}
done

getopt
getopt: missing optstring argument

… and slash!

C’est bon, mais pas suffisant.

La version du binaire mktemp de busybox n’est malheureusement PAS compatible avec le script lxc-download. On va devoir le modifier à la main…

Usage: mktemp [-dq] TEMPLATE

Le passage problématique se situe autour des lignes 320-325

320 if ! command -V mktemp >/dev/null 2>&1; then
321 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}/tmp/lxc-download.$$"
322 else
323 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}$(mktemp -d)"
324 fi

En vrai, mktemp s’attend à avoir le path complet, accompagné d’un pattern à base de XXXXXX. mktemp remplace ensuite les caractères XXXXXX par un nombre aléatoire en s’assurant que le dossier n’existe pas déjà, puis le créé. Par exemple

mktemp /tmp/mydirXXXXX

Mode bourrin, j’ai remplacé la ligne par :

323 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}/tmpdir" && mkdir -p ${DOWNLOAD_TEMP}

De toute façon, il est supprimé à la fin de l’exécution du script, ce dossier (fonction cleanup dans le shell).

GPG

On progresse !

[~] # lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf
Setting up the GPG keyring
chmod: /var/lib/lxc/container_jammy/tmpdir/gpg: No such file or directory
Error creating container container_jammy

En creusant un peu, la vraie erreur est que je n’ai pas le binaire gpgkeys_curl à l’endroit attendu :

gpg: unable to execute program `/opt/cross-project/arm/linaro/arm-linux-gnueabihf/libc/libexec/gnupg/gpgkeys_curl': No such file or directory

Voilà un autre point que je n’ai pas réussi à corriger correctement.

Le plus simple est de simplement ignorer la validation avec --no-validate mais si vous avez une piste, je suis preneur.

lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf --no-validate

Des dossiers qui disparaissent tout seul ???

Dernier mystère…

Downloading the image index
ERROR: Failed to download http://images.linuxcontainers.org//meta/1.0/index-system

L’erreur n’est pas du tout un problème d’accès à l’URL pour télécharger l’index des systèmes disponibles sur images.linuxcontainers.org (code 302, page redirigée sur uk.lxd.images.canonical.com).

En réalité, si active les messages d’erreurs lors du wget dans le script, l’erreur est que le dossier /var/lib/lxc/container_jammy/tmpdir/ n’existe pas !

Pourtant, ça devrait être corrigé, suite à la modif qu’on a faite ligne 323 (voir plus haut)… trop bizarre :/

J’en ai eu un peu marre de creuser et au bout d’un moment, j’ai juste fait :

export CONTAINER_NAME=jammy
mkdir -p /var/lib/lxc/${CONTAINER_NAME}/tmpdir/
mkdir -p /var/lib/lxc/${CONTAINER_NAME}/rootfs/
lxc-create -t download -n ${CONTAINER_NAME} -- -d ubuntu -r jammy -a armhf --no-validate

Et croyez-le ou non, mais ça marche ! Le container existe (il n’est juste pas visible dans la console pour l’instant)

[...]
You just created an Ubuntu jammy armhf (20220611_07:42) container.

On a plus qu’à redémarrer Container Station, il apparaît

Conclusion

Si jamais quelqu’un de chez QNAP lit ce blogpost… Arrêtez de vous fiche de nous et :

mettez nous LXD dans nos NAS ARM
OU si c’est trop de boulot (je peux l’entendre), remettre LXC en attendant.

Ce genre de hack est indigne et j’ai perdu plusieurs heures pour corriger votre m***e. J’ai payé pour un NAS compatible LXC, ce n’est pas pour que vous retiriez la fonctionnalité 1 an après.

Ce genre de pratiques est vraiment dégueulasse et je n’hésiterais pas à dire tout le mal que je pense de cette décision.

Sources

Stockage pour un admin geek : QNAP TS431P2 ou Synology DS418(j) ?

Tue, 23 Jan 2018 12:45:24 +0000

Behold!

Mon TS431P2

J’en ai déjà parlé sur le blog, j’ai entamé une phase de dés-auto-hébergement. Oui je sais, c’est triste.

Au delà des problématiques de disponibilités des services plus réduite en auto-hébergement (sauf à réaliser des efforts conséquents) par rapport à des services en ligne, héberger son serveur, ce n’est pas toujours très écolo et ça peut coûter plus cher.

Louer une machine physique et y installer un hyperviseur chez Kimsufi (ou OneProvider ou autre) permet de faire des économies pour une qualité de service supérieure (cf les articles de M4vr0x). Alors ce n’est certainement pas aussi fun que de concevoir et monter son propre meuble « rack » et y visser une carte mère dedans mais c’est probablement aussi plus rationnel.

N’ayant plus que le « serveur NAS » dans mon Red Helmer maison, j’ai donc décidé d’aller au bout de la démarche et d’abandonner mon Xubuntu customisé pour acquérir un QNAP TS431 P2.

Migration en cours

Synology ou QNAP, un choix de société ? Vous avez 4 heures !

Je vais esquiver (ou au moins tenter d’esquiver) un flame war Synology versus QNAP et simplement lister mes besoins. Je veux remplacer un NAS existant à base d’OS Linux disposant des caractéristiques et fonctionnalités suivantes :

Matériel :
- Intel Pentium (dual core 3GHz)
- 8 Go de RAM
- ~6 To via 3x 3To de HDD Western Digital Red en grappe RAID 5 via mdadm . Le but est de réutiliser ces disques.
- 4 baies 3,5″ minimum (cf ligne précédente)
Performances :
- Je souhaite disposer d’un NAS capable a minima de saturer le port gigabit Ethernet (>100 Mo/seconde en lecture ou écriture séquentielle) sans perte de performance sur les autres services
Fonctionnalités :
- Partages NFS, CIFS, iSCSI
  - Serveur SFTP, Plex et Deluge centralisant les téléchargement démarrés depuis tous les PC du foyer
- Accès SSH en admin (pour hébergement de petits services complémentaires comme des scripts de supervision, mise à jour de DynHost OVH, …)
Prix :
- Le moins cher possible une fois que les critères de performances et fonctionnalités sont respectés

Si on met de côté le serveur Deluge qui est un besoin un peu exotique, les fonctionnalités nécessaires sont relativement basiques. Ce n’est donc pas réellement un critère de choix.

Shortlister du matériel

Je me suis néanmoins limité à Synology et QNAP (les deux leaders) pour m’assurer un meilleur support et une meilleure assurance d’avoir de nouvelles fonctionnalités dans les années à venir car leurs OS sont régulièrement mis à jour.

J’ai donc épluché les références sur le site des deux marques (Synology et QNAP) et voilà les modèles qui ont retenus mon attention :

QNAP TS431P2 (Home - Middle range)
QNAP TS451* (Home - High end)
Synology DiskStation DS418j (Home - Middle range)
Synology DiskStation DS418 (Home - Middle range)

Clairement, le TS451 (et ses déclinaisons) est overkill. Outre la sortie HDMI dont je n’ai que faire (le NAS est dans le dressing, loiiiin de la TV), le TS451 dispose d’un Celeron, capable sur le papier de faire tourner des VMs. L’argument est intéressant mais je ne pense pas en avoir l’utilité à la maison, toutes mes VMs ayant été transportées sur les serveurs chez Kimsufi.

La vraie « battle » s’est donc faite entre le TS431P2 et les deux Synology DS418 et sa version « j ».

Comparer des oranges et des bananes

Voici un petit tableau comparatif des trois NAS :

La RAM

Il y a clairement 2 philosophies. Synology se vante d’avoir doublé la capacité de la RAM de ces modèles de 2018 (2G/1G) par rapport à ceux de 2016 (1G/512M). En même temps on partait de tellement loin ! Chez QNAP, si les modèles d’entrée de gamme sont aussi en 1Go, on hésite pas à proposer des modèles avec 2, 4, voire 8 Go, et à indiquer que tous les modèles sont upgradables. Dans l’optique d’héberger de futurs services supplémentaires à la maison, c’est rassurant, mon TS431P2 ne manquera pas de RAM.

Performance brute

A première vue, les 3 NAS disposent de processeurs ARM récents et se valent.

Pourquoi je parle de CPU ? Au delà de la vitesse des disques qui est indépendante du NAS choisi, et de la vitesse des ports Gigabit (bridée… à 1 Gbit ! surprise !), c’est le CPU le facteur limitant sur la plupart des NAS sur le marché.

Or dans le cas présent, les 3 saturent les ports Ethernet en lecture ou écriture séquentielles (le DS418j n’a qu’un port Ethernet, d’où les débits 2x inférieurs).

C’était une vraie inquiétude pour moi car les premiers Synology que j’avais pu manipuler il y a quelques années étaient plombés par des ARM sous dimensionnés induisant des plateaux à 40-50 Mo/s et bloquant toutes les autres opérations (CPU à 100%). C’était la raison pour laquelle j’ai monté plusieurs « NAS maisons » depuis 2011, avec des performances bien plus importantes à tarif égal.

Comparer les ARM entre eux

A ma connaissance, il n’existe pas de base de données en ligne de benchmark sur les différents CPU ARM (comme on peut trouver pour Intel et AMD par exemple), donc pas de possibilité de comparer comme cela.

Cependant, en fouillant un peu plus, j’ai pu me rendre compte que l’Alpine AL-314 semble surclasser très (très) largement les deux autres. En épluchant la fiche technique du TS431X2 (un NAS QNAP entrée de gamme pour PME avec un port… 10GbE fibre !) qui a le même processeur, on découvre des performances maximales théoriques de 1014 Mo/s en lecture et 580 Mo/s en écriture ! On sature même le 10GbE en lecture…

Cet avantage se confirme sur les transferts chiffrés. Le DS418 ne sature plus qu’un seul port Ethernet et le DS418j tombe même bien en dessous des 100Mo/s en écriture.

Parallèlement, le TS431P2 garde un débit assez proche de la saturation de ses deux ports Ethernet. Autant dire qu’avec ce processeur, le NAS s’ennuie quand on transfère à 100 Mo/s (ce que j’ai pu vérifier IRL).

Il n’y a donc aucune contrindication à héberger des services supplémentaires et les gros transferts n’ont aucun impact sur les performances globales du NAS (si ce n’est congestionner le réseau).

Killer features (containers et snapshots)

Déjà, côté matoss, le QNAP est donc devant.

Côté fonctionnalités, si DSM (OS des Synology) possède beaucoup plus de paquets/applications que QTS (OS des QNAP), les DS418(j) ne sont pas compatibles avec l’application Docker alors que le TS431P2 (et tous les autres QNAP) propose une application officielle pour gérer les containers LXC ET Docker.

Container Station

Dans l’optique de remonter mon serveur Deluge sur le NAS (et d’autres services par la suite), c’est donc un autre point positif pour QNAP.

Deux derniers point mis en avant par QNAP, la possibilité de gérer sur tous les modèles de la gamme des snapshots de tous les volumes avec la dernière version (QTS 4.3.4), ce qui n’est pas possible sur les DS418(j), ainsi qu’une application pour gérer des devices de type IoT.

User friendly versus bidouilleur

Clairement, le positionnement de Synology est de proposer des boitiers suffisants pour la plupart des utilisateur, un peu moins customisables et performants mais aussi un peu plus simple d’utilisation. C’est pour ça que, pour tout autre personne que moi (ou un geek sysadmin), je conseille les Synology.

J’insiste : les différences sont vraiment infimes car QNAP est aussi très user friendly. L’interface est très fluide et très intuitive, mais on a clairement plus la main (pas encore autant que je voudrais :-p) et un néophyte serait probablement plus à l’aise sur un Synology.

Le « bureau » de QNAP

Administration et Filestation

Mais le fait que le CPU soit bien plus costaud côté sur les QNAP et qu’on ait la possibilité d’augmenter la RAM sont clairement des points qui plaisent aux bidouilleurs dont je fais partie.

L’ajout de fonctionnalités comme Docker/LXC, les snapshots ou le support de l’IoT sur toute la gamme aussi.

Sans trop d’hésitation, j’ai donc choisi le TS431P2. En profitant d’une promo j’ai réussi à avoir le modèle 1 Go avec une barrette de RAM 8 Go pour pratiquement le même prix que sans. Je ferai peut être un petit article sur la partie upgrade de la RAM ;-)