Pools de ressources
Un pool de ressources comprend plusieurs installations d’hôtes XenServer®, liées ensemble en une seule entité gérée qui peut héberger des machines virtuelles. S’il est combiné avec un stockage partagé, un pool de ressources permet de démarrer des machines virtuelles sur n’importe quel hôte XenServer disposant de suffisamment de mémoire.
Le coordinateur de pool (anciennement « maître de pool ») 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 CLI xe). Le coordinateur de 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, c’est-à-dire un pool d’un seul hôte, XenServer est optimisé pour les hôtes regroupés en 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 d’organiser vos hôtes XenServer en pools de ressources sont les suivants :
- Mobilité des machines virtuelles : Lorsque vos machines virtuelles s’exécutent sur un pool et que leurs disques se trouvent sur le stockage partagé du pool, ces machines virtuelles peuvent être déplacées dynamiquement entre les hôtes XenServer tout en étant en cours d’exécution (migration en direct). De plus, si un hôte XenServer individuel subit une défaillance 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é protège les machines virtuelles de votre charge de travail et garantit un temps d’arrêt minimal en cas de défaillance matérielle ou d’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 en cas de défaillance de leur hôte. Si le coordinateur de pool échoue, la haute disponibilité élit un autre coordinateur de pool. Pour plus d’informations, consultez 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 s’exécute pour recommander le placement optimal de vos machines virtuelles. Vous pouvez également choisir que l’équilibrage de la charge de travail 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 machines virtuelles anti-affinité : Assurez-vous que les machines virtuelles d’un groupe sont réparties uniformément sur les hôtes d’un pool. Pour plus d’informations, consultez Placement des machines virtuelles.
- Facilité de gestion : Plutôt que de gérer chaque hôte XenServer individuellement, ajoutez le pool de ressources à XenCenter et gérez tous les hôtes, SR et machines virtuelles qu’il contient ensemble. Pour plus d’informations, consultez XenCenter.
Exigences pour la création de pools de ressources
Lors de la conception de votre déploiement XenServer et de la décision concernant la configuration de votre pool, prenez en compte les exigences suivantes :
Exigences matérielles
Tous les serveurs d’un pool de ressources XenServer doivent avoir des processeurs largement compatibles, c’est-à-dire :
-
Le fournisseur de CPU (Intel, AMD) doit être le même sur tous les CPU de tous les serveurs.
-
Tous les CPU doivent avoir la virtualisation activée.
Selon la similarité des CPU, le pool est de 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 CPU 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 CPU 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 par l’utilisation de technologies dans les CPU Intel (FlexMigration) et AMD (Extended Migration) qui fournissent le masquage ou le nivellement des CPU. Ces fonctionnalités permettent de configurer un CPU pour qu’il apparaisse comme offrant une marque, un modèle ou un ensemble de fonctionnalités différents de ce qu’il est réellement. Ces capacités vous permettent de créer des pools d’hôtes avec des CPU différents tout en prenant en charge en toute sécurité les migrations en direct. En raison de ce masquage ou nivellement de fonctionnalités, vous pourriez ne pas obtenir les performances maximales de vos CPU.
Exigences pour l’hôte rejoignant le pool
XenServer vérifie que les conditions suivantes sont remplies pour l’hôte rejoignant le pool :
-
Il doit exécuter la même version de XenServer, au même niveau de mise à jour, que les hôtes déjà présents dans le pool.
-
L’hôte rejoignant le pool n’est pas membre d’un pool de ressources existant.
-
L’hôte rejoignant le pool n’a pas de stockage partagé configuré.
-
L’hôte rejoignant le pool 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 rejoignant le pool, comme l’arrêt ou l’exportation d’une machine virtuelle.
-
L’horloge de l’hôte rejoignant le pool est synchronisée avec celle du coordinateur de pool (par exemple, en utilisant NTP).
-
L’interface de gestion de l’hôte rejoignant le pool n’est pas liée. Vous pouvez configurer l’interface de gestion lorsque l’hôte rejoint le pool avec succès.
-
L’adresse IP de gestion de l’hôte rejoignant le pool est statique, configurée soit 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 rejoignant le pool se trouve sur le même VLAN balisé que celui du pool de ressources.
-
L’hôte rejoignant le pool 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 rejoignant 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 tout membre du pool après l’avoir rejoint. 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 s’assure qu’une licence correspondante est appliquée à l’hôte rejoignant le pool. 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 rejoignant le pool doit se trouver sur le même site que le pool 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 partagé NFS ou iSCSI pour le pool doivent avoir une adresse IP statique ou un bail DHCP statique.
Taille de pool recommandée
La limite de configuration indiquée de 32 est le nombre maximal d’hôtes que nous prenons en charge dans un pool. Cependant, ce n’est pas une taille de pool recommandée, car ce 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 lorsque vous décidez de la meilleure taille pour votre déploiement :
-
Considérations de gestion : La plupart de la gestion de 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 plus 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 plus d’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 de 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 à plus 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 plus d’hôtes partageant une image dorée, 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 regroupements 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 de pool. La charge sur la pile d’outils de cet hôte augmente à mesure que vous ajoutez des hôtes au pool : il y a plus d’activités en arrière-plan de chaque hôte et le nombre attendu d’opérations concurrentes 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 critique pour le pool (par exemple, un périphérique de stockage) rencontre un problème, dans un pool plus grand, cela pourrait avoir un impact plus important sur vos charges de travail que si cette charge de travail était répartie sur plusieurs pools plus petits.
-
Stockage GFS2 : Si vous utilisez le stockage GFS2 pour le provisionnement léger sur le stockage par blocs, XenServer prend en charge un maximum de 16 hôtes. Cela est dû aux limitations de l’implémentation GFS2 et à l’augmentation des communications 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 mutuellement 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. Si la charge sur le domaine de contrôle est élevée, cela peut augmenter la probabilité de perte de certains de ces messages de surveillance. Dans des scénarios extrêmes, la perte de messages peut entraîner la mise hors service inattendue des hôtes pour des raisons de sécurité. Lorsque vous utilisez la fonction de haute disponibilité, nous vous recommandons d’utiliser des pools plus petits, avec un maximum de 16 hôtes, afin de réduire le risque de mise hors service 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 pool, observez et surveillez le comportement de votre pool pour déterminer si vous devez modifier la taille du pool dans votre environnement en cours 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 le client aux fonctionnalités cryptographiques 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 :
Chiffrements :
- aes128-ctr
- aes256-ctr
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
MACs :
- hmac-sha2-256
- hmac-sha2-512
- hmac-sha1
Algorithmes d’échange de clés :
- curve25519-sha256
- ecdh-sha2-nistp256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
Algorithmes de clé d’hôte :
- 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 le client aux fonctionnalités cryptographiques du produit. Toutefois, 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 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 du pool. Cette configuration est appliquée à l’hôte rejoignant le pool, sauf si vous partagez explicitement les ressources après que l’hôte a rejoint le pool.
-
L’hôte qui rejoint le pool hérite des référentiels de stockage partagés existants dans le pool. Des 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 par l’hôte qui rejoint le pool : les détails structurels des cartes réseau, des VLAN et des interfaces liées sont tous hérités, mais les informations de stratégie ne le sont pas. Ces informations de stratégie, qui doivent être reconfigurées, incluent :
-
Les adresses IP des cartes réseau de gestion, qui sont conservées 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 du pool ont des interfaces de gestion sur une interface liée, l’hôte qui rejoint le pool doit être migré vers la liaison après avoir rejoint le pool.
-
Les cartes réseau de stockage dédiées, qui doivent être réaffectées à l’hôte qui rejoint le pool depuis XenCenter ou la CLI, et les 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 la carte réseau de stockage ne fonctionne que si elle est correctement configurée. Pour plus d’informations sur la façon de dédier une carte réseau de stockage à partir de la CLI, consultez Gérer la mise en réseau.
-