Architecture de référence d’entreprise XenServer®

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 une exécution de charge de travail prévisible et haute performance. 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éployez et gérez les charges de travail au sein de pools de ressources bien définis, et mettez à l’échelle horizontalement en ajoutant des pools supplémentaires
• Isolation des charges de travail par conception : Alignez 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 : Maintenez une capacité suffisante pour tolérer une défaillance d’hôte unique sans impacter la disponibilité des charges de travail
• Séparation des préoccupations : Séparez 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 : Traitez 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 : Introduisez 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 en mode 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 de la charge 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 fort. 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 censés fonctionner dans une limite 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 à partir du SAN.

• 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 capacités telles que le provisionnement léger 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 machine virtuelle 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 assurer la résilience et le 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 traité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 de l’hôte 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 charge de travail (WLB)
• Haute disponibilité (HA) pour les charges de travail
• Reprise après sinistre (DR) entre les centres de données

Chacune de ces options introduit une complexité opérationnelle supplémentaire et doit être adoptée en fonction des exigences claires de la charge de travail et de l’entreprise.

Hors de portée

Cette architecture de référence n’est pas conçue pour tous les scénarios et ne doit pas être traité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é transparente et active-active des charges de travail 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 très 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
• Des serveurs d’applications pour un 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 de 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 (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 comme 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 de confiance pour permettre aux utilisateurs et groupes AD d’être facilement gérés et audités, 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 conditions 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

Toute connexion tierce au pool de ressources doit 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éfinissez SSH en mode Auto afin que si la pile d’outils de gestion échoue, SSH soit automatiquement activé.

Configuration réseau du pool de ressources

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

• Réseau de gestion
• Réseau VM
• Réseau de stockage (si vous utilisez 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 machines virtuelles

Les réseaux de gestion et de machines virtuelles 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 en tant qu’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 machines virtuelles. 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 pour garantir qu’il n’y a pas de 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 considéré comme étant disponible de manière 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 pour 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 de garantir qu’aucun décalage d’horloge ne se produise et ne rompe les chemins de communication. Cela garantira également des horodatages cohérents pour tous les journaux système.

Les exigences complètes de connectivité nécessaires pour permettre le 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 depuis le 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 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 nécessaire pour les disques de VM créés. Cela signifie que chaque disque et modèle occupera la pleine capacité disponible même si seules 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 est utilisé sur le SAN, la surveillance de l’utilisation du stockage est importante ; si la capacité du SAN est épuisée de sorte 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 à cette fin, car l’image dorée doit être copiée sur toutes les LUN, ce qui peut être lent et rendre le provisionnement d’images très long, retardant 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’un ensemble 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 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 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 (via le multipathing de stockage)
• Résilience du réseau (via l’agrégation de liens réseau et les 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é même si un hôte est 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 sera 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 machines virtuelles 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 machines virtuelles 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 de l’hôte et les meilleures performances à mesure que l’utilisation de la charge de travail évolue dans le 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

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 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 qu’en cas de changement d’utilisation de l’hôte. Lorsque le cas d’utilisation fournit de nombreuses machines virtuelles similaires effectuant toutes des tâches similaires, l’utilisation de 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, cela se produit à 00:05 UTC. Cela devrait être configuré pour se produire lorsque l’activité est faible dans le pool de ressources, car il y aura une interruption de 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 ; 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 qu’elle fasse 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 à l’usage, mais voici quelques valeurs de départ 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 qu’un CPU hôte atteint une charge moyenne de 90 % au cours des 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 par des utilisations du CPU inférieures, vous pouvez ajuster ce seuil critique dans le but de maintenir l’utilisation moyenne du CPU à une valeur plus basse sur les hôtes, si 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 gain de performance spécifique à obtenir en conservant 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 : La moins importante
• 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 qu’éviter l’impact sur d’autres machines virtuelles soit pertinent.
  • Pour de nombreuses applications, ce n’est pas un facteur pertinent, et la pondération doit être définie sur le paramètre le moins important.
  • Pour de nombreux réseaux modernes, cette valeur est 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 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 lourdes 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 les performances de toutes les machines virtuelles qui utilisent ce stockage, quel que soit l’hôte sur lequel il est opéré.
  • Pour la plupart des stockages et fabrics modernes, cette valeur est 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. Il devrait être suffisamment élevé pour que la maintenance régulière des machines virtuelles en dehors des heures de bureau 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 des 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 battement de cœur XenServer (voir Battements de cœur pour la disponibilité pour une explication complète de cette exigence). S’il y a plus d’un LUN disponible, peu importe lequel 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 prendre en compte les caractéristiques suivantes lors de l’utilisation de la HA

• Le pool de ressources doit comporter au moins 3 hôtes
• L’isolement forcé fait référence au mécanisme qui isole de force un hôte considéré comme défaillant ou non sécurisé, 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 de l’isolement forcé des hôtes 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 >16 hôtes.
• La HA doit être désactivée pendant les opérations de maintenance des hôtes / du pool de ressources afin de réduire le risque de pannes inattendues pendant que ces activités de maintenance sont effectuées.
• 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 l’isolement forcé inattendu des hôtes afin de 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, alors les approches suivantes doivent également être envisagées pour éviter les limitations énumérées ci-dessus.

Mettre en œuvre la surveillance des hôtes

Intégrez les hôtes XenServer avec 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, alors tous les autres hôtes du pool de ressources passeront en mode d’urgence et permettront d’établir une connectivité à distance avec eux 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 ci-dessous sont donnés 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 s’assurer qu’aucune fonction WLB n’est perdue après une panne inattendue. Elle doit être dans le 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 haute disponibilité des VM (VM HA). Voici des 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 inattendue de l’hôte 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 auront par défaut la valeur ‘Ne pas redémarrer’. La HA devra être reconfigurée après l’ajout de VM à l’environnement si nécessaire.

• VM MCS PVS et 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 de mise à l’échelle automatique pour répondre à la demande prévue, 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), de sorte que cette configuration sera 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), de sorte que cette configuration sera 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 inter-centres de données

Facultatif :

Reprise après sinistre (DR) inter-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 métier 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 de reprise après sinistre CVAD coordonnée.
• Impact opérationnel : La reprise après sinistre n’est pas entièrement automatisée ; le basculement/la reprise nécessite des plans d’exécution planifiés, l’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 de reprise après sinistre permet l’exploitation des charges de travail dans un emplacement temporaire qui peut ne pas être optimal, mais qui prendra en charge les opérations commerciales critiques pendant une période de panne.

Le modèle de reprise après sinistre de XenServer est une solution complexe et il existe d’autres moyens d’assurer une protection contre les pannes de site. Par exemple, pour les charges de travail Citrix où des machines virtuelles non persistantes sont utilisées pour fournir des services, des machines virtuelles 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 de reprise après sinistre de XenServer, car elles peuvent être plus faciles à mettre en œuvre.

Il est recommandé d’éviter d’utiliser la reprise après sinistre pour les charges de travail Citrix VDI, sauf si vous disposez d’une solution de reprise après sinistre appropriée pour CVAD. Il n’est pas sûr de supposer que la même connexion d’hyperviseur peut basculer vers un site de reprise après sinistre 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 (/fr-fr/xenserver/8/dr.html).

Un ou plusieurs pools de ressources sur le site de reprise après sinistre 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 de reprise après sinistre en cas de défaillance. Des charges de travail partielles peuvent être récupérées jusqu’à ce que le fonctionnement complet soit rétabli sur le site principal, cependant, il est impératif 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 de reprise après sinistre doit être configuré en dehors de l’ensemble d’outils XenServer et sa reconfiguration 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 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 savoir comment y parvenir).

Modèle d’opérations

Gestion des versions de XenServer sur les déploiements

Les déploiements XenServer sont construits à partir d’un ou plusieurs pools de ressources, sur un ou plusieurs centres de données, afin de fournir un déploiement évolutif, robuste et sécurisé, capable de fournir 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 à une 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 par canal hors ligne.
• Test de charge de travail/UAT : Cette phase permet de tester les hôtes XenServer avec une charge de travail similaire à celle de la production afin de valider l’évolutivité et la résilience. Les versions sont disponibles sur Internet depuis le CDN XenServer ou via les mécanismes de livraison par canal hors ligne.
• Déploiements de 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 à partir d’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.

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 à prendre en compte.

• 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 intégrées à ces outils tiers.

Remarque :

Lorsque vous ajoutez 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 interruptions SNMP déclenchées 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 permettre 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 de 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 la 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 :

• Une panne planifiée peut se produire si nécessaire sur un hôte à la fois
• 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 attendu que tous les hôtes du pool de ressources aient la même capacité à supporter la charge de travail (c’est-à-dire la même configuration, RAM, CPU). Cela peut entraîner un niveau plus élevé de surallocation de CPU pendant une 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.

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

Entrées

Sorties

Remarque :

Lors d’une défaillance de l’hôte, d’une maintenance ou d’une 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)
• Opération normale :
  • 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 :

Il n’y a pas d’utilisation du contrôle dynamique de la mémoire (DMC) pour fournir un surprovisionnement de RAM. XenServer ne prend pas en charge cela pendant le fonctionnement normal. Cela ne devrait ê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é, le nombre de machines virtuelles pour le pool devra être réduit jusqu’à ce qu’il atteigne un point acceptable.