layout: doc—
Remarque :
XenCenter YYYY.x.x n’est pas encore pris en charge pour une utilisation avec Citrix Hypervisor 8.2 CU1 dans les environnements de production. Pour gérer votre environnement de production Citrix Hypervisor 8.2 CU1, utilisez XenCenter 8.2.7. Pour plus d’informations, consultez la documentation XenCenter 8.2.7.
Vous pouvez installer XenCenter 8.2.7 et XenCenter YYYY.x.x sur le même système. L’installation de XenCenter YYYY.x.x ne remplace pas votre installation de XenCenter 8.2.7.
La haute disponibilité de XenServer permet aux machines virtuelles de redémarrer automatiquement en cas de défaillance matérielle sous-jacente ou de perte d’un serveur. La haute disponibilité consiste à s’assurer que les machines virtuelles importantes sont toujours en cours d’exécution dans un pool de ressources. Lorsque la haute disponibilité est activée, si l’un de vos serveurs tombe en panne, ses machines virtuelles redémarrent sur d’autres serveurs du même pool. Cette fonctionnalité permet de rétablir les services essentiels avec un minimum d’interruption de service en cas de défaillance du système ou des composants.
En cas de défaillance du serveur de coordinateur de pool, la haute disponibilité de XenServer sélectionne un nouveau serveur pour prendre la relève en tant que coordinateur de pool. Tout serveur d’un pool peut être un serveur coordinateur de pool. XenServer réplique constamment la base de données du pool sur tous les nœuds. Il sauvegarde également la base de données sur un stockage partagé sur le SR de pulsation pour plus de sécurité.
La haute disponibilité de XenServer comporte deux aspects essentiels :
Il est difficile de détecter une défaillance de serveur de manière fiable, car vous devez distinguer à distance entre un serveur qui disparaît pendant un certain temps et une défaillance catastrophique. Si la haute disponibilité décide à tort qu’un serveur de coordinateur de pool est en panne et choisit un nouveau coordinateur de pool, il peut y avoir des résultats imprévisibles si le serveur d’origine revient. De même, si un problème de réseau entraîne la division du pool en deux moitiés égales, nous devons nous assurer que seule la moitié accède au stockage partagé et non aux deux simultanément. XenServer résout tous ces problèmes en utilisant deux mécanismes : un battement de cœur de stockage et un battement de cœur réseau.
Lorsque vous activez la haute disponibilité dans un pool, vous nommez un référentiel de stockage iSCSI, Fibre Channel ou NFS comme SR de pulsation. XenServer crée automatiquement deux petits disques virtuels dans ce SR. Le premier disque est utilisé par tous les serveurs du pool de ressources en tant que disque de quorum partagé. Chaque serveur s’alloue un bloc unique sur le disque partagé et écrit régulièrement sur le bloc pour indiquer qu’il est actif. Lorsque la haute disponibilité démarre, tous les serveurs échangent des données sur le réseau et les canaux de stockage. Cette action indique les serveurs qu’ils peuvent voir sur les deux canaux et montre quels chemins d’E/S fonctionnent et lesquels ne le sont pas. Ces informations sont échangées jusqu’à ce qu’un point fixe soit atteint et que tous les serveurs du pool s’accordent sur ce qu’ils peuvent voir. Lorsque cet accord est conclu, la haute disponibilité est activée et le pool est protégé. Ce processus d’armement haute disponibilité peut prendre quelques minutes pour s’adapter à des pools plus importants, mais il n’est nécessaire que lorsque vous activez la haute disponibilité pour la première fois.
Une fois la haute disponibilité active, chaque serveur écrit régulièrement des mises à jour de stockage sur le disque virtuel Heartbeat et des paquets réseau via l’interface de gestion. Assurez-vous que les cartes réseau sont liées pour assurer la résilience et que les interfaces de stockage utilisent le multiacheminement dynamique là où il est pris en charge. Cette configuration garantit que les défaillances d’un seul adaptateur ou de câblage n’entraînent aucun problème de disponibilité.
Pour plus d’informations, consultez :
Le scénario le plus défavorable pour la haute disponibilité est celui où un serveur est considéré comme étant hors ligne mais continue d’écrire sur le stockage partagé. Ce scénario peut entraîner la corruption de données persistantes. XenServer utilise des clôtures de serveur pour éviter cette situation. Le serveur est automatiquement mis hors tension et ne peut plus accéder aux ressources partagées du pool. La clôture empêche le serveur défaillant d’écrire sur des disques partagés. Ce comportement évite d’endommager les données stockées lors d’un basculement automatique, lorsque des machines virtuelles protégées sont déplacées vers d’autres serveurs du pool.
Auto-clôture des serveurs (c’est-à-dire mise hors tension et redémarrage) en cas de défaillance du rythme cardiaque, sauf si l’une des conditions suivantes est vraie :
Le système Heartbeat nous fournit une notification fiable en cas de défaillance du serveur, et nous passons donc à la deuxième étape de la haute disponibilité : la planification de la capacité en cas de panne.
Un pool de ressources se compose de plusieurs serveurs (32 par exemple), chacun avec des quantités de mémoire potentiellement différentes et un nombre différent de machines virtuelles en cours d’exécution. XenServer High Availability calcule dynamiquement un plan de défaillance qui calcule les mesures à prendre en cas de panne de serveur. Ce plan de défaillance garantit qu’aucune défaillance de serveur ne rend impossible le redémarrage de ses machines virtuelles sur un autre serveur (par exemple, en raison d’une mémoire insuffisante sur d’autres serveurs). En plus de faire face à la défaillance d’un seul serveur, la haute disponibilité de XenServer peut faire face à la perte de plusieurs serveurs dans un pool. Par exemple, la haute disponibilité peut être prise en charge lorsque la défaillance d’une partition réseau entraîne l’arrêt d’un groupe entier de serveurs.
Outre le calcul des mesures prises, le plan de défaillance prend en compte le nombre de pannes de serveur pouvant être tolérées dans le pool. Deux considérations importantes sont impliquées dans le calcul du plan haute disponibilité pour un pool :
Capacité de défaillance maximale. Cette valeur est le nombre maximum de serveurs pouvant tomber en panne avant que les ressources ne soient insuffisantes pour exécuter toutes les machines virtuelles protégées du pool. Pour calculer la capacité de défaillance maximale, XenServer prend en compte les éléments suivants :
Limite de défaillance du serveur. Vous pouvez définir cette valeur dans le cadre de la configuration haute disponibilité qui spécifie le nombre de pannes de serveur à autoriser dans le pool, au sein du plan. Par exemple, lorsque la limite de défaillance d’un pool est de 3, XenServer calcule un plan de basculement qui permet à 3 serveurs de tomber en panne et à toutes les machines virtuelles protégées de continuer à fonctionner dans le pool. Vous pouvez configurer la limite de défaillance du serveur à une valeur inférieure à la capacité de défaillance maximale, ce qui rend moins probable que le pool soit surchargé. Cette configuration peut être utile dans un environnement où le RBAC est activé. Par exemple, ce paramètre permet aux utilisateurs RBAC disposant d’autorisations inférieures à celles de l’opérateur de pool de mettre davantage de machines virtuelles en ligne sans interrompre le plan de haute disponibilité. Pour plus d’informations, consultez la section Haute disponibilité et contrôle d’accès basé sur les rôles (RBAC) .
Une alerte système est générée lorsque la valeur maximale de la capacité de défaillance tombe en dessous de la valeur spécifiée pour la limite de défaillance du serveur.
Lorsque la haute disponibilité est activée pour la première fois sur un pool, un plan d’échec est calculé sur la base des ressources disponibles alors. XenServer High Availability calcule dynamiquement un nouveau plan de défaillance en réponse à des événements susceptibles d’affecter le pool, par exemple le démarrage d’une nouvelle machine virtuelle. Si un nouveau plan ne peut pas être calculé en raison de ressources insuffisantes dans le pool, le pool est surchargé. Des exemples de ressources insuffisantes peuvent être l’insuffisance de mémoire libre ou les modifications apportées aux disques virtuels et aux réseaux qui affectent les machines virtuelles susceptibles d’être redémarrées sur quels serveurs.
La priorité de redémarrage haute disponibilité est utilisée pour déterminer les machines virtuelles à démarrer lorsqu’un pool est surchargé. Lorsque vous configurez la priorité de redémarrage pour les machines virtuelles que vous souhaitez protéger dans la boîte de dialogue Configuration HA ou dans l’assistant Configurer HA, la capacité de défaillance maximale du pool est recalculée dynamiquement. Ces informations vous permettent d’essayer différentes combinaisons de priorités de redémarrage de machines virtuelles en fonction des besoins de votre entreprise. Vous pouvez voir si la capacité de défaillance maximale est appropriée au niveau de protection dont vous avez besoin pour les machines virtuelles critiques du pool.
Si vous tentez de démarrer ou de reprendre une machine virtuelle et que cette action entraîne un surengagement du pool, un avertissement s’affiche dans XenCenter. Le message peut également être envoyé à une adresse e-mail, si elle est configurée. Vous avez la possibilité d’annuler l’opération, ou de continuer de toute façon, provoquant une surcharge du pool.
La meilleure pratique en matière de haute disponibilité consiste à ne pas apporter de modifications de configuration au pool tant que la haute disponibilité est activée. Au lieu de cela, il est destiné à être la « sauvegarde de 2 heures du matin » qui redémarre les serveurs en cas de problème lorsqu’il n’y a pas d’administrateur humain à proximité. Si vous apportez activement des modifications de configuration dans le pool, telles que l’application de mises à jour logicielles, désactivez la haute disponibilité pendant ces modifications.
Dans les environnements XenServer où le contrôle d’accès basé sur les rôles (RBAC) est implémenté, tous les utilisateurs ne sont pas autorisés à modifier les paramètres de configuration de haute disponibilité d’un pool. Par exemple, les opérateurs de machine virtuelle ne disposent pas d’autorisations suffisantes pour ajuster la capacité de basculement d’un pool activé par HA. Si le démarrage d’une machine virtuelle réduit le nombre maximal de pannes de serveur autorisées à une valeur inférieure à la valeur actuelle, un opérateur de machine virtuelle ne peut pas démarrer la machine virtuelle. Seuls les utilisateurs de niveau administrateur de pool ou opérateur de pool peuvent configurer le nombre de pannes de serveur autorisées.
Dans ce cas, l’administrateur de pool ou l’opérateur de pool peut définir la limite de défaillance du serveur sur un nombre inférieur au nombre maximum d’échecs autorisés. Ce paramètre crée une marge de capacité et garantit ainsi que les utilisateurs moins privilégiés peuvent démarrer de nouvelles machines virtuelles. Il réduit la capacité de basculement du pool sans menacer le plan de défaillance.