Vouloir s’auto-héberger peut paraître un peu à contre courant des modes actuelles. En effet, une écrasante majorité des personnes utilise massivement les plateformes cloud des grandes entreprises de l’internet. Pour les quelques autres qui souhaitent disposer de leur propre cloud personnel, les plupart se tournent vers des serveurs dédiés ou mutualisés chez de grands fournisseurs. Cet article n’a pas pour objet de discuter du pourquoi il faudrait héberger (ou louer) son cloud perso (de très bons articles en parlent déjà) mais de donner un exemple de comment auto-héberger son cloud perso. La solution logicielle qui sera utilisée est Nextcloud.
Le but sera ici d’utiliser comme base un matériel le plus économe possible en électricité, nous permettant de laisser tourner la solution 24h/24h en ayant la prétention d’affirmer que la solution équivalente dans un datacentre consommerait probablement plus d’énergie.
Attaquons sans plus attendre dans le vif du sujet avec la première étape de ce dossier, traitant du matériel utilisé et de l’installation du système d’exploitation.
Navigation
Base matérielle pour auto-héberger son cloud perso
Ici, le but n’est pas d’avoir une machine ultra puissante capable de servir des milliers de pages web à la minute. Nous montons un petit cloud perso, pour servir les besoins de la famille. Disons 4 à 6 personnes maximum.
Nous souhaitons également que notre machine consomme le moins possible : en effet, elle va tourner 24h/24h. Il faut donc que la facture énergétique soit la plus basse possible. Pour que ça coûte moins cher d’une part, mais aussi pour diminuer l’impact environnemental. On ajoutera que moins ça consomme, moins ça chauffe à priori : la machine n’aura pas besoin de refroidissement actif, et sera donc totalement silencieuse.
Pour cet exemple, mon choix s’est porté sur la solution odroid-HC1 de la société hardkernel, qui est quasiment la même plateforme que celle utilisée par mon NAS de sauvegarde locale (odroid-HC2), mais avec un boîtier adapté aux disques durs de 2,5 pouces, et une alimentation 5V au lieu de 12V. Curieusement hardkernel annonce la fin de vie de cette plateforme au moment d’écrire ces lignes, alors que ce n’est pas le cas de l’odroid-HC2. Cependant, des enseignes comme kubii en ont encore en stock.
Cette plateforme propose un SOC octo-core, le Samsung Exynos5422, un pont USB3/SATA3 pour avoir des débits de disque corrects, une interface gigabit branchée également derrière le contrôleur USB3, ainsi que 2Go de RAM.
Nous utiliserons une carte micro SD de 16Go pour installer l’OS (mais 4Go suffiraient largement). Nous ajouterons également un disque dur SSD 2,5 pouces d’entrée de gamme, de 240Go de capacité.
Je suis convaincu que cette solution consommera au global moins d’électricité que le service équivalent dans un datacentre (pas besoin de refroidissement par exemple). En effet, l’alimentation recommandée pour ce montage propose une puissance de 20W, mais on peut raisonnablement s’attendre à consommer bien moins au quotidien, même à pleine charge. Le disque dur a une consommation maximum de 2,8W (avec une moyenne à 80 mW selon le constructeur), le SOC quant à lui est dans les 15W au maximum. J’espère cependant être sous les 10W en consommation totale, même en charge, et même bien moins en moyenne (nous le vérifierons plus tard).
Bien sûr il existe de nombreuses plateformes alternatives pour réaliser un montage capable d’héberger un petit cloud perso à bas coût et à faible consommation, comme par exemple un raspberry pi avec un disque dur externe USB3, entre autres. Avec son modèle 4, le raspberry pi propose une plateforme bien plus puissante et plus récente (et 64 bits) que la maquette utilisée ici par ailleurs. C’est aussi ça qui est stimulant, le choix et la variété des solutions matérielles.
Installation et configuration du système d’exploitation
Nous allons utiliser ici Armbian comme système d’exploitation, dans sa version Armbian Buster (basée sur Debian Buster) : le projet supporte officiellement notre plateforme matérielle. C’est une version 32 bits de l’OS, pour coller à l’architecture de notre processeur.
Installation du système d’exploitation
L’installation de base de l’OS se fait en flashant la carte micro SD avec l’image du système Armbian Buster à l’aide du logiciel Balena Etcher.
Et paf, l’OS est installé…
A premier démarrage il y a quand même 2-3 bricoles à faire comme changer le mot de passe root (qui est 1234 à l’origine), choisir le shell par défaut (on va mettre bash) et créer un utilisateur sudoer, tout ça en suivant l’assistant qui se lance automatiquement à la première connexion.. C’est du vite fait. Notons que la machine n’a pas de sortie vidéo, tout se fera par ssh, il faudra donc surveiller l’activité du serveur DHCP ou utiliser un scanner de réseau pour déterminer l’adresse qu’aura obtenu le système.
Configuration du système d’exploitation
On va réaliser quelques tâches de personnalisation du système, pour l’adapter au contexte matériel.
Partitionnement du disque SSD
Tout d’abord je vais partitionner le SSD, pour créer deux partitions. La première de 2Go, sera dédiée à une zone de SWAP.
En effet, nous allons quand même configurer une zone de SWAP, car notre machine n’a que 2Go de RAM, ce qui est peu même pour un tout petit cloud perso. On dispose d’un disque dur dans le montage, donc on ne va pas se priver et on va swapper dedans. Personnellement je n’ai guère de scrupules à swapper sur un SSD, même si il paraîtrait que c’est déconseillé :). Je pense qu’avec un SSD de bonne qualité (niveau puces mémoire et contrôleur), et de taille importante, on a une surface d’écriture suffisamment importante pour durer longtemps même en swappant dessus (je connais des baies de stockage full flash qui sont en bien meilleur état après 5 ans d’écritures intenses que leurs équivalentes garnies de disques mécaniques qui se mettent à tomber en panne les uns après les autres dès la 4e année…). Et en plus ça swappera vite, donc les performances seront probablement correctes.
La deuxième partition occupera tout le reste du disque, et contiendra la racine finale du système.
Procédons ainsi à la création d’une nouvelle table de partitions sur le disque dur (ça va détruire tout ce qu’il y a éventuellement dedans) avec fdisk:
fdisk /dev/sda
« o » pour créer une nouvelle table de partitions:
Puis on créé la première partition, de 2Go que nous allons dédier au SWAP.
Création d’une nouvelle partition avec « n« , primaire avec « p« , numérotée « 1« , puis on choisit l’option par défaut pour le premier secteur de la partition. Pour la fin de la partition on indique « +2G« .
Enfin on appelle « t » pour saisir le type de partition : ça sera « 82 » pour indiquer une partition de SWAP.
Toujours avec fdisk, on créé la deuxième partition, immédiatement après le SWAP.
Comme précédemment, « n » pour une nouvelle partition, « p » pour primaire, « 2 » pour indiquer son numéro. Puis on choisit les options par défaut pour le début et la fin de la partition, ainsi elle couvrira tout le reste du disque; en gros 221Go ce qui sera peu, mais largement suffisant pour l’exemple. On enregistre et on quitte avec « w« .
Ce n’est pas la peine de créer le système de fichiers sur la partition /dev/sda2, il sera créé automatiquement après.
Migration du système vers le disque SSD
Elle se fait assez facilement avec l’excellent outil armbian-config, qui présente un assistant sous forme de menu.
Depuis le menu System, choisir le menu « Install » puis le sous-menu « Boot from SD – system on SATA, USB or NVMe« , et choisir la partition /dev/sda2 pour recevoir la racine du système. On choisira ext4 comme système de fichiers pour formater /dev/sda2.
Une fois l’opération terminée, il faut redémarrer le système. La racine du système a été déplacée sur le disque dur, mais la carte micro SD reste néanmoins nécessaire, car elle contient encore le matériel de boot; en effet, ce petit ordinateur odroid-HC1 ne sait pas démarrer sur autre chose que la carte micro SD.
Configuration de base
La suite se passe également avec l’outil armbian-config. Les quelques réglages que j’ai fait sont les suivants:
- Menu System
- CPU : réglé pour utiliser la gamme de fréquences CPU entre 600MHz et 2000MHz, et le governor positionné à « ondemand ».
- DTB : positionné à « hc1 », pour charger les optimisations correspondant à la carte HC1 utilisée ici (nécessite un reboot).
- Menu Personal
- Timezone : positionnée à « Europe/Paris ».
- Locales : en plus de en_US.UTF-8 déjà coché, j’ai ajouté fr_FR.UTF-8 (utilisé en défaut)
- Hostname : comme c’est une toute petite machine, qui va faire tourner un cloud perso, j’ai choisi de l’appeler « minicloud ».
Modification du SWAP
Le système Armbian est configuré pour ne pas swapper de manière classique sur un volume type « block », car bien souvent on l’installe sur des cartes flash, comme les micro SD. Hors ces cartes ont une quantité d’écritures autorisées très limitées, et ne disposent pas d’un contrôleur répartissant uniformément les écritures sur toute la surface mémoire (au contraire des SSD). Il faut donc éviter de configurer une zone de SWAP sur ces cartes.
C’est ce que fait Armbian. Ce système utilise en remplacement un système de SWAP directement dans la RAM, dans une zone compressée qui lui est dédiée. C’est très bien, mais dans notre cas nous allons nous en passer. On va donc mettre en œuvre la partition de SWAP créée tout à l’heure comme ceci:
mkswap /dev/sda1 swapon /dev/sda1
On rend cette configuration persistante en rajoutant la ligne adéquate dans le fichier /etc/fstab, et on en profite pour commenter la ligne configurant le tmpfs pour ne pas monter /tmp dans un ramdisk.
Il reste à désactiver le SWAP en zRAM en éditant le fichier /etc/default/armbian-zram-config, et en passant à « false » le paramètre « SWAP« . Mais on ne va pas s’arrêter là, on va carrément désactiver tout le service de zram, pour s’assurer que le système armbian ne monte pas /tmp dans un ramdisk compressé, en passant à « false » le paramètre « ENABLED« .
On va aussi basculer /var/log qui est aussi dans un ramdisk, pour écrire les logs sur le SSD directement: ça se passe dans le fichier /etc/default/armbian-ramlog.
Et on redémarre la machine.
Voilà, on a fait quelques customisations de base pour économiser un peu de RAM dans ce système, car le disque dur SSD nous le permet. On en a profité pour préparer le stockage qui va héberger l’application de notre cloud perso, la base de données associée, ainsi que nos données à proprement parler.
Configuration réseau
On va laisser le système en client DHCP pour que notre box lui attribue une adresse, qu’on lui réservera. C’est toujours rassurant avec un système sans sortie vidéo, même si on pourrait extraire la carte SD ou le SSD pour modifier la configuration sur un autre ordinateur
Synchronisation de l’heure
Elle est assurée par le démon chronyd. On va juste s’assurer que la machine est bien à l’heure, et qu’elle arrive bien à se synchroniser avec le serveur de temps configuré par défaut (2.debian.pool.ntp.org).
systemctl stop chronyd ; chronyd -q ; systemctl start chronyd date
Si la date est bonne, on est bon.
Les briques de base, matériel et système d’exploitation sont prêts. La suite se passe à la page suivante, exposant l’installation et la configuration du serveur web et de la base de données.