Ce guide concerne BIG-IP sur TMOS. Les noms et options doivent être confrontés à la documentation de votre version.
Ce qui est réellement réparti
Un pool rassemble des destinations. Un member correspond à une adresse et un port ; un node représente l’adresse du serveur. Avant de choisir une méthode, vérifiez quels membres sont disponibles selon leurs moniteurs et leur état administratif.
Le load balancing ne déplace pas continuellement une connexion établie vers le serveur le moins chargé. Il intervient lors d’une sélection de destination. Une connexion HTTP persistante peut transporter plusieurs requêtes vers le même membre. Avec un profil HTTP et OneConnect, une nouvelle sélection peut intervenir entre les requêtes ; la persistance peut encore imposer une destination.
Sources F5 : About Pools ; Other Profiles, OneConnect.
Comparer les méthodes
| Méthode | Principe | Point à comprendre |
|---|---|---|
| Round Robin | Rotation entre les membres éligibles. | Point de départ simple pour des serveurs comparables ; aucune mesure de leur CPU. |
| Ratio | Répartition suivant des poids fixes. | Exprime une préférence de répartition, sans adapter automatiquement les poids à la charge. |
| Least Connections | Privilégie le compteur de connexions actives le plus faible. | Une connexion longue ou coûteuse n’a pas le même travail réel qu’une connexion courte. |
| Ratio Least Connections | Combine connexions actives et poids. | Utile si les capacités diffèrent et que le nombre de connexions reste un indicateur pertinent. |
| Weighted Least Connections | Compare les connexions à la limite configurée. | Une limite non nulle doit être définie pour chaque member ou node concerné. |
| Fastest | Utilise les réponses applicatives en attente comme indicateur. | Nécessite les profils appropriés, notamment TCP et un profil de couche 7 ; ce n’est pas un benchmark de latence HTTP. |
| Observed / Predictive | Classe les destinations d’après les connexions et, pour Predictive, leur évolution. | Plus complexes à interpréter ; F5 déconseille leur usage sur de grands pools. |
| Dynamic Ratio | Adapte les poids à des métriques de performance collectées. | Exige une collecte compatible, par exemple SNMP ou WMI. Un simple moniteur HTTP ne suffit pas. |
| Least Sessions | Privilégie le moins d’entrées dans la table de persistance. | Une « session » désigne ici cette entrée ; la méthode ne fonctionne pas avec la persistance cookie. |
Sources F5 : ltm pool, méthodes et contraintes ; Dynamic Ratio Load Balancing.
Member ou node ?
La variante member utilise les compteurs du membre dans le pool. La variante node considère les connexions au serveur à travers ses services et pools. Elle peut donc changer le résultat même si vous ne consultez qu’une application.
Exemple : A possède 10 connexions sur le service étudié et 100 sur un autre ; B en possède respectivement 20 et 5. Least Connections Member favorise A dans le pool étudié. Least Connections Node favorise B, car les totaux sont 110 et 25. Choisissez le périmètre qui représente réellement la capacité partagée.
Source F5 : ltm pool, variantes member et node.
Poids et capacité : deux exemples
Avec Ratio 3:1, on cherche environ 75 % des nouvelles sélections vers A et 25 % vers B lorsque les deux sont éligibles, sans autre mécanisme imposant la destination. Cela ne garantit ni ce partage des octets, ni celui des requêtes HTTP, ni celui du temps CPU.
Avec Weighted Least Connections, imaginons A à 30 connexions pour une limite de 100, et B à 80 pour une limite de 400. A utilise 30 % de sa limite, B 20 %. La variante pondérée favorise B ; Least Connections ordinaire favorise A. Les limites sont une capacité déclarée, pas une mesure automatique des ressources du serveur.
Persistance et groupes de priorité
La persistance répond à une autre question : faut-il retrouver la destination d’une session précédente ? Un cookie ou une adresse source peut expliquer une répartition apparemment inégale. Examinez ce mécanisme avant d’accuser l’algorithme.
La Priority Group Activation détermine quels groupes participent. Exemple : deux membres de priorité 10 et deux de priorité 5, avec un minimum de deux membres disponibles. Si un membre de priorité 10 tombe, le groupe de priorité 5 devient éligible ; le membre sain de priorité 10 reste participant. Les connexions existantes ne sont pas redistribuées par ce seul réglage.
Lors du retour d’un membre, le slow ramp peut éviter de l’envoyer immédiatement au niveau des autres destinations. Moniteurs, limites, persistance et montée progressive méritent autant d’attention que le choix Round Robin ou Least Connections.
Source F5 : About Pools, persistance, groupes de priorité et slow ramp.
Lire une configuration
tmsh list ltm pool /Common/pool_application all-properties
tmsh show ltm pool /Common/pool_applicationRemplacez le nom par celui de votre pool. Relevez la méthode, les moniteurs, les poids, les limites, les priorités et les états. Consultez aussi les profils et la persistance du Virtual Server. Comparez ensuite connexions, débit et comportement applicatif : une répartition égale des connexions ne prouve pas une charge égale.
Références F5 consultées le . La référence TMSH affiche v17.0.0 ; vérifiez les options de votre version.
Continuer la série F5
Explorer tous les guides du parcours F5 LTM
- F5 : persistance et maintenance des pool members
- F5 : construire un moniteur HTTP ou HTTPS utile
- F5 : moniteurs multiples, Reverse, Transparent et EAV
- F5 OneConnect : connexions réutilisées et persistance HTTP
- F5 LTM : one-arm, two-arm et nPath, suivre le trafic
- F5 : quel Virtual Server reçoit une connexion ?