Stockage

Important :

La mise à jour cumulative 1 de Citrix Hypervisor 8.2 prend fin le 25 juin 2025. Planifiez votre mise à niveau vers XenServer 8 dès maintenant pour assurer une transition en douceur et un support continu. Pour plus d’informations, consultez Mise à niveau.

Si vous utilisez vos fichiers de licence Citrix Virtual Apps and Desktops pour obtenir une licence pour vos hôtes Citrix Hypervisor 8.2 Cumulative Update 1, ces fichiers de licence ne sont pas compatibles avec XenServer 8. Avant la mise à niveau, vous devez acquérir les fichiers de licence socket XenServer Premium Edition à utiliser avec XenServer 8. Ces fichiers de licence de socket sont disponibles en tant que droits des abonnements Citrix pour le cloud privé, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP et Citrix Platform License pour l’exécution de vos charges de travail Citrix. Les clients Citrix qui n’ont pas encore migré vers ces nouveaux abonnements peuvent demander à participer à une promotion gratuite pour 10 000 licences de sockets XenServer Premium Edition. Pour plus d’informations, consultez XenServer.

Si vous n’obtenez pas de licence compatible pour XenServer 8 avant la mise à niveau, lorsque vous mettez à niveau vos hôtes, ils reviennent à l’édition d’essai de 90 jours. L’édition d’essai offre les mêmes fonctionnalités que l’édition Premium, avec quelques limitations. Pour plus d’informations, consultez Présentation des licences XenServer 8.

Cette section décrit comment le matériel de stockage physique est mappé aux machines virtuelles et aux objets logiciels utilisés par l’API de gestion pour effectuer des tâches liées au stockage. Les informations suivantes sont détaillées sur chacun des types de stockage pris en charge :

• 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 de périphérique spécifiques au type
• Génération d’instantanés à des fins de sauvegarde
• Bonnes 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, avec une prise en charge intégrée des disques suivants :

Connexion locale :

• SATA
• SCSI
• SAS
• NVMe

Le matériel de stockage physique local peut être un disque dur (HDD) ou un disque SSD (Solid State Drive).

Connecté à distance :

• 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 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 Provisionnement dynamique, des snapshots VDI et un 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. Cette pile logicielle est basée sur la spécification Virtual Hard Disk (VHD) de Microsoft.

Un référentiel de stockage est une structure de données persistante sur disque. Pour les types 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 serveur Citrix Hypervisor peut utiliser plusieurs SR et différents types de SR simultanément. Ces SR peuvent être partagés entre hôtes ou dédiés à des hôtes particuliers. Le stockage partagé est regroupé entre plusieurs hôtes au sein d’un pool de ressources défini. Un SR partagé doit être accessible au réseau à chaque hôte du pool. Tous les serveurs d’un seul pool de ressources doivent avoir au moins un SR partagé 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 individuelles qu’elles contiennent. Les opérations CLI de gestion des référentiels de stockage sont décrites dans la section Commandes SR.

Avertissement :

Citrix Hypervisor ne prend pas en charge les snapshots au niveau SAN externe d’un LUN pour tout 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 de gestion des VDI sont décrites dans la section Commandes VDI. La représentation des données sur disque 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 physique (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 de connecteur qui permettent de mapper un SR donné à un hôte. Les PBD stockent les champs de configuration de l’appareil utilisés pour se connecter et interagir avec une cible de stockage donnée. Par exemple, la configuration du périphérique NFS inclut l’adresse IP du serveur NFS et le chemin d’accès associé monté par le serveur Citrix Hypervisor. 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 Commandes PBD.

Périphériques de bloc virtuel (VBD)

Les périphériques de bloc virtuel sont des objets de connecteur (similaires au PBD décrit ci-dessus) qui permettent les mappages entre les VDI et les machines virtuelles. En plus de fournir un mécanisme permettant d’attacher un VDI à une machine virtuelle, les VBD permettent d’affiner les paramètres concernant la priorité d’E/S du disque et les statistiques 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.

Résumé des objets de stockage

L’image suivante est un résumé de la façon dont les objets de stockage présentés jusqu’à présent sont liés :

Formats de données de disque virtuel

En général, il existe les types suivants de mappage du stockage physique à une VDI :

1. VHD logique basé sur un volume sur une LUN : Le stockage par bloc Citrix Hypervisor par défaut insère un gestionnaire de volumes logiques sur un disque. Il s’agit d’un périphérique LVM (locally Attached Device) ou d’un LUN connecté à un SAN via Fibre Channel, iSCSI ou SAS. Les VDI sont représentées sous forme de volumes dans le gestionnaire de volumes et stockées au format VHD pour permettre le provisionnement dynamique des nœuds de référence sur l’instantané et le clone.

2. QCOW2 basé sur un fichier sur un LUN : Les images de machine virtuelle sont stockées sous forme de fichiers au format QCOW2 alloués de manière dynamique sur un système de fichiers de disque partagé GFS2 sur un LUN connecté via un initiateur logiciel iSCSI ou un adaptateur HBA matériel.

3. VHD basé sur un fichier sur un système de fichiers : Les images de machine virtuelle sont stockées sous forme de fichiers au format VHD alloués de manière dynamique sur un système de fichiers local non partagé (EXT3/EXT4 de type SR), une cible NFS partagée (NFS de type SR) ou une cible SMB distante (SMB de type SR).

Types de VDI

Pour les SR GFS2, des VDI QCOW2 sont créées.

Pour les autres types de SR, des VDI au format VHD sont créées. Vous pouvez choisir d’utiliser raw au moment de la création de la 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 une VDI brute sur une SR basée sur LVM ou une SR HBA/LUN par VDI, cela peut permettre à la VM propriétaire d’accéder aux données qui faisaient partie d’une VDI précédemment supprimée (de n’importe quel format) appartenant à n’importe quelle VM. Nous vous recommandons de prendre en compte vos exigences en matière de sécurité avant d’utiliser cette option.

Les VDI brutes sur un SR NFS, EXT ou SMB n’autorisent pas l’accès aux données des VDI précédemment supprimées appartenant à une machine virtuelle.

Pour vérifier si un VDI a été créé avec type=brut, vérifiez son sm-config carte. Le sr-param-list et vdi-param-list Les commandes xe peuvent être utilisées respectivement à cet effet.

Création d’un disque virtuel brut à l’aide de l’interface de ligne de commande xe

1. Exécutez la commande suivante pour créer un VDI à partir 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-->
   

2. Attachez 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 l’icône vbd-créer pour créer un VBD afin de mapper le disque virtuel dans votre machine virtuelle.

Conversion entre les formats VDI

Il n’est pas possible d’effectuer une conversion directe entre les formats raw et VHD. Au lieu de cela, vous pouvez créer une VDI (brute, 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 la nouvelle VDI a une taille virtuelle au moins aussi grande que la VDI à partir de laquelle vous copiez. Vous pouvez le faire en vérifiant son taille-virtuelle champ, par exemple en utilisant le vdi-param-list commander. Vous pouvez ensuite attacher cette nouvelle VDI à une machine virtuelle et utiliser l’outil de votre choix au sein de la machine virtuelle pour effectuer une copie directe des données. Par exemple, les outils de gestion de disques standard de Windows ou de l’ Dd sous Linux. Si le nouveau volume est un volume VHD, utilisez un outil qui permet d’éviter d’écrire des secteurs vides sur le disque. Cette action permet de s’assurer 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 des fichiers peut être plus appropriée.

VDI basées sur VHD et QCOW2

Les images VHD et QCOW2 peuvent être enchaîné, ce qui permet à deux VDI de partager des données communes. Dans les cas où une machine virtuelle basée sur un disque dur virtuel ou QCOW2 est clonée, les machines virtuelles résultantes partagent les données communes sur disque au moment du clonage. Chaque machine virtuelle procède à ses propres modifications dans une version isolée de copie sur écriture de la 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.

À mesure que les machines virtuelles et leurs VDI associés sont clonés au fil du temps, cela crée des arborescences de VDI chaînées. Lorsque l’une des VDI d’une chaîne est supprimée, Citrix Hypervisor rationalise les autres VDI de la chaîne pour supprimer les VDI inutiles. Ceci Coalescent Le processus s’exécute de manière asynchrone. La quantité d’espace disque récupérée et le temps nécessaire à l’exécution du processus dépendent de la taille de la VDI et de la quantité de données partagées.

Les formats VHD et QCOW2 prennent en charge Provisionnement dynamique. Le fichier image est automatiquement étendu en blocs granulaires fins à mesure que la machine virtuelle écrit des données sur le disque. Pour le VHD basé sur des fichiers et le QCOW2 basé sur GFS2, cette approche présente l’avantage considérable que les fichiers d’image de machine virtuelle n’occupent que l’espace nécessaire sur le stockage physique. Avec le VHD 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é lorsqu’un instantané ou un clone se produit. La différence entre les deux comportements peut être décrite de la manière suivante :

• Pour Images VHD basées sur LVM, les différents nœuds de disque au sein de la chaîne consomment uniquement la quantité de données écrites sur le disque. Cependant, les nœuds terminaux (clones VDI) restent entièrement gonflés à la taille virtuelle du disque. Les nœuds terminaux 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 conserver l’allocation déflatée. Les nœuds d’instantané qui sont attachés en lecture-écriture sont entièrement gonflés lors de l’attachement et dégonflés lors du détachement.

• Pour disques durs virtuels basés sur des fichiers et Images QCOW2 basées sur GFS2, tous les nœuds ne consomment que la quantité de données écrites. Les fichiers de nœud terminal s’agrandissent 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 ne correspond physiquement qu’à la taille des données du système d’exploitation sur le disque, plus une légère surcharge de métadonnées.

Lors du clonage de machines virtuelles basées sur un seul modèle VHD ou QCOW2, chaque machine virtuelle enfant forme une chaîne où les nouvelles modifications sont écrites sur la nouvelle machine virtuelle. Les anciens blocs sont lus directement à 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 personnes. Ne vous approchez pas de cette limite sans raison valable. En cas de doute, « copiez » la VM à l’aide de XenCenter ou utilisez le vm-copie , qui réinitialise la longueur de la chaîne à 0.

Notes spécifiques au VHD sur la coalescence

Un seul processus de coalescence est actif pour une 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 E/S lentes occasionnelles :

• Migrer la machine virtuelle vers un hôte autre que le maître SR

• Définissez la priorité d’E/S du disque à un niveau supérieur et ajustez le planificateur. Pour plus d’informations, consultez Hiérarchisation des demandes d’E/S de disque virtuel.