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

Proxmox - Tips and tricks

Mon, 22 Aug 2022 06:30:00 +0200

OK je reparle de Proxmox ;-)

Certains trolls velus (😘) m’ont reproché de trop parler de XenServer / XCP-ng / Xen Orchestra, ces derniers temps.

Pour leur faire plaisir (car que je suis quelqu’un de sympa, en vrai), voici donc un article qui parle de tous les petits trucs que je trouve cool dans Proxmox VE et qui ne sont (je pense) pas forcément connus des débutants.

Je ne parlerais donc pas des trucs de base comme le fait qu’on puisse piloter les upgrades depuis l’UI, que les backups sont intégrées (même s’il y a un backup server plus poussé aussi) ou le firewall depuis l’UI (que je n’ai pas utilisé en vrai), ou bien encore la gestion des certificats Let’s Encrypt pour l’UI.

C’est parti !

Avoir un cluster de virtualisation open source

Un truc très fort avec Proxmox VE est quand même que vous disposez d’un OS open source, clé en main, disposant en plus d’un mécanisme de clustering “prod ready”. Grand luxe !

Tout est géré par un cluster corosync. L’ajout des nodes se fait via l’interface graphique en quelques clics (ou via ligne de commande si vous êtes un foufou comme moi).

Normalement, cette fonctionnalité est quand même réservée à un usage dans un LAN dédié. Mais j’ai quand même abondamment tordu la fonctionnalité pour la faire marcher, au fil des ans, chez des hébergeurs grand public, voire au travers d’Internet, dans des réseaux NATé, etc…

Et avec un PRA !

Avec mon cluster Proxmox, j’ai aussi un plan de reprise d’activité (PRA). Les développeurs de Proxmox VE ont astucieusement tiré parti de la fonctionnalité de réplication asynchrone de ZFS pour périodiquement (par défaut toutes les 15 minutes) synchroniser des disques entre des machines distantes.

Note: ZFS, j’en ai aussi beaucoup parlé.

Tout est prévu dans l’interface graphique, il n’y a rien à faire à part avoir un cluster Proxmox VE et du stockage ZFS, ça “juste marche”.

Les containers LXC

C’est littéralement LE TRUC que j’utilise le plus dans Proxmox VE. Je fais très peu de machines virtuelles KVM car je loue des machines très peu puissantes (et pas chères), pas capables de faire de la virtualisation (pas d’instructions VT-x sur les Atom C2350).

Même si j’utilise tous les jours des containers de type “Docker” au travail, ce n’est pas ce que je cherche quand je monte des petites machines sur mon infra perso.

LXC est un bon compromis : j’ai le sentiment d’avoir une machine virtuelle (j’installe des OS, des packages, dépose mon application où je veux, …) sans la lourdeur de la VM.

Les temps de boot sont quasiment instantanés, l’overhead CPU, surtout sur mes machines faiblardes, est très léger. Mais le plus important reste l’empreinte mémoire ridicule. J’ai plusieurs containers hébergeant des serveurs webs qui tournent avec moins de 128 Mo de RAM. Impossible avec une machine virtuelle KVM.

Exemple avec un reverse proxy nginx en frontal de plusieurs petits sites. Le container consomme quelques Mo.

En revanche, l’isolation est moins bonne (on partage un kernel donc forcément…). En termes de sécurité c’est moins bien, et on arrive parfois à des petits soucis comme j’ai pu en parler dans l’article Jeedom dans un container LXC.

Je ferai (un jour) un article dédié aux containers LXC tellement je trouve ça cool.

Tuning ZFS

La croyance populaire veut que ZFS nécessite beaucoup de RAM pour fonctionner. C’est faux (sauf si vous activez la déduplication).

Dans la documentation officielle de Solaris (les inventeurs de ZFS), on parle de 1 Go de RAM (dont 768 Mo pour le système).

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.

https://docs.oracle.com/cd/E18752_01/html/819-5461/gbgxg.html

Sauf que des fois, ZFS est un peu trop gourmand, par défaut. C’est typiquement le cas sur mes Atom qui n’ont que 4 Go de RAM, sur lesquels ZFS croque 50% de la RAM pour son cache ARC.

On tune ça avec une simple commande :

#Restrict to 512MB
echo 536870912 |sudo tee -a /sys/module/zfs/parameters/zfs_arc_max

#Restrict to 4GB
echo 4294967296 |sudo tee -a /sys/module/zfs/parameters/zfs_arc_max

Plus de tips sur le tuning de ZFS sont disponibles sur ce post de admin magazine.

Monter des disques LXC/QEMU avec ZFS

Un truc un peu déstabilisant quand on passe sur ZFS comme gestionnaire de stockage pour son cluster Proxmox VE est qu’on ne voit plus les disques comme des fichiers (.qcow2) comme avant.

Rappelez-vous, ZFS est aussi un gestionnaire de stockage, pas juste un filesystem.

Pour accéder à vos disques de machines virtuelles, il faut aller chercher dans les fichiers spéciaux dans /dev. Par exemple pour la VM avec l’ID 100 :

ls -l /dev/zvol/rpool/vm-100*
lrwxrwxrwx 1 root root 10 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0 -> ../../zd16
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part1 -> ../../zd16p1
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part2 -> ../../zd16p2
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part5 -> ../../zd16p5

Note: on peut d’ailleurs directement monter les partitions dans notre hyperviseur avec un bête mount. Avouez que c’est plus pratique à monter qu’un disque qcow2 nan ?

Pour accéder à vos disques de containers LXC, c’est encore plus simple, ils sont à la racine de votre pool ZFS. Par exemple pour le container LXC avec l’ID 201 :

ls /rpool/subvol-201-disk-0/
bin dev home lib64 media opt root sbin srv tmp var
boot etc lib lost+found mnt proc run selinux sys usr

Télécharger les ISOs directement depuis l’UI

Là, c’est vraiment du “nice to have” mais j’aime bien ce genre de fonctionnalités pour aider l’admin: vous pouvez directement télécharger vos images ISO pour installer vos machines virtuelles directement depuis la console Web.

Et de la même manière, vous pouvez aussi télécharger les images de containers LXC depuis une URL ou depuis la base d’images déjà accessibles depuis Proxmox VE (la section “système” me semble être une sous-sélection des images officielles disponibles sur le site de LXD).

Optimisation de perf pour les VMs

J’avais fait un article pour parler des optimisations que j’avais pu faire pour les machines virtuelles sous Proxmox VE. Le titre de l’article cite pfsense mais c’est applicable à tous les OS en réalité.

Optimisation de PFsense dans Proxmox VE

L’optim consistant à décocher “Use tablet for pointer” est vraiment hyper utile et marche très souvent si vous remarquez un usage CPU idle anormal sur vos VMs.

Automatisation

Si vous êtes fans d’infrastructure as code (as you should), sachez qu’il existe :

J’utilise en prod les modules Ansible, ce qui me permet de générer à la fois une VM puis d’installer des choses dedans avec mes playbooks. Hyper utile.

Je ferai probablement un article pour le provider terraform car il me fait de l’oeil (mais du coup, dur de chaîner l’install des logiciels dans la VM après instanciation).

Monitoring

Enfin, si vous avez déjà une infra Prometheus, sachez qu’il existe plusieurs exporters pour avoir de jolis graphes de vos Proxmox. Je les avais testés à l’occasion de cet article - Proxmox VE + Prometheus = <3.

Sachez que vous pouvez aussi directement brancher depuis la console votre cluster sur des TSDB de type InfluxDB ou Graphite (pas encore testé mais pourquoi pas :D).

Fin de cet article

A plus de 9000 signes, je pense qu’il faut que j’arrête là pour ce premier article sur les trucs que je trouve cool et les astuces que j’utilise souvent sur Proxmox VE.

Cependant, je ne m’interdis pas d’en écrire un autre plus tard, si jamais je retrouve assez de choses à dire.

En connaissez-vous d’autres que vous voudriez partager ? Est-ce que vous avez envie que je creuse un point en particulier ?

InfluxDB comme metrics server ?
Le provider Terraform ?
LXC ?

Sortie de Proxmox VE 5.2.1, les nouveautés

Tue, 22 May 2018 14:45:57 +0000

Proxmox VE 5.2.1

La semaine dernière, Proxmox Server Solutions GmbH, l’équipe derrière Proxmox VE a sortie la version 5.2 de son hyperviseur libre & clé en main.

J’ai déjà écris de nombreux articles sur cette distribution car c’est un très beau projet, à mon sens une des seuls distributions clés en main pour faire de la virtualisation aussi bien pour des besoins perso que des besoins pros. Pour ceux qui ne connaissent pas, je vous conseille de commencer par les tutos de M4vr0x sur Proxmox VE 5.x (part1) (part2) (part3).

Dans le rétroviseur, Proxmox VE 5.0 et Proxmox VE 5.1

Sortie l’été dernier, le changement de la branche 4 vers la branche 5 de Proxmox VE a surtout marqué une évolution de l’OS à la base de Proxmox VE (Debian 8 vers Debian 9), même si quelques features sympa avaient quand même été ajoutées.

Dans les points marquants, il y avait tout de même eu :

le renforcement de l’intégration avec Ceph, via l’intégration de la version Luminous (Ceph 12.1, preview) et des améliorations dans le Dashboard Ceph dans l’UI (apparue en 4.4)
l’introduction de la fonctionnalité de Storage Replication, basée sur des mécanismes built-in de ZFS
la migration à chaud de VMs, même s’il s’agit de stockages locaux
un effort particulier pour importer des VMs provenant d’autres hyperviseurs

Clairement, l’équipe de Proxmox a fait un focus sur le stockage, dans le but de rattraper les « grands » hyperviseurs sur ces aspects (i.e. des alternatives à VSAN, vSphere Replication et storage vMotion). Voir ce genre de features dans un hyperviseur (qui peut être) gratuit et sans pour autant être une usine à gaz comme RHEV/oVirt est très appréciable.

Sortie fin Octobre, la version 5.1 était passée relativement inaperçue (au moins de moi) puisqu’elle apporte surtout un passage à l’état « production ready » du stockage Ceph (v12.2) dans PVE ainsi qu’une mise à jour de ZFS apportant des gains de performance (en plus des mises à jour de kernel/packages habituelles).

Et Proxmox VE 5.2 alors ?

Là, en revanche, ya du lourd !

Déjà, on est passé sur une Debian 9.4, avec un kernel 4.15.17 (assez récent puisqu’on est en est au 4.16). LXC passe de la 2.0.0 à la 3.0.0, la LTS sortie en mars du container runtime disponible dans PVE. Ceph passe en Luminous LTS stable, ce qui rassurera les plus frileux qui attendaient avant de tester Ceph sous Proxmox VE.

Voilà pour les mises à jour de packages. Maintenant, les features que j’ai hâte de tester =>

Support de Cloudinit dans la GUI. Pour ceux qui ne connaissent pas, c’est un mécanisme universel sous Linux permettant de configurer votre VM dès son instanciation (voir doc officielle)
La possibilité de gérer les nœuds des clusters Proxmox VE
Gestion des certificats Let’s encrypt directement depuis la GUI; ce point va faire l’objet d’un petit article très vite ;-)
Ajout des partages SMB/CIFS comme support de stockage officiel (backups, images, templates, iso et containers)
Affichage de l’adresse IP de la VM dans l’UI (première intégration de l’agent qemu-guest-agent, on peut espérer plus de fonctionnalités à l’avenir)
Possibilité de limiter la bande passante lors des opérations de restauration des backups
Intégration de xterm.js comme console en plus de noVNC et SPICE

Il y en a d’autre mais qui m’intéressent moins. Vous pouvez néanmoins consulter la liste complète sur le changelog de la version.

Concrètement ça donne quoi ?

Je suis assez enthousiaste quant à cette nouvelle version, qui apporte plein de bonnes choses. Je ne souhaite pas en dire plus pour le moment, car je vais (en cours d’écriture) publier des articles dans les jours qui viennent sur ces nouvelles fonctionnalités. Un petit teasing tout de même :

cloud-init dans l’UI de PVE

Génération d’un certificat Let’s Encrypt pour un nœud PVE

L’ajout de xterm.js dans l’UI

La gestion des clusters dans l’UI de PVE

Limites en MiB/s lors d’une restauration

Migration CentOS + KVM vers Proxmox VE

Sat, 21 Nov 2015 11:30:53 +0000

Juste après avoir sorti un article qui traite de la migration de KVM/Ubuntu vers KVM/RHEL, voilà que je migre ENCORE pour ProxMox !?! Mais c’est parce qu’en fait j’avais juste beaucoup de retard sur ces précédents articles ;-).

Présentation de la solution

Cette fois ci, il s’agit donc de vous donner les clés pour migrer sans stress votre serveur sous KVM (Ubuntu, Debian, RHEL, Whatever …) vers Proxmox VE.

Pour ceux qui ne connaissent pas Proxmox VE, il s’agit d’une distribution Debian adaptée pour faire de la virtualisation full (qemu/KVM) et par conteneur (anciennement via openVZ, maintenant via LXC). LE gros plus de la solution, c’est l’interface graphique et l’installation clé en main d’un hyperviseur disposant de fonctionnalités qu’on retrouve chez les grands du marché.

Pour être honnête, j’étais très content de mon KVM pour ce qui est des performances et de la consommation de ressources (point faible d’un ESXi à la maison), mais pas du tout satisfait des manières que j’avais pour l’administrer. J’ai testé plusieurs interfaces graphiques (web ou pas) sans jamais en trouver une à ma convenance (même les usines à gaz comme oVirt, la base de RedHat Entreprise Virtualisation).

Installation

Comme beaucoup d’hyperviseur clés en main, l’étape d’installation est particulièrement soignée pour être simple et rapide. On récupère un ISO, on le copie sur une clé USB, on boot dessus. Quelques écrans et moins de 5 minutes plus tard le serveur reboot et on nous invite à nous connecter à la console web.

Ah ! Ça fait du bien !

La première chose à faire est de créer des pools de stockages (un local est créé par défaut). On peut choisir s’il s’agit d’un pool dédié aux VMs, à la sauvegarde, aux fichiers ISOs. C’est assez pratique.

RAID logiciel MDADM

Sous ProxMox, le RAID logiciel via MDADM Linux n’est pas supporté (voir wiki officiel). Seuls les RAID Hardware sont supportés.

Dans l’interface, vous ne pourrez donc pas le configurer (ni même pendant la phase d’installation). Depuis la version 3.4, vous pouvez cependant installer ProxMox sur un espace ZFS, avec notamment tous les niveaux de RAID/RAIDZ que vous souhaitez. Mais mon petit doigt me dit qu’il s’agit probablement de ZFSonLinux et j’ai déjà donné ;-).

Cette absence de RAID logiciel est une des raisons pour lesquels j’étais initialement réfractaire à ProxMox par rapport à un linux classique avec qemu. Cependant, ce n’est pas parce ce n’est pas supporté que vous ne pouvez pas le faire ! Après tout, il s’agit d’une Debian customisée donc il n’y a rien qui vous retient.

Voici deux articles que j’ai sélectionnés qui vous guideront pas à pas pour le faire (à vos risques et périls, comme d’habitude).

[Edit]

Attention : la partie amorçage ne fonctionnera pas si vous avez un boot EFI (Proxmox 4+). Il faudra trouver une autre technique. Vous pouvez lire cet article qui explique comment faire en général sur Debian :

www.debian-fr.org/t/raid-logiciel-linux-et-amorcage-en-uefi/64655

La partie du tutoriel traitant de lvm pour ProxMox (3ème partition) contenant le / et les données importantes peut par contre bien être suivie. C’est vraiment uniquement le boot EFI qui va nous enquiquiner.

[/Edit]

Migrer ses VM existantes

Nous voici maintenant dans le vif du sujet. Selon la documentation officielle, voici ce qu’on doit faire pour migrer une machine KVM dans ProxMox.

D’abord, on nous dit de créer une nouvelle machine virtuelle. Jusque là tout va bien. On lui affecte les options par défaut et pas de CD-ROM dans le lecteur.

Ensuite ça se gâte. En effet, on veut supprimer le disque dur par défaut puis ajouter notre disque importé de l’ancien système KVM. On va donc dans les propriétés de la machine virtuelle nouvellement créée.

Et là, blague… Pas de bouton « Parcourir » pour aller chercher notre disque virtuel à importer !

On peut trouver la solution assez vite sur les forums, mais c’est quand même assez frustrant, surtout quand on voit la malheureuse ligne donnée dans le wiki en guise de procédure…

Dans ce thread et ce thread, on apprend que pour chaque banque de données, chaque VM dispose d’un dossier dans lequel il faut déposer le disque. Dans le bon dossier ! Par exemple :

pour le stockage local, la VM avec l’id 100 a un dossier /var/lib/vz/images/100/
pour le stockage NFS nommé de manière originale NFS_VM, il y a un dossier /mnt/pve/NFS_VM/images avec des sous dossiers pour chaque VM qui dispose d’un disque sur ce partage NFS.

A partir de là, on copie donc nos fichiers dans les bons dossiers en fonction de ce qu’on veut faire. Dans le cas présent je copie les fichiers sur le stockage local, dans un premier temps.

cp MaVM.qcow2 /var/lib/vz/images/100/

Une fois que c’est fait, les disques apparaissent dans la page spécifique de la banque de données.

Mais le disque virtuel n’apparaît toujours pas dans la machine virtuelle. Il faut aller éditer à la main le fichier de configuration de la VM, situé dans /etc/pve/nodes/xxx/qemu-server/[VMID].conf.

vi /etc/pve/nodes/xxx/qemu-server/100.conf
bootdisk: ide0;
cores: 2
ide2: none,media=cdrom
memory: 1024
name: bck-xxx-xxx
net0: e1000=7A:FA:D6:DC:06:70,bridge=vmbr0
numa: 0
ostype: l26
smbios1: uuid=ae5d66d6-724f-46cd-a85b-24eda7b9ecec
sockets: 1
ide0: local:100/xxx-xxx-flat.vmdk
ide1: local:100/xxx-xxx_1-flat.vmdk
unused0: local:100/vm-100-disk-1.vmdk
unused1: local:100/vm-100-disk-2.qcow2,size=32G

A partir de là, les disques apparaissent dans la VM au niveau de ide0 et ide1 dans mon cas. On progresse.

Cas des disques QCOW2

Dans le cas des disques QCOW2 (et les QCOW2 uniquement, pas les RAW), il sera nécessaire d’ajouter également un argument « taille » du disque, sans quoi la VM peut ne pas démarrer. Il faudra rajouter en fin de ligne la taille du disque (xxx,size=yyG).

Astuce : si vous ne la connaissez pas, supprimez le disque de la VM (qui passera en inutilisé), puis éditer le (edit) pour l’ajouter à nouveau. Le fichier de configuration devrait se recréer avec les bonnes options automatiquement.

Cas des disques RAW

A l’inverse, la taille du disque en argument dans la configuration d’une VM pour une image RAW ne semble pas nécessaire.

Par contre, pour les disques raw, il faut savoir qu’il faut ABSOLUMENT les nommer en « .raw » pour qu’ils soient visibles dans la liste des disques (mes disques provenant de KVM étaient nommés par défaut en « .img »).

Si vous ne les renommez pas, les disques seront présents dans la VM, mais elle refusera de démarrer avec l’erreur suivante :

unable to parse volume filename

Il faudra prendre soin de tous les renommer, puis de modifier la configuration de la machine virtuelle en tenant compte de cette modification.

Erreur lors du remplacement d’un disque avec ZFSonLinux : devices have different sector alignment

Thu, 28 Aug 2014 10:08:49 +0000

Ceux qui me lisent savent que j’adore ZFS.

ZFS, c’est juste génial.

Les types qui ont inventé ce FS ont pris toutes les fonctionnalités intéressantes qu’on peut trouver dans un FS moderne, et les ont intégrés. Pour rappel, quelques unes qui me tiennent à cœur :

b-tree FS
transactions en mode copy-on-write
abstraction du stockage, création de FS simplifiée
gestion des snapshots
partages NFS/CIFS natifs
compression/déduplication native
gestion de caches SSD native
…

Mais ils ont aussi eu le malheur de le développer pour Solaris … et lui coller la malédiction d’un OS en perdition avec une licence le rendant difficilement compatible à un portable sur le kernel Linux… C’est la vie ;-)

Toujours est-il que ça n’a pas arrêté certaines personnes pour le porter, avec le projet ZFSonLinux, et permettre au ZFS fanboy que je suis d’avoir du ZFS sur mon NAS sous Linux, sans passer par la méthode ZFS/fuse en userland.

Cependant, ce projet relativement confidentiel n’est pas sans ses petits accros. C’est notamment ce que j’ai pu constater amèrement l’an dernier, quand ma grappe Z-RAID s’est dégradée suite à la perte d’un disque…

zpool status tank
pool: tank
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
scan: resilvered 31,5K in 0h0m with 0 errors on Sun Mar 24 12:44:41 2013
config:

NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD20EARX-00PASB0_WD-WCAZAH899460 ONLINE 0 0 0
scsi-SATA_SAMSUNG_HD204UIS2HGJ90B632655 ONLINE 0 0 0
ata-ST2000DL003-9VT166_5YD769R0-part3 UNAVAIL 0 0 1

OK. J’ai un disque HS. J’en achète un autre, et je le remplace. Finger in ze noz !

zpool replace tank ata-ST2000DL003-9VT166_5YD769R0-part3 ata-ST2000DL003-9VT166_5YD769R0
cannot replace ata-ST2000DL003-9VT166_5YD769R0-part3 with ata-ST2000DL003-9VT166_5YD769R0: devices have different sector alignment
zpool get ashift tank
NAME PROPERTY VALUE SOURCE
tank ashift 0 default

Malheureusement, à la création du pool, j’avais des vieux disques ne supportant pas les blocs de 4K (Advanced format), qui a donc été créé par défaut en mode legacy, à savoir 512 octets. Jusque là, rien de critique : le disque récent en 4k devra fonctionner sur des blocs de 512, ce qui restreindra ses performances brutes mais je ne suis pas à ça près, je veux juste remplacer mon fichu disque… Bien sur, j’ai testé …

zpool set ashift=12 tank

… et ça ne fonctionne pas. Faut pas croire au père noël, ce paramètre est malheureusement inscrit en dur lors de la création du pool, et ne peux pas être modifié à postériori.

Cependant, ça n’explique pas pourquoi je ne pouvais pas ajouter mon disque 4k dans un pool en 512.

Et là, c’est le drame…en fait il s’agit d’un bug qui avait été introduit dans ZFSonLinux qui empêche le remplacement d’un disque de format différent de celui du pool :

Plutôt gênant… Heureusement, je suis tombé sur des gens suffisamment calé en code pour comprendre le problème, et proposer une solution. Voici ce que j’ai du faire pour remplacer la version ZFSonLinux officielle d’Ubuntu par une version patchée qui elle acceptait le remplacement.

apt-get install git uuid-dev alien
git clone https://github.com/murrayju/zfs
cd zfs
./autogen.sh
./configure
apt-get install uuid-dev
./configure
make deb
dpkg -l | grep zfs
apt-get remove zfsutils zfs-fuse zfs-dkms ubuntu-zfs libzfs1
dpkg -i *.deb
dpkg -l | grep zfs
init 6 #dans le doute
zpool status
zpool replace tank ata-ST2000DL003-9VT166_5YD769R0-part3 ata-ST2000DL003-9VT166_5YD769R0
zpool status
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Sun Mar 24 14:00:28 2013
20,8M scanned out of 2,59T at 2,98M/s, 253h10m to go
6,25M resilvered, 0,00% done
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
ata-WDC_WD20EARX-00PASB0_WD-WCAZAH899460 ONLINE 0 0 0
scsi-SATA_SAMSUNG_HD204UIS2HGJ90B632655 ONLINE 0 0 0
replacing-2 UNAVAIL 0 0 0
ata-ST2000DL003-9VT166_5YD769R0-part3 UNAVAIL 0 0 0
ata-ST2000DL003-9VT166_5YD769R0 ONLINE 0 0 0 (resilvering)

Je ne vous raconte pas le soupir de soulagement que j’ai poussé lorsque j’ai vu ceci à l’écran

Du ZFS à la maison avec ZFSonLinux et un coup de main pour comprendre grâce à Aaron Toponce

Mon, 07 Jan 2013 17:59:37 +0000

Je l’ai déjà dis, je suis un sysadmin/technophile. Et comme je ne peux rien faire comme tout le monde, quand j’ai décidé de me monter mon NAS/MediaCenter perso, j’ai voulu le faire aussi bien au niveau hardware que software. Ceci m’a permis, à coût égal, de faire au moins aussi bien qu’un NAS tout prêt, et même beaucoup mieux dans certains domaines… au prix de multiples passes/améliorations/prises de tête ;-).

Pour toutes ces raisons, je ne pouvais PAS passer à côté de ZFSonLinux, une implémentation du FS introduit par Sun dans Solaris, car ZFS et à mon sens un des filesystems les plus aboutis en terme de fonctionnalités et surtout de sécurité des données :

b-tree file system
checksuming de tous les blocks à 256 bits (eux même checksumés) et équivalent du fsck à chaud
équivalent de parité/RAID en natif
gestion de FS simplifiée avec des propriétés qui peuvent être héritées ou modifiées
compression et même déduplication (!!!) en natif
protocoles de présentations sur le réseau en natif
snapshots quasiment illimités
… (j’en oublie sûrement beaucoup => go site officiel/wikipédia)

Sans aller plus loin, je vous propose juste d’aller voir un travail assez complet sur ZFSonLinux, qui regroupe l’équivalent de plusieurs documentations ZFS expliquées et appliquées au cas qu’est ZFSonLinux :

Rappel des concepts de ZFS
Mise en place étape par étape
Best Practices et ressenti de l’auteur sur la techno et la stabilité des fonctionnalités délivrées par cet implémentation

Je ne ferais pas mieux que lui pour expliquer, c’est un must-read pour tout ceux qui voudraient en savoir plus sans savoir où commencer

Install ZFS on Debian (lien mort, j’utilise Internet Archive)

En bonus track, je vous linke aussi la documentation officielle Oracle pour aller plus loin dans l’utilisation de la CLI et un bon vieux troll de 2007 ;-)

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.