ARM on Zwindler's Reflection

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

Déployer en 5 minutes un cluster Kubernetes sur ARM avec k3s et Ansible

Thu, 21 Mar 2019 13:00:14 +0000

C’est quoi k3s ?

Il y a quelques jours, vous avez peut être vu passer dans vos fil d’actus k3s, ce nouveau projet open sourcé par Rancher.

Lightweight Kubernetes. 5 less than k8s.

Il s’agit d’une version réduite de Kubernetes, sans pour autant être minimaliste, qui nous vante la possibilité de monter des clusters Kubernetes avec très peu de ressources nécessaires. On parle de moins de 512 Mo de RAM pour un master, encore moins pour un worker, tout dans un binaire de 40 Mo, support de armhf, et arm64, …

Great for Edge, IoT, CI, ARM, and situations where a PhD in k8s clusterology is infeasible

Cerise sur le gâteau, comme tout est regroupé dans un seul et même binaire, l’installation est ultra simple et se résume en :

Récupérer un binaire
Lancer le binaire sur le master
Lancer le binaire sur le worker avec l’URL du master et un token

Mais c’est génial !

Nécessairement, pour arriver à ça, il a fallut faire quelques concessions mais pour l’instant je ne les trouves pas très gênantes. Parmi les modifications notables, on retrouve :

Suppression des features alpha, legacy et non standard
Suppression de tous les add-on des cloud providers
Remplacement de etcd3 par sqlite3 (même si etcd3 peut être toujours être utilisé)

J’en veux un !

Autant dire que pas mal de bidouilleurs du dimanche se sont jetés dessus.

Le premier exemple qui vient à l’esprit est de monter un cluster Kubernetes sur Raspberry pi. Nombre de personnes ont déjà installé Docker sur un raspberry qui traînait dans un tiroir (moi compris), et le nombre d’articles avec Docker Swarm sur plusieurs Raspberry pullule sur le web.

Geekerie du week end : installer Docker sur un Raspberry Pi

Tout ça c’est très bien mais jusqu’à présent, il était difficile d’installer Kubernetes sur ce genre de machines, assez limités en CPU/RAM. Du coup, vous vous en doutez, je ne suis pas le premier à parler de ça.

Vincent RABAT aka itwars (que vous connaissez sûrement si vous écumez les meetups sur Bordeaux) m’a coiffé au poteau en releasant un playbook Ansible pour installer k3s, et notamment sur un Raspberry Pi (mais pas que).

A charge de revanche, Vincent ;-).

Un peu différent

Du coup, pour me démarquer, je vous propose aujourd’hui quelque chose d’un peu différent. N’ayant pas suffisament de raspberry sous la main, j’ai voulu faire un PoC de k3s en me basant sur des machines ARM créées chez un cloud provider.

L’idée étant que si ça marche sur des machines de faible puissance en ARM, ça marchera partout (x64, raspberry, etc).

Ça fait plusieurs fois que j’utilise Scaleway comme hébergeur pour des petits projets, et en particulier pour déployer rapidement des machines car leur API est pas trop mal fichues et surtout ils disposent de modules Ansible très bien fait, notamment avec la feature « inventaire dynamique », ce que beaucoup ne font pas.

Pour ceux que ça intéresse, mon talk sur BDX.IO était basé sur le même principe :

https://www.youtube.com/watch?v=WPRE1_f0pyg

Dans ce tuto, je vais donc vous montrer comment en quelque commande, monter un cluster k3s sur des machines ARM créées à la volée chez Scaleway, le tout avec Ansible (vous l’aurez compris).

Quelques prérequis

La première chose à faire est de cloner sur votre machine les playbooks Ansible que j’ai mis à disposition sur Github à l’adresse suivante : github.com/zwindler/ansible-scaleway-k3s

Pour réaliser ce tuto, je pars du principe que vous avec déjà un compte sur Scaleway, que vous avez un clé SSH qu’on déposera à la racine du projet, appelée admin.pub (c’est original).

Il faudra également installer les package pipy suivant sur la machine locale :

pip install jinja2 PyYAML paramiko cryptography packaging

Ensuite, vous devrez installer Ansible depuis les sources (>= 2.8devel) et éventuellement le binaire jq pour requêter dans les output JSON (ça c’est juste pour se faciliter la vie)

Dans la console Scaleway, vous devrez créer un token sur le site de Scaleway pour les accès distants et le stocker dans un fichier scaleway_token

export SCW_API_KEY='aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa'

Et enfin sourcer le fichier pour avoir la variable dans votre environnement

source scaleway_token

OK, on est prêt

La première étape de cette procédure va être de générer des instances ARM pour héberger le master et le worker Kubernetes. Pour ça, le playbook Ansible create_arm_vms.yaml va :

récupérer l’ID d’organisation du compte Scaleway
récupérer un ID d’image compatible debian Stretch
ajouter si nécessaire la clé SSH de l’admin
créer autant de machines que nécessaire

On lance la commande suivante :

ansible-playbook create_arm_vms_scaleway.yml

ET C’EST TOUT !

Normalement en 2 minutes, vous devriez avoir 2 instances ARM sur le datacenter de Paris (par1).

A noter, il se peut qu’elles ne soient pas accessibles tout de suite en SSH. J’adapterai peut être le playbook pour qu’il ne rende pas la main tant que les machines ne sont pas accessibles, et qu’on enchaîne automatiquement sur l’étape suivante (TODO).

Inventaire automatique

Je le disais plus haut, la grande force de Scaleway avec Ansible est le fait qu’ils ont fait l’effort de coder l’inventaire dynamique. Vous n’avez pas besoin de renseigner à la main les IPs des instances que vous venez de créer dans un fichier ansible/hosts. Grâce à l’API, la découverte se fait automatiquement. On va dont pouvoir enchaîner sur la suite directement.

De base, voici le contenu de mon fichier d’inventaire (inventory.yml) :

plugin: scaleway
regions:
- par1
tags:
- k3smaster
- k3sworker

Maintenant que les machines sont UP, on peut vérifier ce que nous renvoie Scaleway avec la commande ansible-inventory. Ça devrait ressembler à ça :

ansible-inventory --list -i inventory.yml
{
"_meta": {
"hostvars": {
"x.x.x.x": {
"arch": "arm64",
"commercial_type": "ARM64-2GB",
"hostname": "k3smaster1",
[...]
"k3sworker": {
"hosts": [
"x.x.x.x",
"y.y.y.y",
"z.z.z.z"
]
}

SSH fingerprints

Une étape qui est souvent fastidieuse, surtout quand on ajoute beaucoup de serveur, est l’étape de vérification de l’empreinte SSH des nouveaux serveurs lors de la première connexion. Cette authentification est très importante et il n’est pas du tout conseillé (comme je le vois parfois) d’ajouter l’option ANSIBLE_HOST_KEY_CHECKING=False.

Ici, je vous propose de scanner automatiquement la première fois l’empreinte, et l’ajouter dans votre known_hosts. Ainsi, si l’empreinte change en cours de route, vous serez prévenus. Cependant, ce n’est à utiliser que dans le cas de notre bidouille, pas en production.

ansible-inventory --list -i inventory.yml | jq -r '.k3smaster.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts
ansible-inventory --list -i inventory.yml | jq -r '.k3sworker.hosts | .[]' | xargs ssh-keyscan >> ~/.ssh/known_hosts

Vous pouvez maintenant ajouter votre clé SSH dans le ssh-agent, et vérifier qu’on vous pouvez vous connecter à tous les serveurs via Ansible :

eval `ssh-agent`
ssh-add myprivate.key

Préparation du serveur

C’était facile, non ?

Et bien la suite l’est encore plus, à l’exception de cette petite subtilité/piège => Il se trouve que l’image ARM par défaut proposée par Scaleway ne dispose ni de python ni de sudo. Pour faire du Ansible, c’est très très handicapant.

J’ai donc écris un petit playbook, à n’exécuter la première fois, qui installe les prérequis non présents sur l’image de base (python et sudo)

ansible-playbook -i inventory.yml -u root install_prerequisites_scaleway.yml

Si vous n’êtes pas sur ce genre de machines, vous n’aurez pas à faire cette étapes.

Maintenant qu’on a des machines avec python et sudo, on peut installer k3s normalement avec Ansible :

ansible-playbook -i inventory.yml -u root install_k3s_scaleway.yml

Une fois de plus : ET C’EST TOUT !

Le cluster est maintenant opérationnel. Les serveurs ont Kubernetes installé et fonctionnel. Le ou les workers ont rejoint le master et font parti d’un même cluster. Un Ingress controller Treafik est créé, on peut jouer dessus directement :-)

Bonus : accéder au cluster

Bon je vous ai un peu feinté.

Certes, on peut se connecter en SSH sur le master et le piloter avec les commandes kubectl classique (mais il faut rajouter k3s devant car le binaire kubectl est intégré à k3s). Mais c’est quand même plus simple si on peut y accéder à distance, depuis votre machine locale.

Là encore, j’ai donc fais un petit playbook qui va aspirer la configuration kubectl et la coller dans le fichier ~/.kube/config.k3smaster

ansible-playbook -i inventory.yml -u root configure_kubeconfig.yml

A partir de là, vous devriez pouvoir tester votre nouveau cluster depuis votre PC :-)

cd
kubectl --kubeconfig=.kube/config.k3smaster get nodes
NAME STATUS ROLES AGE VERSION
k3smaster1 Ready <none> 2d v1.13.3-k3s.6
k3sworker1 Ready <none> 2d v1.13.3-k3s.6

Enjoy !!!

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 ;-)