Création d’un référentiel de stockage

Vous pouvez utiliser l’icône Nouveau référentiel de stockage dans XenCenter pour créer des référentiels de stockage (SR). L’assistant vous guide tout au long des étapes de configuration. Vous pouvez également utiliser l’interface de ligne de commande et le sr-création commander. Le sr-création crée une SR sur le substrat de stockage (détruisant potentiellement toutes les données existantes). Il crée également l’objet API SR et un enregistrement PBD correspondant, ce qui permet aux machines virtuelles d’utiliser le stockage. Lors de la création réussie du SR, le PBD est automatiquement branché. Si l’indicateur SR shared=true est défini, un enregistrement PBD est créé et connecté pour chaque XenServer dans le pool de ressources.

Si vous créez une SR pour le stockage IP (iSCSI ou NFS), vous pouvez configurer l’un des éléments suivants en tant que réseau de stockage : la carte réseau qui gère le trafic de gestion ou une nouvelle carte réseau pour le trafic de stockage. Pour attribuer une adresse IP à une carte réseau, voir Configurer une carte réseau de stockage dédiée.

Tous les types XenServer SR prennent en charge le redimensionnement VDI, le clonage rapide et la capture instantanée. Les SR basés sur le type SR LVM (local, iSCSI ou HBA) fournissent un provisionnement léger pour les nœuds parents instantanés et masqués, mais pas pour d’autres disques, tels que les disques delta par VM MCS. Les autres types de SR (EXT3/EXT4, NFS, GFS2) prennent en charge le provisionnement dynamique complet, y compris pour les disques virtuels actifs.

Avertissements :

• Lorsque les VDI VHD ne sont pas attachées à une machine virtuelle, par exemple pour un instantané VDI, elles sont stockées par défaut en tant que provisionnement dynamique. Si vous tentez de rattacher le VDI, assurez-vous qu’il y a suffisamment d’espace disque disponible pour que le VDI soit provisionné de manière dense. Les clones VDI sont provisionnés de manière dense.

• XenServer ne prend pas en charge les snapshots au niveau SAN externe d’un LUN pour aucun type de SR.

• N’essayez pas de créer un SR si l’ID de LUN du LUN de destination est supérieur à 255. Assurez-vous que votre cible expose le LUN avec un ID de LUN inférieur ou égal à 255 avant d’utiliser ce LUN pour créer un SR.

• Si vous utilisez le provisionnement dynamique sur une SR basée sur des fichiers, assurez-vous de surveiller l’espace libre sur votre SR. Si l’utilisation de SR passe à 100 %, les écritures ultérieures à partir de machines virtuelles échouent. Ces écritures échouées peuvent entraîner le blocage ou le blocage de la machine virtuelle.

Les tailles VDI maximales prises en charge sont les suivantes :

Local LVM

Le type LVM local présente les disques au sein d’un groupe de volumes attaché localement. Nous vous recommandons de n’attacher qu’un seul SR local par hôte.

Par défaut, XenServer utilise le disque local sur l’hôte physique sur lequel il est installé. Le gestionnaire de volumes logiques Linux (LVM) est utilisé pour gérer le stockage des machines virtuelles. Une VDI est implémentée au format VHD dans un volume logique LVM de la taille spécifiée.

Remarque :

La taille de bloc d’un LUN LVM doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).

Considérations relatives aux performances de LVM

La fonctionnalité d’instantané et de clonage rapide pour les SR basés sur LVM s’accompagne d’une surcharge de performance inhérente. Lorsque des performances optimales sont requises, XenServer prend en charge la création de VDI au format brut ** en plus du format VHD par défaut. La fonctionnalité de snapshot XenServer n’est pas prise en charge sur les VDI bruts.

Avertissement :

N’essayez pas de capturer une machine virtuelle qui a type=brut disques attachés. Cette action peut entraîner la création d’un instantané partiel. Dans ce cas, vous pouvez identifier les VDI de snapshot orphelines en cochant le instantané de puis de les supprimer.

Création d’une SR LVM locale

Un LVM SR est créé par défaut lors de l’installation de l’hôte.

Les paramètres de configuration de périphérique pour les SR LVM sont les suivants :

Pour créer un SR LVM local sur /dev/disk/<id>, utilisez la commande suivante.

      xe sr-create host-uuid=valid_uuid content-type=user \
      name-label="Example Local LVM SR" shared=false \
      device-config:device=/dev/disk/<id> type=lvm
<!--NeedCopy-->

Sections locales EXT3/EXT4

L’utilisation d’EXT3/EXT4 permet le provisionnement dynamique sur le stockage local. Toutefois, le type de référentiel de stockage par défaut est LVM car il offre des performances d’écriture constantes et empêche la surcharge de stockage. Si vous utilisez EXT3/EXT4, vous pouvez constater une réduction des performances dans les cas suivants :

• Lors de l’exécution d’opérations de cycle de vie de machine virtuelle, telles que la création de machine virtuelle et la suspension/reprise
• Lors de la création de fichiers volumineux à partir de la machine virtuelle

Les SR EXT3/EXT4 du disque local doivent être configurés à l’aide de l’interface de ligne de commande XenServer.

Le fait qu’un EXT SR local utilise EXT3 ou EXT4 dépend de la version de XenServer qui l’a créé :

• Si vous avez créé le SR EXT local sur une version antérieure de Citrix Hypervisor ou XenServer, puis effectué une mise à niveau vers XenServer 8.4, il utilise EXT3.
• Si vous avez créé le SR EXT local sur XenServer 8.4, il utilise EXT4.

Remarque :

La taille de bloc d’un disque EXT3/EXT4 doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).

La création d’un EXT4 SR local (Poste)

Paramètres de configuration de l’appareil pour les SR EXT :

Pour créer un SR EXT4 local sur /dev/disk/<id>, utilisez la commande suivante :

      xe sr-create host-uuid=valid_uuid content-type=user \
         name-label="Example Local EXT4 SR" shared=false \
         device-config:device=/dev/disk/<id> type=ext
<!--NeedCopy-->

Local XFS

L’utilisation de XFS permet un provisionnement léger sur le stockage local. Le type XFS local vous permet de créer des périphériques de stockage locaux avec des blocs physiques de 4 Ko sans nécessiter une taille de bloc logique de 512 octets.

Contraintes

Les SR XFS ont les contraintes suivantes :

• La migration en direct du stockage ne peut pas être utilisée sur les machines virtuelles dont les VDI se trouvent sur un SR XFS.

• Intellicache n’est pas pris en charge pour les machines virtuelles utilisant un SR XFS.

• Le transport FCoE logiciel n’est pas pris en charge avec les SR XFS (pour un FCoE entièrement déchargé, utilisez HBA).

• Le découpage/démapper n’est pas pris en charge sur les SR XFS.

• Vous ne pouvez pas exporter des VDI de plus de 2 Tio au format VHD ou OVA/OVF. Toutefois, vous pouvez exporter des machines virtuelles avec des VDI supérieures à 2 Tio au format XVA.

Création d’un SR XFS local

Paramètres de configuration de périphérique pour les SR XFS :

Pour créer un SR XFS local sur /dev/disk/<id>, utilisez la commande suivante :

      xe sr-create host-uuid=valid_uuid content-type=user \
         name-label="Example Local XFS SR" shared=false \
         device-config:device=/dev/disk/<id> type=xfs
<!--NeedCopy-->

udev

Le type udev représente les périphériques branchés à l’aide du gestionnaire de périphériques udev en tant que VDI.

XenServer dispose de deux SR de type udev qui représentent un stockage amovible. L’un est destiné au disque CD ou DVD dans le lecteur de CD ou de DVD-ROM physique de l’hôte XenServer. L’autre est destiné à un périphérique USB branché sur un port USB de l’hôte XenServer. Les VDI qui représentent le support vont et viennent au fur et à mesure que les disques ou les clés USB sont insérés et retirés.

ISO

Le type ISO gère les images de CD stockées sous forme de fichiers au format ISO. Ce type de SR est utile pour créer des bibliothèques ISO partagées.

Les types ISO SR suivants sont disponibles :

• nfs_iso: Le type NFS ISO SR gère les images de CD stockées sous forme de fichiers au format ISO disponibles en partage NFS.
• CIFS: Le type Windows File Sharing (SMB/CIFS) SR gère les images CD stockées sous forme de fichiers au format ISO disponibles en partage Windows (SMB/CIFS).

Si vous ne spécifiez pas le type de stockage à utiliser pour le SR, XenServer utilise le paramètre de configuration de périphérique location pour décider du type.

Paramètres de configuration de l’appareil pour les SR ISO :

Remarque :

Lors de l’exécution de la commande sr-création , nous vous recommandons d’utiliser la commande config_appareil :cifspassword_secret au lieu de spécifier le mot de passe sur la ligne de commande. Pour plus d’informations, consultez Secrets.

Pour les référentiels de stockage qui stockent une bibliothèque d’ISO, la commande type_contenu doit être défini sur ISOpar exemple:

      xe sr-create host-uuid=valid_uuid content-type=iso  type=iso name-label="Example ISO SR" \
        device-config:location=<path_to_mount> device-config:type=nfs_iso
<!--NeedCopy-->

Vous pouvez utiliser NFS ou SMB pour monter l’ISO SR. Pour plus d’informations sur l’utilisation de ces types de SR, consultez NFS et SMB.

Nous vous recommandons d’utiliser SMB version 3 pour monter ISO SR sur le serveur de fichiers Windows. La version 3 est sélectionnée par défaut, car elle est plus sécurisée et plus robuste que la version 1.0 de SMB. Toutefois, vous pouvez monter ISO SR à l’aide de SMB version 1 à l’aide de la commande suivante :

       xe sr-create content-type=iso type=iso shared=true device-config:location=<path_to_mount>
       device-config:username=<username> device-config:cifspassword=<password> \
       device-config:type=cifs device-config:vers=1.0 name-label="Example ISO SR"
<!--NeedCopy-->

Prise en charge logicielle iSCSI

XenServer prend en charge les SR partagés sur les LUN iSCSI. iSCSI est pris en charge à l’aide de l’initiateur iSCSI du logiciel Open-iSCSI ou d’un adaptateur de bus hôte (HBA) iSCSI pris en charge. Les étapes d’utilisation des adaptateurs HBA iSCSI sont identiques à celles des adaptateurs HBA Fibre Channel. Les deux séries d’étapes sont décrites dans Créer un LVM partagé sur Fibre Channel / Fibre Channel sur Ethernet / iSCSI HBA ou SAS SR.

La prise en charge partagée d’iSCSI à l’aide de l’initiateur logiciel iSCSI est mise en œuvre sur la base du gestionnaire de volumes Linux (LVM). Cette fonctionnalité offre les mêmes avantages en termes de performances que les VDI LVM dans le cas du disque local. Les SR iSCSI partagés utilisant l’initiateur d’hôte basé sur un logiciel peuvent prendre en charge l’agilité des machines virtuelles à l’aide de la migration en direct : les machines virtuelles peuvent être démarrées sur n’importe quel hôte XenServer dans un pool de ressources et migrées entre elles sans temps d’arrêt notable.

Les SR iSCSI utilisent l’intégralité de la LUN spécifiée au moment de la création et ne peuvent pas s’étendre sur plus d’une LUN. La prise en charge CHAP est fournie pour l’authentification du client, à la fois lors de l’initialisation du chemin d’accès aux données et des phases de découverte des LUN.

Remarque :

La taille de bloc d’un LUN iSCSI doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).

Configuration iSCSI de l’hôte XenServer

Tous les initiateurs et cibles iSCSI doivent avoir un nom unique pour garantir leur identification unique sur le réseau. Un initiateur a une adresse d’initiateur iSCSI et une cible a une adresse cible iSCSI. Collectivement, ces noms sont appelés noms qualifiés iSCSI, ou IQN.

Les hôtes XenServer prennent en charge un seul initiateur iSCSI qui est automatiquement créé et configuré avec un IQN aléatoire lors de l’installation de l’hôte. L’initiateur unique peut être utilisé pour se connecter simultanément à plusieurs cibles iSCSI.

Les cibles iSCSI fournissent généralement un contrôle d’accès à l’aide de listes IQN d’initiateur iSCSI. Toutes les cibles/LUN iSCSI auxquelles votre hôte XenServer accède doivent être configurées pour autoriser l’accès par l’IQN initiateur de l’hôte. De même, les cibles/LUN à utiliser en tant que SR iSCSI partagés doivent être configurés pour autoriser l’accès à tous les IQN de l’hôte dans le pool de ressources.

Remarque :

Les cibles iSCSI qui ne fournissent pas de contrôle d’accès limitent généralement par défaut l’accès des LUN à un seul initiateur pour garantir l’intégrité des données. Si un LUN iSCSI est utilisé comme SR partagé sur plusieurs hôtes d’un pool, assurez-vous que l’accès multi-initiateur est activé pour le LUN spécifié.

La valeur IQN de l’hôte XenServer peut être ajustée à l’aide de XenCenter ou à l’aide de la CLI avec la commande suivante lors de l’utilisation de l’initiateur logiciel iSCSI :

      xe host-param-set uuid=valid_host_id other-config:iscsi_iqn=new_initiator_iqn
<!--NeedCopy-->

Avertissement :

• Chaque cible et initiateur iSCSI doit avoir un IQN unique. Si un identifiant IQN non unique est utilisé, l’altération des données ou le refus d’accès aux LUN peuvent se produire.
• Ne modifiez pas l’IQN de l’hôte XenServer avec des SR iSCSI connectés. Cela peut entraîner des échecs de connexion à de nouvelles cibles ou à des SR existants.

Stockage FCoE logiciel (obsolète)

Le FCoE logiciel fournit un cadre standard auquel les fournisseurs de matériel peuvent connecter leur carte réseau compatible FCoE et bénéficier des mêmes avantages qu’une FCoE matérielle. Cette fonctionnalité élimine le besoin d’utiliser des adaptateurs HBA coûteux.

Remarque :

Le logiciel FCoE est obsolète et sera supprimé dans une version ultérieure.

Avant de créer un stockage FCoE logiciel, effectuez manuellement la configuration requise pour exposer un LUN à l’hôte. Cette configuration inclut la configuration de la structure FCoE et l’attribution de LUN au nom public mondial (PWWN) de votre SAN. Une fois cette configuration terminée, le LUN disponible est monté sur le CNA de l’hôte en tant que périphérique SCSI. Le périphérique SCSI peut ensuite être utilisé pour accéder au LUN comme s’il s’agissait d’un périphérique SCSI attaché localement. Pour plus d’informations sur la configuration du commutateur physique et de la matrice pour la prise en charge de FCoE, reportez-vous à la documentation fournie par le fournisseur.

Remarque :

Le logiciel FCoE peut être utilisé avec Open vSwitch et le pont Linux en tant que back-end réseau.

Création d’un logiciel FCoE SR

Avant de créer une carte réseau FCoE logicielle, les clients doivent s’assurer que des cartes réseau compatibles FCoE sont attachées à l’hôte.

Les paramètres de configuration de périphérique pour les SR FCoE sont les suivants :

Exécutez la commande suivante pour créer un SR FCoE partagé :

      xe sr-create type=lvmofcoe \
      name-label="FCoE SR" shared=true device-config:SCSIid=SCSI_id
<!--NeedCopy-->

Adaptateurs de bus hôte (HBA) matériels

Cette section couvre les différentes opérations requises pour gérer les adaptateurs HBA SAS, Fibre Channel et iSCSI.

Outils de configuration tiers

Les versions précédentes de Citrix Hypervisor et XenServer incluaient des outils tiers pour gérer le stockage HBA matériel. Ces outils ne sont plus inclus, mais peuvent être téléchargés à partir du site Web du fournisseur de matériel. Pour plus d’informations, voir Modifications apportées aux composants tiers.

Suppression des entrées de périphérique SAS, FC ou iSCSI basées sur un adaptateur HBA

Remarque :

Cette étape n’est pas obligatoire. Nous recommandons que seuls les utilisateurs expérimentés effectuent ce processus si nécessaire.

Chaque LUN basé sur un adaptateur HBA a une entrée de chemin d’appareil globale correspondante sous /dev/disque/par-scsibus dans le format <SCSIid>-<adapter>:<bus>:<target>:<lun> et un chemin d’accès de périphérique standard sous /Dev. Pour supprimer les entrées de périphérique des LUN qui ne sont plus utilisées en tant que SR, procédez comme suit :

1. Utilisez sr-forget ou sr-destroy selon le cas pour supprimer le SR de la base de données de l’hôte XenServer. Voir Supprimer les SR pour plus de détails.

2. Supprimez la configuration de zonage au sein du SAN pour le LUN souhaité vers l’hôte souhaité.

3. Utilisez le Sonde SR pour déterminer les valeurs ADAPTER, BUS, TARGET et LUN correspondant au LUN à retirer. Pour plus d’informations, Sondez un SR.

4. Supprimez les entrées de l’appareil à l’aide de la commande suivante :

     echo "1" > /sys/class/scsi_device/adapter:bus:target:lun/device/delete
   <!--NeedCopy-->
   

Avertissement :

Assurez-vous d’être certain du LUN que vous retirez. La suppression accidentelle d’un LUN requis pour le fonctionnement de l’hôte, tel que le périphérique de démarrage ou le périphérique racine, rend l’hôte inutilisable.

Stockage LVM partagé

Le type LVM partagé représente les disques en tant que volumes logiques au sein d’un groupe de volumes créé sur un LUN iSCSI (FC ou SAS).

Remarque :

La taille de bloc d’un LUN iSCSI doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).

Créez un LVM partagé sur iSCSI SR à l’aide de l’initiateur logiciel iSCSI

Paramètres de configuration de périphérique pour les SR LVMoiSCSI :

Remarque :

Lors de l’exécution de la commande sr-création , nous vous recommandons d’utiliser la commande configuration_appareil :chappassword_secret au lieu de spécifier le mot de passe sur la ligne de commande. Pour plus d’informations, consultez Secrets.

Pour créer un SR LVMoiSCSI partagé sur un LUN spécifique d’une cible iSCSI, utilisez la commande suivante.

      xe sr-create host-uuid=valid_uuid content-type=user \
      name-label="Example shared LVM over iSCSI SR" shared=true \
      device-config:target=target_ip= device-config:targetIQN=target_iqn= \
      device-config:SCSIid=scsci_id \
      type=lvmoiscsi
<!--NeedCopy-->

Création d’un adaptateur HBA LVM sur Fibre Channel / Fibre Channel sur Ethernet / iSCSI ou SAS SR partagé

Les SR de type LVMoHBA peuvent être créés et gérés à l’aide de l’interface de ligne de commande xe ou de XenCenter.

Paramètres de configuration de périphérique pour les SR LVMoHBA :

Pour créer un SR LVMoHBA partagé, effectuez les étapes suivantes sur chaque hôte du pool :

1. Zonez un ou plusieurs LUN sur chaque hôte XenServer du pool. Ce processus est très spécifique à l’équipement SAN utilisé. Pour plus d’informations, reportez-vous à la documentation de votre SAN.

2. Si nécessaire, configurez le HBA à l’aide d’outils tiers dans le BIOS ou le micrologiciel.

   • Pour plus d’informations sur la configuration des HBA QLogic Fibre Channel et iSCSI, consultez le site Web Marvell .
   • Pour plus d’informations sur la configuration des HBA Emulex Fibre Channel, consultez le site Web Broadcom .

3. Utilisez le Sonde SR pour déterminer le chemin d’accès global du LUN HBA. Le Sonde SR force une nouvelle analyse des adaptateurs HBA installés dans le système pour détecter les nouvelles LUN qui ont été zonées sur l’hôte. La commande renvoie une liste de propriétés pour chaque LUN trouvé. Spécifiez l’icône hôte-uuid pour s’assurer que la sonde se produit sur l’hôte souhaité.

   Le chemin d’accès global de l’appareil renvoyé sous la forme <path> est commune à tous les hôtes du pool. Par conséquent, ce chemin doit être utilisé comme valeur pour la valeur device-config :appareil lors de la création du SR.

   Si plusieurs LUN sont présents, utilisez le fournisseur, la taille du LUN, le numéro de série du LUN ou l’ID SCSI du <path> pour identifier la LUN souhaitée.

         xe sr-probe type=lvmohba \
         host-uuid=1212c7b3-f333-4a8d-a6fb-80c5b79b5b31
         Error code: SR_BACKEND_FAILURE_90
         Error parameters: , The request is missing the device parameter, \
         <?xml version="1.0" ?>
         <Devlist>
             <BlockDevice>
                 <path>
                     /dev/disk/by-id/scsi-360a9800068666949673446387665336f
                 </path>
                 <vendor>
                     HITACHI
                 </vendor>
                 <serial>
                     730157980002
                 </serial>
                 <size>
                     80530636800
                 </size>
                 <adapter>
                     4
                 </adapter>
                 <channel>
                     0
                 </channel>
                 <id>
                     4
                 </id>
                 <lun>
                     2
                 </lun>
                 <hba>
                     qla2xxx
                 </hba>
             </BlockDevice>
             <Adapter>
                 <host>
                     Host4
                 </host>
                 <name>
                     qla2xxx
                 </name>
                 <manufacturer>
                     QLogic HBA Driver
                 </manufacturer>
                 <id>
                     4
                 </id>
             </Adapter>
         </Devlist>
   <!--NeedCopy-->
   

4. Sur le coordinateur de pool, créez le SR. Spécifiez le chemin d’accès global de l’appareil renvoyé dans le <path> propriété à partir de Sonde SR. Les PBD sont créés et branchés automatiquement pour chaque hôte du pool.

         xe sr-create host-uuid=valid_uuid \
         content-type=user \
         name-label="Example shared LVM over HBA SR" shared=true \
         device-config:SCSIid=device_scsi_id type=lvmohba
   <!--NeedCopy-->
   

Remarque :

Vous pouvez utiliser la fonction XenCenter Repair Storage Repository pour réessayer la création et le branchement de PBD des parties sr-création opération. Cette fonction peut s’avérer utile dans les cas où le zonage des LUN était incorrect pour un ou plusieurs hôtes d’un pool lors de la création du SR. Corrigez le zonage des hôtes concernés et utilisez la fonction Réparer le référentiel de stockage au lieu de supprimer et de recréer le SR.

Stockage par blocs GFS2 partagé alloué de manière dynamique

Le provisionnement léger utilise mieux le stockage disponible en allouant de l’espace de stockage sur disque aux VDI au fur et à mesure que les données sont écrites sur le disque virtuel, plutôt qu’en allouant à l’avance la taille virtuelle complète du VDI. Le provisionnement léger vous permet de réduire considérablement la quantité d’espace requise sur une baie de stockage partagée, et par conséquent votre coût total de possession (TCO).

Le provisionnement léger pour le stockage de blocs partagés présente un intérêt particulier dans les cas suivants :

• Vous souhaitez une efficacité accrue de l’espace. Les images sont réparties de manière clairsemée et non épaisse.
• Vous souhaitez réduire le nombre d’opérations d’E/S par seconde sur votre baie de stockage. Le GFS2 SR est le premier type SR à prendre en charge la mise en cache de lecture de stockage sur un stockage de blocs partagé.
• Vous utilisez une image de base commune pour plusieurs machines virtuelles. Les images des machines virtuelles individuelles utiliseront alors généralement encore moins d’espace.
• Vous utilisez des instantanés. Chaque instantané est une image et chaque image est désormais clairsemée.
• Votre stockage ne prend pas en charge NFS et ne prend en charge que le stockage en blocs. Si votre stockage prend en charge NFS, nous vous recommandons d’utiliser NFS au lieu de GFS2.
• Vous souhaitez créer des VDI d’une taille supérieure à 2 Tio. Le GFS2 SR prend en charge les VDI jusqu’à 16 Tio.

Remarque :

Nous vous recommandons de ne pas utiliser un SR GFS2 avec un VLAN en raison d’un problème connu selon lequel vous ne pouvez pas ajouter ou supprimer des hôtes sur un pool en cluster si le réseau de cluster se trouve sur un VLAN non de gestion.

Le type SR GFS2 partagé crée un système de fichiers GFS2 sur un LUN iSCSI ou HBA. Les VDI sont stockés dans le GFS2 SR sous forme de fichiers au format d’image QCOW2.

Pour plus d’informations sur l’utilisation du stockage GFS2, consultez Stockage en blocs GFS2 partagé à provisionnement léger.

NFS et SMB

Les partages sur des serveurs NFS (qui prennent en charge n’importe quelle version de NFSv4 ou NFSv3) ou sur des serveurs SMB (qui prennent en charge SMB 3) peuvent être utilisés immédiatement en tant que SR pour les disques virtuels. Les VDI sont stockées au format Microsoft VHD uniquement. De plus, comme ces SR peuvent être partagés, les VDI stockées sur les SR partagés permettent :

• Machines virtuelles à démarrer sur n’importe quel hôte XenServer dans un pool de ressources

• Migration de machines virtuelles entre les hôtes XenServer dans un pool de ressources à l’aide d’une migration en direct (sans temps d’arrêt notable)

Important :

• La prise en charge de SMB3 est limitée à la possibilité de se connecter à un partage à l’aide du protocole 3. Des fonctionnalités supplémentaires telles que le basculement transparent dépendent de la disponibilité des fonctionnalités dans le noyau Linux en amont et ne sont pas prises en charge dans XenServer 8.4.
• Le SMB en cluster n’est pas pris en charge avec XenServer.
• Pour NFSv4, seul le type d’authentification AUTH_SYS est pris en charge.
• Le stockage SMB est disponible pour les clients XenServer Premium Edition.
• Il est fortement recommandé pour le stockage NFS et PME d’utiliser un réseau de stockage dédié, utilisant au moins deux liaisons liées, idéalement vers des commutateurs réseau indépendants avec des alimentations redondantes.
• Lorsque vous utilisez le stockage SMB, ne supprimez pas le partage du stockage avant de détacher le SMB SR.

Les VDI stockées sur les SR basés sur des fichiers sont Provisionné de manière dynamique. Le fichier image est alloué au fur et à mesure que la machine virtuelle écrit les données sur le disque. Cette approche présente l’avantage considérable que les fichiers d’image de machine virtuelle n’occupent que l’espace de stockage nécessaire. Par exemple, si une VDI de 100 Go est allouée à une machine virtuelle et qu’un système d’exploitation est installé, le fichier VDI reflète uniquement la taille des données du système d’exploitation écrites sur le disque plutôt que l’intégralité des 100 Go.

Les fichiers VHD peuvent également être chaînés, ce qui permet à deux VDI de partager des données communes. Dans les cas où une machine virtuelle basée sur un fichier 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 des machines virtuelles basées sur des fichiers à partir de modèles, ce qui facilite le provisionnement et le déploiement très rapides de nouvelles machines virtuelles.

Remarque :

La longueur maximale prise en charge des chaînes VHD est de 30.

Les implémentations SR et VHD basées sur des fichiers dans XenServer supposent qu’elles ont un contrôle total sur le répertoire SR sur le serveur de fichiers. Les administrateurs ne doivent pas modifier le contenu du répertoire SR, car cette action peut risquer de corrompre le contenu des VDI.

XenServer a été optimisé pour le stockage de classe entreprise qui utilise une RAM non volatile pour fournir des accusés de réception rapides des demandes d’écriture tout en maintenant un degré élevé de protection des données contre les pannes. XenServer a été testé de manière approfondie par rapport au stockage Network Appliance FAS2020 et FAS3210, en utilisant Data OnTap 7.3 et 8.1

Avertissement :

Étant donné que les VDI sur les SR basés sur des fichiers sont créées en tant que provisionnement dynamique, les administrateurs doivent s’assurer que les SR basés sur des fichiers disposent de suffisamment d’espace disque pour toutes les VDI requises. Les hôtes XenServer n’imposent pas que l’espace requis pour les VDI sur les SR basés sur des fichiers soit présent.

Assurez-vous de surveiller l’espace libre sur votre SR. Si l’utilisation de SR passe à 100 %, les écritures ultérieures à partir de machines virtuelles échouent. Ces écritures échouées peuvent entraîner le blocage ou le blocage de la machine virtuelle.

Création d’un NFS SR (NFS) partagé

Remarque :

Si vous tentez d’attacher un SR NFS en lecture seule, cette action échoue avec le message d’erreur suivant : « SR_BACKEND_FAILURE_461 - Le système de fichiers pour SR ne peut pas être écrit ».

Pour créer un SR NFS, vous devez fournir le nom d’hôte ou l’adresse IP du serveur NFS. Vous pouvez créer le SR sur n’importe quel chemin de destination valide ; Utilisez l’icône Sonde SR pour afficher la liste des chemins de destination valides exportés par le serveur.

Dans les scénarios où XenServer est utilisé avec un stockage bas de gamme, il attend prudemment que toutes les écritures soient reconnues avant de transmettre les accusés de réception aux machines virtuelles. Cette approche entraîne un coût notable en termes de performances et peut être résolue en configurant le stockage pour qu’il présente le point de montage SR en tant qu’exportation en mode asynchrone. Les exportations asynchrones accusent réception des écritures qui ne se trouvent pas réellement sur le disque. Considérez attentivement les risques d’échec dans ces situations.

Remarque :

Le serveur NFS doit être configuré pour exporter le chemin spécifié vers tous les hôtes du pool. Si cette configuration n’est pas faite, la création du SR et le branchement de l’enregistrement PBD échouent.

L’implémentation XenServer NFS utilise TCP par défaut. Si votre situation le permet, vous pouvez configurer l’implémentation pour utiliser UDP dans des scénarios où il peut y avoir un avantage en termes de performances. Pour effectuer cette configuration, lors de la création d’un SR, spécifiez l’icône configuration-appareil paramètre useUDP=true.

Ce qui suit configuration-appareil sont utilisés avec les SR NFS :

Par exemple, pour créer une SR NFS partagée sur 192.168.1.10 :/export1, à l’aide de n’importe quelle version 4 de NFS mise à disposition par le fileur, utilisez la commande suivante :

      xe sr-create content-type=user \
      name-label="shared NFS SR" shared=true \
      device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
      device-config:nfsversion="4"
<!--NeedCopy-->

Pour créer une SR NFS non partagée sur 192.168.1.10 :/export1, à l’aide de NFS version 4.0, exécutez la commande suivante :

      xe sr-create host-uuid=host_uuid content-type=user \
      name-label="Non-shared NFS SR" \
      device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
      device-config:nfsversion="4.0"
<!--NeedCopy-->

Créer une SR SMB PARTAGÉE (SMB)

Pour créer un SR SMB, fournissez le nom d’hôte ou l’adresse IP du serveur SMB, le chemin d’accès complet du partage exporté et les informations d’identification appropriées.

Paramètres de configuration de périphérique pour les SR SMB :

Remarque :

Lors de l’exécution de la commande sr-création , nous vous recommandons d’utiliser la commande config_appareil :password_secret au lieu de spécifier le mot de passe sur la ligne de commande. Pour plus d’informations, consultez Secrets.

Par exemple, pour créer un SR SMB partagé sur 192.168.1.10 :/partager1, utilisez la commande suivante :

      xe sr-create content-type=user \
      name-label="Example shared SMB SR" shared=true \
      device-config:server=//192.168.1.10/share1 \
      device-config:username=valid_username device-config:password_secret=valid_password_secret type=smb
<!--NeedCopy-->

Pour créer un SR SMB non partagé, exécutez la commande suivante :

      xe sr-create host-uuid=host_uuid content-type=user \
      name-label="Non-shared SMB SR" \
      device-config:server=//192.168.1.10/share1 \
      device-config:username=valid_username device-config:password_secret=valid_password_secret type=smb
<!--NeedCopy-->

LVM sur HBA matériel

Le type LVM sur HBA matériel représente les disques en tant que disques VHD sur des volumes logiques au sein d’un groupe de volumes créé sur un LUN HBA qui fournit, par exemple, une prise en charge matérielle iSCSI ou FC.

Les hôtes XenServer prennent en charge les SAN Fibre Channel via des adaptateurs de bus hôte (HBA) Emulex ou QLogic. Toutes les configurations Fibre Channel requises pour exposer un LUN Fibre Channel à l’hôte doivent être effectuées manuellement. Cette configuration inclut les périphériques de stockage, les périphériques réseau et le HBA au sein de l’hôte XenServer. Une fois la configuration FC terminée, l’adaptateur HBA expose à l’hôte un périphérique SCSI soutenu par le LUN FC. Le périphérique SCSI peut ensuite être utilisé pour accéder au LUN FC comme s’il s’agissait d’un périphérique SCSI attaché localement.

Utilisez le Sonde SR pour répertorier les périphériques SCSI basés sur des LUN présents sur l’hôte. Cette commande force une recherche de nouveaux périphériques SCSI basés sur des LUN. Valeur du chemin d’accès renvoyée par Sonde SR pour un périphérique SCSI basé sur une LUN est cohérente sur tous les hôtes ayant accès à la LUN. Par conséquent, cette valeur doit être utilisée lors de la création de SR partagés accessibles par tous les hôtes d’un pool de ressources.

Les mêmes fonctionnalités s’appliquent aux adaptateurs HBA iSCSI QLogic.

Consultez Créer des référentiels de stockage pour plus de détails sur la création de SR FC et iSCSI basés sur HBA partagés.

Remarque :

La prise en charge de XenServer pour Fibre Channel ne prend pas en charge le mappage direct d’un LUN à une machine virtuelle. Les LUN basés sur HBA doivent être mappés à l’hôte et spécifiés pour être utilisés dans une demande de distribution. Les VDI au sein du SR sont exposées aux machines virtuelles en tant que périphériques de bloc standard.

La taille de bloc d’un LVM sur un LUN HBA doit être de 512 octets. Pour utiliser le stockage avec des blocs physiques de 4 Ko, le stockage doit également prendre en charge l’émulation de blocs d’allocation de 512 octets (la taille du bloc logique doit être de 512 octets).