Citrix Hypervisor

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 options de configuration de périphérique spécifiques à un type
  • Générer des instantanés à des fins de sauvegarde
  • Meilleures pratiques de gestion du stockage
  • Paramètres QoS (Quality of Service) du disque virtuel

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 pour 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 provisionnementfin, les instantanés VDI et le clonage rapide. Pour les sous-systèmes de stockage qui ne prennent pas en charge directement 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 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 SR qui utilisent un périphérique de bloc sous-jacent, le processus de création d’une SR implique l’effacement des 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 commun 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 seul 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 sur disque des données diffère selon le type 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 blocs physiques (PBD)

Les périphériques de blocs 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 périphérique utilisés pour se connecter à une cible de stockage donnée et interagir avec elle. Par exemple, la configuration de périphérique NFS inclut l’adresse IP du serveur NFS et le chemin d’accès 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 virtuels (VBD)

Virtual Block Devices sont des objets de connecteur (similaire au PBD décrit ci-dessus) qui permettent les mappages entre les VDI et les machines virtuelles. En plus de fournir un mécanisme pour attacher un VDI à une machine virtuelle, les VBD permettent d’affiner les paramètres relatifs à la QoS (qualité de service) et aux statistiques d’un VDI donné, et de savoir si ce VDI peut être démarré. Les opérations CLI relatives aux VBD sont décrites dans les 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 :

Présentation graphique des référentiels de stockage et des objets associés

Formats de données de disque virtuel

En général, il existe les types suivants de mappage de stockage physique vers un VDI :

  1. 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 la 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 les snapshots et les clones.

  2. 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.

  3. 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 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

  1. 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-->
    
  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 la commande vbd-create pour créer un VBD pour mapper le disque virtuel dans votre machine virtuelle.

Convertir entre les formats VDI

Il n’est pas possible de faire une conversion directe entre les formats bruts et 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 aussi grande que celle du VDI à partir de laquelle vous copiez. Vous pouvez le faire en cochant son champ virtual-size, par exemple en utilisant 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 de blocage 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 peut é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 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 de copie sur écriture isolée du VDI. Cette fonctionnalité permet de cloner rapidement de telles machines virtuelles à partir de modèles, ce qui facilite le provisionnement et le déploiement très rapides de nouvelles machines virtuelles.

Lorsque les machines virtuelles et leurs VDI associés sont clonés au fil du temps, cela crée des arborescences de VDI enchaî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 provisionnementléger. Le fichier image est automatiquement étendu en morceaux granulaires fins lorsque la machine virtuelle écrit des données dans 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 image de machine virtuelle occupent seulement autant d’espace sur le stockage physique que nécessaire. 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 snapshot ou un clone se produit. 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 consomment uniquement autant de données que ce qui a été écrit sur le disque. Toutefois, les nœuds feuilles (clones VDI) restent complètement gonflés à la taille virtuelle du disque. Les nœuds feuille d’instantané (snapshots 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 lecture-écriture sont complètement gonflés lors de l’attachement et dégonflés lors du détachement.

  • Pour les VHDs basés sur des fichiers et les**images QCOW2 basées sur GFS2 , tous les nœuds consomment uniquement autant de données qu’il a été écrit. 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, ainsi qu’à quelques frais de métadonnées mineurs.

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ù de 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. N’approchez pas 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.

Notes spécifiques au VHD sur le coalesce

Un seul processus de coalescence est toujours actif pour une SR. Ce thread de processus s’exécute sur l’hôte maître SR.

Si des machines virtuelles critiques sont exécutées 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é des E/S du disque à un niveau supérieur et ajustez le planificateur. Pour plus d’informations, consultez Paramètres QoS de disque virtuel.

Stockage