Haute disponibilité
La haute disponibilité de XenServer permet aux machines virtuelles de redémarrer automatiquement en cas de panne matérielle sous-jacente ou de perte d’un serveur. La haute disponibilité consiste à garantir que les machines virtuelles importantes s’exécutent toujours dans un pool de ressources. Avec la haute disponibilité 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 capacité permet de restaurer les services essentiels avec une interruption de service minimale en cas de défaillance du système ou d’un composant.
Si le serveur coordinateur de pool échoue, la haute disponibilité XenServer sélectionne un nouveau serveur pour prendre le relais en tant que coordinateur de pool. N’importe quel 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 Heartbeat pour plus de sécurité.
La haute disponibilité de XenServer comporte deux aspects clés :
- Détecter de manière fiable les pannes de serveur
- Calculer un plan d’échec pour permettre une récupération rapide
Battements de cœur pour la disponibilité
Détecter de manière fiable une panne de serveur est difficile car vous devez faire la distinction à distance entre la disparition d’un serveur pendant un certain temps et une panne catastrophique. Si la haute disponibilité décide à tort qu’un serveur coordinateur de pool est en panne et élit un nouveau coordinateur de pool, les résultats peuvent être 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 qu’une seule moitié accède au stockage partagé et non les deux simultanément. XenServer résout tous ces problèmes en ayant 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 désignez un référentiel de stockage iSCSI, Fibre Channel ou NFS comme SR de pulsation. XenServer crée automatiquement quelques petits disques virtuels dans ce SR. Le premier disque est utilisé par chaque serveur du pool de ressources comme disque quorum partagé. Chaque serveur s’attribue 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 via les canaux réseau et de stockage. Cette action indique quels serveurs ils peuvent voir sur les deux canaux et démontre quels chemins d’E/S fonctionnent et lesquels ne fonctionnent pas. Ces informations sont échangées jusqu’à ce qu’un point fixe soit atteint et que tous les serveurs du pool soient d’accord sur ce qu’ils peuvent voir. Lorsque cet accord se produit, la haute disponibilité est activée et le pool est protégé. Ce processus d’armement de haute disponibilité peut prendre quelques minutes pour s’adapter à des pools plus grands, mais n’est requis que lorsque vous activez la haute disponibilité pour la première fois.
Une fois la haute disponibilité activée, chaque serveur écrit régulièrement des mises à jour de stockage sur le disque virtuel de pulsation et des paquets réseau sur l’interface de gestion. Assurez-vous que les adaptateurs réseau sont liés pour la résilience et que les interfaces de stockage utilisent le multivoie dynamique lorsqu’il est pris en charge. Cette configuration garantit qu’aucune défaillance d’adaptateur ou de câblage n’entraîne de problèmes de disponibilité.
Pour plus d’informations, consultez :
Clôture des serveurs
Le pire scénario pour la haute disponibilité est celui où l’on pense qu’un serveur est hors ligne mais qu’il écrit toujours dans le stockage partagé. Ce scénario peut entraîner l’altération des données persistantes. XenServer utilise le fencement des serveurs pour éviter cette situation. Le serveur est automatiquement mis hors tension et isolé de l’accès aux ressources partagées du pool. La séparation empêche le serveur défaillant d’écrire sur les disques partagés. Ce comportement permet d’éviter d’endommager les données stockées lors d’un basculement automatisé, lorsque des machines virtuelles protégées sont déplacées vers d’autres serveurs du pool.
Les serveurs se mettent automatiquement en marche (c’est-à-dire qu’ils s’éteignent et redémarrent) en cas d’échec de la pulsation, sauf si l’une des conditions suivantes est vraie :
- La pulsation de stockage est présente pour tous les serveurs, mais le réseau a été partitionné (de sorte qu’il y a maintenant deux groupes de serveurs). Dans ce cas, tous les serveurs membres de la partition réseau la plus volumineuse restent en cours d’exécution et les serveurs de la partition réseau la plus petite se clôturent automatiquement. L’hypothèse ici est que la panne de réseau a isolé les machines virtuelles et qu’elles doivent être redémarrées sur un serveur doté d’un réseau fonctionnel. Si les partitions réseau sont de la même taille, alors une seule d’entre elles s’auto-clôture selon une fonction de sélection stable.
- Si la pulsation de stockage disparaît mais que la pulsation du réseau persiste, les serveurs vérifient s’ils peuvent voir tous les autres serveurs du réseau. Si cette condition est vraie, les serveurs restent en cours d’exécution en supposant que le serveur de pulsation de stockage a disparu. Cette action ne compromet pas la sécurité de la machine virtuelle, mais tout problème de réseau entraîne une clôture, car cela signifie que les deux pulsations ont disparu.
Planification de la capacité en cas de défaillance
Le système de pulsation nous envoie 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 (par exemple, 32), chacun avec des quantités de mémoire potentiellement différentes et un nombre différent de machines virtuelles en cours d’exécution. La haute disponibilité de XenServer calcule dynamiquement un plan de défaillance qui calcule les actions à entreprendre en cas de défaillance d’un serveur. Ce plan d’échec garantit qu’aucune défaillance d’un seul serveur n’empêche 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 la gestion de la défaillance d’un seul serveur, la haute disponibilité XenServer peut gérer la perte de plusieurs serveurs dans un pool. Par exemple, la haute disponibilité peut être gérée lorsque la défaillance d’une partition réseau entraîne l’arrêt d’un groupe entier de serveurs.
En plus de calculer les actions effectuées, le plan d’échec prend en compte le nombre de défaillances de serveur qui peuvent être tolérées dans le pool. Deux considérations importantes entrent en jeu dans le calcul du plan de haute disponibilité d’un pool :
-
Capacité de défaillance maximale. Cette valeur correspond au nombre maximal de serveurs qui peuvent échouer avant que les ressources ne soient insuffisantes pour exécuter toutes les machines virtuelles protégées dans le pool. Pour calculer la capacité de défaillance maximale, XenServer prend en compte les éléments suivants :
- Les priorités de redémarrage des machines virtuelles dans le pool
- Le nombre de serveurs dans le pool
- La capacité du processeur et de la mémoire du serveur
-
Limite de défaillance du serveur. Vous pouvez définir cette valeur dans le cadre de la configuration de haute disponibilité qui spécifie le nombre de défaillances de serveur à autoriser dans le pool, dans le cadre du plan. Par exemple, lorsque la limite de défaillance d’un serveur pour un pool est de 3, XenServer calcule un plan de basculement qui permet à 3 serveurs de tomber en panne et à toutes les VM protégées de s’exécuter dans le pool. Vous pouvez configurer la limite de défaillance du serveur sur une valeur inférieure à la capacité de défaillance maximale, ce qui réduit le risque de surcharge du pool. Cette configuration peut être utile dans un environnement où 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 en ligne davantage de machines virtuelles sans interrompre le plan de haute disponibilité. Pour plus d’informations, consultez la page Haute disponibilité et contrôle d’accès basé sur les rôles (RBAC) section.
Une alerte système est générée lorsque la valeur de la capacité de défaillance maximale tombe en dessous de la valeur spécifiée pour la limite de défaillance du serveur.
Protection contre les surengagements
Lorsque la haute disponibilité est activée pour la première fois sur un pool, un plan d’échec est calculé en fonction des ressources disponibles à ce moment-là. La haute disponibilité de XenServer calcule dynamiquement un nouveau plan d’échec en réponse à des événements qui affecteraient 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, celui-ci est surchargé. Par exemple, des ressources insuffisantes peuvent être une mémoire libre insuffisante ou des 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 de la 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 des machines virtuelles que vous souhaitez protéger dans le Configuration de la haute disponibilité ou dans la boîte de dialogue 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 machine virtuelle 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 une survalidation 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 quand même, ce qui entraîne une surcharge du pool.
Utilisation d’un pool compatible HA
La meilleure pratique pour la haute disponibilité consiste à ne pas apporter de modifications de configuration au pool lorsque la haute disponibilité est activée. Au lieu de cela, il s’agit d’une « sauvegarde à 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.
- Si vous essayez d’arrêter une machine virtuelle protégée à partir de XenCenter, XenCenter offre la possibilité de supprimer la machine virtuelle du plan d’échec, puis de l’arrêter. Cette option garantit que les arrêts accidentels de machines virtuelles n’entraînent pas de temps d’arrêt, mais que vous pouvez toujours arrêter une machine virtuelle protégée si vous le souhaitez vraiment.
- Si vous devez redémarrer un serveur lorsque la haute disponibilité est activée, XenCenter utilise automatiquement les priorités de redémarrage de la machine virtuelle pour déterminer si ce redémarrage invalide le plan de défaillance du pool. Si cela n’affecte pas le plan, le serveur est arrêté normalement. Si le plan n’est pas respecté, mais que la capacité de défaillance maximale est supérieure à 1, XenCenter offre la possibilité de réduire de 1 la limite de défaillance du serveur du pool. Cette action réduit la résilience globale du pool, mais garantit toujours qu’au moins une défaillance du serveur est tolérée. Lorsque le serveur redémarre, le plan est automatiquement recalculé et la limite de défaillance du serveur d’origine est restaurée le cas échéant.
- Lorsque vous installez des mises à jour logicielles à l’aide de la commande Installer les mises à jour , vous devez désactiver la haute disponibilité sur le pool en sélectionnant Désactiver la haute disponibilité. Vous pouvez réactiver la haute disponibilité après l’installation de la mise à jour. Si vous ne désactivez pas la haute disponibilité, la mise à jour ne se poursuit pas. Surveillez le pool manuellement pendant l’installation des mises à jour pour vous assurer que les défaillances du serveur n’interrompent pas le fonctionnement du pool.
- Lorsque la haute disponibilité est activée, certaines opérations susceptibles de compromettre le plan de redémarrage des machines virtuelles peuvent être désactivées, telles que la suppression d’un serveur d’un pool. Pour effectuer ces opérations, désactivez temporairement la haute disponibilité ou vous pouvez arrêter les machines virtuelles protégées avant de continuer.
Haute disponibilité et contrôle d’accès basé sur les rôles (RBAC)
Dans les environnements XenServer où le contrôle d’accès en fonction du rôle (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 machines virtuelles ne disposent pas des autorisations suffisantes pour ajuster la capacité de basculement d’un pool compatible HA. Si le démarrage d’une machine virtuelle réduit le nombre maximal de défaillances 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 ou Opérateur de pool peuvent configurer le nombre de défaillances de serveur autorisées.
Dans ce cas, l’administrateur ou l’opérateur du pool peut définir la limite d’échec du serveur sur un nombre inférieur au nombre maximal d’échecs autorisés. Ce paramètre crée une capacité insuffisante 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.