layout: doc—

Stockage par blocs GFS2 partagé à provisionnement léger

Remarque :

XenCenter YYYY.x.x n’est pas encore pris en charge pour une utilisation avec Citrix Hypervisor 8.2 CU1 dans les environnements de production. Pour gérer votre environnement de production Citrix Hypervisor 8.2 CU1, utilisez XenCenter 8.2.7. Pour plus d’informations, consultez la documentation XenCenter 8.2.7.

Vous pouvez installer XenCenter 8.2.7 et XenCenter YYYY.x.x sur le même système. L’installation de XenCenter YYYY.x.x ne remplace pas votre installation de XenCenter 8.2.7.

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 les protocoles NFS ou SMB3 et prend uniquement en charge 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.

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.

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

• 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 meilleures pratiques suivantes renforcent la résilience contre les 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.

Remarque :

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

Pour créer un réseau lié à utiliser comme réseau de clustering :

1. Ouvrez l’Assistant Nouveau réseau.
2. Sur la première page de l’Assistant, sélectionnez Réseau lié, puis cliquez sur Suivant.
3. Sur la page Membres obligataires, sélectionnez les NIC que vous souhaitez lier ensemble. Pour sélectionner une carte réseau, cochez sa case dans la liste. Vous pouvez sélectionner jusqu’à quatre cartes réseau dans cette liste. Désactivez la case à cocher pour désélectionner une carte réseau.

4. En mode Liaison, choisissez le type de liaison :

   • Sélectionnez Actif-actif pour configurer une liaison actif-actif. Avec cette liaison, le trafic est équilibré entre les NIC liées. Si une carte réseau de la liaison échoue, le trafic réseau du serveur est automatiquement acheminé sur la deuxième carte réseau.
   • Sélectionnez Actif-passif pour configurer une liaison active-passive, où le trafic passe sur une seule des cartes réseau liées. Dans ce mode, la deuxième carte réseau ne devient active qu’en cas de défaillance de la carte réseau active, par exemple en cas de perte de connectivité réseau.
   • Sélectionnez LACP avec équilibrage de charge basé sur l’adresse MAC source pour configurer une liaison LACP. Avec cette liaison, la carte réseau sortante est sélectionnée sur la base de l’adresse MAC de la machine virtuelle d’où provient le trafic. Utilisez cette option pour équilibrer le trafic dans un environnement où plusieurs machines virtuelles sont sur le même hôte. Cette option ne convient pas s’il y a moins d’interfaces virtuelles (VIF) que de cartes réseau : l’équilibrage de charge n’est pas optimal car le trafic ne peut pas être réparti entre les cartes réseau.
   • Sélectionnez LACP avec équilibrage de charge basé sur l’adresse IP et le port de la source et de la destination pour configurer une liaison LACP. Cette liaison utilise l’adresse IP source, le numéro de port source, l’adresse IP de destination et le numéro de port de destination pour allouer le trafic entre les cartes réseau. Utilisez cette option pour équilibrer le trafic des machines virtuelles dans un environnement où le nombre de cartes réseau dépasse le nombre de VIF.

   Remarques :

   • Pour pouvoir afficher les options de liaison LACP dans XenCenter et créer une liaison LACP, configurez vSwitch comme pile réseau. En outre, vos commutateurs doivent prendre en charge la norme IEEE 802.3ad.
   • Les types de liaison actif-actif et actif-passif sont disponibles pour le vSwitch et le pont Linux.
   • Vous pouvez lier deux, trois ou quatre cartes réseau lorsque vSwitch est la pile réseau. Toutefois, vous ne pouvez lier que deux cartes réseau lorsque le pont Linux est la pile réseau.

5. Pour utiliser des trames étendues, définissez l’unité de transmission maximale (MTU) surune valeur comprise entre 1500 et 9216.
6. Activez la case à cocher Ajouter automatiquement ce réseau aux nouvelles machines virtuelles pour que le nouveau réseau soit ajouté aux nouvelles machines virtuelles créées à l’aide de l’Assistant Nouvelle machine virtuelle.
7. Cliquez sur Terminer pour créer le nouveau réseau et fermer l’Assistant.

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 Configuration des cartes réseau.

Remarques :

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

4. Configuration d’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.

Pour créer un pool en cluster :

1. Ouvrez la boîte de dialogue Nouveau pool en cliquant sur Nouveau pool dans la barre d’outils.
2. Entrez un nom pour le nouveau pool et une description facultative. Le nom s’affiche dans le volet Ressources .
3. Désignez le coordinateur du pool en sélectionnant un serveur dans la liste des coordinateurs .
4. Sélectionnez d’autres serveurs à placer dans le nouveau pool dans la liste Membres supplémentaires . Tous les serveurs gérés disponibles sont répertoriés. Si un serveur n’est pas répertorié, vous pouvez l’ajouter à la liste en cliquant sur Ajouter un nouveau serveur. Si un serveur géré n’est pas répertorié, cela peut être dû au fait qu’il ne satisfait pas à une ou plusieurs des exigences de jointure de pool répertoriées dans Exigences de pool.
5. Sélectionnez Créer un pool pour créer le pool et fermer la boîte de dialogue.
6. Sélectionnez le pool dans le panneau Ressources et dans son onglet Général, sélectionnez Propriétés. La fenêtre Propriétés du pool s’ouvre.
7. Dans l’onglet Clustering, sélectionnez Activer le clustering et choisissez le réseau lié dédié que vous avez créé comme réseau de cluster.
8. Cliquez sur OK.

5. 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 :

Procédez comme suit pour chaque serveur de votre pool :

1. Dans le volet Ressources, sélectionnez le serveur, puis mettez-le en mode de maintenance. Le temps que XenCenter migre toutes les machines virtuelles actives et débranche le stockage existant est court. Si le serveur est un coordinateur de pool, il est déconnecté et peut disparaître temporairement du volet Ressources pendant qu’un nouveau coordinateur de pool est affecté. Lorsque le serveur réapparaît dans le volet Ressources avec l’icône du mode de maintenance du), passez à l’étape suivante.
2. Dans l’onglet Général, sélectionnez Propriétés, puis sélectionnez l’onglet Multiacheminement .
3. Pour activer le multiacheminement, cochez la case Activer le multiacheminement sur ce serveur . Pour désactiver le multiacheminement, désactivez la case à cocher.
4. Cliquez sur OK pour appliquer le nouveau paramètre et fermer la boîte de dialogue. XenCenter enregistre la nouvelle configuration de stockage pendant un court délai.
5. Sortez le serveur du mode de maintenance. Sélectionnez le serveur dans le volet Ressources, cliquez avec le bouton droit de la souris et sélectionnez Quitter le mode de maintenance.

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.

6. Création d’un GFS2 SR

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.

Pour créer un SR iSCSI logiciel

Remarque :

Avant d’effectuer les étapes suivantes, assurez-vous que l’IQN de l’initiateur iSCSI est correctement défini pour tous les hôtes du pool. Pour plus d’informations, consultez Modification des propriétés du serveur.

1. Ouvrez l’assistant Nouveau référentiel de stockage  : cliquez sur Nouveau stockage dans la barre d’outils. Alternativement :
   • Sous l’onglet Stockage du pool ou du serveur sélectionné, cliquez sur Nouveau SR.
   • Dans le menu Stockage, cliquez sur New SR.
   • Dans le volet Ressources, sélectionnez un serveur ou un pool, puis cliquez avec le bouton droit de la souris et cliquez sur Nouveau SR dans le menu contextuel.
2. Sélectionnez iSCSI logiciel comme type de stockage physique, puis cliquez sur Suivant.
3. Dans la page Nom, entrez le nom de la nouvelle SR. Par défaut, l’assistant génère une description du SR. Cette description inclut un résumé des options de configuration que vous sélectionnez au fur et à mesure de votre progression dans l’Assistant. Pour entrer votre propre description, désactivez la case à cocher Génération automatique de la description et saisissez la case Description. Cliquez sur Next pour continuer.
4. Sur la page Provisioning, sélectionnez Thin Provisioning (GFS2).

5. Sur la page Emplacement, spécifiez les détails de la cible iSCSI :

   • Hôte cible : adresse IP ou nom DNS de la cible iSCSI. Il peut également s’agir d’une liste de valeurs séparées par des virgules.

   • Utiliser le protocole CHAP : cela n’est pas pris en charge avec les SR GFS2. Ne sélectionnez pas cette option.

   • IQN cible : pour spécifier l’IQN cible iSCSI, cliquez sur le bouton Découvrir les IQN, puis choisissez un IQN dans la liste IQN cible .

     Important :

     La cible iSCSI et tous les serveurs du pool ne doivent pas avoir le même ensemble IQN. Chaque cible et chaque initiateur iSCSI doivent disposer d’un IQN unique. Si un identifiant IQN non unique est utilisé, les données peuvent être corrompues, l’accès à la cible peut être refusé, ou les deux.

   • LUN cible : pour spécifier le LUN sur lequel créer le référentiel de stockage, cliquez sur le bouton Découvrir les LUN . Choisissez un LUN dans la liste des LUN cibles .

     Chaque référentiel de stockage iSCSI individuel doit être entièrement contenu sur un seul LUN. Le SR ne peut pas s’étendre sur plus d’un LUN. Si le LUN contient déjà un SR, choisissez d’utiliser le SR existant ou de remplacer le SR existant par un nouveau. Le remplacement du SR existant détruit toutes les données présentes sur le disque.

6. Cliquez sur Terminer pour terminer la nouvelle configuration du SR et fermer l’assistant.

Pour créer un SR d’adaptateur HBA matériel

1. Pour ouvrir l’Assistant Nouveau référentiel de stockage, vous pouvez effectuer l’une des actions suivantes :
   • Dans la barre d’outils, sélectionnez Nouveau stockage.
   • Dans l’onglet Stockage du pool ou du serveur sélectionné, sélectionnez Nouveau SR.
   • Dans le menu Stockage, sélectionnez Nouveau SR.
   • Dans le volet Ressources, sélectionnez un serveur ou un pool, puis cliquez avec le bouton droit de la souris et sélectionnez Nouveau SR dans le menu contextuel.
2. Sélectionnez HBA matériel comme type de stockage physique, puis sélectionnez Suivant.
3. Dans la page Nom, entrez le nom de la nouvelle SR. Par défaut, l’assistant génère une description du SR. Cette description inclut un résumé des options de configuration que vous sélectionnez au fur et à mesure de votre progression dans l’Assistant. Pour entrer votre propre description, désactivez la case à cocher Génération automatique de la description et saisissez la case Description. Cliquez sur Suivant pour passer à la page Provisioning .
4. Sur la page Provisioning, sélectionnez le Thin Provisioning (GFS2).
5. Cliquez sur Suivant pour accéder à la page Emplacement .

6. L’Assistant recherche les LUN disponibles, puis affiche une page répertoriant tous les LUN trouvés. Sélectionnez un LUN dans la liste, puis cliquez sur Créer.

   Remarque :

   Un message d’avertissement s’affiche s’il existe des SR existants sur le LUN que vous avez sélectionné. Vérifiez les détails et choisissez l’une des options suivantes.

   • Pour utiliser l’existant, cliquez sur Réattacher.
   • Pour supprimer le SR existant et créer un SR, cliquez sur Format.
   • Si vous préférez sélectionner un autre LUN, cliquez sur Annuler et sélectionnez un LUN dans la liste.

7. La page Récapitulatif affiche des informations sur le nouveau SR. Lisez les informations, puis cliquez sur Terminer pour terminer le processus de création de SR.

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.

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