4.12. Haute disponibilité et clusters
Le méta-attribut de ressource resource-stickiness est désormais fixé par défaut à 1 au lieu de 0 pour les grappes nouvellement créées
Auparavant, la valeur par défaut du méta-attribut resource-stickiness resource était de 0 pour les clusters nouvellement créés. La valeur par défaut de ce méta-attribut est désormais de 1.
Avec une adhérence de 0, une grappe peut déplacer des ressources si nécessaire pour équilibrer les ressources entre les nœuds. Les ressources peuvent donc se déplacer lorsque des ressources non apparentées démarrent ou s'arrêtent. Avec un taux de fidélité positif, les ressources préfèrent rester là où elles sont et ne se déplacent que si d'autres circonstances l'emportent sur le taux de fidélité. Cela peut avoir pour conséquence que les nœuds nouvellement ajoutés ne se voient pas attribuer de ressources sans l'intervention de l'administrateur. Les deux approches ont un comportement potentiellement inattendu, mais la plupart des utilisateurs préfèrent une certaine rigidité. La valeur par défaut de ce méta-attribut a été fixée à 1 pour refléter cette préférence.
Seules les grappes nouvellement créées sont concernées par cette modification, de sorte que le comportement ne change pas pour les grappes existantes. Les utilisateurs qui préfèrent l'ancien comportement pour leur cluster peuvent supprimer l'entrée resource-stickiness des ressources par défaut.
(BZ#1850145)
Nouvel indicateur de groupe de volume LVM pour contrôler l'auto-activation
Les groupes de volumes LVM prennent désormais en charge l'indicateur setautoactivation qui détermine si les volumes logiques que vous créez à partir d'un groupe de volumes seront automatiquement activés au démarrage. Lors de la création d'un groupe de volumes qui sera géré par Pacemaker dans un cluster, définissez cet indicateur sur n avec la commande vgcreate --setautoactivation n pour le groupe de volumes afin d'éviter une éventuelle corruption des données. Si vous disposez d'un groupe de volumes existant utilisé dans un cluster Pacemaker, définissez l'indicateur avec vgchange --setautoactivation n.
Nouvelles commandes d'affichage de l'état des ressources pcs
Les commandes pcs resource status et pcs stonith status prennent désormais en charge les options suivantes :
-
Vous pouvez afficher l'état des ressources configurées sur un nœud spécifique à l'aide de la commande
pcs resource status node=node_idet la commandepcs stonith status node=node_idet la commande Vous pouvez utiliser ces commandes pour afficher l'état des ressources sur les nœuds de cluster et les nœuds distants. -
Vous pouvez afficher l'état d'une seule ressource à l'aide des boutons
pcs resource status resource_idet la commandepcs stonith status resource_idpour afficher l'état d'une seule ressource. -
Vous pouvez afficher l'état de toutes les ressources avec une balise spécifiée à l'aide des boutons
pcs resource status tag_idet la commandepcs stonith status tag_idpour afficher l'état de toutes les ressources dont la balise est spécifiée.
(BZ#1290830, BZ#1285269)
Nouvelle option d'affichage réduit pour la commande pcs resource safe-disable
Les commandes pcs resource safe-disable et pcs resource disable --safe impriment un long résultat de simulation après un rapport d'erreur. Vous pouvez désormais spécifier l'option --brief pour ces commandes afin de n'imprimer que les erreurs. Le rapport d'erreur contient toujours les identifiants des ressources affectées.
Nouvelle commande pcs pour mettre à jour le dispositif de clôture SCSI sans provoquer le redémarrage de toutes les autres ressources
La mise à jour d'un dispositif de clôture SCSI à l'aide de la commande pcs stonith update entraîne le redémarrage de toutes les ressources s'exécutant sur le même nœud que celui où s'exécutait la ressource stonith. La nouvelle commande pcs stonith update-scsi-devices vous permet de mettre à jour les périphériques SCSI sans provoquer le redémarrage des autres ressources du cluster.
Possibilité de configurer un SBD avec chien de garde uniquement pour la clôture d'un sous-ensemble de nœuds de la grappe
Auparavant, pour utiliser une configuration SBD avec chien de garde uniquement, tous les nœuds de la grappe devaient utiliser le SBD. Cela empêchait d'utiliser le SMD dans un cluster où certains nœuds le supportent mais où d'autres nœuds (souvent des nœuds distants) ont besoin d'une autre forme de clôture. Les utilisateurs peuvent désormais configurer une configuration SBD avec chien de garde uniquement à l'aide du nouvel agent fence_watchdog, qui permet de configurer des clusters dans lesquels seuls certains nœuds utilisent le SBD avec chien de garde uniquement pour le clôturage et d'autres nœuds utilisent d'autres types de clôturage. Un cluster ne peut avoir qu'un seul dispositif de ce type, et il doit être nommé watchdog.
Affichage détaillé de l'état du stimulateur cardiaque pour les erreurs internes
Si Pacemaker ne peut pas exécuter une ressource ou un agent de clôture pour une raison quelconque, par exemple si l'agent n'est pas installé ou s'il y a eu un dépassement de délai interne, les écrans d'état de Pacemaker affichent désormais un motif de sortie détaillé pour l'erreur interne.
(BZ#1470834)
Le paramètre pcmk_delay_base peut désormais prendre des valeurs différentes selon les nœuds
Lors de la configuration d'un dispositif de clôture, vous pouvez désormais spécifier des valeurs différentes pour différents nœuds à l'aide de l'adresse pcmk_delay_base parameter. Cela permet d'utiliser un seul dispositif de clôture dans un cluster à deux nœuds, avec un délai différent pour chaque nœud. Cela permet d'éviter que chaque nœud tente de clôturer l'autre nœud en même temps. Pour spécifier des valeurs différentes pour les différents nœuds, vous mappez les noms d'hôte à la valeur de délai pour ce nœud en utilisant une syntaxe similaire à celle de pcmk_host_map. Par exemple, node1:0;node2:10s n'utilise pas de délai pour clôturer le nœud 1 et un délai de 10 secondes pour clôturer le nœud 2.
Prise en charge des caractères spéciaux dans les valeurs pcmk_host_map
La propriété pcmk_host_map prend désormais en charge les caractères spéciaux dans les valeurs pcmk_host_map en utilisant une barre oblique inverse (\N) devant la valeur. Par exemple, vous pouvez spécifier pcmk_host_map="node3:plug\ 1" pour inclure un espace dans l'alias de l'hôte.
Nouvel agent de clôture pour OpenShift
L'agent de clôture fence_kubevirt est désormais disponible pour une utilisation avec RHEL High Availability sur Red Hat OpenShift Virtualization. Pour plus d'informations sur l'agent fence_kubevirt, consultez la page de manuel fence_kubevirt(8).
La version en mode local de la commande pcs cluster setup est désormais entièrement prise en charge
Par défaut, la commande pcs cluster setup synchronise automatiquement tous les fichiers de configuration sur les nœuds du cluster. La commande pcs cluster setup prend désormais en charge l'option --corosync-conf. En spécifiant cette option, la commande passe en mode local. Dans ce mode, l'interface de ligne de commande pcs crée un fichier corosync.conf et l'enregistre dans un fichier spécifié sur le nœud local uniquement, sans communiquer avec aucun autre nœud. Cela vous permet de créer un fichier corosync.conf dans un script et de gérer ce fichier au moyen du script.
Suppression automatique des contraintes de localisation à la suite d'un déplacement de ressources
Lorsque vous exécutez la commande pcs resource move, vous ajoutez une contrainte à la ressource pour l'empêcher de s'exécuter sur le nœud sur lequel elle s'exécute actuellement. Par défaut, la contrainte d'emplacement créée par la commande est automatiquement supprimée une fois que la ressource a été déplacée. Cela ne ramène pas nécessairement les ressources sur le nœud d'origine ; l'endroit où les ressources peuvent s'exécuter à ce moment-là dépend de la manière dont vous avez configuré vos ressources au départ. Si vous souhaitez déplacer une ressource et laisser en place la contrainte qui en résulte, utilisez la commande pcs resource move-with-contraint.
pcs support pour la norme OCF Resource Agent API 1.1
L'interface en ligne de commande pcs prend désormais en charge les agents OCF 1.1 resource et STONITH. Dans le cadre de la mise en œuvre de ce support, les métadonnées de tout agent doivent être conformes au schéma OCF, que l'agent soit un agent OCF 1.0 ou OCF 1.1. Si les métadonnées d'un agent ne sont pas conformes au schéma OCF, pcs considère que l'agent n'est pas valide et ne créera pas ou ne mettra pas à jour une ressource de l'agent, sauf si l'option --force est spécifiée. L'interface Web pcsd et les commandes pcs pour lister les agents omettent désormais les agents dont les métadonnées ne sont pas valides.
pcs accepte désormais Promoted et Unpromoted comme noms de rôle
L'interface de ligne de commande pcs accepte désormais Promoted et Unpromoted partout où des rôles sont spécifiés dans la configuration de Pacemaker. Ces noms de rôles sont l'équivalent fonctionnel des rôles Master et Slave de Pacemaker dans les versions précédentes de RHEL, et ce sont les noms de rôles qui sont visibles dans les affichages de configuration et les pages d'aide.
Version actualisée de l'interface web pcsd
L'interface Web pcsd, l'interface utilisateur graphique permettant de créer et de configurer les clusters Pacemaker/Corosync, a été mise à jour. L'interface Web mise à jour offre une expérience utilisateur améliorée et une interface standardisée qui est construite avec le cadre PatternFly utilisé dans d'autres applications Web de Red Hat.
(BZ#1996067)
