XenServer

Stockage par blocs GFS2 partagé à provisionnement léger

August 1, 2026

Contributeur:

Le provisionnement léger optimise l’utilisation du stockage disponible en allouant de l’espace de stockage disque aux VDI au fur et à mesure que les données sont écrites sur le disque virtuel, plutôt que d’allouer la taille virtuelle complète du VDI à l’avance. Le provisionnement léger vous permet de réduire considérablement l’espace requis sur un tableau de stockage partagé, et par conséquent votre coût total de possession (TCO).

Avertissement :

GFS2 présente un certain nombre de limitations et de complexités qui doivent être soigneusement prises en compte avant de continuer. Dans de nombreux cas, une stratégie de stockage alternative sera plus appropriée.

Les limitations de GFS2 incluent :

Fonctionnalités limitées (pas de prise en charge de la reprise après sinistre, pas de prise en charge de la migration de stockage, tailles de pool limitées à 16)

Limitations de performance, le rendant inadapté aux charges de travail importantes et gourmandes en E/S

Nécessite des services de cluster, ce qui peut entraîner des problèmes de stabilité

Plus complexe à comprendre, ce qui entraîne davantage de mauvaises configurations et d’erreurs

Compte tenu de ces limitations et complexités, il est recommandé d’utiliser GFS2 uniquement lorsqu’il n’existe pas d’alternatives pour répondre aux exigences. Les scénarios où GFS2 peut être approprié sont :

Le provisionnement léger est requis et n’est pas fourni par votre SAN. Il est recommandé d’utiliser le stockage LVM avec un SAN qui répond aux exigences de provisionnement léger. Lorsque cela n’est pas possible, GFS2 peut être envisagé.

Prise en charge des disques >2 Tio. GFS2 prendra en charge des disques allant jusqu’à 16 To. Lorsque des disques >2 Tio sont requis, GFS2 peut être envisagé. Les clients doivent effectuer des tests pour s’assurer que l’environnement peut répondre aux exigences de charge et de performance.

Si votre SAN prend en charge le provisionnement léger, nous vous recommandons de l’utiliser, avec LVM, de préférence à GFS2, sauf si vous avez besoin de disques de VM de plus de 2 Tio. Dans les cas où des disques de VM de plus de 2 Tio sont requis, envisagez plusieurs disques dans LVM pour y parvenir.

Le type GFS2 partagé représente les disques comme un système de fichiers créé sur un LUN iSCSI ou HBA. Les VDI stockés sur un SR GFS2 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 produit de XenCenter.

1. Planifiez votre environnement GFS2

Pour offrir les avantages du provisionnement dynamique sur le stockage en bloc partagé sans risque de perte de données, votre pool doit offrir un bon niveau de fiabilité et de connectivité. Il est crucial que les hôtes du pool de ressources qui utilise GFS2 puissent communiquer de manière fiable entre eux. Pour ce faire, XenServer® 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 XenServer pour offrir autant de résilience et de redondance que possible.

Avant de configurer votre pool XenServer pour fonctionner avec des SR GFS2, examinez les exigences et recommandations suivantes pour un environnement GFS2 idéal :

Recommandé : Configurez une infrastructure réseau redondante.
Recommandé : Créez un réseau agrégé dédié
Requis : Configurez un pool en cluster
Facultatif Augmentez la mémoire de votre domaine de contrôle
Recommandé : Configurez le multipathing de stockage
Requis : Créez un SR GFS2

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

2. Configurez une infrastructure réseau redondante

Un réseau agrégé relie deux cartes réseau (NIC) ou plus pour créer un canal unique pour le trafic réseau. Nous vous recommandons d’utiliser un réseau agrégé pour le trafic de votre pool en cluster. Cependant, avant de configurer votre réseau agrégé, assurez-vous que la configuration de votre matériel réseau favorise la redondance dans le réseau agrégé. Envisagez de mettre en œuvre autant de ces recommandations que possible pour votre organisation et votre environnement.

Les meilleures pratiques suivantes ajoutent de la résilience contre les pannes logicielles, matérielles ou électriques qui peuvent affecter vos commutateurs réseau.

Assurez-vous de disposer de commutateurs réseau physiques distincts pour le réseau agrégé, et pas seulement de ports sur le même commutateur.
Assurez-vous que les commutateurs distincts sont alimentés par des unités de distribution d’énergie (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 compagnies d’électricité.
Envisagez d’utiliser des unités d’alimentation sans interruption (UPS) pour vous assurer 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éer un réseau agrégé 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 agrégé pour ce trafic de pool augmente la résilience de votre pool en cluster.

Remarque :

Le réseau de cluster ne peut pas être sur un VLAN non-gestion.

Un réseau agrégé crée un lien entre deux ou plusieurs cartes réseau pour former un canal unique et performant que votre pool en cluster peut utiliser pour le trafic de pulsation du cluster. Nous recommandons fortement que ce réseau agrégé ne soit pas utilisé pour d’autres trafics. Créez un réseau séparé pour le pool à utiliser 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 de cluster. La perte de paquets réseau de gestion de cluster peut entraîner la perte de quorum de votre pool en cluster et certains ou tous les hôtes du pool s’auto-isoleront.

Si votre cluster est en train de s’isoler ou rencontre un problème dans cette configuration non recommandée, le support XenServer pourrait 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 agrégé à utiliser comme réseau de cluster GFS2 :

Si vous avez un pare-feu entre les hôtes de votre pool, assurez-vous que les hôtes peuvent communiquer sur le réseau de cluster en utilisant les ports suivants :
- TCP : 8892, 8896, 21064
- UDP : 5404, 5405
Pour plus d’informations, consultez (/fr-fr/xenserver/9/system-requirements/connectivity.html#communication-ports-used-by-xenserver-product-components) [Ports de communication utilisés par XenServer].
Ouvrez une console sur l’hôte XenServer que vous souhaitez désigner comme coordinateur de pool.
Créez un réseau à utiliser avec la carte réseau agrégée à l’aide de la commande suivante :
```
xe network-create name-label=bond0

```
L’UUID du nouveau réseau est renvoyé.
Trouvez les UUID des PIF à utiliser dans l’agrégation à l’aide de la commande suivante :
```
xe pif-list

```
Créez votre réseau agrégé en mode actif-actif, actif-passif ou LACP. Selon le mode d’agrégation que vous souhaitez utiliser, effectuez l’une des actions suivantes :
- Pour configurer l’agrégation en mode actif-actif (par défaut), utilisez la commande bond-create pour créer l’agrégation. En utilisant des virgules pour séparer les paramètres, spécifiez l’UUID du réseau nouvellement créé et les UUID des PIF à agréger :
```
 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 agrégez deux cartes réseau et quatre UUID lorsque vous agrégez quatre cartes réseau. L’UUID de l’agrégation est renvoyé après l’exécution de la commande.
- Pour configurer l’agrégation en mode 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
 
```

Après avoir créé votre réseau agrégé sur le coordinateur de pool, lorsque vous joignez d’autres hôtes XenServer au pool, les informations de réseau et d’agrégation sont automatiquement répliquées sur le serveur rejoignant.

Pour plus d’informations, consultez Mise en réseau.

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 l’agrégation de votre réseau de cluster lorsque le cluster est actif et contient des machines virtuelles en cours d’exécution. Cette action peut entraîner le redémarrage brutal (fence) des hôtes du cluster.

Si vous avez un conflit d’adresses IP (plusieurs hôtes ayant la même adresse IP) sur votre réseau de cluster impliquant au moins un hôte avec le clustering activé, le cluster ne se forme pas correctement et les hôtes ne peuvent pas être mis en quarantaine (fence) si nécessaire. Pour résoudre ce problème, résolvez le conflit d’adresses IP.

La valeur de 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 la valeur token-timeout en secondes pour le pool :

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

Si le temps de basculement du lien réseau est susceptible d’être supérieur à la valeur de délai d’attente, votre infrastructure et configuration réseau pourraient ne pas être 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 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 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 sont conscients de l’état de chaque hôte du cluster. Cette coordination des hôtes permet au cluster de contrôler l’accès au contenu du SR GFS2. 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 appelé un hôte ayant un quorum. Si un hôte n’a pas de quorum, il redémarre brutalement et se retire du cluster. Cette action est appelée ‘fencing’.

Pour plus d’informations, consultez Pools en cluster.

Avant de commencer à configurer votre pool en cluster, assurez-vous que les prérequis suivants sont remplis :

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 un quorum. 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-fencing de l’ensemble du pool.

Les pools en cluster ne prennent en charge que jusqu’à 16 hôtes par pool.
Tous les hôtes XenServer du pool en cluster doivent disposer d’au moins 2 GiB 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 clusterisez 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 :

Créez un pool de ressources d’au moins trois hôtes XenServer.

Répétez les étapes suivantes sur chaque hôte XenServer rejoignant qui n’est pas le coordinateur du pool :
1. Ouvrez une console sur l’hôte XenServer.
2. Joignez l’hôte XenServer au pool sur le coordinateur de pool en utilisant la commande suivante :
```
xe pool-join master-address=<master_address> /
    master-username=<administrators_username> /
    master-password=<password>

```
  La valeur du paramètre master-address doit être définie sur le nom de domaine complet de l’hôte XenServer qui est le coordinateur de pool. Le password doit être le mot de passe administrateur défini lors de l’installation du coordinateur de pool.
Pour plus d’informations, consultez Hôtes et pools de ressources.
Pour chaque PIF appartenant à ce réseau, définissez disallow-unplug=true.
1. Trouvez les UUID des PIF appartenant au réseau en utilisant la commande suivante :
```
xe pif-list

```
2. 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>

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

```
Fournissez l’UUID du réseau agrégé que vous avez créé à une étape précédente.

5. Augmenter 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 subir une instabilité réseau. L’instabilité réseau peut causer 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 sur plusieurs chemins pour la redondance. Tous les chemins peuvent avoir un trafic actif pendant le fonctionnement normal, ce qui entraîne une augmentation du débit.

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

Votre commutateur Ethernet ou Fibre est configuré pour rendre plusieurs cibles 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
```
Cependant, vous pouvez effectuer une configuration supplémentaire pour activer le multipathing iSCSI pour les baies qui n’exposent qu’une seule cible. Pour plus d’informations, consultez Multipathing iSCSI pour les baies qui n’exposent qu’une seule cible.
Pour iSCSI uniquement, le domaine de contrôle (dom0) a une adresse IP sur chaque sous-réseau utilisé par le stockage multipath.

Assurez-vous que pour chaque chemin vers le 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 vers votre stockage, vous devez disposer de quatre cartes réseau, chacune avec une adresse IP configurée.
Pour iSCSI uniquement, chaque cible et initiateur iSCSI a un IQN unique.
Pour iSCSI uniquement, les ports cibles iSCSI fonctionnent en mode portail.
Pour les HBA uniquement, plusieurs HBA sont connectés au fabric du commutateur.
Si possible, utilisez plusieurs commutateurs redondants.

Pour activer le multipathing à l’aide de la CLI xe

Nous vous recommandons d’activer le multipathing 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>

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

```
S’il existe des SR sur les hôtes fonctionnant en mode chemin unique qui ont plusieurs chemins :
- Migrez ou suspendez tous les invités en cours d’exécution avec des disques virtuels dans les SR affectés.
- Rebranchez le PBD de tous les SR affectés pour les reconnecter à l’aide du multipathing :
```
 xe pbd-plug uuid=<pbd_uuid>
 
```
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âblages et, dans le cas de l’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éer un SR GFS2

Créez votre SR GFS2 partagé sur un LUN iSCSI ou HBA visible par tous les hôtes XenServer de votre pool de ressources. Nous ne recommandons pas d’utiliser un LUN à provisionnement léger avec GFS2. Cependant, 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 précédemment utilisé votre périphérique de stockage basé sur des blocs pour le provisionnement épais avec LVM, cela est détecté par XenServer. XenCenter vous donne la possibilité d’utiliser la partition LVM existante ou de formater le disque et de configurer une partition GFS2.

Créer un SR GFS2 partagé sur iSCSI

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

Paramètres device-config pour les SR GFS2 :

Nom du paramètre	Description	Obligatoire ?
`provider`	L’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 du périphérique	Oui

Vous pouvez trouver les valeurs à utiliser pour ces paramètres en utilisant 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

```
La sortie de la commande vous invite à fournir des paramètres supplémentaires et affiche une liste des 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 Found the following complete configurations that can be used to create SRs:, vous pouvez localiser le SR en utilisant la commande xe sr-create et les 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:
<!--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 lorsque les systèmes de fichiers GFS2 sont montés, certains hôtes du pool en cluster peuvent redémarrer brutalement (fence).

Pour plus d’informations sur l’utilisation des SR iSCSI, consultez Stockage iSCSI logiciel.

Créer un SR GFS2 partagé sur HBA

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

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

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

Vous pouvez trouver les valeurs à utiliser pour le paramètre SCSIid en utilisant 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=hba

```
La sortie de la commande vous invite à fournir des paramètres supplémentaires et fournit une liste des valeurs possibles à chaque étape.
Répétez la commande, en ajoutant de nouveaux paramètres à chaque fois.

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, consultez Stockage HBA matériel.

Et ensuite ?

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, consultez (/fr-fr/xenserver/9/hosts-pools/troubleshoot.html).

Vous pouvez gérer votre SR GFS2 de la même manière que les autres SR. Par exemple, vous pouvez ajouter de la capacité à la baie de stockage pour augmenter la taille du LUN. Pour plus d’informations, consultez (/fr-fr/xenserver/9/storage/manage.html#live-lun-expansion).

Contraintes

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

Intellicache™ n’est pas pris en charge pour les machines virtuelles utilisant un SR GFS2.
Comme pour tout SR à provisionnement dynamique, si l’utilisation du SR GFS2 atteint 100 %, les écritures ultérieures 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 l’utilisation de votre SR atteint 80 %. Assurez-vous de surveiller votre SR GFS2 pour cette alerte et prenez les mesures appropriées si elle est détectée. Sur un SR GFS2, une utilisation élevée entraîne une dégradation des performances. Nous vous recommandons de maintenir l’utilisation de votre SR en dessous de 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 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 le FCoE entièrement déchargé, utilisez un HBA).
Trim/unmap n’est pas pris en charge sur les SR GFS2.
CHAP n’est pas pris en charge sur les SR GFS2.
Vous ne pouvez pas exporter des VDI de plus de 2 Tio au format VHD ou OVA/OVF. Cependant, vous pouvez exporter des machines virtuelles avec des VDI de plus de 2 Tio au format XVA.
Nous ne recommandons pas d’utiliser un LUN à provisionnement dynamique avec GFS2. Cependant, si vous choisissez cette configuration, vous devez vous assurer que le LUN dispose toujours de suffisamment d’espace pour permettre à XenServer d’y écrire.
Nous ne recommandons pas d’utiliser la déduplication SAN avec les SR GFS2. Cependant, 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 XenServer puisse y écrire.
Votre système de fichiers GFS2 ne peut pas dépasser 100 Tio.
Vous ne pouvez pas avoir plus de 62 SR GFS2 dans votre pool.
Les pools en cluster ne prennent en charge que jusqu’à 16 hôtes par pool.
Pour activer la haute disponibilité (HA) sur votre pool en cluster, le SR de pulsation doit être un SR GFS2.
Pour le trafic de cluster, nous vous recommandons fortement d’utiliser un réseau agrégé 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 l’agrégation de votre réseau de cluster tant que le cluster est actif et contient des machines virtuelles en cours d’exécution. Cette action peut entraîner le redémarrage forcé (fence) des hôtes du cluster.
Si vous avez un conflit d’adresses IP (plusieurs hôtes ayant la même adresse IP) sur votre réseau de cluster impliquant au moins un hôte avec le clustering activé, le cluster ne se forme pas correctement et les hôtes ne peuvent pas être mis en quarantaine (fence) si nécessaire. Pour résoudre ce problème, résolvez le conflit d’adresses IP.

La version officielle de la documentation de ce produit est en anglais. Toute version dans une langue autre que l’anglais est fournie uniquement à titre indicatif et peut inclure du contenu traduit automatiquement. Pour en savoir plus, veuillez consulter la clause de non-responsabilité relative à la traduction automatique sur Cloud Software Group home.

Cela vous a-t-il été utile ?

Stockage par blocs GFS2 partagé à provisionnement léger

August 1, 2026

Contributeur:

August 1, 2026

Contributeur:

Dans cet article

1. Planifiez votre environnement GFS2
2. Configurez une infrastructure réseau redondante
3. Créer un réseau agrégé dédié
4. Configurer un pool en cluster
5. Augmenter la mémoire de votre domaine de contrôle
6. Configurer le multipathing de stockage
7. Créer un SR GFS2
Et ensuite ?
Contraintes

Cela vous a-t-il été utile ?