Stockage
Cette section décrit comment le matériel de stockage physique est mappé aux machines virtuelles (VM) et les objets logiciels utilisés par l’API de gestion pour effectuer des tâches liées au stockage. Les sections détaillées sur chacun des types de stockage pris en charge incluent les informations suivantes :
- Procédures de création de stockage pour les machines virtuelles à l’aide de l’interface de ligne de commande, avec des options de configuration
- Génération d’instantanés à des fins de sauvegarde
- Meilleures pratiques pour la gestion du stockage
Référentiels de stockage (SR)
Un référentiel de stockage (SR) est une cible de stockage particulière, dans laquelle les images de disque virtuel (VDI) de machine virtuelle (VM) sont stockées. Un VDI est une abstraction de stockage qui représente un disque dur virtuel (HDD).
Les SR sont flexibles et prennent en charge les lecteurs suivants :
Connecté localement :
- SATA
- SCSI
- SAS
- NVMe
Le matériel de stockage physique local peut être un disque dur (HDD) ou un disque SSD.
Connexion à distance :
- iSCSI
- NFS
- SAS
- PME (version 3 uniquement)
- Fibre Channel
Remarque :
NVMe over Fibre Channel et NVMe over TCP ne sont pas pris en charge.
Les abstractions SR et VDI permettent d’exposer des fonctionnalités de stockage avancées sur des cibles de stockage qui les prennent en charge. Par exemple, des fonctionnalités avancées telles que le provisionnement dynamique, 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 implémentant ces fonctionnalités est fournie. Cette pile logicielle est basée sur la spécification de disque dur virtuel (VHD) de Microsoft.
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 stockage en mode 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 aux SR existants.
Chaque serveur Citrix Hypervisor peut utiliser plusieurs SR et différents types de SR simultanément. Ces SR peuvent être partagées entre des hôtes ou dédiées à des hôtes particuliers. Le stockage partagé est mis en pool entre plusieurs hôtes au sein d’un pool de ressources défini. Un SR partagé doit être accessible en réseau à chaque hôte du pool. Tous les serveurs d’un même pool de ressources doivent avoir au moins une SR partagée en commun. Le stockage partagé ne peut pas être partagé entre plusieurs pools.
Les commandes SR fournissent des opérations de création, de destruction, de redimensionnement, de clonage, de connexion et de découverte des VDI individuels qu’elles contiennent. Les opérations CLI pour gérer les référentiels de stockage sont décrites dans les commandes SR.
Avertissement :
Citrix Hypervisor ne prend pas en charge les instantanés au niveau du SAN externe d’un LUN pour aucun type de 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 Citrix Hypervisor. Les VDI sont des objets persistants sur disque qui existent indépendamment des serveurs Citrix Hypervisor. Les opérations CLI pour gérer les VDI sont décrites dans les commandes VDI. La représentation des données sur disque varie 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 physiques en mode bloc (PBD)
Les périphériques de blocs physiques représentent l’interface entre un serveur physique et un SR connecté. Les PBD sont des objets de connecteur qui permettent de mapper un SR donné à un hôte. Les PBD stockent les champs de configuration des périphériques utilisés pour se connecter et interagir avec une cible de stockage donnée. Par exemple, la configuration de l’appareil NFS inclut l’adresse IP du serveur NFS et le chemin associé que le serveur Citrix Hypervisor monte. Les objets PBD gèrent l’attachement au moment de l’exécution d’un SR donné à un serveur Citrix Hypervisor donné. Les opérations CLI relatives aux PBD sont décrites dans les commandes PBD.
Périphériques en mode bloc virtuels (VBD)
Les Virtual Block Devices sont des objets de connecteur (similaires au PBD décrit ci-dessus) qui permettent les mappages entre les VDI et les VM. En plus de fournir un mécanisme permettant d’associer un VDI à une machine virtuelle, les VBD permettent d’affiner les paramètres concernant la priorité des E/S du disque et les statistiques d’un VDI donné, et de déterminer si ce VDI peut être démarré. Les opérations CLI relatives aux VBD sont décrites dans les commandes VBD.
Récapitulatif des objets de stockage
L’image suivante est un résumé de la manière dont les objets de stockage présentés jusqu’à présent sont liés :
Formats de données des disques virtuels
En général, il existe les types suivants de mappage du stockage physique vers un VDI :
-
Disquedur virtuel basé sur un volume logique sur un LUN : le stockage par blocs Citrix Hypervisor par défaut 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é au SAN sur Fibre Channel, iSCSI ou SAS. Les VDI sont représentés sous forme de volumes dans le gestionnaire de volumes et stockés au format VHD pour permettre le provisionnement fin des nœuds de référence sur le snapshot et le clone.
-
QCOW2 basé sur des fichiers sur un LUN : les images de machine virtuelle sont stockées sous forme de fichiers au format QCOW2 à provisionnement fin sur un système de fichiers à disque partagé GFS2 sur un LUN connecté via un initiateur logiciel iSCSI ou un adaptateur HBA matériel.
-
Disque dur virtuel basé sur des fichiers sur un système de fichiers : les images de machine virtuelle sont stockées en tant que fichiers au format VHD à provisionnement dynamique sur un système de fichiers local non partagé (EXT3/EXT4 type SR), une cible NFS partagée (type NFS SR) ou une cible SMB distante (type SMB SR).
Types VDI
Pour les SRs GFS2, les VDI QCOW2 sont créés.
Pour les autres types de SR, des VDI au format VHD sont créés. Vous pouvez choisir d’utiliser raw au moment de la création du VDI. Cette option ne peut être spécifiée qu’à l’aide de l’interface de ligne de commande xe.
Remarque :
Si vous créez un VDI brut sur un SR basé sur un LVM ou un adaptateur HBA/LUN par VDI SR, cela peut permettre à la machine virtuelle propriétaire d’accéder aux données qui faisaient partie d’un VDI précédemment supprimé (quel que soit son format) appartenant à une machine virtuelle. Nous vous recommandons de prendre en compte vos exigences de sécurité avant d’utiliser cette option.
Les VDI bruts sur un NFS, un EXT ou un SR SMB n’autorisent pas l’accès aux données des VDI précédemment supprimés appartenant à une machine virtuelle.
Pour vérifier si un VDI a été créé avectype=raw, vérifiez sasm-configcarte. Les commandes sr-param-list et vdi-param-list xe 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 fonction de 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--> -
Connectez le nouveau disque virtuel à une machine virtuelle. Utilisez les outils de disque de la machine virtuelle pour partitionner et formater, ou utilisez le nouveau disque. Vous pouvez utiliser la commande
vbd-createpour créer un VBD pour mapper le disque virtuel dans votre machine virtuelle.
Conversion entre les formats VDI
Il n’est pas possible d’effectuer une conversion directe entre le format brut et le format VHD. Au lieu de cela, vous pouvez créer un VDI (brut, comme décrit ci-dessus, ou 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 égale à celle du VDI à partir duquel vous copiez. Vous pouvez le faire en vérifiant son champ virtual-size, par exemple à l’aide de la commande vdi-param-list. Vous pouvez ensuite attacher ce nouveau VDI à une machine virtuelle et utiliser votre outil préféré au sein de la machine virtuelle pour effectuer une copie en bloc directe des données. Par exemple, les outils de gestion de disque standard dans Windows ou la commande dd sous Linux. Si le nouveau volume est un volume VHD, utilisez un outil qui évitera d’écrire des secteurs vides sur le disque. Cette action peut garantir une utilisation optimale de l’espace dans le référentiel de stockage sous-jacent. Une approche de copie basée sur des fichiers peut être plus appropriée.
VDI basés sur VHD et QCow2
Les images VHD et QCOW2 peuvent être chaînées, ce qui permet à deux VDI de partager des données communes. Dans les cas où une machine virtuelle basée sur VHD ou basée sur QCow2 est clonée, les machines virtuelles résultantes partagent les données sur disque communes au moment du clonage. Chaque machine virtuelle procède à ses propres modifications dans une version isolée de copie sur écriture du VDI. Cette fonctionnalité permet de cloner rapidement ces machines virtuelles à partir de modèles, ce qui facilite le provisionnement et le déploiement très rapides de nouvelles machines virtuelles.
Au fur et à mesure que les VM et leurs VDI associés sont clonés au fil du temps, cela crée des arborescences de VDI chaînés. Lorsque l’un des VDI d’une chaîne est supprimé, Citrix Hypervisor 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é et le temps nécessaire à l’exécution du processus dépendent de la taille du VDI et de la quantité de données partagées.
Les formats VHD et QCOW2 prennent en charge le Thin Provisioning. Le fichier image est automatiquement étendu en petits morceaux granulaires lorsque la machine virtuelle écrit des données sur le disque. Pour le disque dur virtuel basé sur fichiers et le QCOW2 basé sur GFS2, cette approche présente l’avantage considérable que les fichiers d’image de machine virtuelle occupent uniquement autant d’espace que nécessaire sur le stockage physique. Avec un disque dur virtuel basé sur LVM, le conteneur de volume logique sous-jacent doit être dimensionné à la taille virtuelle du VDI. Toutefois, l’espace inutilisé sur le disque d’instance de copie sur écriture sous-jacent est récupéré lors d’un snapshot ou d’un clone. 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 différents au sein de la chaîne consomment uniquement autant de données que celles qui ont été écrites sur le disque. Toutefois, les nœuds terminaux (clones VDI) restent complètement gonflés à la taille virtuelle du disque. Les nœuds terminaux de snapshots (snapshots VDI) restent condensés lorsqu’ils ne sont pas utilisés et peuvent être attachés en lecture seule pour préserver l’allocation condensée. Les nœuds d’instantané attachés en lecture-écriture sont complètement gonflés lors de l’attachement et dégonflés lors du détachement.
-
Pour les disques durs virtuels 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 du nœud feuille augmentent pour s’adapter aux données au fur et à mesure qu’elles sont écrites activement. Si un VDI de 100 Go est alloué à une machine virtuelle et qu’un système d’exploitation est installé, le fichier VDI correspond physiquement uniquement à la taille des données du système d’exploitation sur le disque, plus une surcharge mineure de métadonnées.
Lors du clonage de machines virtuelles basées sur un seul VHD ou un modèle QCOW2, chaque machine virtuelle enfant forme une chaîne dans laquelle les nouvelles modifications sont écrites sur la nouvelle machine virtuelle. Les anciens blocs sont directement lus à partir du modèle parent. Si la nouvelle machine virtuelle a été convertie en un autre modèle et que d’autres machines virtuelles ont été clonées, la chaîne résultante entraîne une dégradation des performances. Citrix Hypervisor prend en charge une longueur de chaîne maximale de 30. Ne vous approchez pas de cette limite sans raison valable. En cas de doute, « copiez » la machine virtuelle à l’aide de XenCenter ou utilisez la commande vm-copy, qui réinitialise la longueur de la chaîne à 0.
Remarques spécifiques au VHD sur la fusion
Un seul processus de coalescence est actif pour un SR. Ce thread de processus s’exécute sur l’hôte maître SR.
Si vous avez des machines virtuelles critiques en cours d’exécution sur le serveur maître du pool, vous pouvez prendre les mesures suivantes pour atténuer les ralentissements occasionnels des E/S :
-
Migrer la machine virtuelle vers un hôte autre que le maître SR
-
Définissez la priorité des E/S du disque à un niveau supérieur et ajustez le planificateur. Pour plus d’informations, consultez la section Priorisation des demandes d’E/S sur disque virtuel.