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

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.

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.
• Vous souhaitez créer des VDI d’une taille supérieure à 2 Tio. Le GFS2 SR prend en charge les VDI jusqu’à 16 Tio.
• Votre stockage ne prend pas en charge NFS ou SMB3 et ne prend en charge que le stockage par blocs. Si votre stockage prend en charge NFS ou SMB3, nous vous recommandons d’utiliser ces types SR au lieu de GFS2.
• Votre stockage ne prend pas en charge le provisionnement dynamique des LUN. Si votre stockage effectue le provisionnement dynamique des LUN, vous pouvez rencontrer des problèmes et manquer d’espace lors de la combinaison avec GFS2. La combinaison de GFS2 avec un LUN alloué de manière dynamique n’offre pas beaucoup d’avantages supplémentaires et n’est pas recommandée.

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 GFS2 partagé représente les disques sous la forme d’un système de fichiers créé sur un LUN iSCSI ou HBA. Les VDI stockées sur un SR GFS2 sont stockées au format d’image QCOW2.

Cet article explique comment configurer votre environnement GFS2 à l’aide de l’interface de ligne de commande xe. Pour configurer un environnement GFS2 à l’aide de XenCenter, consultez la documentation du produit XenCenter.

1. Planifiez votre environnement GFS2

Pour bénéficier des avantages du provisionnement fin sur le stockage par blocs partagé sans risque de perte de données, votre pool doit offrir un bon niveau de fiabilité et de connectivité. Il est essentiel que les hôtes du pool de ressources qui utilisent GFS2 puissent communiquer de manière fiable entre eux. Pour ce faire, Citrix Hypervisor exige que vous utilisiez un pool en cluster avec votre SR GFS2. Nous vous recommandons également de concevoir votre environnement et de configurer les fonctionnalités de Citrix Hypervisor pour fournir autant de résilience et de redondance que possible.

Avant de configurer votre pool d’hyperviseurs Citrix pour qu’il fonctionne avec les SR GFS2, passez en revue les exigences et les recommandations suivantes pour un environnement GFS2 idéal :

• Recommandé: Configurer une infrastructure réseau redondante.

• Recommandé: Créez un réseau sous douane dédié

• Obligatoire: Configurer un pool cluster

• Optionnel Augmentez la mémoire de votre domaine de contrôle

• Recommandé: Configurer le multipathing de stockage

• Obligatoire: Création d’un GFS2 SR

Un pool en cluster avec des SR GFS2 présente des différences de comportement par rapport à d’autres types de pool et de SR. Pour plus d’informations, consultez Contraintes.

2. Configurer une infrastructure réseau redondante

Un réseau lié relie deux ou plusieurs cartes réseau ensemble pour créer un canal unique pour le trafic réseau. Nous vous recommandons d’utiliser un réseau lié pour le trafic de votre pool en cluster. Toutefois, avant de configurer votre réseau lié, assurez-vous que la configuration matérielle de votre réseau favorise la redondance dans le réseau lié. Envisagez de mettre en œuvre le plus grand nombre possible de ces recommandations pour votre organisation et votre environnement.

Les bonnes pratiques suivantes renforcent la résilience contre les pannes logicielles, matérielles ou d’alimentation qui peuvent affecter vos commutateurs réseau :

• Assurez-vous que vous disposez de commutateurs réseau physiques distincts pour une utilisation dans le réseau lié, et pas seulement de ports sur le même commutateur.
• Assurez-vous que les commutateurs séparés sont alimentés par des unités de distribution d’alimentation (PDU) différentes et indépendantes.
• Si possible, dans votre centre de données, placez les PDU sur différentes phases de l’alimentation électrique ou même sur des alimentations fournies par différentes sociétés de services publics.
• Envisagez d’utiliser des unités d’alimentation sans coupure pour vous assurer que les commutateurs et les serveurs réseau peuvent continuer à fonctionner ou effectuer un arrêt ordonné en cas de panne de courant.

3. Créez un réseau lié dédié

Il est important de s’assurer que les hôtes d’un pool en cluster peuvent communiquer de manière fiable entre eux. La création d’un réseau lié pour ce trafic de pool augmente la résilience de votre pool en cluster.

Un réseau lié crée un lien entre deux ou plusieurs cartes réseau pour créer un canal unique et performant que votre pool en cluster peut utiliser pour le trafic de pulsation de cluster. Nous vous recommandons vivement de ne pas utiliser ce réseau lié pour d’autres trafics. Créez un réseau distinct pour le pool à utiliser pour la gestion du trafic.

Avertissement :

Si vous choisissez de ne pas suivre cette recommandation, vous courez un risque plus élevé de perdre des paquets réseau de gestion de cluster. La perte de paquets réseau de gestion de cluster peut entraîner la perte du quorum de votre pool en cluster et une partie ou la totalité des hôtes du pool s’auto-clôturent.

Si votre cluster est en train de clôturer ou de rencontrer un problème dans cette configuration non recommandée, le support peut vous demander de reproduire le même problème sur une configuration recommandée au cours de l’enquête.

Pour créer un réseau lié à utiliser comme réseau de clustering :

1. Si vous disposez d’un pare-feu entre les hôtes de votre pool, assurez-vous que les hôtes peuvent communiquer sur le réseau du cluster à l’aide des ports suivants :

   • TCP : 8892, 8896, 21064
   • UDP : 5404, 5405

   Pour plus d’informations, consultez Ports de communication utilisés par Citrix Hypervisor.

2. Ouvrez une console sur le serveur Citrix Hypervisor que vous souhaitez utiliser en tant que maître de pool.

3. Créez un réseau à utiliser avec la carte réseau liée à l’aide de la commande suivante :

     xe network-create name-label=bond0
   <!--NeedCopy-->
   

   L’UUID du nouveau réseau est renvoyé.

4. Recherchez les UUID des PIF à utiliser dans la liaison à l’aide de la commande suivante :

     xe pif-list
   <!--NeedCopy-->
   

5. Créez votre réseau lié en mode actif-actif, en mode actif-passif ou en mode liaison LACP. Selon le mode de liaison que vous souhaitez utiliser, effectuez l’une des actions suivantes :

   • Pour configurer la liaison en mode actif-actif (par défaut), utilisez la commande bond-create pour créer la liaison. En utilisant des virgules pour séparer les paramètres, spécifiez l’UUID du réseau nouvellement créé et les UUID des PIF à lier :

        xe bond-create network-uuid=<network_uuid> /
            pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4>
      <!--NeedCopy-->
     

     Tapez deux UUID lorsque vous liez deux cartes réseau et quatre UUID lorsque vous liez quatre cartes réseau. L’UUID de la liaison est renvoyé après l’exécution de la commande.

   • Pour configurer la liaison en mode liaison actif-passif ou LACP, utilisez la même syntaxe, ajoutez le paramètre facultatif mode et spécifiez lacp ou active-backup:

        xe bond-create network-uuid=<network_uuid> /
            pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4> /
            mode=balance-slb | active-backup | lacp
      <!--NeedCopy-->
     

Une fois que vous avez créé votre réseau lié sur le pool master, lorsque vous joignez d’autres serveurs Citrix Hypervisor au pool, les informations de réseau et de liaison sont automatiquement répliquées sur le serveur de jonction.

Pour plus d’informations, consultez Réseautage.

Remarque :

• La modification de l’adresse IP du réseau de cluster à l’aide de XenCenter nécessite la désactivation temporaire du clustering et de GFS2.
• Ne modifiez pas la liaison de votre réseau de clustering lorsque le cluster est en ligne et que des machines virtuelles sont en cours d’exécution. Cette action peut entraîner un redémarrage dur des hôtes du cluster (clôture).
• Si vous avez un conflit d’adresses IP (plusieurs hôtes ayant la même adresse IP) sur votre réseau de clustering impliquant au moins un hôte pour lequel le clustering est activé, le cluster ne se forme pas correctement et les hôtes ne peuvent pas se clôturer lorsque cela est nécessaire. Pour résoudre ce problème, résolvez le conflit d’adresse IP.

Pour tester les temps de basculement de votre réseau lié, actif-passif :

Pour les réseaux liés qui utilisent le mode actif-passif, en cas de défaillance de la liaison active, il existe une période de basculement lorsque la liaison réseau est rompue alors que la liaison passive devient active. Si le temps nécessaire au basculement de votre réseau lié actif-passif est plus long que le délai d’expiration du cluster, certains ou tous les hôtes de votre pool en cluster peuvent toujours être clôturés.

Vous pouvez tester le temps de basculement de votre réseau lié en forçant le réseau à basculer à l’aide de l’une des méthodes suivantes :

• En retirant physiquement les câbles réseau
• En désactivant les ports de commutation sur une liaison réseau

Répétez le test un certain nombre de fois pour vous assurer que le résultat est cohérent.

La valeur du délai d’expiration du cluster de votre pool dépend du nombre d’hôtes dans votre cluster. Exécutez la commande suivante pour trouver le timeout de jeton Valeur en secondes pour le pool :

  xe cluster-param-get uuid=<cluster_uuid> param-name=token-timeout

Si le temps de basculement est susceptible d’être supérieur à la valeur du délai d’expiration, votre infrastructure et votre configuration réseau ne sont peut-être pas suffisamment fiables pour prendre en charge un pool en cluster.

4. Configurer un pool en cluster

Pour utiliser le stockage GFS2 partagé, le pool de ressources Citrix Hypervisor doit être un pool en cluster. Activez le clustering sur votre pool avant de créer un SR GFS2.

Un pool en cluster est un pool de serveurs Citrix Hypervisor qui sont plus étroitement connectés et coordonnés que les hôtes des pools non en cluster. Les hôtes du cluster maintiennent une communication constante entre eux sur un réseau sélectionné. Tous les hôtes du cluster connaissent l’état de chaque hôte du cluster. Cette coordination de l’hôte permet au cluster de contrôler l’accès au contenu du GFS2 SR. Pour s’assurer que le pool en cluster reste toujours en communication, chaque hôte d’un cluster doit toujours être en communication avec au moins la moitié des hôtes du cluster (y compris lui-même). Cet état est connu sous le nom d’hôte ayant le quorum. Si un hôte n’a pas le quorum, il redémarre et se retire du cluster. Cette action est appelée « clôture ».

Pour plus d’informations, voir Pools en cluster.

Avant de commencer à configurer votre pool en cluster, assurez-vous que les conditions préalables suivantes sont remplies :

• Prévoyez de créer un pool de 3 à 16 hôtes.

  Dans la mesure du possible, utilisez un nombre impair d’hôtes dans un pool en cluster, car cela garantit que les hôtes sont toujours en mesure de déterminer s’ils ont quorun. Nous vous recommandons d’utiliser le clustering uniquement dans les pools contenant au moins trois hôtes, car les pools de deux hôtes sont sensibles à l’auto-séparation de l’ensemble du pool.

  Les pools en cluster ne prennent en charge que 16 hôtes par pool.

• Tous les serveurs Citrix Hypervisor du pool en cluster doivent disposer d’au moins 2 Gio de mémoire de domaine de contrôle.
• Tous les hôtes du cluster doivent utiliser des adresses IP statiques pour le réseau du cluster.
• Si vous mettez en cluster un pool existant, assurez-vous que la haute disponibilité est désactivée. Vous pouvez réactiver la haute disponibilité une fois le clustering activé.

Pour utiliser l’interface de ligne de commande xe afin de créer un pool en cluster :

1. Créez un pool de ressources d’au moins trois serveurs Citrix Hypervisor.

   Répétez les étapes suivantes sur chaque serveur Citrix Hypervisor qui n’est pas le maître du pool :

   1. Ouvrez une console sur le serveur Citrix Hypervisor.

   2. Joignez le serveur Citrix Hypervisor au pool sur le maître de pool à l’aide de la commande suivante :

        xe pool-join master-address=<master_address> /
            master-username=<administrators_username> /
            master-password=<password>
      <!--NeedCopy-->
      

      La valeur de la adresse-maître doit être défini sur le nom de domaine complet du serveur Citrix Hypervisor qui est le maître du pool. Le mot de passe Il doit s’agir du mot de passe administrateur défini lors de l’installation du maître de pool.

   Pour plus d’informations, consultez Hôtes et pools de ressources.

2. Pour chaque PIF appartenant à ce réseau, définissez disallow-unplug=vrai.

   1. Recherchez les UUID des PIF qui appartiennent au réseau à l’aide de la commande suivante :

        xe pif-list
      <!--NeedCopy-->
      

   2. Exécutez la commande suivante sur un serveur Citrix Hypervisor dans votre pool de ressources :

        xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
      <!--NeedCopy-->
      

3. Activez le clustering sur votre pool. Exécutez la commande suivante sur un serveur Citrix Hypervisor dans votre pool de ressources :

     xe cluster-pool-create network-uuid=<network_uuid>
   <!--NeedCopy-->
   

   Indiquez l’UUID du réseau lié que vous avez créé à l’étape précédente.

5. Augmentez la mémoire de votre domaine de contrôle

Si vous ne disposez pas d’une mémoire de domaine de contrôle suffisante sur vos hôtes, votre pool peut rencontrer une instabilité du réseau. L’instabilité du réseau peut entraîner des problèmes pour un pool en cluster avec des SR GFS2.

Il est important de s’assurer que votre pool en cluster dispose d’une quantité appropriée de mémoire de domaine de contrôle. Pour plus d’informations sur la modification de la quantité de mémoire du domaine de contrôle et la surveillance du comportement de la mémoire, consultez Utilisation de la mémoire.

6. Configurer le multipathing de stockage

Assurez-vous que le multipathing de stockage est configuré entre votre pool en cluster et votre SR GFS2.

Le multipathing achemine le trafic de stockage vers un périphérique de stockage via plusieurs chemins à des fins de redondance. Toutes les routes peuvent avoir un trafic actif en fonctionnement normal, ce qui entraîne une augmentation du débit.

Avant d’activer le multipathing, vérifiez que les instructions suivantes sont vraies :

• Votre commutateur Ethernet ou fibre optique est configuré pour rendre plusieurs cibles disponibles sur votre serveur de stockage.

  Par exemple, un back-end de stockage iSCSI a demandé sendtargets sur un portail donné renvoie plusieurs cibles, comme dans l’exemple suivant :

      iscsiadm -m discovery --type sendtargets --portal 192.168.0.161
      192.168.0.161:3260,1 iqn.strawberry:litchie
      192.168.0.204:3260,2 iqn.strawberry:litchie
  

  Toutefois, vous pouvez effectuer une configuration supplémentaire pour activer le multichemin d’accès iSCSI pour les baies qui n’exposent qu’une seule cible. Pour plus d’informations, consultez Chemin d’accès multiple iSCSI pour les baies qui n’exposent qu’une seule cible.

• Pour iSCSI uniquement, le domaine de contrôle (dom0) dispose d’une adresse IP sur chaque sous-réseau utilisé par le stockage à chemins d’accès multiples.

  Assurez-vous que pour chaque chemin d’accès au stockage, vous disposez d’une carte réseau et qu’une adresse IP est configurée sur chaque carte réseau. Par exemple, si vous souhaitez quatre chemins d’accès à votre stockage, vous devez disposer de quatre cartes réseau qui ont chacune une adresse IP configurée.

• Pour iSCSI uniquement, chaque cible et initiateur iSCSI possède un IQN unique.

• Pour iSCSI uniquement, les ports cibles iSCSI fonctionnent en mode portail.

• Pour les adaptateurs HBA uniquement, plusieurs adaptateurs HBA sont connectés à la structure du commutateur.

• Si possible, utilisez plusieurs commutateurs redondants.

Pour activer le multipathing à l’aide de l’interface de ligne de commande xe

Nous vous recommandons d’activer le multipathing pour tous les hôtes de votre pool avant la création du SR. Si vous créez le SR avant d’activer le multipathing, vous devez mettre vos hôtes en mode de maintenance pour activer le multipathing.

1. Ouvrez une console sur le serveur Citrix Hypervisor.

2. Débranchez tous les PBD de l’hôte à l’aide de la commande suivante :

     xe pbd-unplug uuid=<pbd_uuid>
   <!--NeedCopy-->
   

   Vous pouvez utiliser la commande xe pbd-list pour trouver l’UUID des PBD.

3. Définissez la valeur de la fonction multipathing pour vrai à l’aide de la commande suivante :

     xe host-param-set uuid=<host uuid> multipathing=true
   <!--NeedCopy-->
   

4. S’il existe des SR existants sur les hôtes s’exécutant en mode chemin unique qui ont plusieurs chemins d’accès :

   • Migrez ou suspendez tous les invités en cours d’exécution avec des disques virtuels dans les SR concernés.

   • Rebranchez le PBD de tous les SR concernés pour les reconnecter à l’aide du multipathing :

        xe pbd-plug uuid=<pbd_uuid>
      <!--NeedCopy-->
     

5. Répétez ces étapes pour activer le multipathing sur tous les hôtes du pool.

Assurez-vous d’activer le multipathing sur tous les hôtes du pool. Tous les câbles et, dans le cas d’iSCSI, les configurations de sous-réseau doivent correspondre aux cartes réseau correspondantes sur chaque hôte.

Pour plus d’informations, consultez Multipathing de stockage.

7. Créez un GFS2 SR

Créez votre SR GFS2 partagé sur un LUN iSCSI ou HBA visible par tous les serveurs Citrix Hypervisor de votre pool de ressources. Nous vous déconseillons d’utiliser un LUN à provisionnement dynamique avec GFS2. Toutefois, si vous choisissez cette configuration, vous devez vous assurer que le LUN dispose toujours de suffisamment d’espace pour permettre à Citrix Hypervisor d’y écrire.

Vous pouvez ajouter jusqu’à 62 SR GFS2 à un pool en cluster.

Si vous avez déjà utilisé votre périphérique de stockage basé sur des blocs pour le provisionnement statique avec LVM, cela est détecté par Citrix Hypervisor. XenCenter vous donne la possibilité d’utiliser la partition LVM existante ou de formater le disque et de configurer une partition GFS2.

Création d’un GFS2 partagé sur iSCSI SR

Vous pouvez créer GFS2 sur des SR iSCSI à l’aide de XenCenter. Pour plus d’informations, consultez Stockage iSCSI logiciel dans la documentation du produit XenCenter.

Vous pouvez également utiliser l’interface de ligne de commande xe pour créer un GFS2 sur iSCSI SR.

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

Vous pouvez trouver les valeurs à utiliser pour ces paramètres à l’aide de la commande xe sr-probe-ext commander.

  xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

1. Commencez par exécuter la commande suivante :

     xe sr-probe-ext type=gfs2 device-config:provider=iscsi
   <!--NeedCopy-->
   

   Le résultat de la commande vous invite à fournir des paramètres supplémentaires et donne une liste de valeurs possibles à chaque étape.

2. Répétez la commande en ajoutant de nouveaux paramètres à chaque fois.

3. Lorsque la sortie de la commande commence par Vous avez trouvé les configurations complètes suivantes qui peuvent être utilisées pour créer des SR :, vous pouvez localiser le SR à l’aide de l’icône xe sr-create et la commande configuration-appareil paramètres que vous avez spécifiés.

   Exemple de sortie :

     Found the following complete configurations that can be used to create SRs:
     Configuration 0:
       SCSIid       : 36001405852f77532a064687aea8a5b3f
           targetIQN: iqn.2009-01.example.com:iscsi192a25d6
              target: 198.51.100.27
            provider: iscsi
   
   
     Configuration 0 extra information:
   <!--NeedCopy-->
   

Pour créer un SR GFS2 partagé sur un LUN spécifique d’une cible iSCSI, exécutez la commande suivante sur un serveur de votre pool en cluster :

  xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
     device-config:provider=iscsi device-config:targetIQN=<target_iqns> \
     device-config:target=<portal_address> device-config:SCSIid=<scsci_id>
<!--NeedCopy-->

Si la cible iSCSI n’est pas accessible pendant le montage des systèmes de fichiers GFS2, certains hôtes du pool en cluster peuvent redémarrer brutalement (clôture).

Pour plus d’informations sur l’utilisation des SR iSCSI, reportez-vous à la section Prise en charge logicielle iSCSI.

Création d’un GFS2 partagé sur HBA SR

Vous pouvez créer des SR GFS2 sur HBA à l’aide de XenCenter. Pour plus d’informations, consultez Stockage HBA matériel dans la documentation du produit XenCenter.

Vous pouvez également utiliser l’interface de ligne de commande xe pour créer un GFS2 sur HBA SR.

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

Vous pouvez trouver les valeurs à utiliser pour le paramètre SCSIid à l’aide de la commande xe sr-probe-ext commander.

  xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

1. Commencez par exécuter la commande suivante :

     xe sr-probe-ext type=gfs2 device-config:provider=hba
   <!--NeedCopy-->
   

   Le résultat de la commande vous invite à fournir des paramètres supplémentaires et donne une liste de valeurs possibles à chaque étape.

2. Répétez la commande en ajoutant de nouveaux paramètres à chaque fois.

3. Lorsque la sortie de la commande commence par Vous avez trouvé les configurations complètes suivantes qui peuvent être utilisées pour créer des SR :, vous pouvez localiser le SR à l’aide de l’icône xe sr-create et la commande configuration-appareil paramètres que vous avez spécifiés.

   Exemple de sortie :

     Found the following complete configurations that can be used to create SRs:
     Configuration 0:
       SCSIid       : 36001405852f77532a064687aea8a5b3f
           targetIQN: iqn.2009-01.example.com:iscsi192a25d6
              target: 198.51.100.27
            provider: iscsi
   
   
     Configuration 0 extra information:
   <!--NeedCopy-->
   

Pour créer un SR GFS2 partagé sur un LUN spécifique d’une cible HBA, exécutez la commande suivante sur un serveur de votre pool en cluster :

  xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
    device-config:provider=hba device-config:SCSIid=<device_scsi_id>
<!--NeedCopy-->

Pour plus d’informations sur l’utilisation des SR HBA, reportez-vous à la section Adaptateurs de bus hôte matériels.

Quelle est la prochaine étape ?

Maintenant que votre environnement GFS2 est configuré, il est important de maintenir la stabilité de votre pool en cluster en vous assurant qu’il dispose d’un quorum. Pour plus d’informations, consultez Gérer votre pool en cluster.

Si vous rencontrez des problèmes avec votre environnement GFS2, reportez-vous à la section Résoudre les problèmes liés aux pools en cluster.

Vous pouvez gérer votre SR GFS2 de la même manière que vous le faites pour les autres SR. Par exemple, vous pouvez ajouter de la capacité à la baie de stockage pour augmenter la taille de la LUN. Pour plus d’informations, consultez Extension des LUN en direct.

Contraintes

Le stockage GFS2 partagé présente actuellement les contraintes suivantes :

• Comme pour tout SR alloué de manière dynamique, si l’utilisation du SR GFS2 passe à 100 %, les écritures ultérieures à partir de machines virtuelles échouent. Ces échecs d’écriture peuvent ensuite entraîner des défaillances au sein de la machine virtuelle, une éventuelle corruption des données, ou les deux.

• XenCenter affiche une alerte lorsque votre utilisation de SR atteint 80 %. Assurez-vous de surveiller votre GFS2 SR pour détecter cette alerte et de prendre les mesures appropriées si elle est visible. Sur un GFS2 SR, une utilisation élevée entraîne une dégradation des performances. Nous vous recommandons de maintenir votre utilisation de SR en dessous de 80 %.

• La migration de machines virtuelles avec migration du stockage (en direct ou hors connexion) n’est pas prise en charge pour les machines virtuelles dont les VDI se trouvent sur un SR GFS2. Vous ne pouvez pas non plus migrer des VDI d’un autre type de SR vers un SR GFS2.

• Le transport FCoE logiciel n’est pas pris en charge avec les SR GFS2 (pour FCoE entièrement déchargé à l’aide de l’adaptateur HBA).

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

• Le protocole CHAP n’est pas pris en charge sur les SR GFS2.

• Les machines virtuelles de clone complet MCS ne sont pas prises en charge avec les SR GFS2.

• L’utilisation de plusieurs SR GFS2 dans le même catalogue MCS n’est pas prise en charge.

• Les mesures de performances ne sont pas disponibles pour les SR GFS2 et les disques sur ces SR.

• Le suivi des blocs modifiés n’est pas pris en charge pour les VDI stockées sur les SR GFS2.

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

• Nous vous déconseillons d’utiliser un LUN à provisionnement dynamique avec GFS2. Toutefois, si vous choisissez cette configuration, vous devez vous assurer que le LUN dispose toujours de suffisamment d’espace pour permettre à Citrix Hypervisor d’y écrire.

• Nous vous déconseillons d’utiliser la déduplication SAN avec les SR GFS2. Toutefois, si vous choisissez cette configuration, vous devez utiliser une surveillance externe appropriée de l’utilisation de votre SAN pour vous assurer qu’il y a toujours de l’espace pour que Citrix Hypervisor puisse écrire.

• Votre système de fichiers GFS2 ne peut pas être supérieur à 100 Tio.

• Vous ne pouvez pas avoir plus de 62 SR GFS2 dans votre pool.

• Les pools en cluster ne prennent en charge que 16 hôtes par pool.

• Pour activer HA sur votre pool en cluster, le SR de pulsation doit être un SR GFS2.

• Pour le trafic de cluster, nous vous recommandons vivement d’utiliser un réseau lié qui utilise au moins deux commutateurs réseau différents. N’utilisez pas ce réseau à d’autres fins.

• La modification de l’adresse IP du réseau de cluster à l’aide de XenCenter nécessite la désactivation temporaire du clustering et de GFS2.

• Ne modifiez pas la liaison de votre réseau de clustering lorsque le cluster est en ligne et que des machines virtuelles sont en cours d’exécution. Cette action peut entraîner un redémarrage dur des hôtes du cluster (clôture).

• Si vous avez un conflit d’adresses IP (plusieurs hôtes ayant la même adresse IP) sur votre réseau de clustering impliquant au moins un hôte pour lequel le clustering est activé, le cluster ne se forme pas correctement et les hôtes ne peuvent pas se clôturer lorsque cela est nécessaire. Pour résoudre ce problème, résolvez le conflit d’adresse IP.