Salutations aux passionnés de ZimaBoard ! Aujourd’hui, nous sommes ravis de vous présenter un tutoriel complet de notre membre dévoué de la communauté, Tyrehl. Non seulement Tyrehl vous guide avec expertise à travers le processus d’installation de ZFS sur ZimaBoard, mais il offre également une vue d’ensemble holistique du ZimaBoard lui-même.
Des insights communautaires aux instructions d’installation détaillées, l’article de Tyrehl est votre ressource unique pour libérer tout le potentiel de ZFS et du ZimaBoard. Nos sincères remerciements à Tyrehl pour cette contribution enrichissante, qui fait le lien entre l’engagement communautaire et le savoir-faire technique. Embarquons ensemble dans ce voyage et élevons votre expérience ZimaBoard. Bonne exploration !
Introduction
Les ordinateurs monocartes (SBC) sont très populaires dans les scénarios de home lab, et ces dernières années, ils ont gagné du terrain dans les environnements professionnels et industriels également. Aujourd’hui, il existe un large écosystème centré autour de l’edge computing et des systèmes compacts.
Une puissance de calcul décente est facile à obtenir, avec divers SBC offrant 4 cœurs et beaucoup de RAM pour différentes applications. Là où ils échouent généralement, c’est au niveau du stockage. Les cartes SD et le stockage Flash en général sont généralement lents et sujets à des défaillances dans des scénarios d’écriture intensive. Les disques connectés via USB n’offrent pas la même fiabilité, et choisir un bon connecteur USB-vers-SATA n’est pas non plus trivial.
Le ZimaBoard a un atout dans sa manche. Deux ports SATA, l’Ethernet double 100/1000, et diverses options d’extension PCIe, en font un système très flexible.
Quelles sont les limites de ce qu’un SBC peut réellement accomplir, et pourquoi le stockage est-il toujours un tel casse-tête ? Où se trouve le juste milieu entre une machine compacte, qui ne maîtrise aucune tâche particulièrement bien, et un monstre de câbles avec 6 disques SATA nécessitant une alimentation ATX externe ?
Cet article vise à explorer les points forts du ZimaBoard, et comment ils peuvent être exploités afin de le mettre à bon usage. Sans finir avec une installation ridicule et peu pratique.
Motivation
Comme mentionné précédemment, beaucoup de puissance de calcul est facile à déployer et à utiliser. La mémoire est également bon marché, donc le stockage devient rapidement le facteur limitant. Toute personne ayant eu à gérer une infrastructure en est probablement consciente. Il suffit de jeter un œil aux options de stockage réseau k8s, aux différentes plateformes prétendant apporter des API compatibles S3 à votre cluster, et à quel point elles sont pénibles à déployer et à faire fonctionner correctement.
Le ZimaBoard, avec ses excellentes capacités d'E/S, est un excellent candidat pour un NAS compact ou un serveur polyvalent avec un stockage local résilient. Et voici le défi : comment fournir un stockage tolérant aux pannes dans un boîtier compact, sur une plateforme qui « fonctionne simplement » et qui est opérationnellement sans souci.
Côté matériel, nous nous limiterons à utiliser seulement deux disques de 2,5 pouces alimentés et connectés en SATA à l'arrière du ZimaBoard. Cela permet une solution très compacte sans nécessité d'une alimentation externe ni de cartes d'extension.
Moins c'est plus
Déployer beaucoup de stockage est bien, mais avoir un stockage tolérant aux pannes est encore mieux. Pour cela, nous avons besoin d'un système de fichiers plus avancé offrant une redondance de stockage.
ZFS offre des capacités RAID logicielles surpassant celles de la plupart des contrôleurs RAID matériels. C'est un système de fichiers vraiment excellent avec de nombreuses autres fonctionnalités notables comme les snapshots incrémentiels, la synchronisation entre systèmes distants et pools de stockage, ainsi que le chiffrement.
L'objectif aujourd'hui est uniquement de faire fonctionner les disques en redondance. Normalement, ZFS est utilisé pour gérer un ensemble RAIDZ. Mais comme nous nous limitons à deux disques, il ne reste qu'une option pertinente : le pool miroir ZFS. Cela réduira effectivement la capacité de stockage de moitié, mais en même temps cela nous offrira une meilleure redondance et la capacité de supporter la défaillance d'un seul disque. Ce n'est pas idéal, mais cela devra suffire.
Matériel
Disques
En général, la communauté ZimaBoard recommande d'utiliser des disques de 2,5 pouces. Leur principal avantage est qu'ils n'ont pas besoin d'une alimentation 12V pour fonctionner. Des tests réussis avec des disques de 3,5 pouces ont été rapportés, donc à vous de voir. Pour ma part, j'ai choisi deux SSD de 1 To. Vous pouvez aussi opter pour des HDD si vous avez besoin de plus de capacité.
Connecteurs et accessoires imprimés en 3D
Le Y-Splitter officiel est fortement recommandé pour connecter et alimenter les deux disques. Il existe des solutions alternatives, comme l'utilisation d'adaptateurs USB vers SATA pour l'alimentation. Ce n'est pas esthétique, mais cela fonctionne. Pour tout maintenir ensemble, un support double HDD imprimé en 3D est idéal. Le résultat final est un ensemble très portable et discret.
Des liens sont inclus à la fin de l'article. J'ai trouvé cette version très compacte et pratique grâce à sa petite taille. Il existe aussi diverses plaques imprimées en 3D pour montage en rack, si vous avez l'espace nécessaire.
Installation de ZFS
Le ZimaBoard est livré par défaut avec Debian. C'est aussi ma recommandation personnelle pour une distribution solide qui ne vous gênera pas ni ne vous surprendra. Pour d'autres distributions, consultez la documentation respective et les instructions d'installation de ZFS.
Avant de commencer, pensez à mettre à jour vers la dernière version LTS si possible. Sauvegardez vos données pour pouvoir tout démonter et recommencer facilement. Et documentez chaque étape, cela facilitera le dépannage. Consultez le script commande pour une méthode pratique de le faire.
Des instructions détaillées et des cas d'utilisation avancés sont documentés à https://wiki.debian.org/ZFS c'est la source principale recommandée pour configurer ZFS.
Prérequis
Assurez-vous que les dépôts HTTPS sont accessibles :
1 apt install -y lsb-release apt-transport-https
Ajoutez le dépôt Backports pour votre version en modifiant /etc/apt/sources.list ou en ajoutant un nouveau fichier de sources sous ‘/etc/apt/sources.list.d/’ :
1 #déterminer le nom de code ou remplacer manuellement ci-dessous :
2 codename=$(lsb_release -cs)
3 #ajouter le dépôt backports à la liste des sources :
4 echo “deb http://deb.debian.org/debian $codename-backports main contrib non-free”|sudo tee /etc/apt/sources.list.d/debian_backports.list && sudo apt update
Paquets ZFS
Enfin, selon la documentation Debian, installez les derniers en-têtes Linux et les paquets ZFS pertinents :
1 sudo apt install linux-headers-amd64;sudo apt install -t $codename-backports zfsutils-linux zfs-dkms
« Oh non – quelque chose a mal tourné »
L’échec de l’installation de ZFS est généralement dû à un noyau ancien ou incorrect, ou à des en-têtes manquants. Il est préférable de purger tous les paquets liés à ZFS, de vérifier les en-têtes installés, et de relire la documentation d’installation.
1 sudo dpkg -l | egrep ‘linux-image|linux-headers’
Création d’un pool et d’un système de fichiers
Lister les disques par ID :
1 ls -l /dev/disk/by-id/
2 ls -l /dev/disk/by-id/
3 lrwxrwxrwx 1 root root 9 22 déc. 15:29 ata-KINGSTON_SA400S37960G_50026B73818333D1 -> ../../sdb
lrwxrwxrwx 1 root root 9 22 déc. 15:29 ata-KINGSTON_SA400S37960G_50026B73818333DB -> ../../sda
4 lrwxrwxrwx 1
Et créer un pool en spécifiant les ID de périphériques stables, par exemple :
1 zpool create $mirror_pool_name mirror ata-KINGSTON_SA400S37960G_50026B73818333D1 ata-KINGSTON_SA400S37960G_50026B73818333DB
Créer un système de fichiers chiffré :
1 zfs create \
2 -o encryption=on \ # supprimer si inutile
3 -o keyformat=passphrase -o casesensitivity=mixed \
4 -o acltype=posixacl -o xattr=sa -o dnodesize=auto $mirror_pool_name/$dataset_name
Scénarios d’utilisation réels et performances
ZimaBoard ne rencontre aucun problème pour faire fonctionner ZFS, et offre de bonnes performances, seule l’encryption impacte notablement l’utilisation du CPU. Le transcodage et le streaming (par exemple avec Jellyfin) ne posent pas non plus de problème. Il est important de noter que la lecture ou l’écriture de très gros fichiers sur un système de fichiers chiffré sollicitera fortement le CPU. Cela peut affecter d’autres charges de travail en cours sur le système.
SMB/NFS
Lors des tests généraux, l’écriture d’un seul fichier de 12 Go sur le pool miroir ZFS a pris environ 5 minutes, le goulot d’étranglement étant les entrées/sorties disque. La lecture depuis le pool ZFS a été beaucoup plus rapide, prenant moins de la moitié du temps. En effet, la connexion réseau 1 Gbps a été complètement saturée. Les deux tests ont été effectués vers / depuis un système de fichiers non chiffré :
Le test suivant montre l’impact important que le chiffrement a sur le CPU. Le même fichier de 12 Go a été lu depuis le système de fichiers ZFS non chiffré, puis écrit sur un système chiffré. Les performances restent excellentes, mais l’utilisation du CPU a fortement augmenté et est restée très élevée tout au long du processus.
Ressources et références
- Installation de ZFS sur Debian : https://wiki.debian.org/ZFS#Installation
- https://www.printables.com/model/224057-zimaboard-dual-hdd-stand
- Câble Y SATA : https://shop.zimaboard.com/products/sata-y-cable-for-zimaboard-2-5-inch-hdd-3-5-inch-hdd-raid-free-nas-unraid
Conclusion
Vous avez des questions ou souhaitez des éclaircissements supplémentaires sur un aspect du tutoriel ? Tyrehl est là pour vous aider ! Rejoignez notre communauté Discord pour entrer en contact direct avec Tyrehl et participer à des discussions enrichissantes. Votre curiosité ne doit pas s’arrêter au tutoriel – Tyrehl est prêt à vous accompagner dans votre aventure ZFS. Rejoignez notre serveur Discord : [ zimaboard.com/discord]
