Haute disponibilité
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é vise à garantir 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 capacité permet de restaurer les services essentiels avec une interruption minimale en cas de défaillance du système ou d’un composant.
Si le serveur coordinateur de pool tombe en panne, la haute disponibilité de XenServer sélectionne un nouveau serveur pour prendre le relais 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 une sécurité accrue.
La haute disponibilité de XenServer repose sur deux aspects clés :
- Détection fiable des pannes de serveur
- Calcul d’un plan de défaillance pour permettre une récupération rapide
Pulsations pour la disponibilité
Détecter de manière fiable une panne de serveur est difficile, car il faut distinguer à distance si un serveur disparaît temporairement ou s’il s’agit d’une panne catastrophique. Si la haute disponibilité décide à tort qu’un serveur coordinateur de pool est tombé en panne et élit un nouveau coordinateur de pool, des résultats imprévisibles pourraient survenir si le serveur d’origine revient. De même, si un problème réseau provoque 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 grâce à deux mécanismes : une pulsation de stockage et une pulsation 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 de quorum partagé. Chaque serveur s’attribue un bloc unique dans le disque partagé et écrit régulièrement dans ce bloc pour indiquer qu’il est actif. Lorsque la haute disponibilité démarre, tous les serveurs échangent des données via les canaux de stockage et les canaux réseau. La pulsation réseau utilise un transport UDP sur le port 694. 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 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 de la haute disponibilité peut prendre quelques minutes pour les pools plus grands, mais il n’est requis que lors de la première activation de la haute disponibilité.
Une fois la haute disponibilité active, chaque serveur écrit régulièrement des mises à jour de stockage sur le disque virtuel de pulsation et des paquets réseau via l’interface de gestion. Assurez-vous que les cartes réseau sont agrégées pour la résilience et que les interfaces de stockage utilisent le multipathing dynamique là où il est pris en charge. Cette configuration garantit qu’aucune défaillance d’adaptateur ou de câblage unique n’entraîne de problèmes de disponibilité.
Pour plus d’informations, consultez :
Mise en quarantaine des serveurs
Le pire scénario pour la haute disponibilité est celui où un serveur est considéré comme hors ligne mais continue d’écrire sur le stockage partagé. Ce scénario peut entraîner une corruption des données persistantes. XenServer utilise la mise en quarantaine des serveurs pour éviter cette situation. Le serveur est automatiquement mis hors tension et isolé de l’accès à toutes les ressources partagées du pool. La mise en quarantaine empêche le serveur défaillant d’écrire sur les disques partagés. Ce comportement évite d’endommager les données stockées lors d’un basculement automatisé, lorsque les machines virtuelles protégées sont déplacées vers d’autres serveurs du pool.
Les serveurs s’auto-isolent (c’est-à-dire s’éteignent et redémarrent) en cas de défaillance du signal de pulsation, sauf si l’une des conditions suivantes est remplie :
- Le signal de pulsation de stockage est présent pour tous les serveurs, mais le réseau a été partitionné (de sorte qu’il existe maintenant deux groupes de serveurs). Dans ce cas, tous les serveurs membres de la plus grande partition réseau restent en cours d’exécution, et les serveurs de la plus petite partition réseau s’auto-isolent. L’hypothèse est que la panne réseau a isolé les machines virtuelles, et qu’elles doivent être redémarrées sur un serveur avec un réseau fonctionnel. Si les partitions réseau sont de la même taille, une seule d’entre elles s’auto-isole selon une fonction de sélection stable.
- Si le signal de pulsation de stockage disparaît mais que le signal de pulsation réseau demeure, les serveurs vérifient s’ils peuvent voir tous les autres serveurs sur le réseau. Si cette condition est remplie, les serveurs restent en cours d’exécution en supposant que le périphérique de stockage a échoué. Cette action ne compromet pas la sécurité des machines virtuelles, mais toute perte de signal de pulsation réseau entraîne une isolation, car cela signifierait que les deux signaux de pulsation ont disparu.
Planification de la capacité en cas de défaillance
Le système de pulsation nous fournit une notification fiable des défaillances de serveur, et nous passons donc à la deuxième étape de la haute disponibilité : la planification de la capacité en cas de défaillance.
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é XenServer calcule dynamiquement un plan de défaillance qui détermine les actions à entreprendre en cas de défaillance d’un serveur. Ce plan de défaillance garantit qu’aucune défaillance de serveur unique 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 gérer 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 gérer la situation où la défaillance d’une partition réseau met hors service un groupe entier de serveurs.
En plus de calculer les actions à entreprendre, le plan de défaillance prend en compte le nombre de défaillances de serveur pouvant être tolérées dans le pool. Deux considérations importantes sont impliquées dans le calcul du plan de haute disponibilité pour un pool :
-
Capacité de défaillance maximale. Cette valeur est le nombre maximal de serveurs pouvant tomber en panne avant qu’il n’y ait des ressources 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 priorités de redémarrage des machines virtuelles dans le pool
- Le nombre de serveurs dans le pool
- La capacité CPU et 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 du serveur pour 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 réduit la probabilité que le pool devienne surchargé. Cette configuration peut être utile dans un environnement où le RBAC est activé. Par exemple, ce paramètre permet aux utilisateurs RBAC ayant des autorisations inférieures à celles de l’opérateur de pool de mettre plus de machines virtuelles en ligne sans rompre 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 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 la surcharge
Lorsque la haute disponibilité est activée pour la première fois sur un pool, un plan de défaillance est calculé en fonction des ressources alors disponibles. La haute disponibilité XenServer calcule dynamiquement un nouveau plan de défaillance 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, le pool devient surchargé. Des exemples de ressources insuffisantes peuvent être une mémoire libre insuffisante ou des modifications des disques virtuels et des réseaux qui affectent les machines virtuelles pouvant être redémarrées sur quels serveurs.
La priorité de redémarrage de la haute disponibilité est utilisée pour déterminer quelles 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 diverses combinaisons de priorités de redémarrage des machines virtuelles en fonction de vos besoins métier. Vous pouvez vérifier 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înerait la surcharge du pool, un avertissement s’affiche dans XenCenter. Le message peut également être envoyé à une adresse e-mail, si configuré. Vous avez la possibilité d’annuler l’opération, ou de continuer quand même, ce qui entraînerait la surcharge du pool.
Utilisation d’un pool activé pour la haute disponibilité
La meilleure pratique pour la haute disponibilité est de ne pas apporter de modifications de configuration au pool lorsque la haute disponibilité est activée. Au lieu de cela, elle est conçue pour être la « protection de 2h du matin » qui redémarre les serveurs en cas de problème lorsqu’aucun administrateur humain n’est à proximité. Si vous effectuez 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 tentez d’arrêter une machine virtuelle protégée depuis XenCenter, XenCenter offre la possibilité de retirer la machine virtuelle du plan de défaillance, 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 des machines virtuelles 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 alors arrêté normalement. Si le plan est violé, mais que la capacité de défaillance maximale est supérieure à 1, XenCenter offre la possibilité de réduire la limite de défaillance du serveur du pool de 1. Cette action réduit la résilience globale du pool, mais garantit toujours qu’au moins une défaillance de 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 si nécessaire.
- Lorsque vous installez des mises à jour logicielles à l’aide de l’assistant Installer les mises à jour, vous devez désactiver la haute disponibilité sur le pool en sélectionnant Désactiver HA. Vous pouvez réactiver la haute disponibilité une fois la mise à jour installée. 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 de 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, comme 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 basé sur les rôles (RBAC) est implémenté, tous les utilisateurs ne sont pas autorisés à modifier les paramètres de configuration de la haute disponibilité d’un pool. Par exemple, les opérateurs de machines virtuelles n’ont pas les autorisations suffisantes pour ajuster la capacité de basculement d’un pool activé pour la haute disponibilité. 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 de pool ou Opérateur de pool peuvent configurer le nombre de défaillances 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 à un nombre inférieur au nombre maximal de défaillances autorisées. Ce paramètre crée une capacité de réserve et garantit ainsi que les utilisateurs moins privilégiés peuvent démarrer de nouvelles machines virtuelles. Cela réduit la capacité de basculement du pool sans menacer le plan de défaillance.