Pools de ressources
Un pool de ressources ** comprend plusieurs installations hôtes XenServer, liées entre elles à une seule entité gérée pouvant héberger des machines virtuelles. S’il est associé à un stockage partagé, un pool de ressources permet de démarrer des machines virtuelles quelconque XenServer qui dispose de suffisamment de mémoire.
Le coordinateur de pool ** (anciennement « pool master ») est un serveur du pool de ressources qui expose une interface d’administration (utilisée par XenCenter et l’interface de ligne de commande XenServer, connue sous le nom de xe CLI). Le coordinateur du pool transmet les commandes aux membres individuels si nécessaire.
Cet article décrit les concepts, les exigences et les meilleures pratiques concernant les pools de ressources. Pour plus d’informations sur la création et la gestion de vos pools, consultez Gérer vos pools.
Avantages des pools de ressources
Bien que vous puissiez organiser vos hôtes XenServer en tant qu’hôtes autonomes , en fait un pool d’un seul, XenServer est optimisé pour les hôtes regroupés dans des pools de ressources avec stockage partagé. Plusieurs de nos fonctionnalités, telles que la haute disponibilité et la migration en direct, ne sont disponibles que dans les pools de ressources de plusieurs hôtes. Les avantages de l’organisation de vos hôtes XenServer en pools de ressources sont les suivants :
- Mobilité des VM: Lorsque vos VM s’exécutent sur un pool et que leurs disques se trouvent sur le stockage partagé du pool, ces VM peuvent être déplacées dynamiquement entre les hôtes XenServer tout en étant toujours en cours d’exécution (migration à chaud). De plus, si un hôte XenServer individuel subit une panne matérielle, l’administrateur peut redémarrer les machines virtuelles défaillantes sur un autre hôte XenServer dans le même pool de ressources.
- Haute disponibilité Cette fonctionnalité permet de protéger les machines virtuelles de votre charge de travail et de garantir qu’elles subissent un temps d’arrêt minimal en cas de défaillance matérielle ou de l’hôte. Lorsque la haute disponibilité est activée sur le pool de ressources, les machines virtuelles peuvent redémarrer automatiquement sur un autre hôte lorsque leur hôte tombe en panne. Si le coordinateur de pool échoue, la haute disponibilité élit un autre coordinateur de pool. Pour plus d’informations, voir Haute disponibilité.
- Équilibrage de la charge de travail L’équilibrage de la charge de travail peut évaluer votre pool de ressources et la charge de travail des machines virtuelles qui y sont exécutées pour recommander le placement optimal pour vos machines virtuelles. Vous pouvez également choisir que Workload Balancing suive automatiquement ses recommandations de placement et migre vos machines virtuelles entre les hôtes du pool. Pour plus d’informations, consultez Équilibrage de la charge de travail.
- Placement de VM anti-affinité: Assurez-vous que les VM d’un groupe sont réparties uniformément sur les hôtes d’un pool. Pour plus d’informations, consultez Placement de la machine virtuelle.
- Facilité de gestion: Plutôt que de gérer chaque hôte XenServer individuellement, ajoutez le pool de ressources à XenCenter et gérez ensemble tous les hôtes, SR et VM qu’il contient. Pour plus d’informations, voir XenCenter.
Configuration requise pour la création de pools de ressources
Lors de la conception de votre déploiement XenServer et du choix de la configuration de votre pool, tenez compte des exigences suivantes :
Configuration matérielle requise
Tous les serveurs d’un pool de ressources XenServer doivent avoir des processeurs largement compatibles, c’est-à-dire :
-
Le fournisseur de processeur (Intel, AMD) doit être le même sur tous les processeurs de tous les serveurs.
-
La virtualisation doit être activée sur tous les processeurs.
En fonction de la similitude des processeurs, le pool appartient à l’un des types suivants :
-
Pool homogène: Un pool de ressources homogène est un agrégat de serveurs avec des CPU identiques. Les processeurs d’un serveur rejoignant un pool de ressources homogène doivent avoir le même fournisseur, le même modèle et les mêmes fonctionnalités que les processeurs des serveurs déjà présents dans le pool.
-
Pool hétérogène: La création de pools hétérogènes est rendue possible grâce à l’utilisation de technologies dans les processeurs Intel (FlexMigration) et AMD (Extended Migration) qui fournissent un masquage CPU ou un nivellement. Ces fonctionnalités permettent de configurer un processeur pour Apparaître comme fournir une marque, un modèle ou un ensemble de fonctionnalités différents de ceux qu’il fait réellement. Ces fonctionnalités vous permettent de créer des pools d’hôtes avec différents processeurs, tout en prenant en charge en toute sécurité les migrations dynamiques. En raison de ce masquage ou de ce nivellement des fonctionnalités, vous risquez de ne pas bénéficier des performances optimales de vos processeurs.
Conditions requises pour rejoindre l’hôte
XenServer vérifie que les conditions suivantes sont vraies pour que l’hôte rejoigne le pool :
-
Il doit exécuter la même version de XenServer, au même niveau de correctif, que les hôtes déjà présents dans le pool.
-
L’hôte qui rejoint n’est pas membre d’un pool de ressources existant.
-
L’hôte qui rejoint n’a aucun stockage partagé configuré.
-
L’hôte qui rejoint n’héberge aucune machine virtuelle en cours d’exécution ou suspendue.
-
Aucune opération active n’est en cours sur les machines virtuelles de l’hôte qui rejoint l’organisation, comme l’arrêt ou l’exportation d’une machine virtuelle.
-
L’horloge de l’hôte qui rejoint le pool est synchronisée à la même heure que celle du coordinateur du pool (par exemple, en utilisant NTP).
-
L’interface de gestion de l’hôte qui rejoint n’est pas liée. Vous pouvez configurer l’interface de gestion lorsque l’hôte rejoint le pool.
-
L’adresse IP de gestion de l’hôte qui rejoint est statique, soit configurée sur l’hôte lui-même, soit en utilisant une configuration appropriée sur votre serveur DHCP.
-
L’interface de gestion de l’hôte qui rejoint se trouve sur le même VLAN balisé que celui du pool de ressources.
-
L’hôte qui rejoint doit être configuré avec les mêmes packs supplémentaires à la même révision que les hôtes déjà présents dans le pool.
-
L’hôte qui rejoint le pool doit avoir la même licence XenServer que les hôtes déjà présents dans le pool. Vous pouvez modifier la licence de n’importe quel membre du pool après avoir rejoint le pool. L’hôte avec la licence la plus basse détermine les fonctionnalités disponibles pour tous les membres du pool.
Si vous ajoutez un hôte à un pool à l’aide de XenCenter, XenCenter garantit qu’une licence correspondante est appliquée à l’hôte qui le rejoint. Cependant, si vous effectuez une jonction de pool à l’aide de l’interface de ligne de commande xe, nous vous recommandons d’attribuer une licence correspondante à l’hôte avant de le joindre au pool.
-
L’hôte qui rejoint le pool doit se trouver sur le même site que celui-ci et être connecté par un réseau à faible latence.
Exigences de stockage
Le stockage partagé utilisé par le pool de ressources présente les exigences suivantes :
- Les serveurs fournissant un stockage NFS ou iSCSI partagé pour le pool doivent avoir une adresse IP statique ou un bail DHCP statique.
Taille de piscine recommandée
La limite de configuration répertoriée de 64 est le nombre maximal d’hôtes que nous prenons en charge dans un pool. Cependant, il ne s’agit pas d’une taille de pool recommandée, car elle n’est souvent pas la taille optimale du point de vue de la gestion ou des performances pour la plupart des charges de travail. Tenez compte des facteurs suivants pour décider de la taille optimale de votre déploiement :
-
Considérations de gestion: La majeure partie de la gestion XenServer est effectuée au niveau du pool. Un pool plus grand réduit la quantité de gestion requise et vous permet de gérer davantage d’hôtes ensemble. Cependant, certaines opérations de gestion, par exemple l’application de mises à jour à un pool, peuvent prendre plus de temps si vous avez plusieurs hôtes, car l’opération doit être effectuée séquentiellement sur chaque hôte du pool. Dans ce cas, vous pourriez avoir besoin d’une fenêtre de maintenance plus longue pour effectuer certaines opérations dans un grand pool que pour plusieurs pools plus petits.
-
Partage des ressources: Un pool XenServer partage généralement des ressources telles que des référentiels de stockage entre les hôtes. Un pool plus grand permet à davantage d’hôtes de partager des ressources, ce qui peut présenter des avantages. Par exemple, dans votre environnement Citrix Virtual Apps and Desktops, vous pouvez avoir plusieurs hôtes partageant une image Gold, plutôt que de devoir créer plusieurs copies sur différents pools. Cependant, les périphériques particuliers que vous choisissez pour vos ressources partagées peuvent avoir des considérations de performances spécifiques qui rendent préférable l’utilisation de groupes d’hôtes plus petits.
-
Performances du plan de contrôle: Dans un pool XenServer, toutes les opérations sont gérées par le coordinateur du pool. La charge sur la pile d’outils de cet hôte augmente à mesure que vous ajoutez d’autres hôtes au pool : il y a davantage d’activités en arrière-plan de chaque hôte et le nombre attendu d’opérations simultanées augmente. À mesure que la charge sur la pile d’outils augmente, le temps nécessaire à chaque opération est susceptible d’augmenter. Par conséquent, un grand pool peut fonctionner sensiblement plus lentement que deux pools plus petits.
-
Isolation des pannes: Si XenServer ou un autre composant essentiel au pool (par exemple, un périphérique de stockage) rencontre un problème, dans un pool plus grand, cela peut avoir un impact plus important sur vos charges de travail que si cette charge de travail est répartie sur plusieurs pools plus petits.
-
Stockage GFS2: Si vous utilisez le stockage GFS2 pour le provisionnement léger sur le stockage en blocs, XenServer prend en charge un maximum de 16 hôtes. Cela est dû aux limitations de l’implémentation GFS2 et aux communications accrues requises entre les hôtes pour gérer le stockage.
-
Haute disponibilité: Si vous utilisez notre fonctionnalité de haute disponibilité pour protéger vos machines virtuelles, tous les hôtes du pool se surveillent en permanence et communiquent leur état. À mesure que la taille du pool augmente, le volume de messages que chaque hôte doit envoyer et recevoir dans le cadre de cette surveillance augmente. S’il y a une charge élevée sur le domaine de contrôle, cela peut augmenter la probabilité que certains de ces messages de surveillance soient perdus. Dans les scénarios extrêmes, la perte de messages peut amener les hôtes à se protéger de manière inattendue pour des raisons de sécurité. Lorsque vous utilisez la fonctionnalité de haute disponibilité, nous vous recommandons d’utiliser des pools plus petits, avec un maximum de 16 hôtes, pour réduire le risque de clôture inattendue.
Pour la plupart des cas d’utilisation de Citrix Virtual Apps and Desktops, nous recommandons une taille de pool de 16 hôtes, avec une taille maximale de 32.
En plus de prendre en compte ces facteurs lors de la planification de la taille de votre piscine, observez et surveillez le comportement de votre piscine pour déterminer si vous devez modifier la taille de la piscine dans votre environnement d’exécution.
Communiquer avec les hôtes XenServer et les pools de ressources
TLS
XenServer utilise le protocole TLS 1.2 pour chiffrer le trafic de l’API de gestion. Toute communication entre XenServer et les clients (ou appliances) de l’API de gestion utilise le protocole TLS 1.2.
Important :
Nous ne prenons pas en charge les modifications apportées par les clients à la fonctionnalité cryptographique du produit.
XenServer utilise les suites de chiffrement suivantes :
- ECDHE-RSA-AES256-GCM-SHA384
- ECDHE-RSA-AES128-GCM-SHA256
SSH
Lors de l’utilisation d’un client SSH pour se connecter directement à l’hôte XenServer, les algorithmes suivants peuvent être utilisés :
Chiffrement:
- AES128-CTR
- AES256-CTR
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
Mac:
- Référence : HMAC-SHA2-256
- HMAC-SHA2-512
- HMAC-SHA1
KexAlgorithms :
- Courbe25519-SHA256
- ECDH-SHA2-NISTP256
- ECDH-SHA2-NISTP384
- ECDH-SHA2-NISTP521
- diffie-hellman-groupe14-sha1
HostKeyAlgorithms :
- ECDSA-SHA2-NISTP256
- ECDSA-SHA2-NISTP384
- ECDSA-SHA2-NISTP521
- ssh-ed25519
- ssh-rsa
Important :
Nous ne prenons pas en charge les modifications apportées par les clients à la fonctionnalité cryptographique du produit. Cependant, si vous souhaitez désactiver l’accès SSH à un hôte XenServer, consultez Désactiver l’accès SSH pour un hôte ou Désactiver l’accès SSH pour un pool.
Que se passe-t-il lorsqu’un hôte rejoint un pool de ressources ?
Lorsqu’un nouvel hôte rejoint un pool de ressources, l’hôte qui le rejoint synchronise sa base de données locale avec celle à l’échelle du pool et hérite de certains paramètres du pool :
-
La configuration du stockage VM, local et distant est ajoutée à la base de données à l’échelle du pool. Cette configuration est appliquée à l’hôte qui rejoint le pool, sauf si vous partagez explicitement les ressources après que l’hôte a rejoint le pool.
-
L’hôte de jonction hérite des référentiels de stockage partagés existants dans le pool. Les enregistrements PBD appropriés sont créés afin que le nouvel hôte puisse accéder automatiquement au stockage partagé existant.
-
Les informations de mise en réseau sont partiellement héritées de l’hôte de jonction : le structural les détails des cartes réseau, des VLAN et des interfaces liées sont tous hérités, mais politique l’information ne l’est pas. Ces informations de stratégie, qui doivent être reconfigurées, comprennent :
-
Adresses IP des cartes réseau de gestion, qui sont conservées à partir de la configuration d’origine.
-
L’emplacement de l’interface de gestion, qui reste le même que la configuration d’origine. Par exemple, si les autres hôtes de pool ont des interfaces de gestion sur une interface liée, l’hôte de jonction doit être migré vers la liaison après la jonction.
-
Des cartes réseau de stockage dédiées, qui doivent être réaffectées à l’hôte de jonction à partir de XenCenter ou de l’interface de ligne de commande, et des PBD rebranchés pour acheminer le trafic en conséquence. Cela est dû au fait que les adresses IP ne sont pas attribuées dans le cadre de l’opération de jonction de pool et que la carte réseau de stockage ne fonctionne que lorsqu’elle est correctement configurée. Pour plus d’informations sur la façon de dédier une carte réseau de stockage à partir de l’interface de ligne de commande, reportez-vous à la section Gérer la mise en réseau.
-