Chaque algorithme classique repose sur une hypothèse concernant le vService qu'il dessert. Round-robin suppose que les backends sont interchangeables. Least-connections suppose que le nombre de sessions est corrélé à la charge du backend. Source-IP suppose une affinité utilisateur-backend sans persistance explicite. Les hash d'affinité de cache supposent que la clé de requête — URL, header ou session — est stable. Lorsque l'hypothèse tient, l'algorithme est la bonne réponse.
Les cas plus difficiles surviennent quand ces hypothèses ne tiennent plus : les backends dérivent en performance en cours de journée, les générations de matériel se mélangent lors d'une mise à jour progressive, la latence régionale varie d'une requête à l'autre, ou la charge de travail elle-même comporte des rafales de requêtes lourdes qui ne correspondent pas au nombre brut de requêtes. Dans ces scénarios, choisir le backend réellement le plus rapide par requête — ou utiliser un algorithme hash conçu pour absorber les changements de backends sans tout re-partitionner — est ce qui préserve la latence visible par l'utilisateur.
La bonne réponse est de faire correspondre l'algorithme à la charge de travail — par vService, pas globalement.
Un vService dans TR7 regroupe le listener frontend, les règles de trafic, les contrôles de santé et le groupe de backends dans un seul objet de configuration — plus large que le pool classique qui répartit ces éléments en plusieurs endroits. Chaque vService choisit son propre algorithme dans un menu déroulant — sans recompilation, sans redémarrage. Mixez sur une même instance TR7 : round-robin sur le vService d'assets statiques, Fastest+ sur le vService d'API, Maglev hash sur le vService de couche cache. Le filtrage par type de service se fait automatiquement ; l'UI n'affiche que les algorithmes valides pour le protocole du vService.
Le choix de l'algorithme réside sur l'objet vService, pas dans la configuration globale de l'ADC. Des vServices différents exécutent des algorithmes différents dans la même instance TR7.
L'UI ne présente que les algorithmes compatibles avec le protocole du vService — les vServices HTTP, TCP ou réseau obtiennent chacun le sous-ensemble pertinent, sans approximation de la part de l'opérateur.
L'algorithme choisit le backend pour la première requête ; la persistance de session épingle ensuite les requêtes suivantes du même utilisateur. Les deux couches sont configurables indépendamment par vService.
Modifiez l'algorithme sur un vService en production et le trafic bascule immédiatement sur la nouvelle logique. Aucun redémarrage de service, aucun drain de connexion requis.
Chaque algorithme classique, deux variantes de consistent hash modernes, un algorithme à délai minimal, plus le moteur Fastest+ propriétaire de TR7. Tous disponibles par vService — sélectionnez dans un menu déroulant, aucun code de configuration requis.
Distribution équilibrée sur le vService, pondérée ou non. La valeur par défaut standard pour les vServices uniformes où chaque backend a une capacité identique.
Achemine vers le backend ayant le moins de connexions actuellement ouvertes. Très efficace pour les sessions longues où le nombre de sessions est corrélé à la charge du backend. La variante pondérée tient compte des différences de capacité.
Achemine toujours vers le premier backend listé ayant de la capacité ; bascule sur le suivant seulement en cas de surcharge. Utile pour l'ordonnancement chaud-puis-froid des backends ou les déploiements progressifs.
Sélection aléatoire parmi les backends sains. Sans état, statistiquement équilibré — utile quand le vService est large et uniforme. Supporte le random power-of-two pour la sélection du moins chargé avec peu de surcharge.
La même IP client est toujours routée vers le même backend. Utile pour les flux avec état quand l'application ne gère pas de persistance de session explicite.
Hash sur un composant d'URL — la longueur d'URL, le chemin URI ou un paramètre de requête spécifique (ex. ?user_id). Route la même URL ou le même utilisateur vers le même backend pour l'affinité de cache.
Hash sur un header HTTP personnalisé. Utile pour le routage multi-locataire (header tenant-id), le feature flagging ou les scénarios de test A/B.
Lecture du cookie de session RDP pour la sélection du backend. Utile pour les gateways RDP et les fermes de bureau à distance où l'affinité de session est requise.
Mode hash moderne qui minimise la perturbation lorsque des backends rejoignent ou quittent le vService — seule une petite fraction des clés est re-partitionnée, pas le vService entier. Adapté aux couches cache où la rotation des backends ne doit pas invalider l'intégralité du cache.
L'algorithme de consistent hashing de Google conçu pour les équilibreurs de charge logiciels à grande échelle. Variance inférieure au consistent hash classique, déterministe sur les répliques. Excellent pour les services sans état qui nécessitent une assignation de backend prévisible.
Achemine vers le backend ayant le temps d'attente attendu le plus faible, en tenant compte des connexions actives et du poids par backend. Une alternative tenant compte de la latence par rapport à least-connections quand les capacités des backends diffèrent significativement.
Achemine vers le backend ayant le temps de réponse récent le plus faible. Une option plus simple tenant compte de la latence quand le temps de réponse est le seul signal qui compte.
Le moteur adaptatif propriétaire à 8 signaux de TR7. Combine temps de réponse, temps de connexion, profondeur de file, sessions actives, taux d'erreurs et plus encore en un score de rapidité par requête. Voir la section détails ci-dessous.
La plupart des algorithmes adaptatifs surveillent un seul signal — temps de réponse ou nombre de connexions. Fastest+ échantillonne en continu 8 signaux de performance indépendants par backend et les combine en un score de rapidité unique, fraîchement calculé pour chaque requête entrante.
Latence de réponse moyenne du backend, échantillonnée en continu. Le signal principal — un backend qui met plus de temps à répondre chute immédiatement dans le classement.
Durée d'établissement d'une connexion TCP/TLS. Un backend dont le temps de connexion augmente approche de la saturation, même si son temps de réponse semble encore correct.
Temps que les requêtes passent en file avant d'atteindre le backend. Un temps de file croissant est le signal d'alerte le plus précoce qu'un backend ne parvient pas à suivre.
Sessions actuellement ouvertes par backend. Routage tenant compte de la capacité sans le bruit des totaux historiques.
Requêtes actuellement en attente. Un backend avec 0 en file est préféré à un backend également rapide avec 50 requêtes en attente.
Connexions échouées récentes. Un backend qui a refusé 3 des 10 dernières tentatives chute dans le classement avant qu'un contrôle de santé ne le détecte.
Abandons de session initiés par le backend dans la fenêtre récente. Capture le cas où un backend est actif mais échoue en cours de traitement.
Utilisation du pool de connexions — à quelle proximité de la capacité se trouve le pool keep-alive de chaque backend. Détecte l'épuisement du pool avant qu'il ne devienne visible par l'utilisateur.
Backends identiques, capacité identique — round-robin garde la logique simple et la charge symétrique. Ajoutez random pour les grands vServices sans état.
WebSockets, services de streaming, appels vidéo — les sessions restent ouvertes pendant des minutes ou des heures. Least-connections ou SED suit la charge active bien mieux que le nombre de requêtes.
La rotation des backends ne doit pas invalider l'intégralité du cache. Consistent hash ou Maglev ne re-partitionne qu'une petite fraction des clés lorsque les backends changent.
Matériel mixte, déploiements progressifs, variance de latence régionale — Fastest+ score les backends en direct pour que le routage choisisse le réellement le plus rapide, pas le théoriquement optimal.
Découvrez comment TR7 ADC vous permet de définir l'algorithme par vService — et comment Fastest+ gère les charges de travail que les autres ne peuvent pas traiter.