Pools de ressources
Un pool de ressources comprend plusieurs installations d’hôtes XenServer®, liées entre elles pour former 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, ce qui équivaut à 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é permet de protéger les machines virtuelles de votre charge de travail et de garantir 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 afin de recommander le placement optimal pour 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 entre 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, tenez compte des exigences suivantes :
Exigences matérielles
Tous les serveurs d’un pool de ressources XenServer doivent avoir des CPU 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 complètes 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 l’heure du coordinateur de pool (par exemple, en utilisant NTP).
-
L’interface de gestion de l’hôte rejoignant le pool n’est pas agrégé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, 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 rejoignant est sur le même VLAN balisé que celle du pool de ressources.
-
L’hôte rejoignant 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 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 s’assure qu’une licence correspondante est appliquée à l’hôte rejoignant. 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 doit se trouver soit dans le même centre de données que le pool, soit dans un centre de données répondant à la définition de proximité, et être connecté par un réseau à faible latence (temps d’aller-retour inférieur à 5 ms) et à large bande passante (au moins 10 Gbit/s).
Exigences de stockage
Le stockage partagé utilisé par le pool de ressources a 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 pool recommandée
La limite de configuration indiquée de 64 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 est 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. En cas de charge élevée sur le domaine de contrôle, cela peut augmenter la probabilité de perte de certains de ces messages de surveillance. Dans des scénarios extrêmes, les messages perdus peuvent entraîner la mise en quarantaine inattendue des hôtes par mesure 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, afin de réduire le risque de mise en quarantaine 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 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 de l’API de gestion (ou les appliances) utilise le protocole TLS 1.2.
Important :
Nous ne prenons pas en charge les modifications apportées par le client à 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 :
Chiffrements :
- aes128-ctr
- aes256-ctr
- aes128-gcm@openssh.com
- aes256-gcm@openssh.com
MACs :
- hmac-sha2-256
- hmac-sha2-512
- hmac-sha1
KexAlgorithms :
- curve25519-sha256
- ecdh-sha2-nistp256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
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 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 rejoignant 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 rejoignant 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 rejoignant : les détails structurels des cartes réseau, des VLAN et des interfaces agrégé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 agrégée, l’hôte rejoignant doit être migré vers l’agrégat après avoir rejoint.
-
Les cartes réseau de stockage dédiées, qui doivent être réaffectées à l’hôte rejoignant depuis XenCenter ou la CLI, et les PBD rebranchés pour acheminer le trafic en conséquence. En effet, 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.
-