Best Practices für die Verwaltung eines Chassis-Clusters
Im Folgenden finden Sie einige Best Practices für Chassis-Cluster für Geräte der SRX-Serie.
Verwenden von Dual-Control-Links
Bei dualen Steuerverbindungen werden zwei Paare von Steuerverbindungsschnittstellen zwischen jedem Gerät in einem Cluster verbunden. Duale Steuerverbindungen werden auf den SRX5000- und SRX3000-Leitungen unterstützt. Zwei Steuerverbindungen helfen, einen möglichen Single Point of Failure zu vermeiden. Für die SRX5000-Reihe erfordert diese Funktionalität die Installation einer zweiten Routing-Engine sowie eines zweiten Switch Control Board (SCB) für die Routing-Engine, das auf jedem Gerät im Cluster installiert werden muss. Der Zweck der zweiten Routing-Engine besteht nur darin, den Switch auf dem SCB zu initialisieren. Die zweite Routing-Engine, die nur auf Geräten der SRX5000 installiert werden kann, bietet keine Backup-Funktionalität. Für diese SRX3000-Reihe erfordert diese Funktionalität die Installation eines SRX-Clustering-Moduls (SCM) auf jedem Gerät im Cluster. Obwohl der SCM in den Routing-Engine-Steckplatz passt, handelt es sich nicht um eine Routing-Engine. SRX3000-Reihe Geräte unterstützen keine zweite Routing-Engine. Der Zweck des SCM besteht darin, die zweite Steuerverbindung zu initialisieren. Zweigstellengeräte der SRX-Serie unterstützen keine Dual-Control-Links.
Verwenden von Dual-Daten-Links
Sie können zwei Fabric-Links zwischen jedem Gerät in einem Cluster verbinden, wodurch ein redundanter Fabric-Link zwischen den Mitgliedern eines Clusters bereitgestellt wird. Zwei Fabric-Links helfen, einen möglichen Single Point of Failure zu vermeiden. Wenn Sie Dual-Fabric-Links verwenden, werden die Laufzeitobjekte (RTOs) und Sonden auf einer Verbindung und die Fabric-weitergeleiteten und -flow-weitergeleiteten Pakete auf der anderen Verbindung gesendet. Wenn eine Fabric-Verbindung ausfällt, kümmert sich die andere Fabric-Verbindung um die RTOs und Sonden sowie um die Datenweiterleitung. Das System wählt die physische Schnittstelle mit dem niedrigsten Steckplatz, PIC oder der niedrigsten Portnummer auf jedem Knoten für die RTOs und Sondes aus.
Verwendung von BFD
Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfacher Hello-Mechanismus, der Fehler in einem Netzwerk erkennt. Hello-Pakete werden in einem festgelegten, regelmäßigen Intervall gesendet. Ein Nachbarfehler wird erkannt, wenn der Router nach einem bestimmten Intervall keine Antwort mehr empfängt. BFD funktioniert mit einer Vielzahl von Netzwerkumgebungen und Topologien. Die Erkennungszeiten von BFD-Fehlern sind kürzer als die von RIP und bieten schnellere Reaktionszeiten auf verschiedene Arten von Fehlern im Netzwerk. Diese Timer sind auch adaptiv. Beispielsweise kann sich ein Timer an einen höheren Wert anpassen, wenn die Nachbarschaft fehlschlägt, oder ein Nachbar kann einen höheren Wert für einen Timer aushandeln als den konfigurierten. Daher kann BFD-Lebendigkeit zwischen den beiden Knoten eines Chassis-Clusters der SRX-Serie mithilfe der lokalen Schnittstellen und nicht über die fxp0-IP-Adressen auf jedem Knoten konfiguriert werden. Auf diese Weise kann BFD den Status zwischen den beiden Knoten des Clusters überwachen. Wenn es ein Netzwerkproblem zwischen den Knoten gibt, werden die BFD-Session-Down-SNMP-Traps gesendet, was auf ein Problem zwischen den Knoten hinweist.
Verwenden der IP-Überwachung
Die IP-Überwachung ist ein Automatisierungsskript, mit dem Sie diese wichtige Funktion auf den Plattformen der SRX-Serie verwenden können. Es ermöglicht die Validierung von Pfaden und nächsten Hops durch die vorhandene Netzwerkinfrastruktur unter Verwendung des Internet Control Message Protocol (ICMP). Wenn ein Fehler erkannt wird, führt das Skript ein Failover auf den anderen Knoten aus, um Ausfallzeiten zu vermeiden.
Verwenden des Schnittstellen-Monitorings
Die andere implementierte Chassis-Cluster-Funktion der SRX-Serie heißt Schnittstellenüberwachung. Damit eine Redundanzgruppe automatisch ein Failover auf einen anderen Knoten ausführen kann, müssen ihre Schnittstellen überwacht werden. Wenn Sie eine Redundanzgruppe konfigurieren, können Sie eine Reihe von Schnittstellen angeben, die von der Redundanzgruppe auf Status oder Integrität überwacht werden sollen, um festzustellen, ob die Schnittstelle aktiv oder inaktiv ist. Eine überwachte Schnittstelle kann eine untergeordnete Schnittstelle einer ihrer redundanten Ethernet-Schnittstellen (reth) sein. Wenn Sie eine Schnittstelle für eine zu überwachende Redundanzgruppe konfigurieren, gewichten Sie sie. Für jede Redundanzgruppe ist ein Schwellenwert für die Toleranz ursprünglich auf 255 festgelegt. Wenn eine Schnittstelle, die von einer Redundanzgruppe überwacht wird, nicht mehr verfügbar ist, wird ihre Gewichtung vom Schwellenwert der Redundanzgruppe subtrahiert. Wenn der Schwellenwert einer Redundanzgruppe 0 erreicht, wird ein Failover auf den anderen Knoten ausgeführt. Wenn z. B. Redundanzgruppe 1 auf Knoten 0 primär war, wird Redundanzgruppe 1 beim Schwellenwertüberschreiten auf Knoten 1 primär. In diesem Fall beginnen alle untergeordneten Schnittstellen der reth-Schnittstellen der Redundanzgruppe 1 mit der Verarbeitung des Datenverkehrs. Ein Redundanzgruppenfailover tritt auf, weil die kumulative Gewichtung der überwachten Schnittstellen der Redundanzgruppe den Schwellenwert auf 0 gebracht hat. Wenn die überwachten Schnittstellen einer Redundanzgruppe auf beiden Knoten gleichzeitig ihre Schwellenwerte erreichen, ist die Redundanzgruppe primär auf dem Knoten mit der niedrigeren Knoten-ID, in diesem Fall Knoten 0.
Die Schnittstellenüberwachung wird für die Redundanzgruppe 0 nicht empfohlen.
chassis { cluster { reth-count 6; redundancy-group 0 { node 0 priority 129; node 1 priority 128; } redundancy-group 1 { node 0 priority 129; node 1 priority 128; interface-monitor { ge-0/0/0 weight 255; ge-8/0/0 weight 255; } ip-monitoring { global-weight 255; global-threshold 0; family { inet { 128.249.34.1 { weight 10; interface reth0.34 secondary-ip-address 128.249.34.202; } } } } } } }
Verwenden eines ordnungsgemäßen Neustarts
Bei Routing-Protokollen erfordert jede Dienstunterbrechung, dass ein betroffener Router die Nachbarschaft zu benachbarten Routern neu berechnet, Routing-Tabelleneinträge wiederherstellt und andere protokollspezifische Informationen aktualisiert. Ein ungeschützter Neustart eines Routers kann zu Weiterleitungsverzögerungen, Routen-Flapping, Wartezeiten aufgrund von Protokollrekonvergenz und sogar zu Paketverlusten führen. Die Hauptvorteile eines ordnungsgemäßen Neustarts sind die unterbrechungsfreie Paketweiterleitung und die vorübergehende Unterdrückung aller Routingprotokollaktualisierungen. Ein ordnungsgemäßer Neustart ermöglicht es einem Router, Zwischenkonvergenzzustände zu durchlaufen, die für den Rest des Netzwerks verborgen sind.
Auf den Routing-Plattformen von Juniper Networks stehen drei Haupttypen für einen ordnungsgemäßen Neustart zur Verfügung:
Graceful-Restart für aggregierte und statische Routen und für Routing-Protokolle: Bietet Schutz für aggregierte und statische Routen sowie für BGP-, End System-to-Intermediate System (ES-IS), IS-IS, OSPF, RIP, RIPng (Next-Generation RIP) und Protocol Independent Multicast (PIM) Sparse-Mode-Routing-Protokolle.
Graceful-Restart für MPLS-bezogene Protokolle: Bietet Schutz für LDP, RSVP, Circuit Cross-Connect (CCC) und Translational Cross-Connect (TCC).
Graceful Restart for Virtual Private Networks (VPNs) – Bietet Schutz für Layer-2- und Layer-3-VPNs.