Différences

Ci-dessous, les différences entre deux révisions de la page.

--- technique:infrastructure:storage_proxmox [2023/05/31 18:21] – qduchemi
+++ technique:infrastructure:storage_proxmox [2023/06/25 20:19] (Version actuelle) – qduchemi
@@ Ligne 1: / Ligne 1: @@
+{{indexmenu_n>16}}
+# Gestion des disques et du stockage Proxmox
+<bootnote warning>Cette page nécessite de comprendre [les bases de LVM](https://doc.ubuntu-fr.org/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.</bootnote>
+## Introduction
+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.
+## Des disques réels aux périphériques RAID
+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.
+<bootnote learn>Le RAID1 peut être configuré soit directement depuis Linux avec [mdadm](https://wiki.archlinux.org/title/RAID) (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](https://wiki.picasoft.net/doku.php?id=technique:infrastructure:config#utilisation_du_stockage1) (on parle de RAID matériel).</bootnote>
+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`
+## Des disques aux Volume Groups
+Si on a, mettons, 3 SSD, la problématique est la suivante.
+<bootnote 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...?</bootnote>
+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 :
+```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 :
+```bash
+vgextend <VG> <PV>
+```
+## Des Volume Groups aux Logical Volumes
+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 :
+```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 :
+```bash
+mkfs.ext4 /dev/mapper/<VG>-<LV>
+```
+Pour étendre un LV, on utilise la commande suivante :
+```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`.
+<bootnote critical>Depuis les versions récentes de Proxmox, l'installateur a tendance à créer automatiquement un [thin pool LVM](https://pve.proxmox.com/wiki/Storage:_LVM_Thin) 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...</bootnote>
+Par convention, on monte automatiquement les LV au démarrage (via [fstab](https://wiki.archlinux.org/title/fstab)) sur les chemins suivants :
+* `data` → `/var/lib/vz` ;
+* `vm_storage` → `/var/lib/vm_storage` ;
+* `backup` → `/SAVE`.
+## La notion de « stockage Proxmox »
+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](https://pve.proxmox.com/wiki/Storage), le plus simple étant un répertoire ordinaire, les plus complexes utilisant des systèmes redondés comme Ceph.
+<bootnote>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.</bootnote>
+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).
+<bootnote critical>
+**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 [[technique:adminsys:monitoring:alerting:start|alerting]]).
+</bootnote>
+<bootnote learn>
+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.
+</bootnote>
+<bootnote critical>
+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.
+</bootnote>
+## Création d'un stockage Proxmox : exemple
+Créons le stockage `vm_hdd`.
+<bootnote warning>
+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.
+</bootnote>
+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`.
+{{ :technique:infrastructure:storage_proxmox.png |}}
+<bootnote warning>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.</bootnote>
+## Cas particulier : le stockage Scenari
+Comme expliqué [ici](https://wiki.picasoft.net/doku.php?id=technique:infrastructure:config#utilisation_du_stockage1), 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.
+## Synthèse
+<bootnote question>C'est un sec là, y'a pas moyen d'avoir un petit récap ?</bootnote>
+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...
+{{ :technique:infrastructure:storage_summary.png |}}
+## Rendre la machine picasoftienne
+Direction [[technique:infrastructure:setup_machine|cette page]] pour finir la configuration ! :-D