Stockage
Cet article décrit comment le matériel de stockage physique est mappé aux machines virtuelles (VM), ainsi que les objets logiciels utilisés par XenServer® pour effectuer les tâches liées au stockage. Il fournit également des informations sur les types de stockage disponibles pour vous permettre de faire le bon choix de matériel de stockage à utiliser dans votre environnement.
Concepts de stockage
L’image suivante montre comment les objets de stockage décrits dans cette section sont liés :
Référentiels de stockage (SR)
Un référentiel de stockage (SR) est une cible de stockage particulière, dans laquelle sont stockées les images de disque virtuel (VDI) des machines virtuelles (VM). Une VDI est une abstraction de stockage qui représente un disque dur virtuel (HDD). Pour en savoir plus sur les types de SR pris en charge par XenServer, consultez Types de référentiels de stockage.
Les abstractions SR et VDI permettent d’exposer des fonctionnalités de stockage avancées sur les cibles de stockage qui les prennent en charge. Par exemple, des fonctionnalités avancées telles que le provisionnement léger, les instantanés VDI et le clonage rapide. Pour les sous-systèmes de stockage qui ne prennent pas directement en charge les opérations avancées, une pile logicielle qui implémente ces fonctionnalités est fournie.
Un référentiel de stockage est une structure de données persistante sur disque. Pour les types de SR qui utilisent un périphérique de bloc sous-jacent, le processus de création d’un SR implique l’effacement de toutes les données existantes sur la cible de stockage spécifiée. D’autres types de stockage, tels que NFS, créent un conteneur sur la baie de stockage en parallèle des SR existants.
Chaque hôte XenServer peut utiliser plusieurs SR et différents types de SR simultanément. Ces SR peuvent être partagés entre les hôtes ou dédiés à des hôtes particuliers. Le stockage partagé est mis en commun entre plusieurs hôtes au sein d’un pool de ressources défini. Un SR partagé doit être accessible via le réseau à chaque hôte du pool. Le stockage partagé ne peut pas être partagé entre plusieurs pools.
Les commandes SR fournissent des opérations pour créer, détruire, redimensionner, cloner, connecter et découvrir les VDI individuelles qu’ils contiennent. Les opérations CLI pour gérer les référentiels de stockage sont décrites dans Commandes SR.
Image de disque virtuel (VDI)
Une image de disque virtuel (VDI) est une abstraction de stockage qui représente un disque dur virtuel (HDD). Les VDI sont l’unité fondamentale du stockage virtualisé dans XenServer. Les VDI sont des objets persistants sur disque qui existent indépendamment des hôtes XenServer. Pour plus d’informations sur les formats de données pris en charge pour les disques virtuels sur XenServer, consultez Formats de données de disque virtuel.
Les opérations CLI pour gérer les VDI sont décrites dans Commandes VDI. La représentation sur disque des données diffère selon le type de SR. Une interface de plug-in de stockage distincte pour chaque SR, appelée API SM, gère les données.
Périphériques de bloc physiques (PBD)
Les périphériques de bloc physiques représentent l’interface entre un serveur physique et un SR attaché. Les PBD sont des objets connecteurs qui permettent de mapper un SR donné à un hôte. Les PBD stockent les champs de configuration de périphérique qui sont utilisés pour se connecter et interagir avec une cible de stockage donnée. Par exemple, la configuration de périphérique NFS inclut l’adresse IP du serveur NFS et le chemin associé que l’hôte XenServer monte. Les objets PBD gèrent l’attachement en temps réel d’un SR donné à un hôte XenServer donné. Les opérations CLI relatives aux PBD sont décrites dans commandes PBD.
Périphériques de bloc virtuels (VBD)
Les périphériques de bloc virtuels sont des objets connecteurs (similaires aux PBD décrits ci-dessus) qui permettent des mappages entre les VDI et les VM. En plus de fournir un mécanisme pour attacher un VDI à une VM, les VBD permettent d’affiner les paramètres concernant la priorité et les statistiques d’E/S disque d’un VDI donné, et si ce VDI peut être démarré. Les opérations CLI relatives aux VBD sont décrites dans commandes VBD.
Types de référentiels de stockage
XenServer prend en charge une gamme de types de stockage pour les SR connectés localement et à distance.
Avertissement :
XenServer ne prend pas en charge les instantanés au niveau SAN externe d’une LUN pour tout type de SR.
SR locaux
Un référentiel de stockage local (SR) est connecté à un seul hôte et n’est pas partagé entre tous les hôtes d’un pool. Le matériel de stockage physique local peut être un disque dur (HDD) ou un disque SSD (Solid State Drive). Il peut se connecter à l’hôte en utilisant l’une des méthodes suivantes : SATA, SCSI, SAS, NVMe.
Les hôtes XenServer prennent en charge les types de stockage local suivants :
SR distants
XenServer prend en charge le stockage connecté à distance en utilisant les lecteurs suivants : iSCSI, NFS, SAS, SMB (version 3 uniquement), Fibre Channel.
Remarque :
NVMe sur Fibre Channel et NVMe sur TCP ne sont pas pris en charge.
Les types de stockage connectés à distance suivants peuvent être utilisés pour créer des SR partagés pour votre pool XenServer.
Bibliothèques ISO :
Stockage basé sur des fichiers :
Stockage basé sur des blocs :
- Stockage iSCSI logiciel
- Stockage HBA matériel
- Stockage de blocs GFS2 partagé à provisionnement dynamique
Comparaison des types de stockage partagé
Le tableau suivant compare les fonctionnalités des différents types de stockage pris en charge pour les SR partagés. Tenez compte de ces capacités lors du choix de votre solution de stockage.
| Basé sur fichier (SMB/NFS) | Basé sur bloc (iSCSI/HBA) LVM | Basé sur bloc (iSCSI/HBA) GFS2 | |
|---|---|---|---|
| Type de disque virtuel | VHD | VHD | QCOW2 |
| Nombre maximal de disques virtuels par SR | 20000 | 1000 | 20000 |
| Taille maximale du disque virtuel | 2 040 Gio | 2 040 Gio | 16 Tio |
| Taille maximale du pool(/fr-fr/xenserver/9/hosts-pools#recommended-pool-size) | 32/64 | 32 | 16 |
| Fonctionnalités prises en charge | |||
| Migration du stockage(/fr-fr/xenserver/9/vms/migrate) | Oui | Oui | Non |
| Intellicache(/fr-fr/xenserver/9/storage/intellicache) | Oui | Oui | Non |
| Mise en cache en lecture(/fr-fr/xenserver/9/storage/read-cache) | Oui | Non | Oui |
| Provisionnement léger (voir note) | Oui | Non | Oui |
| Reprise après sinistre | Non | Oui | Non |
Remarque :
Pour le stockage LVM basé sur des blocs, vous pouvez implémenter le provisionnement léger dans le SAN sous-jacent. Cependant, cela n’est pas recommandé avec les SR GFS2.
Formats de données de disque virtuel
En général, il existe les types de mappage suivants du stockage physique vers un VDI :
-
VHD basé sur un volume logique sur un LUN : Le stockage par blocs par défaut de XenServer insère un gestionnaire de volumes logiques sur un disque. Ce disque est soit un périphérique connecté localement (LVM), soit un LUN connecté à un SAN via Fibre Channel, iSCSI ou SAS. Les VDI sont représentés comme des volumes au sein du gestionnaire de volumes et stockés au format VHD pour permettre le provisionnement léger des nœuds de référence lors de la création d’instantanés et de clones.
-
QCOW2 basé sur fichier sur un LUN : Les images de VM sont stockées sous forme de fichiers au format QCOW2 à provisionnement dynamique sur un système de fichiers GFS2 à disque partagé sur un LUN attaché via un initiateur logiciel iSCSI ou un HBA matériel.
-
VHD basé sur fichier sur un système de fichiers : Les images de VM sont stockées sous forme de fichiers au format VHD à provisionnement dynamique sur un système de fichiers local non partagé (SR de type EXT3/EXT4), une cible NFS partagée (SR de type NFS) ou une cible SMB distante (SR de type SMB).
-
QCOW2 basé sur fichier sur un système de fichiers : Les images de VM sont stockées sous forme de fichiers au format QCOW2 à provisionnement dynamique sur un système de fichiers XFS local non partagé.
Types de VDI
Pour les SR GFS2 et XFS, des VDI QCOW2 sont créés.
Pour les autres types de SR, des VDI au format VHD sont créés. Vous pouvez choisir d’utiliser le format brut (raw) au moment de la création du VDI. Cette option ne peut être spécifiée qu’en utilisant l’interface de ligne de commande xe.
Remarque :
Si vous créez un VDI brut sur un SR basé sur LVM ou un SR HBA/LUN par VDI, cela pourrait permettre à la VM propriétaire d’accéder à des données qui faisaient partie d’un VDI précédemment supprimé (de n’importe quel format) appartenant à n’importe quelle VM. Nous vous recommandons de prendre en compte vos exigences de sécurité avant d’utiliser cette option.
Les VDI bruts sur un SR NFS, EXT ou SMB n’autorisent pas l’accès aux données des VDI précédemment supprimés appartenant à une VM.
Pour vérifier si un VDI a été créé avec type=raw, vérifiez sa carte sm-config. Les commandes xe sr-param-list et vdi-param-list peuvent être utilisées respectivement à cette fin.
Créer un disque virtuel brut à l’aide de l’interface de ligne de commande xe
-
Exécutez la commande suivante pour créer un VDI en spécifiant l’UUID du SR dans lequel vous souhaitez placer le disque virtuel :
xe vdi-create sr-uuid=sr-uuid type=user virtual-size=virtual-size \ name-label=VDI name sm-config:type=raw <!--NeedCopy--> -
Attachez le nouveau disque virtuel à une VM. Utilisez les outils de disque au sein de la VM pour partitionner et formater, ou utiliser autrement le nouveau disque. Vous pouvez utiliser la commande
vbd-createpour créer un VBD afin de mapper le disque virtuel dans votre VM.
Convertir entre les formats VDI
Il n’est pas possible d’effectuer une conversion directe entre les formats brut (raw) et VHD. Au lieu de cela, vous pouvez créer un VDI (soit brut, comme décrit ci-dessus, soit VHD) puis y copier des données à partir d’un volume existant. Utilisez l’interface de ligne de commande xe pour vous assurer que le nouveau VDI a une taille virtuelle au moins aussi grande que le VDI source. Vous pouvez le faire en vérifiant son champ virtual-size, par exemple en utilisant la commande vdi-param-list. Vous pouvez ensuite attacher ce nouveau VDI à une VM et utiliser votre outil préféré au sein de la VM pour effectuer une copie de bloc directe des données. Par exemple, les outils de gestion de disque standard sous Windows ou la commande dd sous Linux. Si le nouveau volume est un volume VHD, utilisez un outil capable d’éviter d’écrire des secteurs vides sur le disque. Cette action peut garantir que l’espace est utilisé de manière optimale dans le référentiel de stockage sous-jacent. Une approche de copie basée sur les fichiers peut être plus appropriée.
VDI basés sur VHD et QCOW2
Les images VHD et QCOW2 peuvent être chaînées, permettant à deux VDI de partager des données communes. Dans les cas où une VM basée sur VHD ou QCOW2 est clonée, les VM résultantes partagent les données communes sur disque au moment du clonage. Chaque VM procède à ses propres modifications dans une version isolée en copie sur écriture du VDI. Cette fonctionnalité permet de cloner rapidement de telles VM à partir de modèles, facilitant ainsi le provisionnement et le déploiement très rapides de nouvelles VM.
Au fur et à mesure que les VM et leurs VDI associés sont clonés, cela crée des arborescences de VDI chaînés. Lorsqu’un des VDI d’une chaîne est supprimé, XenServer rationalise les autres VDI de la chaîne pour supprimer les VDI inutiles. Ce processus de coalescence s’exécute de manière asynchrone. La quantité d’espace disque récupérée et le temps nécessaire pour effectuer le processus dépendent de la taille du VDI et de la quantité de données partagées. Pour plus d’informations, consultez Remarques sur la coalescence.
Les formats VHD et QCOW2 prennent en charge le provisionnement léger. Le fichier image est automatiquement étendu par petits blocs granulaires à mesure que la VM écrit des données sur le disque. Pour les VHD basés sur des fichiers et les QCOW2 basés sur GFS2, cette approche présente l’avantage considérable que les fichiers image de VM n’occupent que l’espace nécessaire sur le stockage physique. Avec les VHD basés sur LVM, le conteneur de volume logique sous-jacent doit être dimensionné à la taille virtuelle du VDI. Cependant, l’espace inutilisé sur le disque d’instance de copie sur écriture sous-jacent est récupéré lorsqu’un instantané ou un clone est créé. La différence entre les deux comportements peut être décrite de la manière suivante :
-
Pour les images VHD basées sur LVM, les nœuds de disque de différence au sein de la chaîne ne consomment que la quantité de données écrites sur le disque. Cependant, les nœuds feuilles (clones VDI) restent entièrement gonflés à la taille virtuelle du disque. Les nœuds feuilles d’instantané (instantanés VDI) restent dégonflés lorsqu’ils ne sont pas utilisés et peuvent être attachés en lecture seule pour préserver l’allocation dégonflée. Les nœuds d’instantané attachés en mode lecture-écriture sont entièrement gonflés lors de l’attachement et dégonflés lors du détachement.
-
Pour les VHD basés sur des fichiers et les images QCOW2 basées sur GFS2, tous les nœuds ne consomment que la quantité de données écrites. Les fichiers des nœuds feuilles augmentent pour s’adapter aux données au fur et à mesure qu’elles sont activement écrites. Si un VDI de 100 Go est alloué pour une VM et qu’un OS est installé, le fichier VDI n’a physiquement que la taille des données de l’OS sur le disque, plus une petite surcharge de métadonnées.
Lors du clonage de VM basées sur un seul modèle VHD ou QCOW2, chaque VM enfant forme une chaîne où les nouvelles modifications sont écrites dans la nouvelle VM. Les anciens blocs sont lus directement à partir du modèle parent. Si la nouvelle VM était convertie en un autre modèle et que d’autres VM étaient clonées, la chaîne résultante entraînerait une dégradation des performances. XenServer prend en charge une longueur de chaîne maximale de 30. N’approchez pas cette limite sans bonne raison. En cas de doute, « copiez » la VM à l’aide de XenCenter ou utilisez la commande vm-copy, qui réinitialise la longueur de la chaîne à 0.
Remarques sur la coalescence
Un seul processus de coalescence est actif pour un SR. Ce thread de processus s’exécute sur le coordinateur de pool SR. Pendant que le processus de coalescence est actif, un espace supplémentaire dans le SR peut être nécessaire pour accueillir les données fusionnées d’un niveau de l’arborescence delta à un autre. Après ce processus, le niveau redondant est supprimé et l’espace est libéré.
Si vous avez des VM critiques exécutées sur le coordinateur de pool, vous pouvez prendre les mesures suivantes pour atténuer les ralentissements occasionnels des E/S :
-
Migrez la VM vers un hôte autre que le coordinateur de pool SR
-
Définissez la priorité des E/S disque à un niveau supérieur et ajustez le planificateur. Pour plus d’informations, consultez Priorisation des requêtes d’E/S de disque virtuel.