À propos de XenServer HA

XenServer High Availability (HA) permet de redémarrer automatiquement les machines virtuelles en cas de défaillance matérielle sous-jacente ou de perte d’un serveur géré. HA consiste à s’assurer que les machines virtuelles importantes sont toujours en cours d’exécution dans un pool de ressources. Si l’HA est activée, si l’un de vos serveurs tombe en panne, ses machines virtuelles seront redémarrées intelligemment sur d’autres serveurs du même pool, ce qui permet de restaurer les services essentiels en cas de défaillance du système ou des composants avec une interruption minimale du service. Si le serveur maître du pool échoue, XenServer HA sélectionne automatiquement un nouveau serveur à prendre la relève en tant que maître, de sorte que vous pouvez continuer à gérer le pool. Tout serveur d’un pool peut être un serveur maître, et la base de données du pool est constamment répliquée sur tous les nœuds et sauvegardée sur un stockage partagé sur le serveur de fréquence cardiaque pour plus de sécurité.

Il existe deux aspects clés de XenServer HA : détecter de manière fiable les défaillances du serveur et calculer un plan de défaillance pour permettre une récupération rapide, et ceux-ci sont décrits en détail ci-dessous.

Heartbeats pour la disponibilité

Il est difficile de détecter de manière fiable les défaillances du serveur, car vous devez faire la distinction à distance entre un serveur qui disparaît pendant un certain temps et une défaillance catastrophique. Si nous décidons par erreur qu’un serveur maître est en panne et que nous choisissons un nouveau maître à sa place, il peut y avoir des résultats imprévisibles si le serveur d’origine devait faire un retour. De même, s’il y a un problème de réseau et qu’un pool de ressources se divise en deux moitiés égales, nous devons nous assurer que seulement la 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 rythme cardiaque de stockage et un rythme cardiaque réseau.

Lorsque vous activez l’HA dans un pool, vous nommez un référentiel de stockage iSCSI, Fibre Channel ou NFS comme étant le SR de pulsation. XenServer crée automatiquement quelques petits disques virtuels dans cette SR. Le premier disque est utilisé par chaque serveur du pool de ressources en tant que disque quorum partagé. Chaque serveur s’alloue un bloc unique dans le disque partagé et écrit régulièrement dans le bloc pour indiquer qu’il est actif. Lorsque HA démarre, tous les serveurs échangent des données sur les canaux réseau et de stockage, indiquant quels serveurs ils peuvent voir sur les deux canaux, c’est-à-dire quels chemins d’E/S fonctionnent et ceux qui ne le sont pas. Ces informations sont échangées jusqu’à ce qu’un point fixe soit atteint et que tous les serveurs du pool sont convaincus qu’ils sont d’accord sur ce qu’ils peuvent voir. Lorsque cela se produit, HA est activé et le pool est protégé. Ce processus d’armement des HA peut prendre quelques minutes pour se contenter de grands pools, mais n’est requis que lorsque l’HA est activée pour la première fois.

Une fois qu’HA est active, chaque serveur écrit régulièrement des mises à jour de stockage sur le disque virtuel pulsation et les paquets réseau via l’interface de gestion. (Il est essentiel de veiller à ce que les cartes réseau soientlié/en-us/xencenter/current-release/hosts-nics.html[()]adaptées à la résilience et que les interfaces de stockage utilisentmultiacheminement dynamique[]/en-us/xencenter/current-release/storage-pools-multipathing.htmllorsque cela est pris en charge.) Cela garantira que toute défaillance de carte ou de câblage unique n’entraîne aucun problème de disponibilité.

Clôture des serveurs

Le pire scénario pour HA est la situation où un serveur est considéré comme hors ligne, mais qui écrit toujours dans le stockage partagé, car cela peut entraîner une corruption de données persistantes. Afin d’éviter cette situation, XenServer utilise l’escrime de serveur, c’est-à-dire que le serveur est automatiquement mis hors tension et isolé d’accéder aux ressources partagées du pool. Cela empêche le serveur défaillant d’écrire sur des disques partagés et d’endommager la cohérence des données stockées lors du basculement automatisé, lorsque des machines virtuelles protégées sont déplacées vers d’autres serveurs sains du pool.

Les serveurs s’auto-clôturent (c’est-à-dire s’éteindront et redémarreront) en cas de panne cardiaque, sauf si l’un des éléments suivants est vrai :

  • Le rythme cardiaque de stockage est présent pour tous les serveurs, mais le réseau a partitionné (de sorte qu’il y a maintenant deux groupes de serveurs). Dans ce cas, tous les serveurs qui sont membres de la plus grande partition réseau restent en cours d’exécution, et les serveurs de la petite partition réseau s’auto-clôturent. 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’une mise en réseau opérationnelle. Si les partitions réseau sont exactement de la même taille, alors une seule d’entre elles s’auto-clôturera selon une fonction de sélection stable.
  • Si le rythme cardiaque de stockage disparaît mais que le rythme cardiaque du réseau reste, les serveurs vérifient s’ils peuvent voir tous les autres serveurs sur le réseau. Si cette condition est vraie, les serveurs restent en cours d’exécution en supposant que le serveur de pulsations de stockage a disparu. Cela ne compromet pas la sécurité de la machine virtuelle, mais tout problème de réseau entraînera une clôture, car cela signifierait que les deux battements cardiaques ont disparu.

Planification des capacités en cas de panne

Le système de pulsation nous donne une notification fiable en cas de panne de serveur, et nous passons donc à la deuxième étape de la HA : 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 potentiellement différentes de mémoire et un nombre différent de machines virtuelles en cours d’exécution. Afin de s’assurer qu’aucune défaillance d’un 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 un autre serveur), XenServer HA calcule dynamiquement un plan d’échec qui calcule les actions qui seraient prises en cas de défaillance du serveur. En plus de gérer les défaillances d’un seul serveur, XenServer HA peut gérer la perte de plusieurs serveurs dans un pool, par exemple lorsque la défaillance d’une partition réseau entraîne 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. Il y a deux facteurs importants à considérer dans le calcul du plan d’AP pour un pool :

  • Capacité de défaillance maximale. Il s’agit du nombre maximal de serveurs qui peuvent échouer avant qu’il n’y ait suffisamment de ressources pour exécuter toutes les machines virtuelles protégées dans le pool ; cette valeur est calculée par XenServer en tenant compte des priorités de redémarrage des machines virtuelles du pool et de la configuration du pool (le nombre de serveurs, leur processeur et leur mémoire) capacité).
  • Limite de défaillance du serveur. Il s’agit d’une valeur que vous pouvez définir dans le cadre de la configuration HA qui spécifie le nombre de défaillances de serveur que vous souhaitez autoriser dans le pool, dans le plan HA. Par exemple, dans un pool de ressources de 16 serveurs, lorsque vous définissez la limite de défaillance du serveur sur 3, XenServer calcule un plan de basculement qui permet à 3 serveurs d’échouer tout en restant en mesure d’exécuter toutes les machines virtuelles protégées 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 devienne surengagé. Cela peut être utile dans un environnement avec RBAC activé, par exemple, pour permettre aux utilisateurs RBAC sans autorisation d’opérateur de pool d’apporter plus de machines virtuelles en ligne sans rompre le plan HA ; voirHA et contrôle d’accès basé sur les rôles (RBAC)ci-dessous.

Une alerte système est générée lorsque la valeur de 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 l’HA est activée pour la première fois sur un pool, un plan d’échec est calculé en fonction des ressources disponibles à ce moment. XenServer HA 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 (par exemple, la mémoire libre insuffisante ou les modifications apportées aux disques virtuels et aux réseaux qui affectent les machines virtuelles pouvant être redémarrées sur quels serveurs), le pool devient surengagé.

La priorité de redémarrage HA est utilisée pour déterminer quelles machines virtuelles doivent être démarrées lorsqu’un pool est survalorisé. Lorsque vous configurez la priorité de redémarrage pour les machines virtuelles que vous souhaitez protéger dans la boîte de dialogue Configuration H A ou dans l’Assistant Configurer HA , vous pouvez voir la capacité de défaillance maximale du pool recalculé dynamiquement, ce qui vous permet d’essayer diverses combinaisons de redémarrage de VM en fonction des besoins de votre entreprise, et voyez si la capacité de défaillance maximale est adapté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 une surutilisation du pool, un avertissement s’affichera dans XenCenter. Le message peut également être envoyé à une adresse e-mail, si elle est configurée. Vous serez alors autorisé à annuler l’opération, ou à continuer de toute façon, provoquant la surutilisation du pool.

Utilisation d’un pool compatible HA

La meilleure pratique pour HA est de ne pas apporter de modifications de configuration au pool lorsque HA est activée. Au lieu de cela, il est destiné à être la « sauvegarde 2am » qui redémarrera les serveurs en cas de problème lorsqu’il n’y a pas d’administrateur humain à proximité. Si vous effectuez activement des modifications de configuration dans le pool, telles que l’application de mises à jour logicielles, HA doit être désactivée pendant la durée de ces modifications.

  • Si vous essayez d’arrêter une machine virtuelle protégée à partir de XenCenter, XenCenter vous offre la possibilité de supprimer d’abord la machine virtuelle du plan de défaillance du pool, puis de l’arrêter. Cela garantit que les arrêts accidentels de machines virtuelles n’entraîneront pas de temps d’arrêt, mais que vous pouvez toujours arrêter une machine virtuelle protégée si vous le souhaitez.
  • Si vous devez redémarrer un serveur lorsque HA est activée, XenCenter utilise automatiquement les priorités de redémarrage de la machine virtuelle pour déterminer si cela invalide le plan d’échec du pool. Si cela n’affecte pas le plan, le serveur est arrêté normalement. Si le plan est violé, mais que la capacité de défaillance maximale est supérieure à 1, XenCenter vous donnera la possibilité d’abaisser de 1 la limite de défaillance du serveur du pool. Cela réduit la résilience globale du pool, mais garantit toujours qu’au moins une défaillance du serveur sera tolérée. Lorsque le serveur revient, 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 àmises à jour logiciellesl’aide de l’Assistant Installer la mise à jour, vous devez désactiver HA sur le pool en cliquant sur l’option Désactiver HAjusqu’à ce que la mise à jour ait été installée. Si vous ne désactivez pas HA, la mise à jour ne se poursuivra pas. Vous devrez surveiller 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 l’HA est activée, certaines opérations qui compromettraient 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, vous devez désactiver temporairement HA ou vous pouvez arrêter les machines virtuelles protégées avant de continuer.

HA 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 seront pas autorisés à modifier les paramètres de configuration HA d’un pool. Les utilisateurs qui peuvent démarrer des machines virtuelles (opérateurs de machines virtuelles), par exemple, ne disposent pas des autorisations suffisantes pour ajuster la capacité de basculement pour un pool activé HA. Par exemple, si le démarrage d’une machine virtuelle réduit le nombre maximal de défaillances de serveur autorisé à une valeur inférieure à la capacité de défaillance maximale actuelle, l’opérateur de machine virtuelle ne pourra 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’utilisateur qui active HA (avec un rôle Administrateur de pool ou Opérateur de pool) peut définir la limite de défaillance du serveur sur un nombre inférieur au nombre maximal d’échecs autorisé. Cela crée une capacité insuffisante et garantit ainsi que les utilisateurs moins privilégiés peuvent démarrer de nouvelles machines virtuelles et réduire la capacité de basculement du pool sans menacer le plan de défaillance.