Navigation

Attention:

Cette page nécessite de comprendre les bases de LVM. Il faut être root pour toutes les commandes. Des commandes de base sont données, les exemples plus complexes seront à élaborer au cas par cas.

Des disques physiques aux disques des machines virtuelles, il y a une grande chaîne d’abstraction qu’il peut être difficile de comprendre. Cette page vise à donner une vue générale et à permettre aux bénévoles de manipuler le stockage à tous les niveaux, avec en vue la possibilité d’ajouter ou d’enlever des disques.

Les disques « réels » sur nos machines sont soit des SSD (rapides), soit des disques durs ou HDD (moins rapides). La première couche d’abstraction est en général le RAID1 : il s’agit d’une technique permettant de mettre deux disques en « miroir ». Les deux disques sont alors présentés sous forme d’un seul disque virtuel, où chaque écriture sera transformée en deux écritures sur deux disques. L’idée, c’est que si un disque tombe, l’autre contient toujours les données et il suffit de remplacer le premier sans perte.

A Savoir:

Le RAID1 peut être configuré soit directement depuis Linux avec mdadm (on parle de RAID logiciel), soit avec un contrôleur dédié au niveau de la carte mère, comme c’est le cas sur Caribou (on parle de RAID matériel).

On ne fait pas de tutoriel ici ; dans la suite, on imagine qu’on manipule toujours les périphériques RAID et on oublie les « vrais » disques.

#todo : remplacer un disque mort dans une grappe RAID

Si on a, mettons, 3 SSD, la problématique est la suivante.

Question:

Comment utiliser les 3 SSD de manière unifiée, sans avoir besoin de choisir quelles données on mettra sur le premier, sur le deuxième, le troisième…?

Avec LVM, pour Logical Volume Manager, intégré au noyau Linux. C’est notre principale raison de l’utiliser. Dans LVM, l’élément de base est le Physical Volume (PV), un équivalent d’un disque (ou d’une partition). Chaque fois que l’on aura un nouveau disque, il suffira d’en faire un PV :

snippet.bash

pvcreate /dev/<disque>

Ensuite, les Volume Groups (VG) permettent de regrouper des PV en un grand espace de stockage, le choix du disque sous-jacent étant transparent et géré par LVM.

Sur les machines, on a toujours les Volume Groups suivants :

hdd qui contient l’ensemble des PV correspondant à des HDD ;
pve qui contient l’ensemble des PV correspondant à des SSD.

Pour ajouter un PV à un VG existant et l’étendre, on utilisera :

snippet.bash

vgextend <VG> <PV>

On y est : le cœur de LVM. Les Logical Volumes (LV) sont des partitions virtuelles créées à partir d’un VG. C’est le pendant « virtuel » des PV, en réalité ! C’est comme si on avait découpé les PV d’un VG en petits dés dans un saladier et qu’on les tirait au sort pour constituer un LV. L’intérêt est de pouvoir redimensionner de manière très souple un LV, voire d’excéder la taille d’un PV.

Pour créer un LV, on utilise la commande suivante :

snippet.bash

lvcreate -L <taille[M,G]> -n <LV> <VG>

Sur nos machines, les LV contiennent toujours un système de fichier, que l’on créera par exemple comme suit :

snippet.bash

mkfs.ext4 /dev/mapper/<VG>-<LV>

Pour étendre un LV, on utilise la commande suivante :

snippet.bash

# Utiliser --resize si le LV contient un système de fichier
lvextend [--resize] -L +<taille[M,G]> <VG>/<LV>
# Si le LV est un thin-pool (voir plus bas)
lvresize --poolmetadatasize +<size[M,G]> <VG>/<LVThin_pool>

Sur les machines, on retrouve systématiquement les LV suivants, lesquels contiennent un système de fichier ext4 :

data sur le VG pve ;
vm_storage sur le VG hdd ;
backup sur le VG hdd.

Important:

Depuis les versions récentes de Proxmox, l’installateur a tendance à créer automatiquement un thin pool LVM appelé data : il faut imaginer que c’est un genre d’intermédiaire entre VG et LV, dont la taille totale des LV peut dépasser la taille du thin pool et qui n’utilisent que l’espace nécessaire (versus réserver un espace complet). C’est du détail pas très important, et ça complique les choses en étant pas homogène, mais c’est fait c’est fait…

Par convention, on monte automatiquement les LV au démarrage (via fstab) sur les chemins suivants :

data → /var/lib/vz ;
vm_storage → /var/lib/vm_storage ;
backup → /SAVE.

Proxmox utilise le mot « stockage » pour désigner les espaces dans lesquels il stockera les backups, les disques virtuels, les ISO de démarrage… Il supporte un grand nombre de type de stockage, le plus simple étant un répertoire ordinaire, les plus complexes utilisant des systèmes redondés comme Ceph.

Note:

C’est une nouvelle couche d’abstraction, applicative cette fois, qui permet de traiter de la même manière un VG, un partage NFS, un répertoire, un lien iSCSI… ce qui est pratique, mais rajoute une couche à notre histoire.

L’organisation est libre, mais chez Picasoft, on crée généralement trois stockages :

Un stockage nommé local pour les ISO, voire pour les disques virtuels « rapides » (utilisant les SSD) ;
Un stockage nommé vm_hdd pour les disques virtuels « lents » (utilisant les HDD) ;
Un stockage nommé save pour les sauvegardes des disques virtuels (utilisant les HDD).

Important:

Toujours nommer le stockages qui utilisent le SSD local, celui utilisant le HDD vm_hdd et celui pour les backups save pour que les alertes fonctionnent (voir alerting).

A Savoir:

Chez Picasoft, par souci de simplicité, on utilise quasi-systématiquement le stockage le plus simple, à savoir Directory, i.e. un simple dossier sur l’hôte. Si vous avez suivi au-dessus, c’est généralement le point d’un montage d’un LV, exception faite du thin-pool créé par Proxmox 7.

Dans le cas où on utilise un stockage Directory pour créer le disque d’une machine virtuelle, il sera représenté par un fichier dans le dossier ;
Dans le cas d’un stockage Thin-pool ou LVM, un LV sera créé par disque de machine virtuelle, ce qui est peu lisible.

Important:

Même si ça peut sembler plus straightforward, on déconseille de créer un stockage « LVM » basé sur un VG. Ça peut sembler une bonne idée, car Proxmox pourrait alors pour chaque machine virtuelle utiliser l’espace nécessaire pour chaque VM. Mais ça crée un LV par disque virtuel, ce qui rend les choses peu visibles, et produit des interactions étranges quand LVM est utilisé à l’intérieur des machines virtuelles. Passer par le montage d’un dossier est plus maintenable et pas moins efficient.

Créons le stockage vm_hdd.

Attention:

Le nom du stockage a beau être vm_hdd, c’est complètement arbitraire ! C’est nous qui devons le configurer pour qu’il utilise d’une manière ou d’une autre les HDD. De même, save est plus cohérent sur HDD, car on a pas besoin de vitesse pour les sauvegardes, mais c’est à nous de le dire.

On clique sur Datacenter dans le menu de gauche, puis on choisit Storage. On choisit Directory, et on indique le point de montage, en l’occurrence là où est monté le LV vm_storage, qui vient du VG hdd.

Attention:

Attention à la case Content qui peut sembler descriptive. Par exemple, Proxmox refusera d’utiliser le stockage comme cible de backup s’il n’a pas VZDump backup file dans son contenu.

Comme expliqué ici, l’association Scenari a acheté un SSD de 2To non-redondé pour Caribou, pour stocker notamment ses backups. Pour permettre une meilleure isolation, plutôt que d’utiliser ce disque comme du stockage pur et d’ouvrir un accès SSH sur Caribou, ce disque sera monté sur Caribou, puis associé à un stockage Directory appelé scenari.

Le stockage scenari servira exclusivement pour une machine virtuelle dont les accès seront donnés à Scenari. Le contrat d’hébergement prévoie que l’usage des ressources est dédiée aux backups.

Question:

C’est un sec là, y’a pas moyen d’avoir un petit récap ?

J’espère qu’un schéma permettra de mieux comprendre la chaîne entre les disques réels et les disques des machines virtuelles. Si vous vous dites que c’est un peu abusé, je peux pas vous donner tort…