Ce guide concerne BIG-IP sur TMOS. Les noms et options doivent être confrontés à la documentation de votre version.
Choisir où le service doit rester actif
Un HA group permet de comparer la santé de ressources locales sur les équipements BIG-IP. Il contribue à décider quel appareil doit porter un traffic group lorsque la méthode de failover utilise le score HA.
Un équipement peut rester joignable tout en ayant perdu une partie de ses liens utiles. Le HA group apporte alors un critère plus proche de la capacité à servir le trafic. Il complète les mécanismes de Device Service Clustering : il ne remplace ni les communications de failover, ni la synchronisation de configuration.
Le pool répartit les connexions entre serveurs ; le traffic group rassemble des objets flottants qui changent d’équipement lors d’une bascule. Le HA group évalue des ressources pour orienter cette décision. Ces trois groupes ne remplissent donc pas le même rôle.
Source F5 : Managing Failover, traffic groups et HA groups.
Ressources et score
Les ressources prises en compte peuvent être des trunks, des pools et, sur les plateformes concernées, des clusters de blades VIPRION. Une ressource reçoit un poids. Sa disponibilité détermine sa contribution au score local.
Un trunk peut représenter la capacité réseau restante ; un pool, la disponibilité de membres. Choisissez des ressources qui distinguent réellement la capacité de chaque appareil. Un pool de serveurs commun aux deux BIG-IP peut tomber simultanément sur les deux : ce signal ne désigne alors aucun meilleur appareil.
Sources F5 : sys ha-group, ressources et poids ; K16947, recommandations de configuration.
Minimum, sufficient et active bonus
| Paramètre | Signification | Conséquence |
|---|---|---|
| Weight | Importance de la ressource dans le score. | Un poids élevé rend sa dégradation plus déterminante. |
| Minimum threshold | Nombre minimal de liens, membres ou blades exigé. | À partir de BIG-IP 13.0, passer sous un minimum non nul met à zéro le score total du HA group. |
| Sufficient threshold | Nombre à partir duquel la contribution atteint le poids complet. | Permet de considérer une capacité réduite comme suffisante. |
| Active bonus | Bonus accordé à l’appareil actuellement actif. | Limite les bascules pour de faibles écarts ; il ne relève pas un score nul. |
Ne transposez pas une explication ancienne du minimum sans regarder la version : avant BIG-IP 13.0, le passage sous le minimum affectait la contribution de la ressource, sans nécessairement annuler le total. La différence peut changer complètement une décision de bascule.
Sources F5 : K68062382, changement de minimum threshold depuis 13.0 ; sys ha-group, sufficient threshold ; active bonus.
Calculer un exemple
Supposons deux appareils A et B. Chaque HA group utilise un trunk de quatre liens, de poids 80, et un pool de deux membres, de poids 20. Le minimum est de 1 pour chaque ressource. Le seuil suffisant vaut 4 pour le trunk et 2 pour le pool. A est actif avec un bonus de 10 ; B est standby.
| Situation | Score A | Score B | Interprétation |
|---|---|---|---|
| Toutes les ressources disponibles | 80 + 20 + 10 = 110 | 80 + 20 = 100 | Le bonus favorise le maintien sur A. |
| A perd un lien ; seuil suffisant à 4 | 80 × 3/4 + 20 + 10 = 90 | 100 | Le score favorise B. |
| Même perte ; seuil suffisant à 3 | 80 + 20 + 10 = 110 | 100 | Trois liens suffisent à obtenir la contribution complète ; A reste favorisé. |
Autre choix : fixer le minimum du trunk à 4. Avec trois liens disponibles, ce minimum n’est plus atteint. Sur BIG-IP 13.0 et versions suivantes, le total local tombe alors à zéro ; le bonus ne le sauve pas. Le minimum exprime une exigence impérative, alors que le seuil suffisant exprime une capacité jugée assez bonne.
Sources F5 : calcul des contributions ; effet du minimum sur le score total.
Association au traffic group
Le HA group doit être configuré sur chaque appareil et associé localement au traffic group visé. La référence TMSH précise que cette association n’est pas synchronisée. Vérifiez donc les deux côtés, pas uniquement la configuration du nœud actif.
Dans la référence TMSH v17.0.0, l’ancien attribut direct ha-group du traffic group est déprécié depuis 13.0. L’association se trouve dans monitor, avec ha-group, et la méthode de failover doit être ha-score. Cette lecture évite de recopier une ancienne syntaxe de modification.
tmsh list sys ha-group all-properties
tmsh list cm traffic-group /Common/traffic-group-1 all-properties
tmsh show cm traffic-group /Common/traffic-group-1Adaptez le nom du traffic group. Contrôlez les ressources réelles, leurs poids, les deux seuils, le bonus actif et l’association locale. Les messages de failover dans /var/log/ltm aident à relier une bascule à sa cause.
Sources F5 : cm traffic-group, monitor et failover-method ; K000161390, journaux de décision HA.
Ce qu’une bascule ne résout pas
Basculer n’améliore pas une panne commune aux deux appareils. Si les serveurs partagés deviennent indisponibles, déplacer les adresses flottantes ne les rétablit pas. Un choix de ressources inadapté peut ajouter des mouvements de service à une panne déjà existante.
Le score ne garantit pas non plus la continuité de toutes les connexions. La préservation de leur état relève notamment des mécanismes de mirroring et de leurs contraintes. Vérifiez séparément la synchronisation, les chemins réseau, les adresses flottantes et la capacité du standby à absorber le trafic.
Avant d’adopter des seuils, définissez les événements attendus : perte d’un lien, perte d’un trunk, dégradation d’un seul appareil, panne commune et retour des ressources. Comparez le score obtenu sur chaque appareil à la décision souhaitée.
Sources F5 : recommandations HA groups ; failover et mirroring. Références consultées le .