Stockage en bloc partagé GFS2 à provisionnement fin

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 léger vous permet de réduire considérablement l’espace requis sur une baie de stockage partagée, ainsi que le coût total de possession (TCO).

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

  • Vous voulez une plus grande efficacité de l’espace. Les images sont éparpillées 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 sur le stockage en 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 clairsemée.
  • Votre stockage ne prend pas en charge NFS et ne prend en charge que le stockage par blocs. Si votre stockage prend en charge NFS, nous vous recommandons d’utiliser NFS au lieu de GFS2.
  • Vous souhaitez créer des VDI dont la taille est supérieure à 2 TiB. Le GFS2 SR prend en charge les VDI jusqu’à 16 TiB.

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.

Conditions préalables

Avant de commencer, assurez-vous que les conditions préalables suivantes sont remplies :

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

  • 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-clôture de l’ensemble du pool.

  • 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 de cluster à l’aide des ports suivants :
    • TCP : 8892, 21064
    • UDP : 5404, 5405

    Pour de plus amples informations, consultez la section Ports de communication utilisés par Citrix Technologies.

  • 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é après l’activation du clustering.

  • Vous disposez d’un périphérique de stockage basé sur des blocs qui est visible par tous les serveurs Citrix Hypervisor dans le pool de ressources.

Configurer un pool en cluster pour utiliser un GFS2 SR partagé

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.

Remarque :

Les pools en cluster se comportent différemment des pools non groupés. Pour plus d’informations sur le comportement du cluster, reportez-vous à la sectionPools en cluster.

Si vous préférez, vous pouvez configurer le clustering sur votre pool à l’aide de XenCenter. Pour plus d’informations, consultez la Documentation produit XenCenter.

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

  1. Créez un réseau lié à utiliser comme réseau de clustering. Sur le serveur Citrix Hypervisor que vous souhaitez être le maître de pool, procédez comme suit :

    1. Ouvrez une console sur le serveur Citrix Hypervisor.

    2. Nommez votre pool de ressources à l’aide de la commande suivante :

      xe pool-param-set name-label="New Pool" uuid=<pool_uuid>
      
    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
      

      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
      
    5. Créez votre réseau lié en mode actif-actif, actif-passif ou 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 à coller :

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

        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 retourné après l’exécution de la commande.

      • Pour configurer la liaison en mode actif-passif ou liaison 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
        

    Après avoir créé votre réseau lié sur le maître de pool, lorsque vous joignez d’autres serveurs Citrix Hypervisor au pool, les informations réseau et liaison sont automatiquement répliquées sur le serveur de jointure.

    Pour de plus amples informations, consultez la section Gestion des réseaux.

  2. 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 est un membre du pool (non maître) :

    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
      

      La valeur dumaster-address paramètre doit être définie sur le nom de domaine complet du serveur Citrix Hypervisor qui est le maître de pool. Lepassword doit être le mot de passe administrateur défini lors de l’installation du maître de pool.

    Pour de plus amples informations, consultez la section Hôtes et pools de ressources.

  3. Pour chaque PIF appartenant à ce réseau, définissezdisallow-unplug=true.

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

      xe pif-list
      
    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>
      
  4. 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>
    

    Indiquez l’UUID du réseau lié que vous avez créé lors d’une étape antérieure.

Configurer le multiacheminement du stockage sur votre GFS2 SR partagé

Important :

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

  • Plusieurs cibles sont disponibles 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
    
  • Pour iSCSI uniquement, 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 souhaitez quatre chemins d’accès à votre stockage, vous devez disposer de quatre cartes réseau pour lesquelles une adresse IP est configurée.

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

Vous pouvez utiliser XenCenter pour configurer le multiacheminement du stockage. Pour plus d’informations, reportez-vous à Multiacheminement de stockage dans la documentation produit XenCenter.

Vous pouvez également utiliser l’interface de ligne de commande xe pour configurer le multiacheminement de stockage, procédez comme suit sur tous les serveurs Citrix Hypervisor de votre pool en cluster :

  1. Ouvrez une console sur le serveur Citrix Hypervisor.

  2. Débranchez tous les PBD sur le serveur à l’aide de la commande suivante :

    xe pbd-unplug uuid=<pbd_uuid>
    
  3. Définissez la valeur du paramètre other-config:multipathing sur true à l’aide de la commande suivante :

    xe host-param-set other-config:multipathing=true uuid=<server_uuid>
    
  4. Définissez la valeur du paramètre other-config:multipathhandle sur dmp à l’aide de la commande suivante :

<server_uuid>xe host-param-set autre-config:multipathhandle=dmp uuid=
  1. S’il existe des SRS sur le serveur qui s’exécutent en mode chemin unique mais qui ont plusieurs chemins d’accès :

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

    • Débranchez et rebranchez le PBD de tout SR affecté pour les reconnecter en utilisant le multiacheminement :

       xe pbd-unplug uuid=<pbd_uuid>
       xe pbd-plug uuid=<pbd_uuid>
      

Pour de plus amples informations, consultez la section Multiacheminement de stockage.

Créer un GFS2 SR partagé

Vous pouvez créer votre GFS2 SR partagé sur un LUN iSCSI ou un HBA.

Créer un GFS2 partagé sur iSCSI SR

Vous pouvez créer GFS2 sur des SRs iSCSI à l’aide de XenCenter. Pour plus d’informations, reportez-vous à Stockage iSCSI logiciel dans la documentation 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 du périphérique pour les SR GFS2 :

Nom du paramètre Description Obligatoire ?
provider Implémentation du fournisseur de blocs. Dans ce cas, iscsi. Oui
target Adresse IP ou nom d’hôte du serveur de fichiers iSCSI qui héberge Oui
targetIQN La cible IQN du serveur de fichiers iSCSI qui héberge la SR Oui
SCSIid ID SCSI de périphérique Oui

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

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

    La sortie 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 The following SRs were found:, vous pouvez utiliser les paramètres device-config que vous avez spécifiés pour localiser le SR lors de l’exécution de la commande xe sr-create.

Pour créer un GFS2 SR partagé sur une 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 pendant le montage des systèmes de fichiers GFS2, certains hôtes du pool en cluster risquent de se fermer.

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

Créer un GFS2 partagé sur HBA SR

Vous pouvez créer GFS2 sur HBA SRs à l’aide de XenCenter. Pour plus d’informations, reportez-vous à Stockage HBA matériel dans la documentation 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 du périphérique pour les SR GFS2 :

Nom du paramètre Description Obligatoire ?
provider Implémentation du fournisseur de blocs. Dans ce cas, hba. Oui
SCSIid ID SCSI de périphérique Oui

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

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 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 The following SRs were found:, vous pouvez utiliser les paramètres device-config que vous avez spécifiés pour localiser le SR lors de l’exécution de la commande xe sr-create.

Pour créer un GFS2 SR partagé sur une 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

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

Contraintes

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

  • La migration de machines virtuelles avec la migration de stockage en direct n’est pas prise en charge pour les machines virtuelles dont les VDI sont sur un GFS2 SR.
  • Le protocole FCoE n’est pas pris en charge avec les SRs GFS2.
  • TriM/UNMap n’est pas pris en charge sur les SR GFS2.
  • 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 les SR GFS2.
  • Vous ne pouvez pas exporter des VDI supérieurs à 2 TiB en tant que VHD ou OVA/OVF. Toutefois, vous pouvez exporter des machines virtuelles avec des VDI supérieurs à 2 TiB au format XVA.
  • Les pools en cluster ne prennent en charge que 16 hôtes par pool.
  • Si un réseau a été utilisé à la fois pour la gestion et le clustering, vous ne pouvez pas séparer le réseau de gestion sans recréer le cluster.
  • La modification de l’adresse IP du réseau de cluster à l’aide de XenCenter nécessite la mise en cluster et la désactivation temporaire de GFS2.
  • Ne modifiez pas la liaison de votre réseau de clustering lorsque le cluster est actif et dispose de machines virtuelles en cours d’exécution. Cette action peut entraîner la clôture du cluster.
  • 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 dont le clustering est activé, les hôtes ne sont pas clôturés. Pour résoudre ce problème, résolvez le conflit d’adresse IP.