Bonjour à tous, vous le savez, nous avons commencé avec mon collègue Antoine (que j’espère bien arriver à convaincre de rédiger quelque chose sur ce blog un jour…) à monter notre premier cluster de production Proxmox. Une occasion pour moi d’essayer de comprendre et de vous restituer, comme je le peux, ce que j’ai compris du stockage dans Proxmox. Comme toujours dans l’open source, tout est possible, mais ne nous voilons pas la face : c’est un peu le bord, pardon…bazar. 😉
1. Le paradoxe Proxmox : pourquoi c’est très performant et si complexe à la fois
roxmox est une solution open source ultra-puissante, mais comme elle repose sur les fondations de Linux Debian, son écosystème de stockage forme un labyrinthe de technologies superposées, dont la plupart héritent de tout l’écosystème Linux depuis plus de 25 ans… Entre Ceph, ZFS, LVM, iSCSI et les formats de disques (RAW, QCOW2, VMDK), on a l’impression de devoir choisir entre la peste et le choléra. Et surtout, on ne s’y retrouve plus aujourd’hui lorsqu’il s’agit de choisir une solution pour une production stable et critique !
Déjà, rien que sur Linux, en plus de 30 ans, j’ai eu l’expérience de certains admins qui ont perdu des heures à configurer un stockage qui ne fonctionne pas, simplement parce qu’ils ont mélangé des technologies incompatibles ou qu’ils ne maitrisait pas l’empilement des couches sous-jacentes.
2. Les technologies de stockage principales sur Proxmox (et Linux !)
Je vais essayer, de la manière la plus simple possible, souvent via des tableaux, de vous présenter les technologies que je connais (j’en oublierai forcément, pardonnez-moi si c’est le cas, mais nous pouvons enrichir cela ensemble, les commentaires sont ouverts 🙂 !). Commençons par poser les bases : les couches du stockage, à l’image des couches des stacks réseau du modèle OSI.
On le vois, si au départ la gestion de disque était relativement simple, aujourd’hui elle embarque beaucoup de choses, y compris les stack réseaux (pour CEPH et iSCS) ou intègre plusieurs fonctions séparés (comme ZFS). Si on va plus loin, qu’est-ce que Proxmox offre aujourd’hui en terme de solution, sur ces empilements :
| Type de stockage | Description | Remarques |
| CIFS | Stockage NAS | Plutôt pour du lab, simple et facile mais pas orienté performance |
| NFS | Stockage NAS | Plutôt des usages hybrides multi-usage ou sur des baies Entreprise NAS a fort degré de consolidation |
| LVM | Stockage local | Simple et performant, stockage local uniquement |
| LVM-Thin | Stockage local ou iSCSI | Simple et performant, qui intègre de l’allocation « on the fly » |
| iSCSI | Protocole réseau de communication sur TCP/IP | Le protocole de stockage sur IP standard (souvent combiné avec une couche LVM-Thin ou LVM) |
| CEPH | Protocol réseau Hyperconvergé | |
| ZFS | Stockage local | Performant, puissant et réservé à des usage locaux ou DAS |
| ZFS over iSCSI | Stockage local ou iSCSI | Lab uniquement, ajoute la stack IP et un tunnel SSH … donc pas l’idéal pour de la perf (mais très pratique au quotidien) |
J’ai omis quelques modules et filesystems spécifiques qui sont hors du scope de cet article (BTRFS, Dir mode …)
Une note importante que je viens d’apprendre, et c’est là qu’on commence à parler d’une nouvelle technologie de Proxmox, encore en preview aujourd’hui : le snapshot-as-volume-chain sur LVM. Cette option a été conçue pour apporter les snapshots et les linked clones aux stockages en mode bloc.
Concrètement, dans un scénario classique de baie SAN (iSCSI ou FC), on crée un volume logique sur un groupe de volumes (VG) classique sur ce disque (cette LUN iSCSI typiquement), puis on active l’option ad-hoc snapshot-as-volume-chain sur le backend LVM dans Proxmox. À partir de là, chaque snapshot ou clone n’est plus un simple LV figé, mais un maillon dans une chaîne de volumes (volume de base + volumes dérivés, un peu comme sur les datastores VMFS de VMware) que Proxmox gère comme une chaîne de blocs hiérarchiques. Cela ressemble aussi à ce que fait QCOW2, mais appliqué à des volumes logiques standards. L’intérêt est double : profiter du partage de blocs (LUN iSCSI) tout en conservant des fonctionnalités avancées côté hyperviseur (snapshots rapides, clones liés, consommation disque optimisée).
En revanche, on ne peut utiliser cette option qu’avec du LVM classique en mode partagé – c’est-à-dire avec plusieurs serveurs au sein d’un cluster – et non avec LVM-thin, pour une raison structurelle. LVM-thin dispose déjà de son propre moteur de thin provisioning et de snapshots au niveau du noyau, mais ses métadonnées ne sont pas cluster-aware et ne supportent pas de manière sécurisée des accès concurrents depuis plusieurs nœuds. Autrement dit, un pool thin ne peut pas être présenté simultanément à plusieurs hôtes Proxmox en écriture comme stockage partagé. Le snapshot-as-volume-chain sert justement à « compenser » l’absence de snapshots sur un LVM thick partagé ; il serait à la fois inutile et dangereux de tenter de superposer ce mécanisme à celui de LVM thin, qui reste cantonné à un usage local par nœud. Résultat : en mode partagé, Proxmox supporte LVM + volume-chain sur LUN bloc, mais pas LVM-thin, qui reste limité aux pools locaux avec ses propres snapshots intégrés.
3. Les format de volume disque
Enfin on monte à la couche supérieure, la VM et surtout ses nombreux types de disques virtuels :
| Format de disque virtuel | Description | Remarque |
| qcow2 | Le disque virtuel classique d’une VM Proxmox | compatible nativement avec la plupart des filesystems en mode « FILE », CIFS, NFS et consors … |
| zfspool/zvol | Un disque virtuel utilisant le partitionnement zfs avec les dataset ou zvol | Très performant, tire partie des fonctions avancées de zfs, mais réservé a un usage local |
| vmdk | Disque au format VMware, attention aux performances | Peut être une bonne option temporaire pendant une phase de migration |
| luks | Spécifique pour le chiffrement sur disque | A réserver à des cas d’usage spécifiques (HDS, par exemple) |
| rdb | Spécifique à CEPH |
QCOW2 est le format habituel sur des environnements utilisant du stockage fichier en réseau de type NFS, ou en local sur du LVM classique. Ce format intègre nativement la compression et les snapshots, ce qui permet d’éviter d’avoir recours à des fonctions avancées comme l’option volume-chain, mais au prix de performances en retrait.
L’idéal, à mon sens (même si je n’ai pas une grande expérience de production sur Proxmox), consisterait à opter pour iSCSI avec LVM et la fonctionnalité volume-chain. On accepte ainsi l’overhead lié à l’espace occupé par les snapshots en mode thick sur les volumes disques, tout en laissant la baie backend gérer sa propre réduction des données.
Dans la pratique je serais curieux d’avoir vos retours sur ce sujet du sizing moyen des volumes iSCSI provisionnées sur vos clusters et leur nombre. Avez vous des règles de calcul simple du style :
C’est à peu près tout pour l’instant, je découvre et lit beaucoup en ce moment, évidemment, mais à votre écoute sur vos solutions en production et celles que vous recommendez aujourd’hui, avec du recul !
Merci pour vos retours et suite au prochain épisode … allez hop hop hop … production dans moins d’un mois !
