Présentation de Traffic Load Balancer
Résumé de la prise en charge de l’équilibrage de charge du trafic
Le Tableau 1 récapitule la prise en charge de l’équilibrage de charge de trafic sur les cartes MS-MPC et MS-MIC pour les services adaptatifs par rapport à la prise en charge de la carte de services de sécurité MX-SPC3 pour les services de nouvelle génération.
MS-MPC (en anglais seulement) |
MX-SPC3 |
||
|---|---|---|---|
Version de Junos |
< 16.1R6 et 18.2.R1 |
≥ 16.1R6 et 18.2R1 |
19.3R2 |
# max. d’instances par châssis |
32 |
2 000 / 32 en mode DSR L2 |
2,000 |
# max de services virtuels par instance |
32 |
32 |
32 |
# max. d’adresse IP virtuelle par service virtuel |
|
1 |
1 |
# max de groupes par instance |
32 |
32 |
32 |
# max de Real-Services (serveurs) par groupe |
255 |
255 |
255 |
# max de groupes par service virtuel |
|
1 |
1 |
# max de profils de moniteur réseau par groupe |
|
2 |
2 |
# max de HC par service de sécurité et par PIC/NPU en 5 secondes |
|
4,000 |
1 250 à 19,3R2 10 000 – 20.1R1 |
Protocoles de bilan de santé pris en charge |
ICMP, TCP, UDP, HTTP, SSL, personnalisé |
ICMP, TCP, UDP, HTTP, SSL, TLS Bonjour, Personnalisé |
|
Description de l’application Traffic Load Balancer
L’équilibrage de charge de trafic (TLB) est pris en charge sur les routeurs MX Series équipés du concentrateur de ports modulaires multiservices (MS-MPC), de la carte d’interface modulaire multiservices (MS-MIC) ou de la carte de traitement des services de sécurité MX (MX-SPC3) et en conjonction avec les cartes de ligne MPC (Modular Port Concentrator) prises en charge sur les routeurs MX Series, comme décrit dans le Tableau 2.
Il n’est pas possible d’exécuter simultanément le NAT déterministe et le TLB.
TLB Mode |
Couverture de la plate-forme MX |
|---|---|
Concentrateur de port modulaire multiservices (MS-MPC) |
MX240, MX2480, MX960, MX2008, MX2010, MX2020 |
Carte de traitement des services de sécurité MX (MX-SPC3) |
MX240, MX480, MX960 |
TLB vous permet de répartir le trafic entre plusieurs serveurs.
TLB utilise un plan de contrôle basé sur MS-MPC et un plan de données utilisant le moteur de transfert de routeur MX Series.
TLB utilise une version améliorée du routage multichemin à coût égal (ECMP). L’ECMP amélioré facilite la distribution des flux entre les groupes de serveurs. Les améliorations apportées à l’ECMP natif garantissent qu’en cas de défaillance d’un serveur, seuls les flux associés à ces serveurs sont affectés, ce qui réduit l’attrition globale du réseau sur les services et les sessions.
TLB assure une surveillance de l’état des applications pour un maximum de 255 serveurs par groupe, avec une orientation intelligente du trafic basée sur la vérification de l’état des informations de disponibilité des serveurs. Vous pouvez configurer une interface AMS (Aggregated Multiservices) pour fournir une redondance un-à-un pour les MS-MPC ou la carte MX-SPC3 des services nouvelle génération utilisée pour la surveillance de l’état des serveurs.
TLB applique son traitement de distribution de flux au trafic entrant.
TLB prend en charge plusieurs instances de routage virtuel pour une meilleure prise en charge des exigences d’équilibrage de charge à grande échelle.
TLB prend en charge la traduction statique d’adresse IP virtuelle en adresse IP réelle et la traduction statique du port de destination pendant l’équilibrage de charge.
Modes de fonctionnement de l’équilibrage de charge de trafic
L’équilibreur de charge de trafic propose trois modes de fonctionnement : la répartition du trafic sortant et le traitement du trafic retour.
Le tableau 3 récapitule la prise en charge de TLB et les cartes sur lesquelles elle est prise en charge.
Carte de service de sécurité |
MS-MPC (en anglais seulement) |
MX-SPC3 |
|---|---|---|
Traduire |
Oui |
Oui |
Retour direct au serveur transparent de couche 3 |
Oui |
Oui |
Retour direct au serveur de couche 2 transparent |
Oui |
Non pris en charge |
- Mode transparent Retour direct au serveur de couche 2
- Mode Traduit
- Mode transparent Retour direct au serveur de couche 3
Mode transparent Retour direct au serveur de couche 2
Lorsque vous utilisez le retour direct au serveur de couche 2 (DSR) en mode transparent :
Le PFE traite les données.
L’équilibrage de charge fonctionne en modifiant l’adresse MAC des paquets de couche 2.
Les sondes de surveillance réseau sont effectuées par une MS-MPC.
Les serveurs réels doivent être directement (couche 2) accessibles à partir du routeur MX Series.
TLB installe une route et tout le trafic sur cette route est équilibré en charge.
TLB ne modifie jamais les en-têtes de couche 3 et de niveau supérieur.
La figure 1 illustre la topologie TLB pour le DSR de couche 2 en mode transparent.
transparent
Mode Traduit
Le mode traduit offre une plus grande flexibilité que le DSR de couche 2 en mode transparent. Lorsque vous choisissez le mode de traduction :
Les sondes de surveillance réseau sont effectuées par une MS-MPC.
Le PFE effectue un équilibrage de charge sans état :
Le trafic de données dirigé vers une adresse IP virtuelle subit la traduction de l’adresse IP virtuelle en une adresse IP de serveur réelle et traduit le port virtuel en un port d’écoute de serveur. Le trafic de retour subit la traduction inverse.
Le trafic du client à l’IP virtuelle est traduit ; Le trafic est acheminé pour atteindre sa destination.
Le trafic serveur-client est capturé à l’aide de filtres implicites et dirigé vers un prochain saut d’équilibrage de charge approprié pour le traitement inverse. Après la traduction, le trafic est redirigé vers le client.
Deux méthodes d’équilibrage de charge sont disponibles : aléatoire et de hachage. La méthode aléatoire ne concerne que le trafic UDP et fournit une distribution aléatoire quavms. Bien qu’il ne soit pas littéralement aléatoire, ce mode permet une répartition équitable du trafic vers un ensemble de serveurs disponibles. La méthode de hachage fournit une clé de hachage basée sur n’importe quelle combinaison de l’adresse IP source, de l’adresse IP de destination et du protocole.
Note:Le traitement en mode traduit n’est disponible que pour le trafic IPv4 vers IPv4 et IPv6 vers IPv6.
La figure 2 montre la topologie TLB pour le mode traduit.
traduit
Mode transparent Retour direct au serveur de couche 3
Mode transparent L’équilibrage de charge DSR de couche 3 distribue les sessions sur des serveurs qui peuvent se trouver à un saut de couche 3. Le trafic est renvoyé directement au client à partir du serveur réel.
Fonctions d’équilibrage de charge de trafic
TLB offre les fonctions suivantes :
TLB distribue toujours les requêtes pour n’importe quel flux. Lorsque vous spécifiez le mode DSR, la réponse retourne directement à la source. Lorsque vous spécifiez le mode traduit, le trafic inverse est dirigé via des filtres implicites sur les interfaces côté serveur.
TLB prend en charge l’équilibrage de charge basé sur le hachage ou l’équilibrage de charge aléatoire.
TLB vous permet de configurer des serveurs hors connexion afin d’éviter un impact sur les performances qui pourrait être causé par un rehachage de tous les flux existants. Vous pouvez ajouter un serveur à l’état d’indisponibilité d’administration et l’utiliser ultérieurement pour la distribution du trafic en désactivant l’état d’indisponibilité d’administration. La configuration des serveurs hors ligne permet d’éviter que le trafic ne soit impacté sur les autres serveurs.
Lorsque la vérification de l’état détermine qu’un serveur est en panne, seuls les flux affectés sont réexaminés.
Lorsqu’un serveur précédemment indisponible est remis en service, tous les flux appartenant à ce serveur en fonction du hachage lui reviennent, ce qui a un impact sur les performances des flux renvoyés. Pour cette raison, vous pouvez désactiver la réintégration automatique d’un serveur à un groupe actif. Vous pouvez remettre les serveurs en service en exécutant la
request services traffic-load-balance real-service rejoincommande opérationnelle.Note:NAT n’est pas appliqué aux flux distribués.
L’application de surveillance du bilan de santé s’exécute sur un MS-MPC/NPU. Cette unité de traitement réseau (NPU) n’est pas utilisée pour gérer le trafic de données.
TLB prend en charge la traduction statique virtual-IP-adddress-to-real-IP-address et la traduction statique du port de destination pendant l’équilibrage de charge.
TLB prend en charge plusieurs VRF.
Composants de l’application Traffic Load Balancer
- Serveurs et groupes de serveurs
- Surveillance de l’état du serveur : bilan de santé simple et double bilan de santé
- Services virtuels
Serveurs et groupes de serveurs
TLB permet de configurer des groupes de 255 serveurs maximum (appelés services réels dans les instructions de configuration) en vue d’une utilisation en tant que destinations alternatives pour la distribution de sessions sans état. Tous les serveurs utilisés dans les groupes de serveurs doivent être configurés individuellement avant d’être affectés aux groupes. L’équilibrage de charge utilise le hachage ou la randomisation pour la distribution des sessions. Les utilisateurs peuvent ajouter et supprimer des serveurs vers et depuis la table de distribution du serveur TLB et peuvent également modifier le statut administratif d’un serveur.
TLB utilise l’API de saut suivant de distribution de session pour mettre à jour la table de distribution du serveur et récupérer les statistiques. Les applications n’ont pas de contrôle direct sur la gestion des tables de distribution du serveur. Ils ne peuvent influencer les modifications qu’indirectement par le biais des services d’ajout et de suppression de l’API TLB.
Surveillance de l’état du serveur : bilan de santé simple et double bilan de santé
TLB prend en charge les sondes de contrôle de santé TCP, HTTP, SSL Hello, TLS Hello et personnalisées pour surveiller l’état des serveurs d’un groupe. Vous pouvez utiliser un seul type de sonde pour un groupe de serveurs ou une configuration de contrôle de l’état double qui inclut deux types de sondes. La fonction configurable de surveillance de l’intégrité réside sur un MX-SPC3 ou un MS-MPC. Par défaut, les requêtes de sonde sont envoyées toutes les 5 secondes. De plus, par défaut, un serveur réel n’est déclaré inactif qu’après cinq échecs de sonde consécutifs et déclaré inactif seulement après cinq succès consécutifs de sonde.
Utilisez une sonde de contrôle de l’état personnalisée pour spécifier les éléments suivants :
-
Chaîne attendue dans la réponse de la sonde
-
Chaîne envoyée avec la sonde
-
État du serveur à attribuer lorsque la sonde expire (haut ou bas)
-
État du serveur à attribuer à la réception de la réponse attendue à la sonde (hausse ou baisse)
-
Protocole : UDP ou TCP
TLB renforce l’adhérence des applications, ce qui signifie que les défaillances ou les modifications apportées au serveur n’affectent pas les flux de trafic vers les autres serveurs actifs. La modification de l’état administratif d’un serveur de haut en bas n’a pas d’impact sur les flux actifs vers les serveurs restants dans la table de distribution du serveur. L’ajout ou la suppression d’un serveur d’un groupe peut affecter le trafic pendant une durée qui dépend de la configuration des paramètres d’intervalle et de nouvelle tentative dans le profil de surveillance.
TLB fournit deux niveaux de surveillance de l’état du serveur :
-
Vérification de l’état unique : un type de sonde est attaché à un groupe de serveurs au moyen de l’instruction
network-monitoring-profilede configuration. -
TLB Dual Health Check (TLB-DHC) : deux types de sondes sont associés à un groupe de serveurs au moyen de l’instruction
network-monitoring-profilede configuration. L’état d’un serveur est déclaré en fonction du résultat de deux sondes de contrôle de l’état. Les utilisateurs peuvent configurer jusqu’à deux profils de vérification de l’état par groupe de serveurs. Si un groupe de serveurs est configuré pour une double vérification de l’état, un service réel est déclaré actif uniquement lorsque les deux sondes de vérification de l’état sont simultanément actives ; sinon, un service réel est déclaré DOWN.
Les restrictions suivantes s’appliquent aux interfaces AMS utilisées pour la surveillance de l’état des serveurs :
-
Une interface AMS configurée sous une instance TLB utilise ses interfaces membres configurées exclusivement pour la vérification de l’état de plusieurs serveurs réels configurés.
-
Les interfaces membres utilisent l’unité 0 pour les cas VRF uniques, mais peuvent utiliser des unités autres que 1 pour les cas VRF multiples.
-
TLB utilise l’adresse IP configurée pour les interfaces membres AMS comme adresse IP source pour les contrôles d’état.
-
Les interfaces membres doivent se trouver dans la même instance de routage que l’interface utilisée pour atteindre les serveurs réels. Ceci est obligatoire pour les procédures de contrôle de l’état du serveur TLB.
À partir de Junos OS version 24.2R1, lorsque TLS et SSL sont configurés dans le même groupe, le mécanisme OR est désormais utilisé à la place de AND pour déterminer l’état du serveur réel. C’est-à-dire que le serveur réel est marqué comme UP si l’une des sondes fonctionne. Auparavant, le serveur réel n’était marqué UP que si les deux sondes réussissaient.
Lorsque la version de palpage SSL est fournie, il sonde avec cette version. Lorsque la version SSL n’est pas spécifiée, le comportement passe à Repli de la version v3 à la version v2. La sonde commence avec SSLv3. Si la sonde SSLv3 échoue, le système sonde pour SSLv2. Auparavant, lorsque l’attribut version n’était pas fourni explicitement, le test était effectué avec la version par défaut, v3.
Cette amélioration du comportement de contrôle de l’état s’applique uniquement lorsque les sondes TLS et SSL sont configurées dans le même groupe de contrôle de l’état.
La sortie de show services traffic-load-balance statistics instance <inst>extensive est modifiée.
user@host# show services traffic-load-balance statistics instance <inst-name>
Traffic load balance instance name : <inst-name> Multi services interface name : vms-3/0/0 Interface state : UP Interface type : Multi services Route hold timer : 180 Active real service count : 0 Total real service count : 8 Traffic load balance virtual svc name : vs1 IP address : 60.0.0.1 Virtual service mode : Translate mode Routing instance name : fwd_instance_1 Traffic load balance group name : group1 Traffic load balance group warmup time: 15 Traffic load balance group auto-rejoin: TRUE Health check interface subunit : 0 Traffic load balance group down count : 5 Protocol : tcp Port number : 443 Server Listening Port Number : 443 Route metric : 1 Virtual service down count : 5 Traffic load balance hash method : source Network monitoring profile count : 2 Active real service count : 0 Total real service count : 8 Demux Nexthop index : 673 Nexthop index : 674 Down time : 6d 00:01 Total packet sent count : 361749 Total byte sent count : 55165331 Total packet received count : 542636 Total byte received count : 28940680 Network monitoring profile index : 1 Network monitoring profile name : nm_prof_ssl Probe type : SSL-HELLO Probe interval : 2 Probe failure retry count : 5 Probe recovery retry count : 3 Port number : 443 Network monitoring profile index : 2 Network monitoring profile name : nm_prof_tls Probe type : TLS-HELLO Probe interval : 5 Probe failure retry count : 5 Probe recovery retry count : 5 Port number : 443 Traffic load balance real svc name : rs_1 Routing instance name : server_vrf_1 IP address : 40.1.1.2 Traffic load balance group name : group1 Admin state : UP Oper state : UP Network monitoring probe up count : 1 Network monitoring probe down count : 1 Total rejoin event count : 8 Total up event count : 9 Total down event count : 9 Real Service packet sent count : 69804 Real Service byte sent count : 10644724 Real Service packet received count : 104706 Real Service byte received count : 5584336 Total probe sent : 358307 Total probe success : 76 Total probe fail : 358231 Total probe sent failed : 0 Network monitoring profile index : 1 Network monitoring profile name : nm_prof_sslv3 Probe type : SSL-HELLO Probe state : UP SSL probe version : 3 Probe sent : 255933 Probe success : 255879 Probe fail : 54 Probe sent failed : 0 Probe consecutive success : 254635 Probe consecutive fail : 0 Network monitoring profile index : 2 Network monitoring profile name : nm_prof_tls Probe type : TLS-HELLO Probe state : DOWN TLS probe version : 1.2 Probe sent : 102374 Probe success : 22 Probe fail : 102352 Probe sent failed : 0 Probe consecutive success : 0 Probe consecutive fail : 101854
La version de la sonde SSL-hello est déplacée sous Statistiques de serveur réel à partir du service virtuel lorsque la version SSL n’est pas spécifiée dans le profil de contrôle de l’état.
Services virtuels
Le service virtuel fournit une adresse IP virtuelle (VIP) associée au groupe de serveurs vers lequel le trafic est dirigé, tel que déterminé par la distribution de sessions aléatoire ou basée sur le hachage et la surveillance de l’intégrité du serveur. Dans le cas des DSR L2 et L3, l’adresse spéciale 0.0.0.0 entraîne l’équilibrage de charge de tout le trafic transitant vers l’instance de transfert.
La configuration du service virtuel comprend :
-
Mode : indique la manière dont le trafic est traité (traduit ou transparent).
-
Groupe de serveurs sur lesquels les sessions sont distribuées.
-
La méthode de l’équilibrage de charge.
-
Instance de routage et métrique de routage.
Bien que vous puissiez attribuer une adresse virtuelle de 0.0.0.0 afin d’utiliser le routage par défaut, nous vous recommandons d’utiliser une adresse virtuelle qui peut être attribuée à une instance de routage configurée spécifiquement pour TLB.
Limites de configuration de l’équilibreur de charge de trafic
Les limites de configuration de Traffic Load Balancer sont décrites dans le Tableau 4.
Composant de configuration |
Limite de configuration |
|---|---|
Nombre maximal d’instances |
À partir de Junos OS version 16.1R6 et Junos OS version 18.2R1, l’application TLB prend en charge 2000 instances TLB pour les services virtuels qui utilisent le retour direct du serveur ou le mode traduit. Dans les versions antérieures, le nombre maximal d’instances est de 32. Si plusieurs services virtuels utilisent le même groupe de serveurs, tous ces services virtuels doivent utiliser la même méthode d’équilibrage de charge pour prendre en charge 2 000 instances TLB. Pour les services virtuels qui utilisent le mode layer2-direct-server-return, TLB ne prend en charge que 32 instances TLB. Pour exécuter la même fonction que le mode layer2-direct-server-return et prendre en charge 2000 instances TLB, vous pouvez utiliser le mode direct-server-return et utiliser un filtre de service avec l’action skip. |
Nombre maximal de serveurs par groupe |
255 |
Nombre maximal de services virtuels par PIC de services |
32 |
Nombre maximal de vérifications de l’état par PIC de services dans un intervalle de 5 secondes |
Pour les cartes de services MS-MPC : 2000 Pour le mode Services nouvelle génération et les cartes de services MX-SPC3 : 1250 |
Nombre maximal de groupes par service virtuel |
1 |
Nombre maximal d’adresses IP virtuelles par service virtuel |
1 |
Protocoles de contrôle de l’état pris en charge |
ICMP, TCP, HTTP, SSL, TLS-Hello, personnalisé
Note:
La vérification de l’état ICMP n’est prise en charge que sur les cartes de services MS-MPC. À partir de la version 22.4R1 de Junos OS, TLB est amélioré pour prendre en charge le type de vérification de l’état TLS-Hello. Pour TLS-Hello sur TCP, les vérifications de l’état TLS v1.2 et v1.3 sont prises en charge. |
Tableau de l’historique des modifications
La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.