Pourquoi les patterns de trafic exigent des algorithmes différents
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.
Choix d'algorithme, par vService
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.
Algorithme par 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.
Filtrage conscient du protocole
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.
Composable avec la persistance de session
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.
Hot-swap (sans redémarrage)
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.
14 algorithmes livrés avec TR7 ADC
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.
Round-robin (pondéré + statique)
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.
Least-connections (pondéré)
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é.
Temps de réponse le plus court
Achemine vers le backend qui répond le plus vite à l'instant présent, mesuré en continu et non par échantillonnage. Adapté aux pools à capacité égale mais à latence variable par nœud : cache en préchauffage, nœud sous pression GC, voisin bruyant.
Bande passante la plus faible
Achemine vers le backend qui transporte le moins de trafic à cet instant. C'est le bon critère quand les réponses diffèrent par la taille et non par le nombre — médias, téléchargements, exports de rapports —, où le nombre de connexions ne dit rien de la charge réelle.
First-available
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.
Random
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.
Source-IP hash
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.
URL hash (URI / URL-parameter)
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.
Header hash
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.
RDP cookie hash
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.
Consistent hash
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.
Maglev hash
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.
SED — Shortest Expected Delay
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.
Fastest
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.
Fastest+
Le moteur propriétaire en deux étapes de TR7. L'opérateur choisit deux signaux de service en direct parmi huit — temps de réponse, temps d'établissement de connexion, intensité de file d'attente, taux d'erreurs et plus encore ; Fastest+ restreint les candidats selon le signal primaire, puis départage l'égalité par le signal secondaire. Voir la section détails ci-dessous.
Fastest+ — Le moteur en deux étapes, ajusté par l'opérateur de TR7
La plupart des algorithmes adaptatifs surveillent un seul signal — temps de réponse ou nombre de connexions. Fastest+ laisse l'opérateur choisir deux signaux de service en direct parmi huit : le signal primaire restreint les candidats aux backends au meilleur score, et le signal secondaire départage l'égalité entre eux. Les backends en mode maintenance ou dont l'état de santé n'est pas adéquat sont automatiquement écartés, et un mode mono-signal est disponible lorsqu'un seul critère suffit. Voici les huit signaux parmi lesquels choisir :
Temps de réponse
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.
Temps de connexion
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 de file
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 actives
Sessions actuellement ouvertes par backend. Routage tenant compte de la capacité sans le bruit des totaux historiques.
Profondeur de file active
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.
Erreurs de connexion
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 côté serveur
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.
Connexions utilisées
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.
Quatorze en Layer 7, onze au niveau paquet
En Layer 7, la décision se prend en lisant la requête : en-tête, chemin, cookie, temps de réponse en direct. En Layer 4, elle se prend sur le paquet, avant même que le trafic n'atteigne la couche applicative — c'est là que se trouve le débit le plus élevé. Dans les deux cas, l'algorithme se choisit par service et change sans arrêter l'équipement.
Layer 7 — 14 critères de sélection
Layer 4 — 11 ordonnanceurs au niveau paquet
Quand chaque algorithme excelle
vServices uniformes
Backends identiques, capacité identique — round-robin garde la logique simple et la charge symétrique. Ajoutez random pour les grands vServices sans état.
Sessions longues
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.
vServices de couche cache
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.
Charge hétérogène ou variable
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.
Questions fréquentes
Puis-je changer l'algorithme sans redémarrer le service ?
Comment Fastest+ se rapporte-t-il à least-connections ?
Quand choisir Consistent hash plutôt que Maglev hash ?
Qu'est-ce que SED fait que least-connections ne fait pas ?
Le choix d'algorithme nécessite-t-il une surveillance externe ou une intégration APM ?
Quel est l'algorithme par défaut ?
Faites correspondre l'algorithme à la charge de travail
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.