SUR CETTE PAGE
Traffic Load Balancer
Présentation de Traffic Load Balancer
- Résumé de la prise en charge de l’équilibrage de charge du trafic
- Description de l’application Traffic Load Balancer
- Modes de fonctionnement de l’équilibreur de charge de trafic
- Fonctions d’équilibrage de charge du trafic
- Composants de l’application Traffic Load Balancer
- Limites de configuration 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 du trafic sur les cartes MS-MPC et MS-MIC pour Adaptive Services par rapport à la prise en charge de la carte de services de sécurité MX-SPC3 pour les services nouvelle génération.
MS-MPC |
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 services réels (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 |
|
# maximum de HC par services de sécurité par PIC/NPU en 5 secondes |
4,000 |
1 250 – 19,3 R2 10 000 – 20.1R1 |
|
Protocoles de bilan d’état 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’équilibreur de charge de trafic (TLB) est pris en charge sur les routeurs MX Series avec le concentrateur de ports modulaires multiservices (MS-MPC), la carte d’interface modulaire multiservices (MS-MIC) ou la carte de traitement des services MX Sécurité (MX-SPC3) et conjointement avec les cartes de ligne MPC (Modular Port Concentrator) prises en charge sur les routeurs MX Series, comme décrit dans le Tableau 2.
Vous ne pouvez pas exécuter simultanément le NAT déterministe et le TLB.
TLB Mode |
Couverture de la plate-forme MX |
|---|---|
concentrateur de ports modulaires 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.
Le TLB utilise un plan de contrôle basé sur MS-MPC et un plan de données à l’aide du moteur de transfert routeur MX Series.
TLB utilise une version améliorée du multichemin à coût égal (ECMP). L’ECMP amélioré facilite la distribution des flux entre les groupes de serveurs. Les améliorations apportées à ECMP natif garantissent qu’en cas de défaillance des serveurs, seuls les flux associés à ces serveurs sont affectés, ce qui minimise l’attrition globale des services et des sessions.
TLB fournit une surveillance de l’état de santé basée sur les applications pour un maximum de 255 serveurs par groupe, ce qui permet 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 multiservices agrégée (AMS) pour fournir une redondance individuelle pour les MS-MPC ou la carte MX-SPC3 des services de nouvelle génération utilisée pour la surveillance de l’état des serveurs.
Le TLB applique son traitement de distribution de flux au trafic entrant.
TLB prend en charge plusieurs instances de routage virtuel pour fournir 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 de port de destination statique pendant l’équilibrage de charge.
Modes de fonctionnement de l’équilibreur de charge de trafic
L’équilibreur de charge de trafic propose trois modes de fonctionnement pour la distribution du trafic sortant et pour la gestion du traitement du trafic de retour.
Le Tableau 3 résume la prise en charge TLB et les cartes sur lesquelles elle est prise en charge.
Carte de service de sécurité |
MS-MPC |
MX-SPC3 |
|---|---|---|
Traduire |
Oui |
Oui |
Retour direct transparent de serveur de couche 3 |
Oui |
Oui |
Retour direct transparent au serveur de couche 2 |
Oui |
Non pris en charge |
- Mode transparent Retour direct de serveur de couche 2
- Mode traduit
- Mode transparent Retour direct de serveur de couche 3
Mode transparent Retour direct de serveur de couche 2
Lorsque vous utilisez le mode transparent Retour direct du serveur (DSR) de couche 2 :
Le PFE traite les données.
L’équilibrage de charge fonctionne en modifiant l’adresse MAC de couche 2 des paquets.
Un MS-MPC réalise les sondes de surveillance du réseau.
Les serveurs réels doivent être directement accessibles (couche 2) à 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 un 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 traduit :
Un MS-MPC réalise les sondes de surveillance du réseau.
Le PFE effectue un équilibrage de charge sans état :
Le trafic de données dirigé vers une adresse IP virtuelle est traduit de l’adresse IP virtuelle en adresse IP réelle de serveur et traduit le port virtuel en port d’écoute de serveur. Le trafic de retour subit la traduction inverse.
Le trafic client vers IP virtuel est traduit ; Le trafic est acheminé jusqu’à sa destination.
Le trafic serveur-client est capturé à l’aide de filtres implicites et dirigé vers un saut suivant d’équilibrage de charge approprié pour le traitement inverse. Une fois la traduction effectuée, le trafic est renvoyé au client.
Deux méthodes d’équilibrage de charge sont disponibles : aléatoire et hachée. La méthode aléatoire est réservée au trafic UDP et fournit une distribution aléatoire quavms. Bien qu’il ne soit pas littéralement aléatoire, ce mode offre 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.
Remarque :Le traitement en mode traduit n’est disponible que pour le trafic IPv4-IPv4 et IPv6-IPv6.
La figure 2 montre la topologie TLB pour le mode traduit.
traduit
Mode transparent Retour direct de serveur de couche 3
Mode transparent L’équilibrage de charge DSR de couche 3 distribue les sessions vers des serveurs distants de couche 3. Le trafic est renvoyé directement au client à partir du serveur réel.
Fonctions d’équilibrage de charge du trafic
TLB fournit 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é par 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 les serveurs hors ligne afin d’éviter un impact sur les performances qui pourrait être causé par un remaniement de tous les flux existants. Vous pouvez ajouter un serveur à l’état administratif inactif et l’utiliser ultérieurement pour la distribution du trafic en désactivant l’état administratif inactif. La configuration hors ligne des serveurs permet d’éviter l’impact du trafic 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 remaniés.
Lorsqu’un serveur précédemment en panne est remis en service, tous les flux appartenant à ce serveur basés sur le hachage y 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 donnant la
request services traffic-load-balance real-service rejoincommande opérationnelle.Remarque :Le NAT n’est pas appliqué aux flux distribués.
L’application de surveillance des bilans de santé s’exécute sur un MS-MPC/NPU. Cette unité de processeur de réseau (NPU) n’est pas utilisée pour gérer le trafic de données.
TLB prend en charge la traduction statique de l’adresse IP virtuelle en adresse IP réelle 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 des serveurs : vérification de l’état unique et double vérification de l’état
- Services virtuels
Serveurs et groupes de serveurs
Le TLB permet de configurer des groupes de 255 serveurs maximum (appelés services réels dans les instructions de configuration) pour les utiliser comme 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 à des 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 de serveur TLB et peuvent également modifier le statut administratif d’un serveur.
TLB utilise l’API de prochain saut 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 via les services d’ajout et de suppression de l’API TLB.
Surveillance de l’état des serveurs : vérification de l’état unique et double vérification de l’état
TLB prend en charge TCP, HTTP, SSL Hello, TLS Hello et des sondes de contrôle d’état 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 vérification d’é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 demandes de sonde sont envoyées toutes les 5 secondes. De plus, par défaut, un serveur réel est déclaré hors service seulement après cinq échecs consécutifs de sonde et déclaré opérationnel seulement après cinq résultats consécutifs de sonde.
Utilisez une sonde de bilan d’é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 (active ou arrêtée)
-
État du serveur à attribuer lorsque la réponse attendue à la sonde est reçue (active ou désactivée)
-
Protocole — UDP ou TCP
Le TLB assure l’adhérence des applications, ce qui signifie que les pannes ou les modifications du serveur n’affectent pas les flux de trafic vers d’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 a un impact sur le trafic pendant une durée qui dépend de votre configuration de l’intervalle et des paramètres de nouvelle tentative dans le profil de surveillance.
Le TLB fournit deux niveaux de surveillance de l’état des serveurs :
-
Vérification d’é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 vérification 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 plusieurs cas VRF.
-
TLB utilise l’adresse IP configurée pour les interfaces membres AMS comme adresse IP source pour les vérifications de l’état.
-
Les interfaces membres doivent se trouver dans la même instance de routage que l’interface utilisée pour atteindre des serveurs réels. Ceci est obligatoire pour les procédures de vérification de l’état des serveurs TLB.
À partir de la version 24.2R1 de Junos OS, lorsque TLS et SSL sont configurés dans le même groupe, le mécanisme OR est 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 vrai serveur n’était marqué que si les deux sondes réussissaient.
Lorsque la version de sonde SSL est fournie, elle sonde avec cette version. Lorsque la version SSL n’est pas spécifiée, le comportement passe de la version v3 à la v2. La sonde commence par SSLv3. Si la sonde SSLv3 échoue, le système recherche SSLv2. Auparavant, lorsque l’attribut version n’était pas fourni explicitement, l’analyse était effectuée avec la version par défaut, v3.
Cette amélioration du comportement de vérification de l’état s’applique uniquement lorsque les sondes TLS et SSL sont configurées dans le même groupe de vérification de l’état.
La sortie de l’instance <inst> des statistiques de répartition de la charge du trafic des services show services 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 les statistiques du serveur réel à partir du service virtuel lorsque la version SSL n’est pas spécifiée sous le profil de vérification 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 session basée sur le hachage ou aléatoire et la surveillance de l’état du serveur. Dans le cas de DSR L2 et L3 DSR, l’adresse spéciale 0.0.0.0 entraîne un équilibrage de charge de tout le trafic circulant vers l’instance de transfert.
La configuration du service virtuel comprend :
-
Mode : indique comment le trafic est traité (traduit ou transparent).
-
Groupe de serveurs sur lequel les sessions sont distribuées.
-
La méthode d’équilibrage de charge.
-
Instance de routage et métrique de routage.
Bien que vous puissiez affecter une adresse virtuelle 0.0.0.0 afin d’utiliser le routage par défaut, nous vous recommandons d’utiliser une adresse virtuelle qui peut être affectée à une instance de routage configurée spécifiquement pour TLB.
Limites de configuration de Traffic Load Balancer
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 2 000 instances TLB pour les services virtuels qui utilisent le mode direct-server-return 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 2000 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 service PIC |
32 |
Nombre maximal de vérifications de l’état par PIC de service par service dans un intervalle de 5 secondes |
Pour les cartes de services MS-MPC : 2000 Pour le mode Services Next Gen 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 vérification de l’état pris en charge |
ICMP, TCP, HTTP, SSL, TLS-Hello, personnalisé
Remarque :
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. |
Voir aussi
Configuration du TLB
Les rubriques suivantes décrivent comment configurer TLB. Pour créer une application complète, vous devez également définir des interfaces et des informations de routage. Vous pouvez éventuellement définir des filtres de pare-feu et des options de stratégie afin de différencier le trafic TLB.
- Chargement du package de services TLB
- Configuration d’un nom d’instance TLB
- Configuration des informations d’interface et de routage
- Configuration des serveurs
- Configuration des profils de surveillance réseau
- Configuration des groupes de serveurs
- Configuration des services virtuels
- Configuration du suivi pour la fonction de surveillance des vérifications de l’état
Chargement du package de services TLB
Chargez le package de services TLB sur chaque PIC de service sur lequel vous souhaitez exécuter TLB.
Pour les services de nouvelle génération et la carte de services MX-SPC3, vous n’avez pas besoin de charger ce package.
Pour charger le package de services TLB sur un PIC de service :
Chargez le
jservices-traffic-dirdpackage.[edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] user@host# set package jservices-traffic-dird
Par exemple :
[edit chassis fpc 3 pic 0 adaptive-services service-package extension-provider] user@host# set package jservices-traffic-dird
Configuration d’un nom d’instance TLB
system processes sdk-service enable dans la hiérarchie [modifier].
Pour configurer un nom pour l’instance TLB :
-
Au niveau de la
[edit services traffic-load-balance]hiérarchie, identifiez le nom de l’instance TLB.[edit services traffic-load-balance] user@host# set instance instance-name
Par exemple :
[edit services traffic-load-balance] user@host# set instance tlb-instance1
Configuration des informations d’interface et de routage
Pour configurer l’interface et les informations de routage :
Configuration des serveurs
Pour configurer les serveurs de l’instance TLB :
[edit services traffic-load-balance instance instance-name] user@host# set real-service real-service-name address server-ip-address
Par exemple :
[edit services traffic-load-balance instance tlb-instance1] user@host# set real-service rs138 address 172.26.99.138 user@host# set real-service rs139 address 172.26.99.139 user@host# set real-service rs140 address 172.26.99.140
Configuration des profils de surveillance réseau
Un profil de surveillance réseau configure une sonde de contrôle de l’état que vous affectez à un groupe de serveurs auquel le trafic de session est distribué.
Pour configurer un profil de surveillance du réseau :
Configuration des groupes de serveurs
Les groupes de serveurs sont constitués de serveurs vers lesquels le trafic est distribué au moyen d’une distribution de sessions sans état basée sur le hachage et d’une surveillance de l’état des serveurs.
Pour configurer un groupe de serveurs :
Configuration des services virtuels
Un service virtuel fournit une adresse associée à un groupe de serveurs vers lequel le trafic est dirigé, tel que déterminé par la distribution de session basée sur le hachage ou aléatoire et la surveillance de l’état du serveur. Vous pouvez éventuellement spécifier des filtres et des instances de routage pour orienter le trafic pour TLB.
Pour configurer un service virtuel :
Configuration du suivi pour la fonction de surveillance des vérifications de l’état
Pour configurer les options de suivi pour la fonction de surveillance des vérifications de l’état :
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.