Chapitre 15. System Storage Managerm(SSM)
System Storage Manager (SSM) fournit une interface de ligne de commande pour gérer le stockage dans diverses technologies. Les systèmes de stockage sont de plus en plus compliqués avec l’utilisation de plusieurs dispositifs de mappage ou gestionnaires de volumes logiques (LVM). Cela crée un système qui n’est pas facile à utiliser et qui facilite les erreurs et les problèmes qui se posent. SSM soulage tout cela en créant une interface utilisateur unifiée. Cette interface permet aux utilisateurs d’exécuter des systèmes compliqués de manière simple. Par exemple, pour créer et installer un nouveau système de fichiers sans SSM, il y a cinq commandes qui doivent être utilisées. Avec SSM, une seule est nécessaire.
Ce chapitre va vous expliquer comment SSM intéragit avec les divers backends, puis détaillera certains cas qui reviennent souvent.
15.1. SSM Backends
SSM utilise une couche d'abstraction de
ssmlib/main.py compatible avec les abstractions de volume, périphérique, et pool, tout en ignorant les spécificités de la technologie sous-jacente. Les backends peuvent être enregistrées dans ssmlib/main.py pour gérer des méthodes de technologie de stockage spécifiques comme create, snapshot, ou bien, pour supprimer remove les volumes et les pools.
Il y a déjà plusieurs backends enregistrées dans SSM. Les sections suivantes vous donneront des informations de base, ainsi que des définitions sur la façon de gérer ces pools, volumes, clichés et périphériques.
15.1.1. BTRFS Backend
BTRFS, un système de fichiers avec plusieurs fonctionnalités avancées, est utilisé en tant que backend de gestion de volume dans SSM. Les pools, volumes et clichés peuvent être créés avec le backend de BTRFS.
15.1.1.1. BTRFS Pool
Le système de fichiers BTRFS en soi correspond au pool. Il peut être étendu en ajoutant plus de périphériques ou rétréci en retirant des périphériques. SSM crée un système de fichiers BTRFS lorsqu’un pool BTRFS est créé. Cela signifie que chaque nouveau pool BTRFS dispose d’un volume du même nom que le pool, qui ne peut être supprimé sans supprimer l’ensemble complet du pool. Le nom par défaut du pool BTRFS est
btrfs_pool.
Le nom du pool est utilisé comme libellé du système de fichiers. S'il y a déjà un système de fichiers BTRFS existant dans le système sans libellé, le pool BTRFS générera un nom d'utilisation interne sous le format suivant
btrfs_device_base_name.
15.1.1.2. BTRFS Volume
Les volumes créés dans un pool après le premier volume sont comme des sous-volumes. SSM montera temporairement le système de fichiers BTRFS, si il est démonté afin de créer un volume secondaire.
Le nom d'un volume est utilisé comme chemin de sous-volume dans le système de fichiers BTRFS. Ainsi, un sous-volume s'affiche ainsi
/dev/lvm_pool/lvol001. Chaque objet de ce chemin doit sortir pour que le volume soit créé. Les volumes peuvent également être référéncés par leur point de montage.
15.1.1.3. BTRFS Snapshot
Des clichés peuvent être pris de n’importe quel volume BTRFS dans le système avec SSM. Sachez que BTRFS ne distingue pas entre sous-volumes et clichés. Même si cela signifie que le SSM ne peut pas reconnaître la destination de chaque cliché, il va essayer de reconnaître les formats de nom spécial. Si le nom spécifié lors de la création du cliché correspond à un modèle spécifique, le cliché ne sera pas reconnu et sera, au lieu de cela, répertorié comme un volume standard de BTRFS.
15.1.1.4. Périphérique BTRFS
BTRFS ne requiert aucun périphérique particulier sur lequel être créé.
15.1.2. LVM Backend
Les pools, volumes, et clichés peuvent être créés par LVM. Les définitions suivantes sont d'un point de vue LVM.
15.1.2.1. LVM Pool
Un pool LVM est la même chose qu'un groupe de volume LVM. Cela signifie que le groupement de périphériques et de nouveaux volumes logiques peuvent être créés à partir du pool de LVM. Le nom du pool LVM par défaut est
lvm_pool.
15.1.2.2. LVM Volume
Un volume LVM ressemble à un volume logique ordinaire.
15.1.2.3. LVM Snapshot
Quand un cliché est créé à partir d'un volume LVM, un nouveau volume de
cliché est créé, qui pourra être manipulé comme tout autre volume LVM. À la différence de BTRFS, LVM est capable de distinguer les clichés des autres volumes habituels, donc vous n'avez pas besoin d'un nom de cliché qui cooresponde à un modèle particulier.
15.1.2.4. Périphérique LVM
SSM exige que LVM backend soit créé sur un périphérique physique transparent pour l'utilisateur.
15.1.3. Crypt
Le backend de cryptage dans SSM utilise
cryptsetup et dm-crypt target pour gérer les volumes encodés. Les backends de cryptage peuvent être utilisés comme backend standards pour créer des volumes encodés sur les périphériques encodés (ou sur d'autres volumes comme les volumes LVM ou MD), ou pour créer des volumes LVM encodés en une seule étape.
Seuls les volumes peuvent être créés avec un backend Crypt ; le pooling n'est pas pris en charge et ne requiert aucun périphérique particulier.
Les sections suivantes définissent des volumes et des clichés d'une point de vue Crypt.
15.1.3.1. Crypt Volume
Les volumes de cryptage sont créés par la commande
dm-crypt et représentent les données qui se trouvent dans le périphérique encodé d'origine sous une forme non encodée. Ne supporte aucune concatenation de périphérique ou RAID.
Deux modes, ou extensions, sont prises en charge : luks et plain. Luks est utilisé par défaut. Pour obtenir plus d'informations sur les extensions, consulter
man cryptsetup.
15.1.3.2. Cliché Crypt
Bien que le backend de cryptage ne prenne pas en charge les clichés, si le volume encodé est créé sur un volume LVM, le volume lui-même pourra être transformé en cliché. Le cliché pourra alors être ouvert par
cryptsetup.
15.1.4. Multiple Devices (MD)
Le MD backend se contente actuellement de collecter des informations sur les volumes MD du système.
