Architecture de référence XenServer® Enterprise

Présentation

Cette architecture de référence définit une approche recommandée pour la conception, le déploiement et l’exploitation de XenServer afin de prendre en charge les charges de travail à l’échelle de l’entreprise. Elle fournit une base validée pour l’hébergement d’environnements Citrix Virtual Apps and Desktops™ (CVAD), ainsi que pour la virtualisation de serveurs générale, en mettant l’accent sur l’évolutivité, la résilience et la simplicité opérationnelle.

L’architecture est construite autour du concept du pool de ressources XenServer comme unité centrale d’échelle et de gestion. Chaque pool de ressources est conçu pour fonctionner au sein d’un seul centre de données (ou d’un ensemble de centres de données étroitement connectés) et prend en charge l’exécution prévisible et haute performance des charges de travail. Les déploiements peuvent être mis à l’échelle horizontalement en ajoutant des pools de ressources supplémentaires pour répondre aux besoins croissants en capacité et aux exigences organisationnelles.

Principes de conception

Les principes suivants résument l’approche de conception :

• Pool de ressources comme unité d’échelle : Déployer et gérer les charges de travail au sein de pools de ressources bien définis, et mettre à l’échelle horizontalement en ajoutant des pools supplémentaires
• Isolation des charges de travail par conception : Aligner les pools de ressources sur des types de charges de travail spécifiques pour garantir des performances et un comportement opérationnel cohérents
• Modèle de capacité N+1 : Maintenir une capacité suffisante pour tolérer la défaillance d’un seul hôte sans impacter la disponibilité des charges de travail
• Séparation des préoccupations : Séparer clairement le trafic de gestion, de VM et de stockage pour garantir les performances, la résilience et la sécurité
• Stratégie de résilience explicite : Traiter la résilience intra-centre de données et la reprise après sinistre inter-centres de données comme des préoccupations architecturales distinctes
• Simplicité opérationnelle : Introduire des capacités optionnelles uniquement là où elles apportent une valeur claire, en évitant toute complexité inutile

Ensemble, ces principes fournissent un cadre cohérent pour la conception d’environnements XenServer évolutifs, résilients et simples à exploiter, tout en restant adaptables aux exigences changeantes des charges de travail et de l’organisation.

Cette architecture suppose l’utilisation d’un stockage bloc distant, d’une gestion d’identité intégrée via Active Directory et d’une gestion sécurisée via TLS. Des capacités optionnelles telles que l’équilibrage de charge (WLB), la haute disponibilité (HA) et la reprise après sinistre (DR) peuvent être intégrées en fonction des exigences des charges de travail, mais chacune introduit des considérations opérationnelles supplémentaires qui doivent être explicitement planifiées. L’architecture de référence est destinée aux environnements d’entreprise nécessitant des performances prévisibles et un contrôle opérationnel rigoureux. Elle n’est pas optimisée pour des scénarios spécialisés tels que des disques de VM individuels très volumineux (>2 To) ou des charges de travail gourmandes en GPU, qui peuvent nécessiter des conceptions ou des adaptations alternatives.

Dans l’ensemble, ce document sert à la fois de guide de conception et de cadre opérationnel, permettant aux organisations de déployer XenServer de manière cohérente et supportable tout en conservant la flexibilité d’étendre et de faire évoluer la plateforme au fil du temps.

Hypothèses et portée

L’architecture est basée sur un ensemble d’hypothèses fondamentales concernant l’échelle, l’infrastructure et les pratiques opérationnelles.

• Tout le matériel utilisé doit être répertorié dans la liste de compatibilité matérielle (HCL) de XenServer.

• Chaque pool de ressources est censé prendre en charge jusqu’à 1 000 machines virtuelles, les déploiements globaux étant mis à l’échelle en ajoutant des pools supplémentaires plutôt qu’en étendant un seul pool indéfiniment, jusqu’à un maximum de 200 pools. Tous les hôtes au sein d’un pool sont supposés fonctionner dans une limite de réseau étroitement couplée, garantissant un accès cohérent et fiable au stockage partagé.
  • Les hôtes doivent disposer de suffisamment de RAM pour prendre en charge la charge de travail requise et le domaine de contrôle avec toutes les exigences de mise en cache des performances (voir Dimensionnement du pool de ressources), jusqu’à un maximum de 6 To.
  • Les hôtes doivent disposer d’un stockage local pour le système d’exploitation XenServer (minimum 46 Go, idéalement 70 Go) ou être capables de démarrer depuis un SAN.
  • Les hôtes doivent utiliser le firmware UEFI ; le BIOS hérité n’est pas pris en charge dans XenServer 9.

• Le stockage est supposé être fourni via des systèmes distants basés sur des blocs, XenServer utilisant des référentiels de stockage basés sur LVM. L’efficacité et la résilience sont principalement assurées par la plateforme de stockage sous-jacente, y compris des fonctionnalités telles que le thin provisioning pour permettre une allocation active à l’utilisation, et le multipathing. Une connectivité de stockage continue et fiable est une exigence critique.

• La mise en réseau suit un modèle de séparation stricte entre le trafic de gestion, de machines virtuelles et de stockage. Pour ce faire, les hôtes doivent être équipés d’un minimum de 2 cartes réseau et 2 connexions Fibre Channel, ou de 4 cartes réseau. Cette séparation est combinée à des interfaces réseau agrégées pour offrir résilience et débit, tout en évitant les configurations qui introduisent des dépendances inutiles ou des contraintes de performance.

• La sécurité et l’identité sont considérées comme faisant partie intégrante de la conception. Les communications de gestion sont sécurisées à l’aide de TLS, et l’intégration avec Active Directory est supposée pour l’authentification et le contrôle d’accès basé sur les rôles. L’accès administratif est censé suivre les pratiques de sécurité d’entreprise standard, avec une utilisation restreinte des comptes locaux et une exposition contrôlée des interfaces de gestion.

• Sur le plan opérationnel, les pools de ressources sont conçus autour d’un modèle de capacité N+1, permettant aux charges de travail de continuer à fonctionner pendant la maintenance des hôtes ou en cas de défaillance d’un seul hôte. Les mises à jour et les mises à niveau sont censées être appliquées régulièrement pour maintenir la prise en charge et la sécurité. Lorsque la reprise après sinistre est requise, elle est mise en œuvre comme un processus opérationnel coordonné plutôt que comme une capacité de basculement transparente ou entièrement automatisée.

Des capacités optionnelles peuvent être intégrées si nécessaire, mais ne sont pas supposées par défaut. Celles-ci incluent :

• Équilibrage de la charge de travail (WLB)
• Haute disponibilité (HA) pour les charges de travail
• Reprise après sinistre (DR) entre les centres de données

Chacun d’eux introduit une complexité opérationnelle supplémentaire et devrait être adopté en fonction d’exigences claires en matière de charge de travail et d’entreprise.

Hors du champ d’application

Cette architecture de référence n’est pas conçue pour tous les scénarios et ne doit pas être considérée comme une solution universelle. En particulier, elle ne traite pas directement :

• Charges de travail nécessitant des disques virtuels individuels de plus de 2 To
• Charges de travail accélérées par GPU ou dépendantes du GPU
• Architectures nécessitant une mobilité de charge de travail active-active et transparente entre des centres de données géographiquement dispersés

Dans ces cas, des éléments de cette conception peuvent toujours être applicables, mais des considérations architecturales et des adaptations supplémentaires seront nécessaires.

Définitions

Termes et définitions pour faciliter la lecture et la compréhension de cette architecture de référence.

Plan d’architecture

Les attentes concernant les pools de ressources sont les suivantes :

• Chaque pool de ressources est conçu pour un maximum de 1000 machines virtuelles en cours d’exécution.
• Chaque pool de ressources est entièrement situé au sein d’un seul centre de données ou réparti sur des centres de données proches.
• Chaque pool de ressources est destiné à un cas d’utilisation spécifique, où toutes les charges de travail présentent des caractéristiques similaires en termes de disponibilité et de performances. Pour les petits déploiements, des cas d’utilisation mixtes sont possibles, mais il convient d’être prudent lors de l’examen de l’équilibrage de charge et des modes de défaillance des pools de ressources.

Voici des exemples de cas d’utilisation uniques :

• Des postes de travail virtuels pour un déploiement CVAD
• Serveurs d’applications pour le déploiement CVAD
• Infrastructure CVAD
• Charges de travail de virtualisation de serveur générales

Chaque pool de ressources aura les attributs suivants

• Protocole LVM utilisé pour tout le stockage par blocs distant. Il n’est pas recommandé d’utiliser le protocole GFS2.
• Haute disponibilité pour la gestion du coordinateur de pool
• Utilisation de TLS 1.2 pour toutes les communications de gestion
• Facultatif : Équilibrage de charge de travail (WLB) pour les machines virtuelles de charge de travail
• Facultatif : Haute disponibilité (HA) des machines virtuelles de charge de travail
• Facultatif : Reprise après sinistre (DR)
• Facultatif : XenServer Conversion Manager installé

Remarque :

La conception peut être mise à l’échelle en créant plusieurs pools de ressources au sein des centres de données ou entre les centres de données pour fournir la charge de travail là où elle est nécessaire.

Construisez chaque pool de ressources tel que défini dans les sections ci-dessous.

Configuration du pool de ressources principal

Lors de la création d’un nouveau pool de ressources, la meilleure pratique consiste à configurer un hôte autonome avec la configuration réseau et de stockage requise, puis à ajouter d’autres hôtes à ce pool. Les hôtes supplémentaires hériteront de la configuration lorsqu’ils seront ajoutés au pool de ressources.

Configurer le contrôle d’accès basé sur les rôles

Connectez tous les pools de ressources à un domaine Active Directory approuvé pour permettre la gestion et l’audit faciles des utilisateurs et groupes AD, et pour contrôler l’accès et les autorisations aux pools de ressources XenServer.

Remarque :

N’utilisez pas le compte par défaut (root) pour la gestion, sauf dans des situations d’urgence où il n’est pas possible de s’authentifier via les informations d’identification AD (par exemple, une défaillance du contrôleur de domaine AD).

Provisionnement de certificats pour les hôtes

Tous les hôtes de tous les pools de ressources doivent disposer d’un certificat TLS provisionné pour une utilisation sur le réseau de gestion. Pour les charges de travail CVAD, les hôtes devront être résolvables par leur FQDN dans le DNS.

Tous les hôtes doivent avoir un certificat provisionné ; il peut s’agir d’un certificat générique partagé ou d’un certificat par hôte.

Remarque :

Certaines applications qui utilisent les API XenServer, telles que certaines versions plus anciennes de Citrix Apps and Desktops, nécessitent l’utilisation d’un certificat individuel pour chaque hôte et n’autorisent pas l’utilisation de certificats génériques. Consultez la documentation pertinente pour plus de détails :

• DaaS
• CVAD 2507 et versions ultérieures
• CVAD antérieur à 2507

Toutes les connexions tierces au pool de ressources doivent utiliser TLS et le FQDN pour adresser les hôtes du pool de ressources.

Sécurisation de la communication vers le pool de ressources

• Désactiver le port 80
• Définir SSH en mode Auto afin que si la pile d’outils de gestion échoue, SSH soit automatiquement activé

Activer le démarrage sécurisé

Les hôtes XenServer 9 peuvent être configurés pour fonctionner avec le démarrage sécurisé activé dans le firmware. Cela impose la vérification de la signature à chaque étape du processus de démarrage, réduisant ainsi le risque d’exécution de code non fiable ou malveillant avant le chargement complet du système d’exploitation de l’hôte.

Activez le démarrage sécurisé dans les paramètres du firmware sur chaque hôte. Tous les modules du noyau Dom0 dans XenServer 9 sont signés, de sorte que le fonctionnement standard de l’hôte n’est pas affecté. Les pools mixtes où le démarrage sécurisé est activé sur certains hôtes et désactivé sur d’autres sont pris en charge.

Pour les étapes de configuration complètes, consultez Démarrage sécurisé pour XenServer 9.

Configuration réseau du pool de ressources

Une séparation est requise pour les réseaux suivants :

• Réseau de gestion
• Réseau de VM
• Réseau de stockage (si utilisation d’un stockage basé sur le réseau)

Cette séparation peut être assurée par des cartes réseau distinctes ou par l’utilisation de VLAN avec les mêmes cartes réseau. Si vous utilisez un stockage basé sur le réseau, il est fortement recommandé d’utiliser des cartes réseau distinctes pour des raisons de performances.

Réseaux de gestion et de VM

Les réseaux de gestion et de VM doivent fonctionner sur des cartes réseau agrégées pour assurer la résilience et le débit.

Les agrégations doivent être configurées comme des agrégations LACP lorsque cela est possible afin d’assurer la meilleure réponse à la perte de connectivité tout en maximisant la disponibilité de la bande passante. Cela nécessitera que les commutateurs soient configurés de manière correspondante. Si les commutateurs ne peuvent pas être configurés pour prendre en charge LACP, alors l’actif-actif est bénéfique pour les réseaux de VM. Les réseaux de gestion peuvent utiliser l’actif-passif sans aucun impact. Pour plus d’informations, consultez Types d’agrégation.

Dans la mesure du possible, les commutateurs doivent être interconnectés aux cartes réseau afin d’éviter tout point de défaillance unique dans le transport réseau, et ils doivent utiliser des sources d’alimentation séparées ou des alimentations redondantes. Pour plus de détails, consultez Bonnes pratiques de mise en réseau.

Tous les hôtes du pool doivent avoir des adresses IP fixes sur le réseau de gestion ; XenServer ne prend pas en charge le scénario où l’adresse IP de l’hôte attribuée par DHCP change. Si des adresses DHCP fixes sont utilisées, l’environnement DHCP doit être fiable (par exemple, dans le cadre de l’infrastructure réseau) et ne doit pas être fourni par une machine virtuelle exécutée sur un hôte qui dépend de ce serveur DHCP. L’adressage statique pour l’infrastructure est recommandé.

Tous les réseaux de gestion des hôtes doivent permettre la connexion à des serveurs NTP synchronisés afin de garantir que leurs horloges restent alignées ; il doit s’agir de la même source de temps que celle utilisée pour l’Active Directory fournissant les comptes d’ordinateur et d’utilisateur pour le contrôle d’accès basé sur les rôles, afin d’éviter la dérive d’horloge et la rupture des chemins de communication. Cela garantira également des horodatages cohérents pour tous les journaux système.

Les exigences complètes de connectivité nécessaires au fonctionnement de l’environnement sont listées ici.

Réseaux de stockage

Lors de l’utilisation d’un stockage basé sur le réseau, la meilleure pratique consiste à utiliser la prise en charge du multipathing à partir du stockage, ce qui nécessite des réseaux indépendants (c’est-à-dire des sous-réseaux différents). Cela signifie généralement l’utilisation de cartes réseau uniques plutôt que de liaisons agrégées et la configuration de sous-réseaux appropriés sur chacune. Consultez votre fournisseur de stockage pour des recommandations supplémentaires.

Configuration du stockage du pool de ressources

Le multipathing doit être activé. Cela doit être configuré individuellement sur tous les hôtes, et il doit y avoir au moins 2 chemins disponibles pour toutes les ressources de stockage. Ces chemins doivent être diversifiés à travers l’infrastructure réseau/fibre optique.

LVM est un stockage provisionné de manière épaisse (thick provisioning), donc XenServer nécessitera la quantité totale de stockage requise pour les disques de VM créés. Cela signifie que chaque disque et modèle occupera la pleine capacité disponible même si seulement de petites portions de ces disques sont utilisées.

Il est recommandé d’utiliser des SAN qui fournissent leur propre fonction de provisionnement léger (thin provisioning) pour garantir une utilisation efficace du stockage. Le provisionnement léger du SAN utilise mieux le 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. La quantité de stockage utilisée doit être surveillée attentivement par l’administrateur à l’aide des outils fournis par le fournisseur du SAN.

Si le provisionnement léger (thin provisioning) est utilisé sur le SAN, la surveillance de l’utilisation du stockage est importante ; si la capacité du SAN est épuisée au point que d’autres écritures ne sont plus possibles, cela peut entraîner des défaillances de VM et/ou une corruption des données.

Si vous utilisez MCS pour provisionner des charges de travail pour les environnements Citrix®, il est recommandé d’utiliser un petit nombre de LUN de grande taille, car l’image de référence doit être copiée sur toutes les LUN, ce qui peut être lent et prolonger considérablement le temps de provisionnement des images, retardant ainsi le déploiement des images mises à jour.

Stratégie de résilience

Les pools de ressources XenServer, ainsi que leurs ressources de stockage, sont exploités au sein d’un seul centre de données (ou au sein d’une collection de centres de données proches).

Ces pools de ressources peuvent être configurés pour être résilients aux défaillances locales de serveur, de stockage et de réseau au sein du centre de données. De plus, les pools de ressources peuvent être utilisés en combinaison pour fournir des fonctions de reprise après sinistre en cas de défaillance d’un centre de données entraînant la perte d’un pool de ressources entier.

Ceux-ci sont examinés séparément ci-dessous.

Résilience au sein d’un centre de données

Bien que les charges de travail au sein d’un centre de données puissent être protégées par une configuration de reprise après sinistre (DR) complète, comme décrit ci-dessous, il existe des mécanismes de résilience au sein de chaque pool de ressources pour assurer la haute disponibilité des ressources. Ces mécanismes sont conçus pour être automatisés et utilisés plus fréquemment afin de se protéger contre les problèmes plus courants et localisés. Les fonctionnalités suivantes sont disponibles :

• Haute disponibilité de la gestion (par le biais d’élections de coordinateur automatisées lors de pannes imprévues)
• Haute disponibilité du calcul des charges de travail (par le biais du redémarrage automatisé des VM lors de pannes imprévues)
• Résilience du stockage (par le biais du multipathing de stockage)
• Résilience du réseau (par le biais de l’agrégation de liens réseau et des configurations de commutateurs)

Pour ce faire, il est attendu que le pool de ressources fonctionne avec un minimum de N+1 hôtes, où N est le nombre d’hôtes requis pour exécuter la charge de travail. Cela permet d’exploiter le pool de ressources à pleine capacité avec un hôte indisponible.

Remarque :

La capacité d’hôte N+1 permet de mettre à jour et de mettre à niveau les pools de ressources sans interruption de la charge de travail, facilitant ainsi l’application des mises à jour de sécurité et des améliorations de fonctionnalités.

Ces fonctionnalités fourniront un déploiement hautement résilient qui est entièrement exploité au sein d’un centre de données ou entre des centres de données proches. Elles ne prendront pas en charge la résilience entre des centres de données géographiquement dispersés. La seule façon de prendre en charge cela est via la fonction de reprise après sinistre (DR) décrite ci-dessous (voir Résilience entre les centres de données).

Fonctionnalités optionnelles

Équilibrage de la charge de travail (WLB)

• Utiliser lorsque : Les charges de travail des VM ont des modèles d’utilisation matériellement différents et variables dans le temps pendant leur exécution, et que vous souhaitez des recommandations automatisées et/ou un rééquilibrage pour maintenir les performances.
• Éviter lorsque : Les charges de travail sont très uniformes (par exemple, de nombreuses VM VDI non persistantes similaires) où le placement initial et les opérations de cycle de vie normales assurent déjà un équilibre adéquat, ou lorsque les migrations sont opérationnellement indésirables.
• Impact opérationnel : Ajoute une appliance supplémentaire à exploiter et à surveiller ; inclut une fenêtre de maintenance quotidienne pendant laquelle le traitement WLB est indisponible.

Le WLB peut être utilisé pour maintenir la meilleure utilisation et les meilleures performances de l’hôte à mesure que l’utilisation de la charge de travail évolue au fil du temps.

Importez l’appliance dans le pool de ressources et utilisez le réseau de gestion pour sa connectivité. L’appliance Workload Balancing (WLB) peut être téléchargée depuis la page de téléchargements XenServer.

Le dimensionnement par défaut de l’appliance (2 Go de RAM, 30 Go de disque et 2 vCPU) doit être utilisé.

Adéquation de la charge de travail

Le WLB ne devrait être requis que lorsque la demande de charge de travail change dynamiquement au sein des machines virtuelles pendant leur durée de vie. Si le WLB est utilisé, chaque fois qu’une machine virtuelle est arrêtée puis redémarrée, elle est placée de manière optimale pour la charge de travail actuelle immédiatement, de sorte que les machines virtuelles ne devraient avoir besoin d’être déplacées que lorsque l’utilisation de l’hôte change. Lorsque le cas d’utilisation fournit de nombreuses machines virtuelles similaires effectuant toutes des tâches similaires, l’utilisation du WLB présente peu d’intérêt et vous pouvez vous fier au placement initial des machines virtuelles pour assurer l’équilibrage de la charge de travail.

Ajuster la fenêtre de maintenance de la base de données

L’appliance WLB effectue une maintenance de routine quotidienne. Par défaut, celle-ci a lieu à 00:05 UTC. Elle doit être configurée pour se produire lorsque l’activité est faible dans le pool de ressources, car il y aura une interruption du traitement WLB pouvant aller jusqu’à 30 minutes pendant ce processus. Cela n’affecte pas le fonctionnement normal, seulement les décisions d’optimisation du placement ; le WLB terminera les actions dès que sa maintenance sera terminée.

Configuration des paramètres WLB

De nombreux paramètres de configuration peuvent être laissés par défaut. Cela configurera la fonction WLB pour faire des recommandations à un administrateur, et l’administrateur devra appliquer ces actions.

La configuration par défaut et attendue pour ce plan ne nécessite que l’ajustement des « seuils critiques » et des pondérations pour permettre aux pools de ressources de fonctionner à des performances maximales. Ceux-ci peuvent être optimisés par l’utilisation, mais voici quelques valeurs initiales suggérées :

• Utilisation du CPU : La valeur par défaut est un seuil critique de 90 % avec une pondération maximale. Cela garantira qu’une fois que le CPU d’un hôte atteint une charge moyenne de 90 % sur les 1,5 dernières minutes, le service WLB évaluera d’autres emplacements pour l’exécution des machines virtuelles.

  • Si les performances de vos machines virtuelles sont affectées à des utilisations de CPU inférieures, vous pouvez ajuster ce seuil critique dans le but de maintenir l’utilisation moyenne du CPU à une valeur inférieure sur les hôtes, lorsque cela est possible.
  • Valeur de seuil critique initiale recommandée : 90 %
  • Valeur de pondération métrique initiale recommandée : La plus importante
• Mémoire libre : Il n’y a pas de performance spécifique à gagner en gardant de la mémoire libre sur les hôtes, donc la migration de machines pour maintenir la mémoire libre est une surcharge qui n’est pas nécessaire.
  • Valeur de seuil critique initiale recommandée : 0
  • Valeur de pondération métrique initiale recommandée : Moins important
• Lecture et écriture réseau : Les valeurs par défaut pour celles-ci sont de 25 Mo/s. Cela signifie que si un hôte utilise plus de bande passante pour les lectures ou les écritures, il sera considéré pour un déplacement. Ce paramètre n’est pas pertinent à moins que vous n’ayez des machines virtuelles exécutant des charges de travail réseau importantes, et que l’évitement de l’impact sur d’autres machines virtuelles soit pertinent.
  • Pour de nombreuses applications, ce n’est pas un facteur pertinent, et la pondération devrait être définie sur le paramètre le moins important.
  • Pour de nombreux réseaux modernes, c’est une valeur très faible et si ce paramètre est pertinent, nous recommandons de le définir pour permettre une bonne utilisation de cette bande passante avant d’envisager la migration vers un autre hôte.
  • Valeur de seuil critique initiale recommandée : 90 % de la bande passante disponible
  • Valeur de pondération métrique initiale recommandée : Importance moyenne
• Lecture et écriture disque : Les valeurs par défaut pour cela sont de 25 Mo/s. Cela signifie que si un hôte utilise plus de bande passante pour les lectures ou les écritures, il sera considéré pour un déplacement. Ce paramètre n’est pas pertinent à moins que vous n’ayez des machines virtuelles exécutant des charges de travail disque importantes et que l’évitement de l’impact sur d’autres machines virtuelles soit pertinent. Si un stockage distant est utilisé, alors à moins que la bande passante du fabric ne soit le goulot d’étranglement, cela n’a aucune valeur car tout impact sur le stockage distant affectera toutes les performances des machines virtuelles qui utilisent ce stockage, quel que soit l’hôte sur lequel il est exploité.
  • Pour la plupart des stockages et fabrics modernes, c’est une valeur faible et si ce paramètre est pertinent, il devrait être défini sur une valeur plus élevée pour permettre une bonne utilisation de la bande passante. Cela devrait être défini suffisamment haut pour que la maintenance régulière des machines virtuelles en dehors des heures de travail ne provoque pas de migration massive inutile.
  • Valeur de seuil critique initiale recommandée : 90 % de la bande passante disponible
  • Valeur de pondération métrique initiale recommandée : Importance moyenne

Haute disponibilité (HA) pour le pool de ressources

La documentation complète sur la HA est disponible ici

Il y a 2 éléments à considérer pour XenServer concernant la haute disponibilité

• HA de gestion : La capacité à maintenir automatiquement les opérations de gestion en cas de panne inattendue de l’hôte coordinateur dans le pool de ressources
• HA de VM : La capacité à maintenir les opérations de charge de travail en cas de panne inattendue d’un hôte dans le pool de ressources

Ces deux aspects nécessitent des configurations de stockage et de réseau spécifiques. Ceci est abordé dans les sections ci-dessous.

L’un des LUN de stockage disponibles sera sélectionné comme SR de pulsation XenServer (voir Pulsations pour la disponibilité pour une explication complète de cette exigence). S’il y a plus d’un LUN disponible, peu importe celui qui est sélectionné. Une petite quantité (<5 Go) d’espace sera allouée à partir de ce LUN pour fournir la fonction HA.

Cette architecture de référence est conçue pour prendre en charge le maintien de la charge de travail dans les limites de la perte inattendue d’un seul hôte. Le paramètre ‘Pannes à tolérer’ doit être défini sur 1.

Remarque :

Il est important de connaître les caractéristiques suivantes lors de l’utilisation de la HA

• Le pool de ressources doit avoir au moins 3 hôtes
• Le fencing fait référence au mécanisme qui isole de force un hôte considéré comme défaillant ou dangereux, garantissant qu’il ne peut pas accéder aux ressources partagées (en particulier le stockage partagé) avant que les machines virtuelles ne soient redémarrées ailleurs. Plus le pool de ressources est grand, plus l’impact du fencing d’hôte est important et plus il est susceptible de se produire en raison des exigences de chemin de communication. Une attention particulière doit être accordée à cet égard aux pools de >16 hôtes.
• La HA doit être désactivée pendant les opérations de maintenance de l’hôte / du pool de ressources afin de réduire le risque de pannes inattendues pendant que ces activités de maintenance sont entreprises.
• Lors de l’utilisation de la HA, il faut veiller à ce que la connectivité de stockage au SR du fichier d’état HA et la mise en réseau ne soient pas interrompues. Une interruption de ces connexions peut entraîner un fencing inattendu des hôtes pour protéger les opérations du pool de ressources. Cela signifie qu’une attention particulière doit être portée lors de la maintenance de l’infrastructure pour s’assurer que la connectivité n’est pas perdue.

Approches alternatives pour la HA de gestion

Si vous utilisez la HA pour fournir une connectivité de gestion fiable et hautement disponible, les approches suivantes doivent également être prises en compte pour éviter les limitations énumérées ci-dessus.

Implémenter la surveillance des hôtes

Intégrer les hôtes XenServer à une solution de surveillance tierce pour détecter quand un hôte ne répond pas.

Récupérer manuellement la connectivité de gestion

Si l’hôte injoignable est le coordinateur et que les opérations de gestion sont indisponibles, tous les autres hôtes du pool de ressources entreront en mode d’urgence et permettront l’établissement d’une connectivité à distance pour élire l’un d’entre eux comme nouveau coordinateur de pool. Cela peut être effectué à l’aide des liaisons de langage à distance. Des exemples sont donnés ci-dessous pour xe CLI et PowerShell.

xe CLI :

xe -s <server_IP> -u <username> -pw <password> host-is-in-emergency-mode                     -> Confirm election possibility
xe -s <server_IP> -u <username> -pw <password> pool-emergency-transition-to-master           -> Designate current host as new master
xe -s <server_IP> -u <username> -pw <password> pool-recover-slaves                           -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

PowerShell :

Invoke-XenPool -XenAction EmergencyTransitionToMaster          -> Designate current host as new master
Invoke-XenPool -XenAction RecoverSlaves                        -> Reconfigure member servers to new coordinator

<!--NeedCopy-->

HA de VM

VM d’équilibrage de charge (WLB)

Cette VM doit avoir la priorité de redémarrage définie sur « redémarrer » pour garantir qu’aucune fonction WLB ne soit perdue après une panne inattendue. Elle doit faire partie du premier groupe de démarrage 0.

Autres VM

Selon l’utilisation exacte de XenServer, des VM supplémentaires peuvent être configurées pour utiliser la HA de VM. Voici quelques suggestions pour certains cas d’utilisation.

Conseils de décision (HA de VM) : Utilisez la HA de VM pour les charges de travail où un redémarrage automatisé après une panne d’hôte inattendue améliore considérablement la continuité du service, et où le pool est dimensionné en N+1 pour absorber la panne. Évitez la HA de VM pour les charges de travail où le courtage/l’orchestration externe fournit déjà un comportement de redémarrage ou de mise à l’échelle (par exemple, de nombreuses charges de travail CVAD non persistantes), ou lorsque l’ordre de redémarrage et les dépendances sont difficiles à contrôler.

Remarque :

Les VM ajoutées au pool de ressources après la configuration de la HA seront par défaut sur « Ne pas redémarrer ». La HA devra être reconfigurée après l’ajout de VM à l’environnement si nécessaire.

• VM PVS et MCS non persistantes : Ne configurez pas ces VM avec une quelconque HA. Assurez-vous qu’elles sont définies sur Do Not Restart. D’autres VM devraient être disponibles pour fournir des services immédiats aux utilisateurs finaux, et Citrix Virtual Apps and Desktops fournira des fonctions de gestion de l’alimentation pour prendre en charge le redémarrage de ces VM, soit lorsqu’un utilisateur final le demande, soit via des fonctions d’auto-mise à l’échelle pour répondre à la demande attendue, voir AutoScale. Cela permettra d’obtenir un résultat plus optimisé pour l’environnement Citrix combiné.

• VM MCS persistantes : Celles-ci doivent être définies sur « Redémarrer ». La configuration conçue doit garantir qu’il y a suffisamment de RAM et de CPU disponibles pour faire fonctionner toutes les VM du pool lorsqu’un hôte est hors service (pour une mise à jour, une maintenance ou une panne) afin que cette configuration soit possible.

• Charges de travail de virtualisation de serveur générales (toute charge de travail non utilisée pour exécuter des VDA Citrix) : Celles-ci doivent être définies sur « Redémarrer ». La configuration conçue doit garantir qu’il y a suffisamment de RAM et de CPU disponibles pour faire fonctionner toutes les VM du pool lorsqu’un hôte est hors service (pour une mise à jour, une maintenance ou une panne) afin que cette configuration soit possible. Les VM peuvent être configurées pour utiliser les groupes de démarrage et les délais selon les besoins afin de garantir que la charge de travail redémarre comme requis. Cela pourrait être utilisé pour prioriser les charges de travail dont dépendent d’autres services, tels que les fournisseurs de services Active Directory, DHCP et DNS.

Résilience entre les centres de données

Facultatif :

Reprise après sinistre (DR) entre les centres de données. Cette architecture de référence peut prendre en charge la DR si nécessaire, avec des considérations de conception et opérationnelles supplémentaires.

Conseils de décision pour la DR

• À utiliser lorsque : Vous avez une exigence commerciale définie pour la résilience du site, une plateforme de stockage capable de réplication et des procédures de récupération convenues (RPO/RTO) qui nécessitent la récupération de VM sur un site secondaire.
• À éviter lorsque : Vous avez besoin d’une mobilité fréquente des charges de travail entre les sites, ou vous n’avez pas la capacité opérationnelle de tester et d’exécuter les processus de basculement/reprise. Pour CVAD, ne supposez pas que la connectivité de l’hyperviseur et les certificats basculeront de manière transparente sans une conception DR CVAD coordonnée.
• Impact opérationnel : La DR n’est pas entièrement automatisée ; le basculement/la reprise nécessite des runbooks planifiés, un accès aux contrôles de réplication du stockage et des tests réguliers.

La configuration de reprise après sinistre (DR) de XenServer décrite ici est un mode de résilience qui devrait être une opération peu fréquente pour prendre en charge les pannes d’infrastructure extrêmes et imprévues. Cette opération n’est pas automatisée et la récupération nécessite une planification et une exécution minutieuses. Le modèle DR permet l’exploitation des charges de travail dans un emplacement temporaire qui peut ne pas être un placement optimal, mais qui prendra en charge les opérations commerciales critiques pendant une période de panne.

Le modèle DR de XenServer est une solution complexe et il existe d’autres moyens d’assurer la protection contre les pannes de site. Par exemple, pour les charges de travail Citrix où des VM non persistantes sont utilisées pour fournir des services, des VM supplémentaires peuvent être provisionnées dans des sites de récupération pour fournir des services temporaires. Ces options doivent être prises en compte avant d’utiliser la fonction DR de XenServer, car elles peuvent être plus faciles à mettre en œuvre.

Il est recommandé d’éviter d’utiliser la DR pour les charges de travail Citrix VDI, sauf si vous disposez d’une solution DR appropriée pour CVAD. Il n’est pas sûr de supposer que la même connexion d’hyperviseur peut basculer vers un site DR XenServer, car les mappages réseau et de certificats peuvent rendre cela peu fiable.

Pour atténuer le risque de défaillance d’un centre de données et de perte de la charge de travail (ou de parties critiques de la charge de travail), un emplacement de centre de données secondaire peut être utilisé pour fournir des fonctions de reprise après sinistre. Une documentation supplémentaire est disponible ici.

Un ou plusieurs pools de ressources sur le site DR peuvent être utilisés pour d’autres charges de travail en plus d’être l’emplacement de récupération pour les charges de travail, mais vous devez maintenir la capacité de réserve requise pour permettre l’exécution des charges de travail supplémentaires si nécessaire.

Il n’est pas nécessaire que la charge de travail complète soit exploitée sur le site DR en cas de défaillance. Les charges de travail partielles peuvent être récupérées jusqu’à ce que le fonctionnement complet soit restauré sur le site principal, cependant, il est nécessaire que les charges de travail soient récupérées d’un pool de ressources vers un seul pool de ressources de récupération. Les charges de travail ne peuvent pas être distribuées à plusieurs pools de récupération.

Important :

Le processus de réplication du stockage qui met en miroir les données des LUN(s) du site principal vers le site DR doit être configuré en dehors de l’ensemble d’outils XenServer et la reconfiguration de celui-ci doit être accessible à l’administrateur responsable du basculement, car il doit interrompre et réinitialiser la mise en miroir dans le cadre des opérations liées à ce processus (voir la section des opérations pour plus de détails).

Lors de la création de ce déploiement :

• Tout le stockage utilisé pour les disques virtuels des machines virtuelles doit être répliqué de l’environnement principal vers l’environnement de sauvegarde.
• Tout le stockage utilisé pour les métadonnées du pool doit être répliqué de l’environnement principal vers l’environnement de sauvegarde.
• L’infrastructure matérielle de votre site de reprise après sinistre n’a pas besoin de correspondre à celle du site principal, mais doit utiliser le même fournisseur de processeurs. Une mémoire, un processeur et une capacité réseau suffisants doivent être configurés dans le pool de ressources de secours pour permettre la recréation et le démarrage de toutes les machines virtuelles basculées requises.
• Le pool de ressources XenServer du site de récupération doit être au même niveau de version et de correctif ou plus récent que le site principal (voir Gestion des versions de XenServer entre les déploiements pour plus de détails sur la façon d’y parvenir).

Modèle d’opérations

Gestion des versions de XenServer entre les déploiements

Les déploiements XenServer sont construits à partir d’un ou plusieurs pools de ressources, répartis sur un ou plusieurs centres de données, afin de fournir un déploiement évolutif, robuste et sécurisé, capable de gérer des charges de travail performantes à grande échelle.

Ces déploiements peuvent fournir des environnements de test et de production, et un flux de travail peut être mis en place pour déployer les modifications à travers ces environnements.

Facultatif :

Les phases de test des hôtes et de test des charges de travail sont facultatives. L’architecture de référence prend en charge le fonctionnement avec ou sans ces phases.

Les étapes de test des hôtes et de test des charges de travail n’ont pas besoin d’être des étapes distinctes ; elles peuvent être combinées. Cela peut être avantageux car cela réduit le temps nécessaire pour que les modifications atteignent la production. Le flux de mises à jour XenServer est robuste et entièrement testé, permettant un déploiement continu. Pour maintenir la sécurité, la robustesse et les performances, il est important de minimiser le temps que prennent les mises à jour pour atteindre la production.

Les attentes pour chaque phase sont les suivantes :

• Test de la version préliminaire : Cette phase est destinée à la visibilité précoce des mises à jour et à la validation des fonctionnalités. Les hôtes de cette phase sont configurés pour utiliser le canal de version préliminaire, qui donne généralement accès aux nouvelles versions 2 semaines avant le canal normal. Les hôtes de cette phase doivent disposer d’une connectivité sortante vers Internet (directement ou via un serveur proxy) pour accéder au réseau de distribution de contenu (CDN) XenServer.
• Test des hôtes : Le but de cette phase est de tester les processus de mise à jour des versions logicielles de XenServer. Les versions sont disponibles sur Internet depuis le CDN XenServer ou via les mécanismes de livraison hors ligne.
• Test de charge/UAT : Cette phase permet de tester les hôtes XenServer avec une charge de travail similaire à celle de la production afin de valider l’échelle et la résilience. Les versions sont disponibles sur Internet depuis le CDN XenServer ou via les mécanismes de livraison hors ligne.
• Déploiements en production : Les hôtes exécutant des charges de travail de production peuvent être mis à jour après les phases de test précédentes (directement ou via les mécanismes de livraison hors ligne).

Remarque :

Les mises à jour hors ligne peuvent être utilisées pour s’assurer que la version attendue de XenServer est déployée dans les environnements UAT et de production. Il est possible de synchroniser les mises à jour directement depuis un autre pool de ressources ; cependant, si des mises à jour sont synchronisées mais pas encore appliquées au pool source, elles peuvent être appliquées au pool de destination, ce qui entraîne une version de correctif plus élevée sur le pool de destination.

Pour rester pris en charge, tous les pools de ressources doivent être mis à jour régulièrement et ne pas être obsolètes de plus de 6 mois.

Gestion des pilotes avec la gestion de versions multiples de pilotes (DMV)

XenServer 9 introduit la gestion de versions multiples de pilotes (DMV), qui fournit des versions de pilotes approuvées via le canal standard de mises à jour d’hôtes en continu, éliminant ainsi le besoin de disques de pilotes séparés dans la plupart des cas.

La DMV permet aux opérateurs de choisir parmi plusieurs versions de pilotes approuvées disponibles dans le flux de mises à jour. XenServer ne présente que les variantes de pilotes compatibles avec le matériel de chaque hôte. Si un pilote incorrect est appliqué, la version correcte peut être sélectionnée et installée sans réinstaller l’hôte, bien qu’un redémarrage soit nécessaire pour que la modification prenne effet. XenServer 9 applique la validation des pilotes signés, bloquant les binaires tiers non approuvés.

Pour plus d’informations, consultez Gestion de versions multiples de pilotes.

Surveillance du pool de ressources

Lorsque des alertes se produisent dans le pool de ressources pour l’un des hôtes ou des machines virtuelles, elles sont disponibles dans la section Alertes de XenCenter®.

Ces alertes peuvent également être rendues disponibles dans un outil de surveillance externe via l’intégration SNMP ou l’intégration SMTP par e-mail.

Il y a 2 types de surveillance à considérer.

• Surveillance de l’utilisation, pour s’assurer que tout problème de capacité inattendu est rapidement identifié et qu’il peut être résolu.
• Surveillance des événements système pour s’assurer que l’infrastructure fonctionne correctement et qu’aucun changement inattendu ne se produit.

Ceux-ci sont détaillés ci-dessous pour être pris en compte dans la conception de l’intégration.

L’intégration aux produits de surveillance tiers peut être réalisée via la fonction SNMP décrite ici et peut fournir des alertes qui sont intégrées à ces outils tiers.

Remarque :

Lors de l’ajout d’un nouvel hôte au pool, vous devez reconfigurer les paramètres SNMP pour vous assurer que le nouvel hôte est inclus dans toute intégration SNMP (voir les contraintes pour plus de détails).

Surveillance de l’utilisation

Des alertes peuvent être configurées pour détecter des éléments tels qu’une utilisation excessive du CPU, voir Alertes de performance pour plus de détails.

Vous trouverez ci-dessous un exemple des données fournies dans les traps SNMP déclenchés pour ces événements.

2026-02-19 09:44:35 <UNKNOWN> [UDP: [10.71.64.14]:53876->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196826250) 22 days, 18:44:22.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:eea63153-f96c-25f5-17b9-08ce49e7ccf4"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "83a9c805-a172-f1b2-55d4-081ec180893b" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALARM"    iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3     iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "VM"       iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "681e4064-16cb-4d0c-9c2c-887623bc623f" iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:45:55Z"       iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "The memory required by the control domain on \"Control domain on host: pm-demolab-3\" is about 5.7% of its allocated memory. Occasional performance degradation can be expected when memory swapping is forced to happen.
This alarm is set to be triggered when the memory required by the control domain is above 5.0% of its allocated memory."
<!--NeedCopy-->

Surveillance des événements système

Les alertes système sont décrites ici

Vous trouverez ci-dessous un exemple des données fournies dans les traps SNMP déclenchés pour ces événements.

2026-02-19 09:43:39 <UNKNOWN> [UDP: [10.71.64.14]:46982->[10.81.143.35]:162]:
iso.3.6.1.2.1.1.3.0 = Timeticks: (196820650) 22 days, 18:43:26.50       iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.60953.1.10.1   iso.3.6.1.4.1.60953.1.10.1.1.0 = STRING: "add"  iso.3.6.1.4.1.60953.1.10.1.2.0 = STRING: "OpaqueRef:ca95e2da-06b7-9aa5-fa4b-ddf007a50c59"   iso.3.6.1.4.1.60953.1.10.1.3.0 = STRING: "525e459c-51bc-c71c-9c52-dcd747e9a84f" iso.3.6.1.4.1.60953.1.10.1.4.0 = STRING: "ALL_RUNNING_VMS_IN_ANTI_AFFINITY_GRP_ON_SINGLE_HOST"      iso.3.6.1.4.1.60953.1.10.1.5.0 = INTEGER: 3iso.3.6.1.4.1.60953.1.10.1.6.0 = STRING: "Pool"  iso.3.6.1.4.1.60953.1.10.1.7.0 = STRING: "419d6735-5d11-56b1-8cdc-2853ce709a27"     iso.3.6.1.4.1.60953.1.10.1.8.0 = STRING: "20260219T09:44:59Z"   iso.3.6.1.4.1.60953.1.10.1.9.0 = STRING: "<body><message>Breach on VM anti-affinity rules</message><VM_group>3224f9d9-9492-06f7-3c92-da610cde33a8</VM_group><host>ce2a3c26-6bbc-4d23-8626-fba28d3dc651</host></body>"
<!--NeedCopy-->

Journalisation à distance

L’objectif principal est de faciliter l’engagement du support. Pour garantir la disponibilité de ces données lors de la résolution des problèmes, la redirection syslog peut être configurée. Cela permet de récupérer les journaux au cas où ils ne pourraient pas être récupérés directement depuis l’hôte, ou s’il y a une raison de suspecter que les journaux sur l’hôte ont pu être altérés.

Si cette option est configurée, elle doit l’être sur tous les hôtes du pool.

Ces données peuvent consommer un espace significatif. L’utilisation et la rétention de cette fonctionnalité et des données sont à votre discrétion, en fonction des politiques de sécurité internes.

Modèle de planification de capacité

Dimensionnement du pool de ressources

Chaque pool de ressources doit contenir suffisamment de ressources pour que, si un hôte est en panne, le pool de ressources puisse gérer la charge de travail complète. Cela permettra :

• Des pannes planifiées peuvent survenir sur un hôte à la fois, selon les besoins
• Les mises à jour du pool de ressources peuvent être effectuées sans aucune interruption de la charge de travail
• Assurer une interruption minimale de la charge de travail si un hôte tombe en panne de manière inattendue

Pour ce faire, il est prévu que tous les hôtes du pool de ressources aient la même capacité à prendre en charge la charge de travail (c’est-à-dire la même configuration, la même RAM, le même CPU). Cela peut entraîner un niveau plus élevé de surallocation de CPU pendant la panne, mais cela devrait être de courte durée jusqu’à ce que la condition de panne soit résolue.

Si plus d’un hôte d’un pool de ressources est perdu, il ne sera plus possible de maintenir toute la charge de travail et il peut y avoir une interruption de la charge de travail jusqu’à ce que les hôtes soient récupérés.

Remarque :

Si les hôtes n’ont pas une capacité identique pendant certaines périodes lors d’activités telles que la mise à jour/le rafraîchissement du matériel, il convient de prévoir la défaillance de l’hôte disposant de la plus grande quantité de mémoire.

Calculs de capacité du pool de ressources

Dans cette architecture de référence, nous avons supposé que chaque pool de ressources a un objectif spécifique. Par conséquent, les calculs ci-dessous supposent que toutes les machines virtuelles du pool de ressources ont les mêmes spécifications.

Optimisation NUMA

XenServer 9 active l’optimisation du placement NUMA par défaut. Lorsque les vCPU et la mémoire d’une machine virtuelle tiennent dans un seul nœud NUMA sur l’hôte, les charges de travail atteignent une latence d’accès à la mémoire plus faible et des performances plus constantes. Cela peut également permettre une densité de machines virtuelles plus élevée par hôte, réduisant ainsi le besoin de serveurs supplémentaires.

Pour de meilleurs résultats, dimensionnez les machines virtuelles de manière à ce que leur mémoire tienne dans un seul nœud NUMA physique. Si une machine virtuelle nécessite plus de mémoire qu’un seul nœud ne peut en fournir, XenServer répartit la machine virtuelle sur plusieurs nœuds et le bénéfice de l’optimisation est réduit. Le dimensionnement des machines virtuelles qui dépasse les limites des nœuds NUMA doit être traité comme une exception plutôt que comme la norme.

Les métriques NUMA par VM sont disponibles pour surveiller le placement et détecter les violations d’affinité. Voir Optimisation NUMA dans XenServer 9 pour plus de détails.

Calculs de capacité du pool de ressources

Dom0 est dimensionné à 32 Go de RAM. Cependant, si l’accélérateur PVS est utilisé, cela devra être augmenté d’au moins 5 Go par vdisk pour prendre en charge l’accélération et doit être pris en compte dans ces calculs.

Entrées

Sorties

Remarque :

En cas de défaillance de l’hôte, de maintenance ou d’opération de mise à jour vm_host = vm_pool_max / (hosts_total - 1)

Exemple pratique

• vm_host_max = (1000 - 32 - 2) / 16 = 60 max VMs per Host
• vm_pool_max = 60 * (8 - 1) = 420 max VMs per pool
• srs_total = 420 * (3 + 0) / 1000 = 1.26 SRs (>1 so need 2 SRs spread over 2 LUNS)
• Fonctionnement normal :
  • vm_host = 420 / 8 = 52.5 VMs per host (round down to 52)
  • host_cpu_overcommit = ((52 * 4) + 16 + 2) / 128 = 1.77 vCPU per pCPU
• Pendant une panne d’hôte unique ou une opération de mise à jour/maintenance :
  • vm_host = 420 / 7 = 60 VMs per host
  • host_cpu_overcommit = ((60 * 4) + 16 + 2) / 128 = 2.01 vCPU per pCPU

Remarque :

Le contrôle dynamique de la mémoire (DMC) n’est pas utilisé pour le surprovisionnement de RAM. XenServer ne prend pas en charge cela en fonctionnement normal. Ceci ne doit être utilisé que pendant de courtes périodes de maintenance planifiée et contrôlée, lorsqu’aucune autre option n’est disponible pour maintenir la charge de travail requise en cours d’exécution.

Si le surprovisionnement est trop élevé, alors le nombre de machines virtuelles pour le pool devra être réduit jusqu’à ce qu’il atteigne un point acceptable.