layout: doc description: “Thin provisioning better utilizes the available storage by allocating disk storage space to VDIs as data is written to the virtual disk, rather than allocating the full virtual size of the VDI in advance. The shared GFS2 type represents disks as a filesystem created on an iSCSI or HBA LUN.”—
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 :
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.
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 garantir cela, XenServer 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 XenServer de manière à fournir autant de résilience et de redondance que possible.
Avant de configurer votre pool XenServer 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.
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 meilleures pratiques suivantes renforcent la résilience contre les pannes logicielles, matérielles ou électriques susceptibles d’affecter vos commutateurs réseau.
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 XenServer 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 :
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 :
Pour plus d’informations, consultez la section Ports de communication utilisés par XenServer.
Ouvrez une console sur l’hôte XenServer que vous souhaitez utiliser en tant que coordinateur du pool.
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é.
Recherchez les UUID des PIF à utiliser dans la liaison à l’aide de la commande suivante :
xe pif-list
<!--NeedCopy-->
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-->
Après avoir créé votre réseau lié sur le coordinateur du pool, lorsque vous joignez d’autres hôtes XenServer au pool, les informations relatives au réseau et aux liaisons sont automatiquement répliquées sur le serveur de jonction.
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 :
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.
Pour utiliser le stockage GFS2 partagé, le pool de ressources XenServer 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 d’hôtes XenServer 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.
Pour utiliser l’interface de ligne de commande xe pour créer un pool en cluster :
Créez un pool de ressources d’au moins trois hôtes XenServer.
Répétez les étapes suivantes sur chaque hôte XenServer se joignant qui n’est pas le coordinateur du pool :
Joignez l’hôte XenServer au pool sur le coordinateur du 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 master-address paramètre doit être définie sur le nom de domaine complet de l’hôte XenServer qui est le coordinateur du pool. password doit être le mot de passe administrateur défini lors de l’installation du coordinateur du pool.
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
<!--NeedCopy-->
Exécutez la commande suivante sur un hôte XenServer de votre pool de ressources :
xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
<!--NeedCopy-->
Activez le clustering sur votre pool. Exécutez la commande suivante sur un hôte XenServer 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.
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.
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.
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.
Ouvrez une console sur l’hôte XenServer.
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.
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-->
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-->
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.
Créez votre GFS2 SR partagé sur un LUN iSCSI ou HBA visible par tous les hôtes XenServer 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 à XenServer 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 XenServer. XenCenter vous permet d’utiliser la partition LVM existante ou de formater le disque et de configurer une partition GFS2.
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>
<!--NeedCopy-->
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.
Répétez la commande en ajoutant de nouveaux paramètres à chaque fois.
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.
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=hba
La 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 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.
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.
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 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 à XenServer 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.