Le Raspberry Pi est souvent vu comme une petite machine à tout faire, ou presque : micro PC de bureau, petit serveur, solution multimédia et même NAS. Mais dans la pratique, ce n'est jamais aussi simple. Surtout si l'on veut un minimum de performances. La version 4 Model B change la donne, on a donc tenté notre chance.
Il est courant de voir des utilisateurs miser sur des cartes mères à petit prix pour fabriquer un NAS maison. Il y a même des OS spécialisés, open source (FreeNAS, OpenMediaVault, etc.) ou chez des constructeurs.
Mais cet acronyme signifie Network Attached Storage, soit « stockage lié au réseau », il n'y a donc pas de la débauche de fonctionnalités proposées par des fabricants comme Asustor, QNAP ou Synology pour trouver son bonheur. En effet, on a parfois simplement besoin de disposer de données centralisées sur le réseau local... avec un budget limité.
On peut donc se tourner vers du matériel qui ne dispose pas d'une puissance énorme, avec des protocoles simples et largement supportés tels que Samba/CIFS. Nombreux sont ceux qui ont opté pour un Raspberry Pi dans ce but, la machine approchant du compromis recherché.
Mais tant le SoC que le système Raspbian ou la connectique disponible jusqu'à lors pouvaient limiter les performances de cette expérience, notamment au niveau du port réseau. Avec le Raspberry Pi 4, vient une offre plus performante, mais surtout le support de nombreuses distributions avec un choix plus large.
La connectique suit la même tendance, avec un véritable port réseau à 1 Gb/s et de l'USB 3.0 annoncé à un débit théorique maximal de 4 Gb/s (partagé avec l'USB 2.0). Nous avons donc décidé de profiter de ces améliorations pour tenter l'expérience d'un NAS basé sur cette machine avec un périphérique de stockage USB.
Branchement et installation de la machine
Nous avons utilisé notre Raspberry Pi 4 de 4 Go avec un dissipateur Armor Case de Geekworm, acheté une vingtaine d'euros. De quoi nous assurer de rester à une température raisonnable même si le SoC est sollicité de manière continue, sans perte de performances (nous y reviendrons).
Une version à deux ventilateurs est également proposée pour ceux qui préfèrent un refroidissement actif. Elle est vendue pour quelques euros de plus et permet de gagner de précieux degrés, parfois utiles.
Côté SSD, pour ce test nous avons utilisé MX500 de Crucial de 500 Go, vendu pour un peu moins de 70 euros. Vous pouvez bien entendu opter pour un modèle plus gros ou un HDD afin de recycler le disque d'un ancien ordinateur portable et disposer de plus d'espace. C'est à vous de voir.
Stockage USB : ne cherchez pas le record de vitesse
Mais le Raspberry Pi 4 n'a toujours pas de port S-ATA natif. Nous avons donc opté pour un boîtier USB externe. Il en existe de différentes formes : classique, clé USB plus ou moins longue, modules externes. Ne payez pas le prix fort pour un produit USB 3.x à 10 Gb/s, vous serez de toute façon limités par les 125 Mo/s du port réseau.
Il faut au moins de l'USB 3.0 à 5 Gb/s pour disposer de plus des 480 Mb/s de l'USB 2.0. Pour notre test du jour, nous avons opté pour un modèle UGreen avec gestion de l'UASP vendu 16 euros. S'il s'agit d'un boîtier USB 3.1 à 10 Gb/s, c'est seulement pour nous assurer qu'il n'est pas une source de limitation des performances lors de nos tests de débits.
Vous pouvez également opter pour des boîtiers avec gestion du RAID, 0 ou 1 via des switchs. Le premier permet, en théorie, de multiplier les performances par deux en accédants aux deux SSD de manière simultanée (ce qui ne sera pas très utile ici). Le second de préserver les données en disposant constamment d'une copie de celles-ci.
Ces produits ont l'avantage de ne pas avoir à gérer le RAID côté logiciel et donc de ne pas dépendre de la configuration de l'OS. Attention tout de même, si on en trouve dès 30/40 euros, les performances ne sont pas toujours au rendez-vous, surtout avec des SSD et/ou en écriture.
L'alimentation de l'ensemble est assurée, sans complément, par un splitter PoE relié au switch Netgear MS510TXPP. Mais là aussi, vous pouvez simplement opter pour une alimentation USB Type-C officielle par simplicité.
Quel distribution Linux et quel système de fichier ?
Dans un premier temps, nous avions décidé de proposer ce tutoriel sous Manjaro Linux, qui dispose d'une installation simple et du support du Raspberry Pi 4 Model B de 4 Go, dans sa version 64 bits. Mais lors de nos tests de débits, nous avons constaté un manque de stabilité des performances.
Nous nous sommes donc retournés vers Ubuntu 19.10 qui dispose d'un noyau récent, d'un support assez large et de bonnes performances globales. Seul hic : nous avons dû nous limiter à la version 32 bits et donc à 3,7 Go de mémoire, ce qui n'est pas un problème pour l'usage visé. Vous pouvez même rester sur un NAS avec 1 Go si vous ne voulez pas l'utiliser pour d'autres tâches ou seulement certaines peu gourmandes en mémoire.
Une fois l'OS transféré sur la carte microSD, les différents éléments branchés et la machine démarrée, nous nous y connectons via SSH avec le compte utilisateur :
ssh utilisateur@ip_de_la_machine
Soit dans notre cas :
ssh [email protected]
Pour la première étape, on commence par une mise à jour du système :
sudo apt update && sudo apt full-upgrade && sudo apt autoremove
Autre choix qui a son importance : le système de fichiers du stockage USB. En effet, nous avions dans un premier temps tenté d'utiliser NTFS afin de disposer de pouvoir utiliser le boîtier sur le Raspberry Pi mais aussi le connecter à une machine Windows si nécessaire, mais là encore les performances étaient trop limitées : de 60 à 80 Mo/s.
Nous avons donc misé sur ext4, natif à Linux, mais vous pouvez vous tourner vers un autre choix comme btrfs si vous le préférez, ou si vous cherchez à disposer de certaines fonctionnalités avancées.
Comment formater un HDD/SSD existant sous Linux ?
Il faut donc commencer par formater votre espace de stockage. Pour cela, identifiez son nom au sein du système avec la commande lsblk, qui donne chez nous le résultat suivant :
ubuntu@ubuntu:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 76M 1 loop /snap/core/7919
loop1 7:1 0 47.1M 1 loop /snap/lxd/12207
loop2 7:2 0 47M 1 loop /snap/lxd/12227
sda 8:0 0 465.8G 0 disk
mmcblk0 179:0 0 59.5G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /boot/firmware
└─mmcblk0p2 179:2 0 59.2G 0 part /
Le SSD connecté en USB est reconnu comme sda, il est donc accessible via le chemin /dev/sda/. Nous utilisons cette référence pour l'ouvrir avec l'outil de formatage fdisk et les droits super utilisateur (sudo) :
sudo fdisk /dev/sda
Ici, il faut entrer des commandes sous forme de lettre pour supprimer la ou les partitions existantes (d), en créer une nouvelle (n) primaire (p) en gardant les paramètres par défaut (Entrée). Il faut ensuite écrire le résultat (w), ce qui aura pour effet de quitter l'application.
La commande lsblk devrait cette fois afficher une partition sda1. Nous mettons maintenant en place le système de fichiers ext4 sur la partition créée :
sudo mkfs.ext4 /dev/sda1
Création du serveur Samba
Il faut ensuite installer le serveur Samba qui nous servira à disposer d'un partage réseau accessible depuis différents systèmes d'exploitation (Linux, macOS, Windows, etc.) :
sudo apt install -y samba
sudo reboot
Cette commande a l'avantage d'installer le serveur et toutes ses dépendances en une seule ligne de commande. Acceptez les différentes étapes qui vous seront proposées. On redémarre ensuite le système avant de continuer pour que tous les éléments soient en place, notamment du côté des comptes utilisateur.
Vous disposez désormais d'un NAS avec un serveur Samba actif !
Ajout d'un utilisateur et création du répertoire partagé
Il nous faut maintenant configurer un partage sur le serveur Samba et permettre à un utilisateur d'y accéder. Pour cela, nous allons commencer par ajouter un compte dans ceux reconnus par le serveur.
Vous pouvez ajouter l'utilisateur courant, ou un autre créé spécialement pour l'occasion. Nous optons pour ce second choix, avec les commandes suivantes :
sudo useradd david
sudo passwd david
sudo smbpasswd -a david
sudo usermod -a -G sambashare david
Cela crée l'utilisateur david, membre du groupe sambashare, configure son mot de passe et l'ajoute à la liste de ceux reconnus par le serveur Samba avec un mot de passe spécifique.
Ensuite, on créé le point de montage :
sudo mkdir -p /data/usbshare
Configuration du serveur Samba
Maintenant que le point de montage et l'utilisateur existent, il faut ouvrir l'accès depuis le réseau local. Pour cela, il faut modifier le fichier de configuration de Samba :
sudo nano /etc/samba/smb.conf
On y ajoute les lignes suivantes à la fin :
[USBShare]
comment = Partage USB du Raspberry Pi
path = /data/usbshare
valid user = david
directory mask = 750
create mask = 750
browsable = yes
writable = yes
guest ok = no
L'ensemble de ces paramètres est assez clair. Précisons tout de même le rôle des masques, utilisés pour les nouveaux répertoires (directory) et fichiers (create). La valeur 750 donne tous les accès à l'utilisateur (david), les membres du groupe (sambashare) peuvent seulement lire les données, alors que les comptes tiers n'ont aucun droit.
Vous pouvez également modifier des paramètres dans la section [Global] :
client min protocol = SMB2
client max protocol = SMB3
Cela permet de désactiver Samba v1 et les failles associées depuis les clients Windows.
Monter le périphérique USB à chaque démarrage de la machine
Maintenant que nous disposons d'un point de montage, il faut l'utiliser. Pour cela nous devons commencer par récupérer l'identifiant (UUID) de la partition créée sur l'espace de stockage USB :
sudo blkid
Qui donne dans notre cas une ligne commençant par :
/dev/sda1: LABEL="USBShare" UUID="aa9fc7b1-a518-4e08-93c4-1d2632dbdbed" TYPE="ext4"
On l'utilise ensuite pour activer l'accès au périphérique USB au démarrage de la machine, en l'ajoutant au fichier de configuration des points de montage :
sudo nano /etc/fstab
On y ajoute la ligne suivante :
UUID=aa9fc7b1-a518-4e08-93c4-1d2632dbdbed /data/usbshare ext4 defaults,noatime 0 0
On enregistre et on ferme le fichier (CTRL+X) puis on redémarre la machine :
sudo reboot
Si vous avez entré tous les bons paramètres, le partage réseau sera accessible dès que la machine aura démarré. Bien entendu, veillez à la mettre à jour régulièrement pour limiter les risques de failles de sécurité.
On s'arrange ensuite pour que le stockage soit accessible :
sudo chmod 777 -R /data/usbshare/
sudo chown -R david:sambashare /data/usbshare/
On rend pour cela le compte david et le groupe sambashare propriétaires, tout en permettant à n'importe qui de pouvoir y accéder : 777 donne l'ensemble des accès à l'utilisateur, son groupe et aux tiers. La raison est simple : au démarrage de la machine, il sera monté par le compte administrateur (root), il faut donc que ceux qui ne sont pas reconnus comme tels puissent y accéder.
Accéder au NAS depuis une machine tierce
Vous devriez alors accéder au partage réseau depuis d'autres machines. Sous Windows, vous pouvez ainsi attribuer une lettre à votre partage avec la ligne de commande suivante (dans notre cas) :
net use j: \\192.168.1.41\USBShare
ou
net use j: \\ubuntu\USBShare
Les identifiants de l'utilisateur vous seront demandés. Parfois sous Windows (lorsque vous utilisez un compte Microsoft pour vous connecter par exemple) il ne faut pas indiquer seulement le nom de ce dernier, mais aussi l'IP ou le nom de la machine à laquelle il est lié (\192.168.1.41\david ou \ubuntu\david plutôt que simplement david par exemple).
Pour rappel, ubuntu est ici le nom de la machine sur le réseau (hostname) configuré lors de l'installation. On peut donc l'utiliser plutôt que l'IP. Pour en changer, tapez :
hostname nom_désiré
sudo reboot
Avec notre configuration, nous obtenons des performances entre 100 et 115 Mo/s tant en lecture qu'en écriture sur l'espace de stockage distant, de manière assez stable. Cela correspond aux limites pratiques d'un port réseau à 1 Gb/s. La machine est donc fonctionnelle, vous pouvez l'oublier et l'utiliser.
Dans l'idéal, il faudrait maintenant placer le Raspberry Pi 4 et son SSD externe dans un boîtier, fabriqué maison ou non. Un point qui sera l'objet d'un prochain article.
Commentaires (33)
#1
Pas mal, je vais regarder car je suis en train de tenter de monter un serveur Plex sur un 3 B+ (j’ai peur des perfs !).
Est-ce qu’il existe des boîtiers rail din pour le Pi 4 ?
Au lieu de Ubuntu, peut-on utiliser Ubuntu Core IoT ?
#2
Moi j’ai fait ça avec un Raspberry Pi 3B+ et openmediavault. Bien plus facile à mettre en place. Ah oui, surtout: le disque utilisé est un Seagate pour portables de 2 To. C’est un disque “basse consommation” qui passe tout seul comme un grand sur le port USB du Raspberry, pas besoin d’alim externe.
#3
C’est ce que j’avais fait à une époque avec un RPi2 et raspbian.
On peut aussi installer Deluge torrent en tant que client torrent. Je trouve que pour faire un NAS, c’est un bon client :
Et des fonctionnalité plus classique :
et plein d’autre plugins.
#4
J’ai une petite question pour ceux qui l’on mis en place : est-ce que la mise en veille des disque est gérée ou est-ce que les disques restent allumés en permanence ? Merci !
#5
Ah super ça
Je garde au chaud pour quand j’aurais le temps
#6
Pas directement.
Mais c’est possible via hdparm.
Éventuellement hd-idle ou sdparm aussi (si hdparm ne reconnait pas le controlleur usb/sata utilisé).
Il vaut donc mieux éviter les contrôleurs exotiques ^^
#7
J’avais aussi trouvé cette vidéo très intéressante pour avoir une idée des performances du Raspberry Pi 4 avec plusieurs disques (et un hub USB3 alimenté) : https://youtu.be/O-FfOWdZAQ4
#8
Merci !
#9
Aucune idée pour les boôtiers sur rail, mais ça doit exister vu que les modifications côté boîtier sont assez minimes (seulement sur les sorties des E/S). Pour IoT Core je ne sais pas, j’utilise l’image Server de la 19.10
De mémoire OMV n’a pas encore été complètement porté pour le RPi 4 (enfin je crois qu’ils ont sorti une version bêta en juillet sans rien de nouveau depuis). Après je suis toujours partisan de faire les choses soi même au moins une fois avant d’utiliser du clé en main au quotidien, ne serait-ce que pour comprendre comment ça marche
#10
Très bon tuto, est ce que tu relèves une différence notable de perfs par rapport à l’image OMV ? (qui permet d’avoir dès le depart la fonction NAS de base + des utilisateurs + du raid + du formatage + sauvegarde + montages), outre plex, docker, downloader etc…)
Et accessoirement est ce qu on peut installer OMV sur cette distrib ubuntu x64 ?
Merci :)
#11
https://www.framboise314.fr/?s=rail+din et plus précisément pour la 4 : https://www.framboise314.fr/deux-boitiers-industriels-pour-le-raspberry-pi-chez-phoenix-contact/
Pour OMV, il y est écrit dans le guide d’utilisation qu’il est fortement déconseiller de faire du raid en usb.
Je dirai que oui : https://openmediavault.readthedocs.io/en/latest/installation/on_debian.html
Je suis en plein dedans. J’ai installé hier soir OMV (que je ne connais pas) sur Rpi4.
Je n’ai pas réussi à chiffrer le disque avec le plugin.
Il existe un plugin qui préserve la flash du genre log2ram, ça c’est cool.
Et le disque est monté, il apparaît dans le fstab mais pas dans /media ou /mnt. Pas tout compris.
En tout cas, si OMV ne me plait pas, j’utiliserai ce tuto avec en plus une config sécurisation iptable, ssh et pi-hole dockerisé (il faut que j’apprenne docker) + unbound.
#12
Cool, a tester donc.
Pour ton dd principal (celui qui va accueillir l’OS et OMV) c’est normal. OMV le considère comme un disque dédié à ses données et pluguins.
Si tu veux utiliser une partie de ton disque comme espace de stockage, dans FSTAB monte le répertoire voulu commun un disque dur, il sera alors dans média et montage. (C’est le seul choix discutable que fait OMV je trouve, pour le reste j’ai lâché yunohost & co pour OMV, même mes serveurs nginx et mariadb sont gérés par lui, car la simplicité des backups (un pluguin pour OMV & ses pluguins, un pluguin pour les datas) fait vraiment la différence).
#13
Désolé, je ne peux pas enregistrer les modifs de mon commentaire, donc en bon français ça donne:
Pour ton dd principal (celui qui va accueillir l’OS et OMV) c’est normal. OMV considère la partition où il est installé comme une partition dédiée à ses données et pluguins. (C’est le seul choix discutable que fait OMV je trouve)
Si tu veux utiliser ton disque comme espace de stockage, dans FSTAB montes le répertoire voulu comme un disque dur, il sera alors dans média et montage. (J’ai lâché yunohost & co pour OMV, même mes serveurs nginx et mariadb sont gérés par lui, car la simplicité des backups (un pluguin pour OMV & ses pluguins, un pluguin pour les datas) fait vraiment la différence et bien souvent ses pluguins sont plus récents que ceux proposés par yunohost).
#14
Et comme certains cherchent des solutions pour encastrer tout ça proprement, perso j’utilise ça:
https://www.amazon.fr/Disque-Fixation-Pilote-Ventilateur-lespace/dp/B07H9B7NG1
Outre les DD, on peut même y caler le Pi en bricolant un adaptateur pour DD 2.5 -> 3.5.
Bref pour 20€ + 10€ on a un cadre propre pour tout mettre et on peut monter facilement un gros ventilo pour éviter le bruit :)
#15
@crocrodule : Dans mon cas, j’ai mis directement l’image d’OMV sur la sd (me parait bien plus léger que le couple OS + OMV) et j’ai monté le disque dur + filesystem à partir de l’interface. Donc je pense que le système sait que le dd ne sert que pour le data.
Pour l’instant c’est le seul point noir mais je vais approfondir et si cela ne me plait pas, je le fais à la main comme sur le tuto et voir le comportement d’OMV dans ce cas.
#16
Dans mon cas, c’est dans une boite à guimauve nounours : 2 DD 2”5 + Rpi4 + au sommet 2*ventilateurs 8cm. Je vais mettre l’alim chinoise 240/5V 5A à l’extérieur.
Il existe la commande raspimon (en fait c’est un script dans github) pour monitorer chaleur/fréquence et tension. Comme celui de David.
Hier en simple copie avec le couvercle ouvert c’est monté à 65° ( cpu + mémoire avec radiateur de récup retaillé pour). Je précise, ventilateurs off
#17
Tu n’es pas le seul, j’ai planqué mon installation dans mon ancien grille pain qui a claqué (si j’ai le courage un jour je couple l’allumage avec la tige du grille pain ^^ ):
https://images-na.ssl-images-amazon.com/images/I/61ba+kP0T6L._AC._SR360,460.jpg
#18
En fait, derrière ma question, je voulais savoir si tout ce que tu utilises dans le tuto est possible qu’avec Snap vu que Ubuntu Core IoT n’autorise que l’installation via Snapd.
#19
A mon avis ça reste une mauvaise idée de faire un NAS avec un Raspberry Pi. Le fait qu’il n’y a pas de contrôleur SATA est un indice. Le stockage sur USB c’est quand même assez risqué.
J’allais faire un commentaire sur les performances de transfert mais vous avez réussi à monter à un niveau correct, chapeau.
#20
Tu prêches un convaincu, après pour du petit usage ou de l’appoint, ça peut être une solution. Puis ce genre de tuto a de toutes façons des visées plur large, on y reviendra ;)
#21
Sur le mien (rpi2) le disque ce met en veille mais c’est un disque 3.5” dans un boitier externe avec alimentation électrique.
#22
Tout va dépendre de ce que l’on souhaite: répondre à un usage perso/familial ou avoir des perfs.
Mais à prix égal je vois rien, sauf à passer par l’occas. (ce que j’ai fait pour avoir de bonnes perfs sur mon cloud pro notamment en édition collaborative, avec un hp proliant gen8 trouvé pour 120€, mais bon neuf l’équivalent c’est le triple d’un pi minimum).
#23
Vu les problèmes de surchauffe du raspberry pi 4, il se pourrait même que ton grille pain retrouve sa fonction d’origine :)
#24
Intéressant, je m’étais déjà posé la question car j’ai actuellement un D-Link d’entrée de gamme qui ne sert pratiquement plus qu’à travers le Pi (Plex, Transmission…) et ça fait du coup une grosse installation pour pas grand chose avec les 2 ethernet, les 2 alims les 2 boîtiers, les deux OS… Et ça reste plus abordable qu’un NAS.
Mais j’aimerais bien que l’ensemble sois fanless pour n’avoir que le bruit du disque, je surveille donc pour une prochaine révision !
#25
Pour une machine avec SATA, il y a ODROID-HC1: https://www.hardkernel.com/shop/odroid-hc1-home-cloud-one/
En terme d’OS, la carte est supportée par le projet ARMBIAN, donc un support logiciel durable: https://www.armbian.com/odroid-hc1
Armbian permet entre autre d’installer OpenMediaVault, nextcloud, ….
#26
Autre point important: A la différence du raspberryPi, l’ODROID est open hardware; les schémas de la carte sont dispo !
D’autres concurrents sont également en open hardware, par exemple olimex.
#27
Exemple de carte ARM OSH avec port sata, et supporté par ARMbian (https://www.armbian.com ):
https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2/open-source-hardware
#28
Intéressant en effet, je vais regarder pour voir si c’est pas trop exotique pour les distrib habituelles et probablement me laisser tenter car je pense faire l’impasse sur cette génération de Pi4. Merci :)
#29
T’as bien regardé les détails de l’article ou la photo ici ?
https://www.inpact-hardware.com/article/1343/peut-on-utiliser-splitter-poe-usb-type-c-pour-alimenter-raspberry-pi-4
#30
Si vous cherchez un port SATA pour les Pi, il existe ça chez Subtronics : http://www.suptronics.com/miniPCkits/x825.html (version Pi4)
#31
Ce qui revient à une connectique USB 3.x comme on l’utilise ici ;)
#32
bah perso je vois pas vraiment de souci, à part si c’est le seul backup.
là ça me donne envie de resortir mon vieux pc que j’avais bricolé en nas mais que je laisse pas allumé vu sa conso.
là on peut faire un système avec le pi toujours allumé, mais qui fait un wake on lan sur un vieil ordi de récup pour faire un rsync toutes les nuits <= on a la praticité du nas, un le backup d’un système un poil plus fiable que l’usb …
#33
Ça dépend franchement de ton usage.
Perso j’ai pas de gros besoins :
Je pars sur un RPI4B + un seul disque usb, on verra ce que ça donne, je m’en suis pas trop occupé pour le moment. Je me fiche complètement des performances de transfert puisque ce sera suffisant pour de la synchro et du streaming.
Pour la partie backup, mes données importantes sont celles qui sont synchronisées, donc qui sont d’une déjà sur plusieurs PCs, en plus de ça, j’ai l’intention d’ajouter un archivage automatique sur Backblaze si j’y arrive (mais pas de client linux/arm :/ ) ou une archive chiffrée sur B2 ou AWS.
Bref, je suis clairement dans le cas où un NAS “plug&play” est trop cher et où le RPI4 peut faire un bon petit job de “cloud maison” à pas cher.
Après c’est pas pour l’investissement que ça représente que le risque est grand. Plus tard j’adorerai récupérer un serveur d’occase ou monter une machine “de guerre” pour faire tourner un hyperviseur capable de faire du streaming steam ou nvidia mais bon, ça pose des problématiques de conso, de temps, de compétences (mais ya les supers articles de David ❤) et … de thunes hein