Proxmox v6 : Création d’un pool de stockage ZFS en RAID-Z

Explications sur l’installation de l’hyperviseur Proxmox en version 6 avec création d’un pool de stockage ZFS en
RAID-Z.

Un peu plus de deux ans se sont écoulés depuis mon tout premier article sur Proxmox (ici pour les plus curieux). A l’époque je ne l’avais présenté que de manière assez brève avec sa mise en cluster, et depuis la version 6 est sortie avec son lot de nouveautés, donc je me suis dit qu’une petite mise à jour pourrait être sympathique !

Je ne vais pas re-détailler ici l’installation qui est des plus classiques, je vais directement vous détailler le lab que nous allons réaliser :

• Un hyperviseur Proxmox en version 6.1 ;
• 1x disque de 50Go* pour l’OS ;
• 3x disque de 100Go pour le pool ZFS en RAID-Z ;
• IP fixe en 192.168.1.100/24 ;
• 16Go de mémoire de vive ;
• 4 processeurs virtuels ;

*50Go pour l’OS peut être un peu juste, si vous ne faites pas un lab prévoyez environ 128Go histoire d’être assez large pour les futures mises à jour.

Ici ce qui nous importe est bien entendu les trois disques dur virtuels de 100Go chacun, que nous utiliserons pour créer un pool de stockage ZFS, qui servira au stockage des machines virtuelles et conteneurs. Je ne vais pas directement en parler ici, je vous laisse démarrer votre installation en premier lieu, en prenant soin de simplement bien choisir le disque de 50Go pour l’installation du système 😉

I) Proxmox en version 6.1, y’a moins bien mais c’est plus cher

Rien de nouveau sous le soleil, à part quelques updates bien symptoches (kernel en version 5.0 avec tout ce que ça inclut, basé sur Debian 10 désormais, update au niveau de Ceph, LXC…) ou encore la migration à chaud de VMs même via du stockage local, qui avait été annoncée depuis un sacré bout de temps ! Bon, il faut dire que je suis un poil en retard donc je ne vais pas vous détailler toutes les nouveautés de cette v6, qui est sortie il y a déjà quelques mois quand même.

II) Configurations supplémentaires

Bien, nous avons donc notre Proxmox fraîchement installé. Nous allons tout d’abord voir comment retirer le message d’annonce qui peut vite être embêtant surtout si nous ne planifions pas d’utiliser le support payant.

Pour le retirer, il suffit donc d’éditer le fichier javascript correspondant via une simple ligne de commande :

sed -i.bak "s/data.status !== 'Active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

On vide le cache de son navigateur (important), et le tour est joué ! Bien penser à refaire cette commande lors de diverses mises à jour cependant, ou la rajouter dans une tâche cron.

Vient ensuite la gestion des dépôts, où il convient simplement de retirer le dépôt correspondant aux mises à jour pour les personnes ayant un abonnement payant chez Proxmox. Vous pouvez le laisser, mais le mieux est de le retirer pour éviter d’obtenir à chaque update un warning ou une erreur.

On supprime donc le fichier contenant la liste des dépôts payants :

rm -f /etc/apt/sources.list.d/pve-enterprise.list

Puis on rajoute le dépôt sans abonnement dans notre fichier /etc/apt/sources.list :

# dépôt sans abonnement
deb http://download.proxmox.com/debian buster pve-no-subscription

Une fois fait, on se rend de nouveau sur l’interface web, on se place sur notre noeud puis Mises à jour, et on clique sur Rafraîchir pour effectuer l’équivalent d’un apt-get update. Ensuite, on peut appliquer les mises à jour disponibles :

On patiente un peu, et le tour est joué !

On va simplement réaliser une dernière petite commande puis on pourra s’attaquer à notre pool de stockage, c’est promis.

Par défaut, dans Proxmox, l’hyperviseur va commencer à utiliser la mémoire SWAP à partir de 60% (faites la commande cat /proc/sys/vm/swappiness et vous verrez la valeur 60 s’afficher), sauf que vu que l’on va utiliser en général pas mal de VMs sur notre hôte, on peut facilement monter cette valeur à 85/90 voir même la désactiver.

Pour ce faire :

# Afficher la valeur par défaut
cat /proc/sys/vm/swappiness
# Utiliser la mémoire SWAP uniquement si la ram de l'hôte est utilisée à 90%
sysctl vm.swappiness=90
# Utiliser la mémoire SWAP uniquement si la ram de l'hôte est utilisée complètement
sysctl vm.swappiness=0

A noter qu’avec un « =disabled » et un « swapoff -a » vous pouvez désactiver complètement la mémoire swap.

III) Création du pool de stockage ZFS

Bien, nous allons donc voir maintenant comment créer un pool de stockage qui sera dédié au stockage des VMs et conteneurs. Pour ce faire, nous allons utiliser nos trois disques dur virtuels de 100Go créés en début d’article pour en faire un pool ZFS, et nous utiliserons le RAID-Z, qui est l’équivalent du RAID-5 (permettant de doubler les vitesses de lecture, et aussi de se prémunir de la parte d’un disque).

Voici d’abord un peu de contexte.

• ZFS, pour « Zettabyte File System » est donc un système de fichier, au même titre que NTFS ou ext4. Il est disponible sous BSD, Unix, et GNU/Linux mais pas sur Windows. Ses avantages sont bien entendu la gestion de « pools » (équivalent de groupe de volumes logiques sous LVM), l’intégrité des données très poussée via divers mécanismes, la déduplication de données, le système de snapshots… bref la liste est longue ;
• RAID-Z, c’est l’équivalent du RAID-5 mais avec certaines fonctionnalités supplémentaires. Il peut par exemple utiliser la mémoire vive comme cache (fonctionnalité dénommée ARC) ou encore d’utiliser des SSD (fonctionnalité dénommée alors L2ARC) pour la lecture des fichiers, etc ;

Vous connaissez désormais les termes que l’on va employer juste après, donc tout est prêt pour se lancer dans le bain !

On se rend donc de nouveau sur notre interface web, sur notre noeud, puis nous allons dans Stockage, puis ZFS et enfin Créer: ZFS.

Ici c’est très simple, on nomme notre pool, on active ou non la compression (prenez deux petites minutes avant de l’activer ou non, car si d’ici X semaines vous décidez seulement de l’activer, les données déjà écrites ne seront pas compressées), puis on sélectionne nos disques. On a droit aussi à un joli petit warning nous disant que ZFS n’est pas compatibles avec les disques montés sur un contrôleur RAID physique.

On patiente quelques minutes et hop, le tour est joué ! On peut passer d’ailleurs en CLI pour afficher quelques infos, notamment les divers paramètres disponibles pour ZFS (à vous d’aller vous documenter sur chacun d’eux, tant ils sont nombreux 😛) :

Bien entendu, l’optimisation et la configuration « aux p’tits oignons » de ZFS est tout un art, et je n’en suis qu’à ses débuts, donc si vous désirez savoir comment rendre le tout optimisé à 1001%, passez votre chemin (pour l’instant).

Bien, la prochaine étape est de se rendre sur Datacenter, puis Stockage et d’éditer notre pool ZFS tout juste créé :

Ici il convient de changer la taille des blocs, car par défaut la valeur est à 8k. Le soucis, c’est qu’avec ce réglage par défaut, lorsque l’on écrira 1Go dans notre VM, l’espace occupé sera de 2Go environ, car les blocs écrits seront de très petites tailles… il convient donc de passer la valeur à 64 ou 128. Ensuite on peut activer ou non l’allocation granulaire, appelée plutôt thin provisionning en anglais. Cela permet donc par exemple de créer un disque dur virtuel de 100Go pour une VM, et l’espace occupé réellement sur le dique ne sera que de 20Go par exemple, ce ne sera pas une taille fixe. Cela a des avantages, par exemple pouvoir faire croire à certains services qu’ils ont X Go ou To de stockage mais si vous avez beaucoup de VMs, vous pourriez avoir un soucis car lorsque l’une d’entre elle aura réellement besoin de cet espace, vous pourriez être bloqué… à vous donc de bien prendre vos dispositions.

On peut ensuite valider via Ok, et tout est bon ! Nous pouvons désormais créer une première machine virtuelle pour vérifier que tout est bien fonctionnel.

IV) Création d’une VM

Ici rien de très sorcier non plus, vous connaissez (et si ce n’est pas le cas, je vous renvoi à mon précédent article). Simple petite note supplémentaire, n’hésitez pas à cocher la case Advanced Settings, permettant donc d’obtenir des options supplémentaires qui peuvent être bien intéressantes. Par exemple ici, on peut démarrer notre VM au boot de Proxmox ou encore lui assigner un délai, par exemple pour un serveur dépendant d’un autre :

Seconde petite note, quand vous crééz des machines GNU/Linux, privilégiez toujours les pilotes virtIO, qui sont disponibles de base dans le Kernel. Et enfin dernière note, si vous choisissez comme type de CPU Host, lorsque vous migrerez cette VM sur un autre serveur qui aura peut être un CPU différent, vous pourriez voir quelques suprises… faites donc bien attention !

Après avoir un peu patienté le temps de l’installation de notre petite Ubuntu Server de test, tout est ok ! Ceci clôture donc cet article qui est plus une « v2 » de l’ancien qu’autre chose 😛

Je ferai sûrement d’autres articles autour de Proxmox, car je n’y avais plus trop touché depuis un bon moment. Hâte de pouvoir recréer des clusters (car cela a légèrement changé depuis la version 5) et de pouvoir tester cette fameuse « migration à chaud 100% fonctionnelle ».

Une bonne journée/soirée à vous !