Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Load Balancer für Datenverkehr

Traffic Load Balancer – Übersicht

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.

Tabelle 1: Zusammenfassung der Unterstützung für den Lastausgleich für den Datenverkehr

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.

Hinweis:

Sie können Deterministic NAT und TLB nicht gleichzeitig ausführen.

Tabelle 2: Zusammenfassung der unterstützten Router-Plattform der TLB-MX-Serie

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.

Tabelle 3: TLB im Vergleich zu Sicherheit Service Cards – Zusammenfassung

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

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.

Abbildung 1: TLB-Topologie für den transparenten Modus TLB Topology for Transparent Mode

Ü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.

Abbildung 2: TLB-Topologie für den übersetzten Modus TLB Topology for Translated Mode

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 rejoin Betriebsbefehl 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

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.

Hinweis:

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-profile Konfigurationsanweisung an eine Servergruppe angehängt.

  • TLB Dual Health Check (TLB-DHC): Zwei Prüfpunkttypen werden einer Servergruppe über die network-monitoring-profile Konfigurationsanweisung 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.

Hinweis:

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.

Hinweis:

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>
Hinweis:

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.

Optimale Vorgehensweise:

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.

Tabelle 4: TLB-Konfigurationslimits

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.

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

Laden Sie das TLB-Servicepaket auf jede Service-PIC, auf der Sie TLB ausführen möchten.

Hinweis:

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-dird Paket.

    Zum Beispiel:

Konfigurieren eines TLB-Instanznamens

Aktivieren Sie vor der Konfiguration von TLB den sdk-service-Prozess, indem Sie ihn in der [edit]-Hierarchie konfigurieren 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.

    Zum Beispiel:

Schnittstellen- und Routing-Informationen konfigurieren

So konfigurieren Sie Schnittstellen- und Routing-Informationen:

  1. Identifizieren Sie auf Hierarchieebene [edit services traffic-load-balance instance instance-name] die Serviceschnittstelle, die dieser Instanz zugeordnet ist.

    Zum Beispiel auf einem MS-MPC:

    Zum Beispiel für Next Gen Services auf einem MX-SPC3:

  2. Aktivieren Sie das Routing von Paketantworten zur Zustandsprüfung von realen Servern an die Dienstschnittstelle, die Sie in Schritt 1 identifiziert haben.

    Zum Beispiel auf einem MS-MPC:

    Zum Beispiel bei einem MX-SPC3:

  3. Geben Sie die Clientschnittstelle an, für die ein impliziter Filter definiert ist, um den Datenverkehr in Vorwärtsrichtung zu leiten. Dies ist nur für den übersetzten Modus erforderlich.

    Zum Beispiel:

  4. Geben Sie die virtuelle Routinginstanz an, die zum Weiterleiten des Datenverkehrs an Server verwendet wird. Dies ist für SLT und Layer 3 DSR erforderlich. für Layer 2 DSR ist er optional.

    Zum Beispiel:

  5. Geben Sie die Serverschnittstelle an, für die implizite Filter definiert sind, um den Datenverkehr an den Client weiterzuleiten.
    Hinweis:

    Implizite Filter für Rückflüsse werden für DSR nicht verwendet.

    Zum Beispiel:

  6. (Optional) Geben Sie den Filter an, der zum Umgehen der Zustandsprüfung für wiederkehrenden Datenverkehr verwendet wird.

    Zum Beispiel:

  7. Geben Sie die virtuelle Routing-Instanz an, in der die Daten in umgekehrter Richtung an die Clients weitergeleitet werden sollen.

    Zum Beispiel:

    Hinweis:

    Virtuelle Routinginstanzen für das Routing von Daten in umgekehrter Richtung werden mit DSR nicht verwendet.

Server konfigurieren

So konfigurieren Sie Server für die TLB-Instanz:

Konfigurieren Sie einen logischen Namen und eine IP-Adresse für jeden Server, der für die Next-Hop-Verteilung verfügbar gemacht werden soll.

Zum Beispiel:

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:

  1. Konfigurieren Sie den Typ des Prüfpunkts, der für die Zustandsüberwachung verwendet werden soll — icmp, tcp, http, ssl-hellotls-hello,oder custom.
    Hinweis:

    icmp Sondierungen werden nur auf MS-MPC-Karten unterstützt.

    Services der nächsten Generation und der MX-SPC3 unterstützen in dieser Version keine ICMP-Sonden.

    • Für eine ICMP-Sondierung:

    • Für eine TCP-Sonde:

    • Für eine HTTP-Sondierung:

    • Für eine SSL-Sondierung:

    • Für eine TLS-Hello-Sondierung:

    • Für eine benutzerdefinierte Sonde:

  2. Konfigurieren Sie das Intervall für Testversuche in Sekunden (1 bis 180).

    Zum Beispiel:

  3. Konfigurieren Sie die Anzahl der Fehlerwiederholungen, nach denen der reale Server als ausgefallen markiert wird.

    Zum Beispiel:

  4. Konfigurieren Sie die Anzahl der Wiederherstellungswiederholungen, d. h. die Anzahl der erfolgreichen Testversuche, nach denen der Server als aktiv deklariert wird.

    Zum Beispiel:

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:

  1. Geben Sie die Namen eines oder mehrerer konfigurierter realer Server an.

    Zum Beispiel:

  2. Konfigurieren Sie die Routing-Instance für die Gruppe, wenn Sie die Standard-Instance nicht verwenden möchten. inet.0

    Zum Beispiel:

  3. (Optional) Deaktivieren Sie die Standardoption, die es einem Server ermöglicht, der Gruppe automatisch wieder beizutreten, wenn sie hochgefahren wird.
  4. (Optional) Konfigurieren Sie die logische Einheit der Serviceschnittstelle der Instanz, die für die Zustandsprüfung verwendet werden soll.
    1. Geben Sie die logische Einheit an.

    2. Aktivieren Sie das Routing von Paketantworten zur Zustandsprüfung von realen Servern an die Schnittstelle.

    Zum Beispiel:

  5. Konfigurieren Sie ein oder zwei Netzwerküberwachungsprofile, die zum Überwachen des Zustands von Servern in dieser Gruppe verwendet werden sollen.

    Zum Beispiel:

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:

  1. Geben Sie auf Hierarchieebene [edit services traffic-load-balance instance instance-name] eine Adresse ungleich Null für den virtuellen Service an.

    Zum Beispiel:

  2. Geben Sie die Servergruppe an, die für diesen virtuellen Dienst verwendet wird.

    Zum Beispiel:

  3. (Optional) Geben Sie eine Routing-Instanz für den virtuellen Service an. Wenn Sie keine Routing-Instance angeben, wird die Standard-Routing-Instance verwendet.

    Zum Beispiel:

  4. Geben Sie den Verarbeitungsmodus für den virtuellen Service an.

    Zum Beispiel:

  5. (Optional) Aktivieren Sie für einen virtuellen Dienst im übersetzten Modus das Hinzufügen der IP-Adressen für alle realen Server in der Gruppe unter dem virtuellen Dienst zu den serverseitigen Filtern. Auf diese Weise können Sie zwei virtuelle Services mit demselben Abhörport und Protokoll auf derselben Schnittstelle und demselben VRF konfigurieren.
  6. (Optional) Geben Sie eine Routing-Metrik für den virtuellen Service an.

    Zum Beispiel:

  7. Geben Sie die Methode an, die für das Load Balancing verwendet wird. Sie können eine Hashmethode angeben, die einen Hashschlüssel basierend auf einer beliebigen Kombination aus Quell-IP-Adresse, Ziel-IP-Adresse und Protokoll bereitstellt, oder Sie können randomangeben.

    Zum Beispiel:

    oder

    Hinweis:

    Wenn Sie für einen virtuellen Service zwischen der Hash-Methode und der Zufallsmethode wechseln, gehen die Statistiken für den virtuellen Service verloren.

  8. Geben Sie für einen virtuellen Dienst im übersetzten Modus einen Dienst für die Übersetzung an, einschließlich eines virtuellen Ports, eines Server-Überwachungsports und eines Protokolls.

    Zum Beispiel:

  9. Bestätigen Sie die Konfiguration.
    Hinweis:

    Wenn keine Clientschnittstellenkonfiguration unter der TLB-Instanz vorhanden ist, wird der implizite Clientfilter (für VIP) an die client-vrf angehängt, die unter der TLB-Instanz konfiguriert ist. In diesem Fall darf die Routing-Instanz unter einem virtuellen Service im Übersetzungsmodus nicht mit der client-vrf identisch sein, die unter der TLB-Instanz konfiguriert ist. Wenn dies der Fall ist, schlägt der Commit fehl.

Konfigurieren der Ablaufverfolgung für die Überwachungsfunktion der Gesundheitsprüfung

So konfigurieren Sie Ablaufverfolgungsoptionen für die Überwachungsfunktion der Zustandsprüfung:

  1. Geben Sie an, dass Sie Ablaufverfolgungsoptionen für die Überwachungsfunktion der Zustandsprüfung konfigurieren möchten.
  2. (Optional) Konfigurieren Sie den Namen der Datei, die für die Ablaufverfolgungsausgabe verwendet wird.
  3. (Optional) Deaktivieren Sie die Remote-Tracing-Funktionen.
  4. (Optional) Konfigurieren Sie Flags, um die zu protokollierenden Vorgänge zu filtern.

    In Tabelle 5 werden die Flags beschrieben, die Sie einschließen können.

    Tabelle 5: Trace-Flags

    Hinweis

    Unterstützung für MS-MPC- und MX-SPC3-Karten

    Beschreibung

    alle

    MS-MPC und MX-SPC3

    Verfolgen Sie alle Vorgänge.

    Komplett-Dienstleistungen

    MX-SPC3

    Verfolgen Sie alle realen Dienstleistungen.

    Konfiguration

    MS-MPC und MX-SPC3

    Verfolgen Sie die Konfigurationsereignisse des Load Balancers für den Datenverkehr.

    Verbinden

    MS-MPC und MX-SPC3

    Verfolgen Sie IPC-Ereignisse des Datenverkehrs Load Balancer.

    Datenbank

    MS-MPC und MX-SPC3

    Verfolgen von Datenbankereignissen.

    file-descriptor-queue

    MS-MPC

    Ablaufverfolgungsdateideskriptor-Warteschlangenereignisse.

    Inter-Thread

    MS-MPC

    Verfolgen von Kommunikationsereignissen zwischen Threads.

    Filtern

    MS-MPC und MX-SPC3

    Verfolgen Sie Ereignisse für die Filterprogrammierung von Datenverkehrs-Load-Balancer-Filtern.

    Gesundheit

    MS-MPC und MX-SPC3

    Verfolgen Sie Integritätsereignisse des Load Balancers für den Datenverkehr.

    Nachrichten

    MS-MPC und MX-SPC3

    Verfolgen Sie normale Ereignisse.

    normal

    MS-MPC und MX-SPC3

    Verfolgen Sie normale Ereignisse.

    Operational-Befehle

    MS-MPC und MX-SPC3

    Verfolgen Sie die Ereignisse des Load Balancers für den Datenverkehr.

    Parse

    MS-MPC und MX-SPC3

    Verfolgen Sie die Analyseereignisse des Load Balancers für den Datenverkehr.

    Sondierung

    MS-MPC und MX-SPC3

    Prüfpunktereignisse verfolgen.

    probe-infra

    MS-MPC und MX-SPC3

    Verfolgen Sie Prüfpunktinfrastrukturereignisse.

    Route

    MS-MPC und MX-SPC3

    Verfolgen Sie Routenereignisse des Load Balancers für den Datenverkehr.

    SNMP

    MS-MPC und MX-SPC3

    Verfolgen Sie SNMP-Ereignisse des Load Balancers für den Datenverkehr.

    Statistiken

    MS-MPC und MX-SPC3

    Verfolgen Sie Statistikereignisse des Load Balancers für den Datenverkehr.

    System

    MS-MPC und MX-SPC3

    Verfolgen Sie Systemereignisse des Load Balancers für den Datenverkehr.

  5. (Optional) Konfigurieren Sie die Ablaufverfolgungsebene.
  6. (Optional) Konfigurieren Sie die Ablaufverfolgung für einen bestimmten realen Server innerhalb einer bestimmten Servergruppe.
  7. (Optional) Konfigurieren Sie ab Junos OS Version 16.1R6 und 18.2R1 die Ablaufverfolgung für einen bestimmten virtuellen Service und eine bestimmte Instanz.

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.

Veröffentlichung
Beschreibung
16.1R6
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.
16.1R6
Konfigurieren Sie ab Junos OS Version 16.1R6 und 18.2R1 die Ablaufverfolgung für einen bestimmten virtuellen Service und eine bestimmte Instanz.