Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Multinode-Unterstützung für virtuelle Firewall vSRX-Instanzen

Multinode-Hochverfügbarkeit erfüllt die hohen Verfügbarkeitsanforderungen für private und öffentliche Cloud-Bereitstellungen, indem es Ausfallsicherheit zwischen den Gehäusen bietet.

Wir unterstützen Multinode-Hochverfügbarkeit auf Juniper Networks Virtuelle Firewall vSRX Virtual Firewalls für private (Kernel-basierte virtuelle Maschine [KVM] und VMware ESXi) und Public Cloud (AWS) Bereitstellungen.

Sie können Multinode-Hochverfügbarkeit auf vSRX-Instanzen mit der gleichen Methode konfigurieren wie für physische Firewalls der SRX-Serie für private Cloud-Bereitstellungen.

So konfigurieren Sie Multinode-Hochverfügbarkeit in VMware ESXi und KVM:

So konfigurieren Sie Multinode-Hochverfügbarkeit in öffentlichen Clouds-Bereitstellungen:

Unterstützung für ICL-Verschlüsselung und flexible Datapath-Fehlererkennung

Die virtuelle Firewall vSRX in Multinode-Hochverfügbarkeit, die in privaten Clouds (KVM und VMware ESXi) bereitgestellt wird, unterstützt ICL-Verschlüsselung und flexible Datapath-Fehlererkennung.

  • ICL Encryption verwendet IPsec-Protokolle, um Synchronisationsnachrichten zwischen hochverfügbaren Knoten zu sichern und den Datenschutz zu gewährleisten. Konfigurationsdetails finden Sie unter Beispiel: Konfigurieren der Multinode-Hochverfügbarkeit in einem Layer-3-Netzwerk .
  • Die flexible Datapath Failure Detection bietet eine Pfadüberwachung mit granularer Kontrolle durch gewichtete Funktionen, die IP, Bidirectional Forwarding Detection (BFD) und Schnittstellenüberwachung unterstützen.

    Weitere Informationen finden Sie unterFlexible Pfadüberwachung .

Verständnis von Multinode-Hochverfügbarkeit Dual Path Interchassis Link (ICL)

Multinode High Availability (MNHA) unterstützt Dual Path Interchassis Link (ICL) über aggregiertes Ethernet (AE) und Loopback-Schnittstellen. Diese Erweiterung ermöglicht eine effiziente Verteilung des Datenverkehrs und eine verbesserte Zuverlässigkeit der hohen Verfügbarkeit in öffentlichen Clouds wie AWS, Azure und Google Cloud Platform (GCP) sowie in privaten Clouds mit KVM und VMware. Beachten Sie bei der Konfiguration von ICL Folgendes:

  • In öffentlichen Clouds-Umgebungen wie AWS, Azure und GCP werden Loopback-Schnittstellen aufgrund von Einschränkungen für AE-Schnittstellen bevorzugt.
  • In privaten Cloud-Umgebungen, die KVM und VMware nutzen, können Sie AE-Schnittstellen zur Einrichtung von Dual-Path-ICLs verwenden, die sich durch flexible Konfigurationen auszeichnen, die den Einsatz verschiedener Netzwerkschnittstellenkarten ermöglichen.

Vorteile von Dual Path ICL bei MNHA

  • Verbessert die Kompatibilität mit öffentlichen Cloud-Umgebungen wie AWS, Azure und GCP und ermöglicht eine effiziente Layer-3-Bereitstellung mit hoher Verfügbarkeit.

  • Verbessert die Verteilung des Datenverkehrs und das Load Balancing durch den Einsatz von AE- und Loopback-Schnittstellen und gewährleistet so eine optimale Leistung sowohl in öffentlichen als auch in privaten Cloud-Setups.

    Unterstützung für AE-Schnittstelle als Dual-Path-ICL in privaten Cloud-Umgebungen

    In einer privaten Cloud mit KVM oder VMware können Sie eine aggregierte Ethernet-Schnittstelle (AE) als Dual-Path-ICL konfigurieren. Dies wird unterstützt mit:

    • Virtio NICs für KVM
    • VMXNET3 NICs für VMware

    Für Setups mit SR-IOV-NICs (wie Intel I40E, E810 oder Mellanox MLX5) muss die AE-Schnittstelle die virtuelle MAC-Funktionalität (vMAC) unterstützen.

    Jede Mitgliedsschnittstelle (untergeordnete Schnittstelle) der AE muss eine Gigabit-Ethernet-Schnittstelle (GE) sein und sich auf unterschiedlichen physischen Funktionen (PFs) befinden – was in der Regel bedeutet, dass sie sich auf verschiedenen Linecards befinden sollten.

Effiziente Verteilung des ICL-Datenverkehrs

Verwalten des Datenverkehrs in vSRX mit aggregiertem Ethernet (AE): Verwenden von LACP und Hypervisor-Bridge-Konfiguration

In einer vSRX-Konfiguration ist die Gewährleistung eines zuverlässigen und effizienten Datenverkehrsflusses von entscheidender Bedeutung, insbesondere wenn es sich um aggregierte Ethernet-Schnittstellen (AE) handelt. Wenn eine untergeordnete Schnittstelle innerhalb der AE-Gruppe nicht in Ordnung ist oder ausfällt, kann dies zu Datenverkehrsverlusten führen. Um dieses Risiko zu mindern, können Sie das Link Aggregation Control Protocol (LACP) verwenden oder die untergeordneten Schnittstellen so konfigurieren, dass sie dieselbe Bridge im Hypervisor verwenden.

Verwenden von LACP auf AE-Schnittstelle

LACP ist ein Protokoll, mit dem die Link-Aggregation dynamisch verwaltet und sichergestellt wird, dass alle untergeordneten Schnittstellen koordiniert arbeiten. Durch die Konfiguration von LACP können Sie Schnittstellenfehler automatisch behandeln und den Datenverkehrsfluss ohne manuellen Eingriff aufrechterhalten. So können Sie LACP auf einer AE-Schnittstelle konfigurieren:

  • Aktiv: Diese Einstellung aktiviert den aktiven LACP-Modus, in dem die vSRX aktiv LACP-Pakete an den Peer sendet, um die LACP-Verbindung zu bilden und aufrechtzuerhalten.
  • Periodisch schnell: Diese Einstellung reduziert das LACP-Zeitüberschreitungsintervall und ermöglicht eine schnellere Erkennung von Verbindungsfehlern und eine schnellere Reaktion zur Aufrechterhaltung des Datenverkehrsflusses.

Konfigurieren von untergeordneten Schnittstellen auf derselben Bridge

In Situationen, in denen LACP schwer zu unterstützen oder zu implementieren ist, besteht ein anderer Ansatz darin, sicherzustellen, dass alle untergeordneten Schnittstellen in der AE-Gruppe mit derselben Bridge innerhalb des Hypervisors verbunden sind. Diese Konfiguration kann dazu beitragen, eine konsistente Konnektivität aufrechtzuerhalten und Datenverkehrsverluste zu vermeiden, wenn eine Schnittstelle außer Betrieb ist.

Nachfolgend finden Sie ein Beispiel für die XML-Konfiguration für zwei untergeordnete Schnittstellen (ge-0/0/0 und ge-0/0/3), die dieselbe Bridge (bridge-vsrx-mnha-icl) in einem KVM-Hypervisor verwenden:

In dieser Konfiguration: Beide Schnittstellen sind mit der bridge-vsrx-mnha-icl-Bridge verbunden, wodurch sichergestellt wird, dass sie dasselbe Netzwerksegment innerhalb des Hypervisors teilen. Mit dieser Einrichtung können Sie den Datenverkehr auch dann effektiv verwalten, wenn eine der Schnittstellen Probleme hat.

Verwendung von AE-Schnittstellen in der MNHA-Konfihuration

Der folgende Konfigurationsausschnitt richtet eine MNHA-Umgebung mit AE Interface ein:

Das obige Beispiel zeigt das Konfigurieren lokaler und Peer Gehäuse-IDs und IPs für die Hohe Verfügbarkeit Kommunikation, das Zuordnen physischer Schnittstellen zu einer aggregierten Ethernet-Schnittstelle (ae0) mithilfe von LACP und das Zuweisen einer IP-Adresse zur logischen Einheit der aggregierten Schnittstelle. In diesem Beispiel:

  • Die AE-Schnittstelle (ae0) wird als ICL zwischen den Knoten verwendet.
  • physische Schnittstellen ge-0/0/0 und ge-0/0/1 werden in ae0 der Verwendung von 802.3ad Link Aggregation gebündelt.

Ausgewogene ICL-Datenverkehrsverteilung über PFEs

Wir haben das System verbessert, um eine ausgewogene ICL-Datenverkehrsverteilung über alle PFE-Verarbeitungseinheiten auf der Empfängerseite in einem MNHA-Setup zu gewährleisten.

In unserem MNHA-Setup wird der Datenverkehr über ICL effizient verwaltet, um eine hohe Leistung zu gewährleisten. Ausgehender Datenverkehr wird automatisch auf mehrere Flow-Verarbeitungseinheiten verteilt, ein integriertes Feature der MNHA-Architektur. Um die Verarbeitung eingehenden Datenverkehrs zu verbessern, verwenden wir eine Hashing-Methode mit fünf Tupeln auf dem ICL-Port. Dadurch wird der Datenverkehr gleichmäßig auf alle Verarbeitungseinheiten der Packet Forwarding Engine (PFE) verteilt, was zu einem besseren Load Balancing und einer besseren Gesamteffizienz des Netzwerks führt.

Der Befehl set chassis high-availability peer-id <id_num> interface <interface-name> unterstützt GE-, AE- und Loopback-Schnittstellen und ermöglicht Konfigurationen mit hoher Verfügbarkeit, die auf Ihre spezifischen Bereitstellung-Anforderungen zugeschnitten sind.

Auf der sendenden Seite hängt die Bestimmung, welcher Port für ICL-Datenverkehr in der Packet Forwarding Engine verwendet wird, nicht nur von dieser Konfiguration ab. Stattdessen hängt es von den Ergebnissen der IP- und Routensuche ab. Für Firewalls der SRX-Serie sind Prioritätswarteschlangen standardmäßig auf allen Ports aktiviert, um die Verwaltung des Datenverkehrs zu erleichtern, insbesondere für aggregierte Schnittstellen und Loopback-Schnittstellen. vSRX3.0 kann diesen Ansatz jedoch nicht nutzen.

Für die empfangsseitige Verteilung in vSRX3.0 ist eine neue CLI-Konfiguration erforderlich, um ICL-Ports für die Aktivierung des 5-Tupel-Hashings anzugeben. Dies geschieht mit dem Befehl:

user@host# set security forwarding-options receive-side-scaling nic-rss hash five-tuple ports [port_ids]

Beispiel:

In dieser Konfiguration sind die Ports 0 und Port 1 für die Verwendung von Fünf-Tupel-Hashing für die empfangsseitige Skalierung konfiguriert. Dadurch wird sichergestellt, dass eingehender Datenverkehr basierend auf Quell- und Ziel-IP-Adressen, Ports und Protokoll effizient verteilt wird.