Stockage par blocs GFS2 partagé à provisionnement léger

Le provisionnement fin 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 que d’allouer à l’avance la taille virtuelle complète du VDI. Le provisionnement fin vous permet de réduire considérablement la quantité d’espace requise sur une baie de stockage partagée et, partant, votre coût total de possession (TCO).

Le provisionnement fin pour le stockage en mode bloc partagé présente un intérêt particulier dans les cas suivants :

• Vous souhaitez une efficacité accrue de l’espace. Les images sont allouées 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 de SR à prendre en charge la mise en cache de lecture du stockage sur le stockage en mode bloc partagé.
• Vous utilisez une image de base commune pour plusieurs machines virtuelles. Les images des machines virtuelles individuelles utilisent alors généralement encore moins d’espace.
• Vous utilisez des instantanés. Chaque instantané est une image et chaque image est désormais fragmentée.
• Vous souhaitez créer des VDI dont la taille est supérieure à 2 Tio. Le GFS2 SR prend en charge les VDI d’une taille maximale de 16 Tio.
• Votre stockage ne prend pas en charge le NFS ou le SMB3 et ne prend en charge que le stockage par blocs. Si votre stockage prend en charge le NFS ou le 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 système de stockage utilise des LUN à provisionnement restreint, vous pouvez rencontrer des problèmes et manquer d’espace lorsque vous l’associez à GFS2. L’association de GFS2 à un LUN à provisionnement dynamique n’apporte pas de nombreux 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 dans lequel vous ne pouvez pas ajouter ou supprimer des hôtes sur un pool en cluster si le réseau en cluster se trouve sur un VLAN non destiné à la gestion.

Le type GFS2 partagé représente les disques en tant que système de fichiers créé sur un LUN iSCSI ou HBA. Les VDI stockés sur un GFS2 SR sont stockés au format d’image QCOW2.

Cet article décrit 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 léger 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 entre eux de manière fiable. Pour ce faire, Citrix Hypervisor nécessite que vous utilisiez un pool en cluster avec votre GFS2 SR. Nous vous recommandons également de concevoir votre environnement et de configurer les fonctionnalités de Citrix Hypervisor afin de fournir autant de résilience et de redondance que possible.

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

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

• Recommandé : créer un réseau lié dédié

• Obligatoire : configurer un pool en cluster

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

• Recommandé : configurer le multiacheminement du stockage

• Obligatoire : créer un GFS2 SR

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

2. Configuration d’une infrastructure réseau redondante

Un réseau lié relie deux cartes réseau ou plus afin de 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 autant de ces recommandations que possible pour votre organisation et votre environnement.

Les bonnes pratiques suivantes renforcent la résilience face aux pannes logicielles, matérielles ou électriques susceptibles d’affecter vos commutateurs réseau :

• Assurez-vous que vous disposez de commutateurs réseau physiques distincts pouvant être utilisés dans le réseau lié, et pas uniquement de ports sur le même commutateur.
• Assurez-vous que les commutateurs séparés sont alimentés par des unités de distribution électrique (PDU) différentes et indépendantes.
• Si possible, dans votre centre de données, placez les PDU sur différentes phases de l’alimentation ou même sur des alimentations fournies par différentes entreprises de services publics.
• Pensez à utiliser des unités d’alimentation sans interruption pour garantir que les commutateurs réseau et les serveurs 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 une liaison entre deux cartes d’interface réseau ou plus afin de créer un canal unique et performant que votre pool en cluster peut utiliser pour le trafic de pulsation du cluster. Nous recommandons vivement de ne pas utiliser ce réseau lié pour d’autres types de trafic. Créez un réseau distinct que le pool utilisera pour le trafic de gestion.

Avertissement :

Si vous choisissez de ne pas suivre cette recommandation, vous courez un risque plus élevé de perdre des paquets réseau de gestion des clusters. La perte de paquets réseau de gestion du cluster peut entraîner la perte du quorum de votre pool en cluster et certains, voire tous les hôtes du pool, se bloqueront automatiquement.

Si votre cluster est clôturé ou rencontre un problème dans cette configuration non recommandée, le support peut vous demander de reproduire le même problème dans 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 la section Ports de communication utilisés par Citrix Hypervisor.

2. Ouvrez une console sur le serveur Citrix Hypervisor dont vous souhaitez faire office de maître du 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. À l’aide de virgules pour séparer les paramètres, spécifiez l’UUID 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-->
     

     Saisissez 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 de liaison actif-passif ou LACP, utilisez la même syntaxe, ajoutez le paramètre mode facultatif 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 relatives au réseau et à la liaison sont automatiquement répliquées sur le serveur de connexion.

Pour plus d’informations, reportez-vous à la section Mise en réseau.

Remarque :

• La modification de l’adresse IP du réseau de clusters à 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 tant que le cluster est actif et que des machines virtuelles sont en cours d’exécution. Cette action peut entraîner un redémarrage brutal (clôture) des hôtes du cluster.
• En cas de 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 dont le clustering est activé, le cluster ne se forme pas correctement et les hôtes ne sont pas en mesure de clôturer en cas de besoin. 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 pendant laquelle la liaison réseau est interrompue alors que la liaison passive devient active. Si le délai nécessaire au basculement de votre réseau lié actif-passif est supérieur au délai d’expiration du cluster, certains ou tous les hôtes de votre pool en cluster risquent encore de se bloquer.

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 plusieurs fois pour vous assurer que le résultat est constant.

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

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

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

4. Configuration d’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 clusterisé est un pool de serveurs Citrix Hypervisor qui sont plus étroitement connectés et coordonnés que les hôtes des pools non clusterisés. 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 garantir 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 quorum. Si un hôte n’a pas le quorum, il redémarre définitivement et se retire du cluster. Cette action est appelée « clôture ».

Pour plus d’informations, consultez 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 atteint le quorun. Nous vous recommandons de n’utiliser le clustering que dans les pools contenant au moins trois hôtes, car les pools de deux hôtes sont susceptibles d’isoler automatiquement 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 du 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 pour 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 rejoint le pool et 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 du paramètre master-address doit être définie sur le nom de domaine complet du serveur Citrix Hypervisor qui est le maître du pool. Le password doit être le mot de passe administrateur défini lors de l’installation du pool master.

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

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

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

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

   2. Exécutez la commande suivante sur un serveur Citrix Hypervisor de 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 de votre pool de ressources :

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

   Fournissez l’UUID du réseau lié que vous avez créé lors d’une étape précédente.

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

Si la mémoire du domaine de contrôle de vos hôtes est insuffisante, votre pool peut connaître une instabilité 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, voir Utilisation de la mémoire.

6. Configuration du multiacheminement du stockage

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

Le multiacheminement achemine le trafic de stockage vers un périphérique de stockage via plusieurs chemins à des fins de redondance. Tous les itinéraires peuvent être parcourus par du trafic actif en fonctionnement normal, ce qui se traduit par une augmentation du débit.

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

• Votre commutateur Ethernet ou fibre est configuré pour mettre plusieurs cibles à disposition sur votre serveur de stockage.

  Par exemple, un back-end de stockage iSCSI interrogé pour 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 multipath iSCSI pour les baies qui n’exposent qu’une seule cible. Pour plus d’informations, consultez Multipath iSCSI pour les baies qui n’exposent qu’une seule cible.

• Pour iSCSI uniquement, le domaine de contrôle (dom0) possède une adresse IP sur chaque sous-réseau utilisé par le stockage multichemin.

  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 voulez quatre chemins d’accès à votre stockage, vous devez disposer de quatre cartes réseau dont chacune possède une adresse IP configurée.

• Pour iSCSI uniquement, chaque cible et chaque 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 de commutation.

• Si possible, utilisez plusieurs commutateurs redondants.

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

Nous vous recommandons d’activer le multiacheminement pour tous les hôtes de votre pool avant de créer le SR. Si vous créez le SR avant d’activer le multipathing, vous devez mettre vos hôtes en mode 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 du paramètre multipathing sur true à l’aide de la commande suivante :

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

4. S’il existe des SR sur les hôtes exécutés en mode chemin unique et dotés de plusieurs chemins :

   • Migrez ou suspendez tous les clients actifs dotés de disques virtuels dans les SR concernés.

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

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

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

Assurez-vous d’activer le multiacheminement 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, voir Multiacheminement de stockage.

7. Création d’un GFS2 SR

Créez votre GFS2 SR partagé sur un LUN iSCSI ou HBA visible par tous les serveurs Citrix Hypervisor de votre pool de ressources. Nous déconseillons d’utiliser un LUN à provisionnement léger 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 un provisionnement détaillé avec LVM, cela est détecté par Citrix Hypervisor. XenCenter vous permet d’utiliser la partition LVM existante ou de formater le disque et de configurer une partition GFS2.

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

Vous pouvez créer GFS2 sur des SRs 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 l’appareil pour les SR GFS2 :

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

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

   La sortie de la commande vous invite à fournir des paramètres supplémentaires et fournit 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 commande commence par Found the following complete configurations that can be used to create SRs:, vous pouvez localiser le SR à l’aide de la commande xe sr-create et des paramètres device-config 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: ```

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>

Si la cible iSCSI n’est pas accessible lorsque les systèmes de fichiers GFS2 sont montés, certains hôtes du pool en cluster risquent de redémarrer brusquement (clôture).

Pour plus d’informations sur l’utilisation des SR iSCSI, consultez la section Prise en charge iSCSI logicielle.

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

Vous pouvez créer GFS2 sur des SRs 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 l’appareil pour les SR GFS2 :

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

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

1. Commencez par exécuter la commande suivante :

   xe sr-probe-ext type=gfs2 device-config:provider=hba
   

   La sortie de la commande vous invite à fournir des paramètres supplémentaires et fournit 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 commande commence par Found the following complete configurations that can be used to create SRs:, vous pouvez localiser le SR à l’aide de la commande xe sr-create et des paramètres device-config 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: ```

Pour créer un SR GFS2 partagé sur un LUN spécifique d’un adaptateur HBA cible, 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 préserver la stabilité de votre pool en clusters en vous assurant qu’il dispose du quorum. Pour plus d’informations, voir Gérer votre pool clusterisé.

Si vous rencontrez des problèmes avec votre environnement GFS2, consultez Résoudreles problèmes liés aux pools en cluster.

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

Contraintes

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

• Comme pour tout SR à provisionnement dynamique, si l’utilisation du SR GFS2 atteint 100 %, les écritures supplémentaires des machines virtuelles échouent. Ces échecs d’écriture peuvent alors 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 apparaît. Sur un GFS2 SR, une utilisation élevée entraîne une dégradation des performances. Nous vous recommandons de maintenir votre consommation de SR inférieure à 80 %.

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

• Le transport FCoE n’est pas pris en charge avec les SR GFS2.

• TriM/UNMap 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 par 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 disques et les disques GFS2 sur ces SR.

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

• Vous ne pouvez pas exporter de VDI supérieurs à 2 Tio en tant que disque dur virtuel ou OVA/OVF. Toutefois, vous pouvez exporter des machines virtuelles avec des VDI supérieurs à 2 Tio au format XVA.

• Nous déconseillons d’utiliser un LUN à provisionnement léger 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 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 pulsateur SR 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 clusters à 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 tant que le cluster est actif et que des machines virtuelles sont en cours d’exécution. Cette action peut entraîner un redémarrage brutal (clôture) des hôtes du cluster.

• En cas de 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 dont le clustering est activé, le cluster ne se forme pas correctement et les hôtes ne sont pas en mesure de clôturer en cas de besoin. Pour résoudre ce problème, résolvez le conflit d’adresse IP.