AUF DIESER SEITE
Load Balancer für Datenverkehr
Traffic Load Balancer – Übersicht
- Zusammenfassung des Support für Traffic Load Balancing
- Beschreibung der Traffic Load Balancer-Anwendung
- Betriebsmodi des Load Balancers für den Datenverkehr
- Funktionen des Load Balancers für den Datenverkehr
- Anwendungskomponenten des Traffic Load Balancer
- Konfigurationslimits für Load Balancer für den Datenverkehr
Zusammenfassung des Support für Traffic Load Balancing
Tabelle 1 enthält eine Zusammenfassung der Unterstützung von Traffic Load Balancing auf den MS-MPC- und MS-MIC-Karten für adaptive Services im Vergleich zur Unterstützung auf der MX-SPC3-Sicherheitsservicekarte für Services der nächsten Generation.
MS-MPC |
MX-SPC3 |
||
|---|---|---|---|
Junos Veröffentlichung |
< 16.1R6 und 18.2.R1 |
≥ 16.1R6 und 18.2R1 |
19.3R2 |
Max. # Instanzen pro Gehäuse |
32 |
2.000 / 32 im L2 DSR-Modus |
2,000 |
Max. # virtuelle Services pro Instanz |
32 |
32 |
32 |
Max. # der virtuellen IP-Adresse pro virtuellem Service |
1 |
1 |
|
Max. # Gruppen pro Instanz |
32 |
32 |
32 |
Max. # Real-Services (Server) pro Gruppe |
255 |
255 |
255 |
Max. # Gruppen pro virtuellem Service |
1 |
1 |
|
Max. # der Netzwerkmonitorprofile pro Gruppe |
2 |
2 |
|
Max. # HCs pro Sicherheitsservices pro PIC/NPU in 5 Sekunden |
4,000 |
1.250 – 19,3 R2 10.000 – 20,1 R1 |
|
Unterstützte Zustandsprüfungsprotokolle |
ICMP, TCP, UDP, HTTP, SSL, Benutzerdefiniert |
ICMP, TCP, UDP, HTTP, SSL, TLS Hallo, benutzerdefiniert |
|
Beschreibung der Traffic Load Balancer-Anwendung
Traffic Load Balancer (TLB) wird auf Routern der MX-Serie entweder mit dem Multiservices Modular Port Concentrator (MS-MPC), der Multiservices Modular Interface Card (MS-MIC) oder der MX Sicherheit Services Processing Card (MX-SPC3) und in Verbindung mit den Modular Port Concentrator (MPC)-Linecards unterstützt, die von den Routern der MX-Serie unterstützt werden, wie in Tabelle 2 beschrieben.
Sie können Deterministic NAT und TLB nicht gleichzeitig ausführen.
TLB-Modus |
Abdeckung der MX-Plattform |
|---|---|
Modularer Multiservices-Portkonzentrator (MS-MPC) |
MX240, MX2480, MX960, MX2008, MX2010, MX2020 |
MX Sicherheit Services Processing Karte (MX-SPC3) |
MX240, MX480, MX960 |
Mit TLB können Sie den Datenverkehr auf mehrere Server verteilen.
TLB verwendet eine MS-MPC-basierte Steuerungsebene und eine Datenebene mit der Router-Weiterleitungs-Engine der MX-Serie.
TLB verwendet eine erweiterte Version von ECMP (Equal-Cost Multipath). Erweitertes ECMP erleichtert die Verteilung von Datenströmen über Servergruppen. Verbesserungen an der nativen ECMP stellen sicher, dass bei einem Serverausfall nur die mit diesen Servern verbundenen Datenströme betroffen sind, wodurch die allgemeine Netzwerkabwanderung bei Diensten und Sitzungen minimiert wird.
TLB bietet eine anwendungsbasierte Zustandsüberwachung für bis zu 255 Server pro Gruppe und bietet eine intelligente Datenverkehrssteuerung basierend auf der Zustandsprüfung von Serververfügbarkeitsinformationen. Sie können eine AMS-Schnittstelle (Aggregated Multiservices) konfigurieren, um Eins-zu-Eins-Redundanz für MS-MPCs oder die Next Gen Services MX-SPC3-Karte für die Überwachung des Serverzustands bereitzustellen.
TLB wendet seine Datenstromverteilungsverarbeitung auf eingehenden Datenverkehr an.
TLB unterstützt mehrere virtuelle Routinginstanzen, um eine verbesserte Unterstützung für umfangreiche Load Balancing-Anforderungen zu bieten.
TLB unterstützt die statische Übersetzung von virtuellen IP-Adressen in reale IP-Adressen und die Übersetzung statischer Zielports während des Load Balancing.
Betriebsmodi des Load Balancers für den Datenverkehr
Traffic Load Balancer stellt drei Betriebsmodi für die Verteilung des ausgehenden Datenverkehrs und für die Verarbeitung des zurückgehenden Datenverkehrs bereit.
Tabelle 3 fasst die TLB-Unterstützung zusammen und auf welchen Karten sie unterstützt wird.
Sicherheit Service Karte |
MS-MPC |
MX-SPC3 |
|---|---|---|
Übersetzen |
Nein |
Nein |
Transparente Layer 3 Direct Server-Rückgabe |
Nein |
Nein |
Transparente Layer 2 Direct Server-Rückgabe |
Nein |
Nicht unterstützt |
- Transparenter Modus Layer 2 Direkte Serverrückgabe
- Übersetzter Modus
- Transparenter Modus Layer 3 Direkte Serverrückgabe
Transparenter Modus Layer 2 Direkte Serverrückgabe
Bei Verwendung des transparenten Modus Layer 2 Direct Server Return (DSR):
Das PFE verarbeitet Daten.
Load Balancing funktioniert durch Ändern der Layer-2-MAC von Paketen.
Ein MS-MPC führt die Sonden zur Netzwerküberwachung durch.
Reale Server müssen direkt (Layer 2) vom Router der MX-Serie aus erreichbar sein.
TLB installiert eine Route, und der gesamte Datenverkehr über diese Route erfolgt über einen Lastenausgleich.
TLB ändert niemals Layer-3- und höhere Header.
Abbildung 1 zeigt die TLB-Topologie für Layer 2-DSR im transparenten Modus.
Übersetzter Modus
Der übersetzte Modus bietet eine größere Flexibilität als der transparente Modus Layer 2 DSR. Wenn Sie den übersetzten Modus wählen:
Ein MS-MPC führt die Sonden zur Netzwerküberwachung durch.
Die PFE führt zustandsloses Load Balancing durch:
Datenverkehr, der an eine virtuelle IP-Adresse gerichtet ist, durchläuft eine Übersetzung der virtuellen IP-Adresse in eine reale Server-IP-Adresse und übersetzt den virtuellen Port in einen Server-Überwachungsport. Der Rückverkehr wird umgekehrt übersetzt.
Der Datenverkehr vom Client in eine virtuelle IP wird übersetzt. Der Datenverkehr wird geroutet, um sein Ziel zu erreichen.
Der Datenverkehr zwischen Server und Client wird mit impliziten Filtern erfasst und zur umgekehrten Verarbeitung an einen geeigneten nächsten Hop mit Lastausgleich weitergeleitet. Nach der Übersetzung wird der Datenverkehr zurück zum Client geleitet.
Es stehen zwei Methoden zum Load Balancing zur Verfügung: Random und Hash. Die Zufallsmethode ist nur für UDP-Datenverkehr geeignet und bietet eine quavms-Zufallsverteilung. Dieser Modus ist zwar nicht buchstäblich zufällig, bietet aber eine faire Verteilung des Datenverkehrs auf eine verfügbare Gruppe von Servern. Die Hash-Methode stellt einen Hash-Schlüssel bereit, der auf einer beliebigen Kombination aus Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll basiert.
Hinweis:Die Verarbeitung im übersetzten Modus ist nur für IPv4-zu-IPv4- und IPv6-zu-IPv6-Datenverkehr verfügbar.
Abbildung 2 zeigt die TLB-Topologie für den übersetzten Modus.
Transparenter Modus Layer 3 Direkte Serverrückgabe
Transparenter Modus Layer 3 DSR Load Balancing verteilt Sitzungen auf Server, die einen Layer-3-Hop entfernt sein können. Der Datenverkehr wird direkt vom Realserver an den Client zurückgegeben.
Funktionen des Load Balancers für den Datenverkehr
TLB stellt folgende Funktionen zur Verfügung:
TLB verteilt die Anforderungen für jeden Flow immer. Wenn Sie den DSR-Modus angeben, kehrt die Antwort direkt an die Quelle zurück. Wenn Sie den übersetzten Modus angeben, wird der umgekehrte Datenverkehr durch implizite Filter auf serverorientierten Schnittstellen geleitet.
TLB unterstützt hashbasiertes Load Balancing oder zufälliges Load Balancing.
Mit TLB können Sie Server offline konfigurieren, um Leistungseinbußen zu vermeiden, die durch ein erneutes Hashing für alle vorhandenen Flows verursacht werden können. Sie können einen Server im Status "Administrator ausgefallen" hinzufügen und ihn später für die Datenverkehrsverteilung verwenden, indem Sie den Status "Administrator ausgefallen" deaktivieren. Durch die Offlinekonfiguration von Servern können Auswirkungen auf den Datenverkehr auf andere Server vermieden werden.
Wenn die Zustandsprüfung feststellt, dass ein Server ausgefallen ist, werden nur die betroffenen Flows erneut aufgewärmt.
Wenn ein zuvor ausgefallener Server wieder in Betrieb genommen wird, kehren alle Datenströme, die basierend auf Hashing zu diesem Server gehören, zu ihm zurück, was sich auf die Leistung der zurückgegebenen Flüsse auswirkt. Aus diesem Grund können Sie das automatische Wiederbeitreten eines Servers zu einer aktiven Gruppe deaktivieren. Sie können Server wieder in Betrieb nehmen, indem Sie den
request services traffic-load-balance real-service rejoinBetriebsbefehl ausführen.Hinweis:NAT wird nicht auf die verteilten Flows angewendet.
Die Anwendung zur Überwachung der Zustandsprüfung läuft auf einer MS-MPC/NPU. Diese Netzwerkprozessoreinheit (NPU) wird nicht für die Verarbeitung des Datenverkehrs verwendet.
TLB unterstützt die statische Übersetzung von virtuellen IP-Adressen in reale IP-Adressen und die statische Übersetzung von Zielports während des Load Balancing.
TLB bietet mehrere VRF-Unterstützung.
Anwendungskomponenten des Traffic Load Balancer
- Server und Servergruppen
- Überwachung des Serverzustands – Einzelzustandsprüfung und duale Zustandsprüfung
- Virtuelle Services
Server und Servergruppen
TLB ermöglicht die Konfiguration von Gruppen von bis zu 255 Servern (in Konfigurationsanweisungen als reale Services bezeichnet) zur Verwendung als alternative Ziele für die zustandslose Sitzungsverteilung. Alle in Servergruppen verwendeten Server müssen vor der Zuweisung zu Gruppen einzeln konfiguriert werden. Load Balancing verwendet Hashing oder Randomisierung für die Sitzungsverteilung. Benutzer können Server zur und aus der TLB-Serververteilungstabelle hinzufügen und löschen sowie den Verwaltungsstatus eines Servers ändern.
TLB verwendet die Next-Hop-API für die Sitzungsverteilung, um die Serververteilungstabelle zu aktualisieren und Statistiken abzurufen. Anwendungen haben keine direkte Kontrolle über die Verwaltung der Serververteilungstabellen. Sie können Änderungen nur indirekt über die Add- und Delete-Services der TLB-API beeinflussen.
Überwachung des Serverzustands – Einzelzustandsprüfung und duale Zustandsprüfung
TLB unterstützt TCP-, HTTP-, SSL-Hello-, TLS-Hello- und benutzerdefinierte Integritätsprüfungstests, um den Zustand von Servern in einer Gruppe zu überwachen. Sie können einen einzelnen Prüfpunkttyp für eine Servergruppe oder eine Konfiguration für die duale Zustandsprüfung verwenden, die zwei Prüfpunkttypen enthält. Die konfigurierbare Zustandsüberwachungsfunktion befindet sich entweder auf einem MX-SPC3 oder einem MS-MPC. Standardmäßig werden Testanforderungen alle 5 Sekunden gesendet. Außerdem wird ein echter Server standardmäßig erst nach fünf aufeinanderfolgenden Testfehlern als ausgefallen und erst nach fünf aufeinanderfolgenden Testtests als aktiv deklariert.
Verwenden Sie einen benutzerdefinierten Integritätsprüfungstest, um Folgendes anzugeben:
-
Erwartete Zeichenfolge in der Testantwort
-
Zeichenfolge, die mit dem Prüfpunkt gesendet wird
-
Serverstatus, der zugewiesen werden soll, wenn die Probe eine Zeitüberschreitung aufweist (aktiv oder runter)
-
Serverstatus, der zugewiesen werden soll, wenn die erwartete Antwort auf die Probe empfangen wird (aktiv oder inaktiv)
-
Protokoll – UDP oder TCP
TLB bietet Anwendungsklebrigkeit, was bedeutet, dass Serverausfälle oder -änderungen keinen Einfluss auf den Datenverkehrsfluss zu anderen aktiven Servern haben. Das Ändern des Verwaltungsstatus eines Servers von "Up" zu "Downdown" wirkt sich nicht auf aktive Flows zu den verbleibenden Servern in der Serververteilungstabelle aus. Das Hinzufügen eines Servers oder das Löschen eines Servers aus einer Gruppe hat für einen bestimmten Zeitraum Auswirkungen auf den Datenverkehr, der von Ihrer Konfiguration der Parameter für das Intervall und die Wiederholung im Überwachungsprofil abhängt.
TLB bietet zwei Ebenen der Überwachung des Serverzustands:
-
Einzelne Zustandsprüfung: Ein Prüfpunkttyp wird mithilfe der
network-monitoring-profileKonfigurationsanweisung an eine Servergruppe angehängt. -
TLB Dual Health Check (TLB-DHC): Zwei Prüfpunkttypen werden einer Servergruppe über die
network-monitoring-profileKonfigurationsanweisung zugeordnet. Der Status eines Servers wird basierend auf dem Ergebnis von zwei Integritätsprüfungstests deklariert. Benutzer können bis zu zwei Integritätsprüfungsprofile pro Servergruppe konfigurieren. Wenn eine Servergruppe für die duale Zustandsprüfung konfiguriert ist, wird ein Real-Service nur dann als UP deklariert, wenn beide Integritätsprüfungstests gleichzeitig UP sind. Andernfalls wird ein Real-Service als DOWN deklariert.
Die folgenden Einschränkungen gelten für AMS-Schnittstellen, die für die Überwachung des Serverzustands verwendet werden:
-
Eine AMS-Schnittstelle, die unter einer TLB-Instance konfiguriert ist, verwendet ihre konfigurierten Mitgliedsschnittstellen ausschließlich für die Zustandsprüfung mehrerer konfigurierter realer Server.
-
Die Mitgliedsschnittstellen verwenden Einheit 0 für einzelne VRF-Fälle, können aber auch andere Einheiten als 1 für mehrere VRF-Fälle verwenden.
-
TLB verwendet die IP-Adresse, die für AMS-Mitgliedsschnittstellen konfiguriert ist, als Quell-IP-Adresse für Zustandsprüfungen.
-
Die Mitgliedsschnittstellen müssen sich in derselben Routing-Instanz befinden wie die Schnittstelle, die zum Erreichen realer Server verwendet wird. Dies ist für Verfahren zur Zustandsprüfung von TLB-Servern obligatorisch.
Ab Junos OS Version 24.2R1 wird bei der Konfiguration von TLS und SSL in derselben Gruppe der ODER-Mechanismus anstelle von AND verwendet, um den Status des tatsächlichen Servers zu bestimmen. Das heißt, der reale Server wird als UP markiert, wenn eine der Sonden funktioniert. Zuvor wurde der reale Server nur dann als UP markiert, wenn beide Tests erfolgreich waren.
Wenn die SSL-Testversion bereitgestellt wird, wird mit dieser Version getestet. Wenn die SSL-Version nicht angegeben ist, ändert sich das Verhalten in Fallback von Version v3 zu v2. Die Untersuchung beginnt mit SSLv3. Wenn der SSLv3-Test fehlschlägt, sucht das System nach SSLv2. Wenn das version-Attribut zuvor nicht explizit angegeben wurde, wurde die Untersuchung mit der Standardversion v3 durchgeführt.
Diese Verbesserung des Verhaltens bei der Zustandsprüfung ist nur anwendbar, wenn die TLS- und SSL-Tests in derselben Zustandsprüfungsgruppe konfiguriert sind.
Die Ausgabe für show services traffic-load-balance statistics instance <inst> extensive wurde geändert.
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
Die SSL-hello-Testversion wird unter "Echte Serverstatistiken" aus dem virtuellen Dienst verschoben, wenn die SSL-Version nicht unter "Integritätsprüfungsprofil" angegeben ist.
Virtuelle Services
Der virtuelle Dienst stellt eine virtuelle IP-Adresse (VIP) bereit, die der Servergruppe zugeordnet ist, an die der Datenverkehr geleitet wird, wie durch die hashbasierte oder zufällige Sitzungsverteilung und die Überwachung des Serverzustands bestimmt. Im Fall von L2 DSR und L3 DSR bewirkt die spezielle Adresse 0.0.0.0, dass der gesamte Datenverkehr, der zur Weiterleitungsinstanz fließt, einen Lastenausgleich hat.
Die virtuelle Servicekonfiguration umfasst:
-
Modus: Gibt an, wie der Datenverkehr verarbeitet wird (übersetzt oder transparent).
-
Die Gruppe von Servern, auf die Sitzungen verteilt werden.
-
Die Load Balancing-Methode.
-
Routing-Instanz und Routenmetrik.
Obwohl Sie eine virtuelle Adresse von 0.0.0.0 zuweisen können, um das Standardrouting zu verwenden, empfehlen wir die Verwendung einer virtuellen Adresse, die einer speziell für TLB eingerichteten Routing-Instanz zugewiesen werden kann.
Konfigurationslimits für Load Balancer für den Datenverkehr
Die Konfigurationsgrenzwerte für Load Balancer für den Datenverkehr werden in Tabelle 4 beschrieben.
Konfigurationskomponente |
Konfigurations-Limit |
|---|---|
Maximale Anzahl von Instanzen |
Ab Junos OS Version 16.1R6 und Junos OS Version 18.2R1 unterstützt die TLB-Anwendung 2000 TLB-Instanzen für virtuelle Services, die den Direct-Server-Return- oder den übersetzten Modus verwenden. In früheren Versionen beträgt die maximale Anzahl von Instanzen 32. Wenn mehrere virtuelle Services dieselbe Servergruppe verwenden, müssen alle diese virtuellen Services dieselbe Load Balancing-Methode verwenden, um 2000 TLB-Instanzen zu unterstützen. Für virtuelle Services, die den Layer2-Direct-Server-Return-Modus verwenden, unterstützt TLB nur 32 TLB-Instanzen. Um die gleiche Funktion wie im layer2-direct-server-return-Modus auszuführen und 2000 TLB-Instanzen zu unterstützen, können Sie den direct-server-return-Modus verwenden und einen Service-Filter mit der Skip-Aktion verwenden. |
Maximale Anzahl von Servern pro Gruppe |
255 |
Maximale Anzahl virtueller Services pro Services-PIC |
32 |
Maximale Anzahl von Zustandsprüfungen pro Service-PIC in einem 5-Sekunden-Intervall |
Für MS-MPC Servicekarten: 2000 Für den Next Gen Services-Modus und die MX-SPC3 Service Cards: 1250 |
Maximale Anzahl von Gruppen pro virtuellem Service |
1 |
Maximale Anzahl virtueller IP-Adressen pro virtuellem Service |
1 |
Unterstützte Zustandsprüfungsprotokolle |
ICMP, TCP, HTTP, SSL, TLS-Hallo, benutzerdefiniert
Hinweis:
Die ICMP-Zustandsprüfung wird nur auf MS-MPC-Servicekarten unterstützt. Ab Junos OS Version 22.4R1 wurde TLB erweitert, um den TLS-Hello-Zustandsprüfungstyp zu unterstützen. Für TLS-Hello über TCP werden TLS v1.2 und v1.3 Zustandsprüfungen unterstützt. |
Siehe auch
Konfigurieren von TLB
In den folgenden Themen wird beschrieben, wie TLB konfiguriert wird. Um eine vollständige Anwendung zu erstellen, müssen Sie auch Schnittstellen und Routing-Informationen definieren. Sie können optional Firewall-Filter und Richtlinienoptionen definieren, um TLB-Datenverkehr zu differenzieren.
- TLB-Servicepaket laden
- Konfigurieren eines TLB-Instanznamens
- Schnittstellen- und Routing-Informationen konfigurieren
- Server konfigurieren
- Konfigurieren von Netzwerküberwachungsprofilen
- Konfigurieren von Servergruppen
- Konfiguration virtueller Services
- Konfigurieren der Ablaufverfolgung für die Überwachungsfunktion der Gesundheitsprüfung
TLB-Servicepaket laden
Laden Sie das TLB-Servicepaket auf jede Service-PIC, auf der Sie TLB ausführen möchten.
Für Next Gen Services und die MX-SPC3 Services Card müssen Sie dieses Paket nicht laden.
So laden Sie das TLB-Servicepaket auf ein Service-PIC:
Laden Sie das
jservices-traffic-dirdPaket.[edit chassis fpc slot-number pic pic-number adaptive-services service-package extension-provider] user@host# set package jservices-traffic-dird
Zum Beispiel:
[edit chassis fpc 3 pic 0 adaptive-services service-package extension-provider] user@host# set package jservices-traffic-dird
Konfigurieren eines TLB-Instanznamens
system processes sdk-service enable .
So konfigurieren Sie einen Namen für die TLB-Instanz:
-
Identifizieren Sie auf Hierarchieebene
[edit services traffic-load-balance]den Namen der TLB-Instanz.[edit services traffic-load-balance] user@host# set instance instance-name
Zum Beispiel:
[edit services traffic-load-balance] user@host# set instance tlb-instance1
Schnittstellen- und Routing-Informationen konfigurieren
So konfigurieren Sie Schnittstellen- und Routing-Informationen:
Server konfigurieren
So konfigurieren Sie Server für die TLB-Instanz:
[edit services traffic-load-balance instance instance-name] user@host# set real-service real-service-name address server-ip-address
Zum Beispiel:
[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
Konfigurieren von Netzwerküberwachungsprofilen
Ein Netzwerküberwachungsprofil konfiguriert einen Integritätsprüfungstest, den Sie einer Servergruppe zuweisen, an die der Sitzungsdatenverkehr verteilt wird.
So konfigurieren Sie ein Netzwerküberwachungsprofil:
Konfigurieren von Servergruppen
Servergruppen bestehen aus Servern, auf die der Datenverkehr über zustandslose, hashbasierte Sitzungsverteilung und Serverzustandsüberwachung verteilt wird.
So konfigurieren Sie eine Servergruppe:
Konfiguration virtueller Services
Ein virtueller Dienst stellt eine Adresse bereit, die einer Gruppe von Servern zugeordnet ist, zu denen der Datenverkehr geleitet wird, wie durch Hash-basierte oder zufällige Sitzungsverteilung und Serverzustandsüberwachung bestimmt. Sie können optional Filter und Routing-Instanzen angeben, um den Datenverkehr für TLB zu steuern.
So konfigurieren Sie einen virtuellen Dienst:
Konfigurieren der Ablaufverfolgung für die Überwachungsfunktion der Gesundheitsprüfung
So konfigurieren Sie Ablaufverfolgungsoptionen für die Überwachungsfunktion der Zustandsprüfung:
Tabellarischer Änderungsverlauf
Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie den Feature-Explorer , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.