Stockage en bloc partagé GFS2 alloué dynamiquement
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 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 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 fragmentée.
- Votre stockage ne prend pas en charge NFS et prend uniquement en charge le stockage en mode bloc. 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 Tio. Le GFS2 SR prend en charge les VDI d’une taille maximale de 16 Tio.
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 du domaine de contrôle.
-
Tous les hôtes du cluster doivent utiliser des adresses IP statiques pour le réseau du cluster.
-
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.
- 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, 21064
- UDP : 5404, 5405
Pour plus d’informations, consultez Ports de communication utilisés par les technologies Citrix.
-
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é.
-
Nous vous recommandons vivement d’utiliser un réseau lié pour votre pool en cluster qui n’est utilisé pour aucun autre trafic.
- Vous disposez d’un périphérique de stockage basé sur des blocs visible par tous les serveurs Citrix Hypervisor du pool de ressources.
Configurer un pool en cluster pour utiliser un SR GFS2 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 clusterisés. Pour plus d’informations sur le comportement des clusters, consultez Pools 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 du produit XenCenter.
Pour utiliser l’interface de ligne de commande xe pour créer un pool en cluster :
-
Créez un réseau lié à utiliser comme réseau de clustering.
Remarque :
Nous vous recommandons vivement d’utiliser un réseau lié dédié pour votre pool en cluster. N’utilisez pas ce réseau pour d’autres trafics.
Sur le serveur Citrix Hypervisor dont vous souhaitez être le maître du pool, procédez comme suit :
-
Ouvrez une console sur le serveur Citrix Hypervisor.
-
Nommez votre pool de ressources à l’aide de la commande suivante :
xe pool-param-set name-label="New Pool" uuid=<pool_uuid> -
Créez un réseau à utiliser avec la carte réseau liée à l’aide de la commande suivante :
xe network-create name-label=bond0L’UUID du nouveau réseau est renvoyé.
-
Recherchez les UUID des PIF à utiliser dans la liaison à l’aide de la commande suivante :
xe pif-list -
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-createpour 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>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
modeparamètre facultatif et spécifiezlacpouactive-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
-
Une fois que vous avez créé votre réseau lié sur le maître du pool, 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, reportez-vous à la section Mise en réseau.
-
-
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 de pool (non maître) :
- Ouvrez une console sur le serveur Citrix Hypervisor.
-
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=passwordLa valeur du paramètre
master-addressdoit être définie sur le nom de domaine complet du serveur Citrix Hypervisor qui est le maître du pool. Lepassworddoit ê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.
-
Pour chaque PIF appartenant à ce réseau, définissez
disallow-unplug=true.-
Recherchez les UUID des PIF appartenant au réseau à l’aide de la commande suivante :
xe pif-list -
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>
-
-
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>Fournissez l’UUID du réseau lié que vous avez créé lors d’une étape précédente.
Assurez-vous que le multiacheminement de stockage est configuré entre votre pool en cluster et votre GFS2 SR. Pour plus d’informations, voir Multiacheminement de stockage.
Création d’un SR GFS2 partagé
Vous pouvez créer votre SR GFS2 partagé sur un LUN iSCSI ou un HBA.
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 :
| Nom du paramètre | Description | Requis ? |
|---|---|---|
provider |
Implémentation du fournisseur de blocs. Dans ce cas, iscsi. |
Oui |
target |
L’adresse IP ou le 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 le SR | Oui |
SCSIid |
ID SCSI de l’appareil | Oui |
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>
-
Commencez par exécuter la commande suivante :
xe sr-probe-ext type=gfs2 device-config:provider=iscsiLa sortie de la commande vous invite à fournir des paramètres supplémentaires et fournit une liste de valeurs possibles à chaque étape.
-
Répétez la commande en ajoutant de nouveaux paramètres à chaque fois.
-
Lorsque la sortie de la commande commence par
The following SRs were found:, vous pouvez utiliser les paramètresdevice-configque vous avez spécifiés pour localiser le SR lors de l’exécution de la commandexe sr-create.
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 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 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 :
| Nom du paramètre | Description | Requis ? |
|---|---|---|
provider |
Implémentation du fournisseur de blocs. Dans ce cas, hba. |
Oui |
SCSIid |
ID SCSI de l’appareil | Oui |
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>
-
Commencez par exécuter la commande suivante :
xe sr-probe-ext type=gfs2 device-config:provider=hbaLa sortie de la commande vous invite à fournir des paramètres supplémentaires et fournit une liste de valeurs possibles à chaque étape.
-
Répétez la commande en ajoutant de nouveaux paramètres à chaque fois.
-
Lorsque la sortie de la commande commence par
The following SRs were found:, vous pouvez utiliser les paramètresdevice-configque vous avez spécifiés pour localiser le SR lors de l’exécution de la commandexe sr-create.
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
Pour plus d’informations sur l’utilisation des SR HBA, reportez-vous à la section Adaptateurs de bus hôte matériels.
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 ou une possible 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.
-
Il est déconseillé d’utiliser un LUN à provisionnement fin 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 le trafic de cluster, vous devez utiliser un réseau lié qui utilise au moins deux commutateurs réseau différents. N’utilisez pas ce réseau à d’autres fins.
- Pour modifier l’adresse IP du réseau de cluster à l’aide de XenCenter, le clustering et GFS2 doivent être temporairement désactivés.
- 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.
- En cas de conflit d’adresse IP (plusieurs hôtes ayant la même adresse IP) sur votre réseau de clustering impliquant au moins un hôte sur lequel 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.