Failover der Chassis-Cluster-Redundanzgruppe

Der Chassis-Cluster verwendet eine Reihe hocheffizienter Failover-Mechanismen , die eine hohe Verfügbarkeit fördern, um die allgemeine Zuverlässigkeit und Produktivität Ihres Systems zu erhöhen.

Eine Redundanzgruppe ist eine Sammlung von Objekten, für die als Gruppe ein Failover ausgeführt wird. Jede Redundanzgruppe überwacht eine Gruppe von Objekten (physische Schnittstellen), und jedem überwachten Objekt wird eine Gewichtung zugewiesen. Jede Redundanzgruppe hat einen anfänglichen Schwellenwert von 255. Wenn ein überwachtes Objekt ausfällt, wird die Gewichtung des Objekts vom Schwellenwert der Redundanzgruppe subtrahiert. Wenn der Schwellenwert Null erreicht, führt die Redundanzgruppe ein Failover auf den anderen Knoten durch. Dies hat zur Folge, dass für alle Objekte, die der Redundanzgruppe zugeordnet sind, ebenfalls ein Failover ausgeführt wird. Ein ordnungsgemäßer Neustart der Routing-Protokolle ermöglicht es der Firewall der SRX-Serie, die Unterbrechung des Datenverkehrs während eines Failovers zu minimieren.

Back-to-Back-Failover einer Redundanzgruppe in einem kurzen Intervall können dazu führen, dass der Cluster ein unvorhersehbares Verhalten aufweist. Um ein solches unvorhersehbares Verhalten zu verhindern, konfigurieren Sie eine Dämpfungszeit zwischen den Failovern. Bei einem Failover wechselt der vorherige primäre Knoten einer Redundanzgruppe in den sekundären Haltestatus und bleibt im sekundären Haltebereich, bis das Halteintervall abläuft. Nach Ablauf des Halteintervalls wechselt der vorherige primäre Knoten in den sekundären Zustand.

Durch die Konfiguration des Halteintervalls wird verhindert, dass innerhalb der Dauer des Halteintervalls aufeinanderfolgende Failover auftreten.

Das Halteintervall wirkt sich sowohl auf manuelle Failover als auch auf automatische Failover im Zusammenhang mit Überwachungsfehlern aus.

Die standardmäßige Dämpfungszeit für eine Redundanzgruppe 0 beträgt 300 Sekunden (5 Minuten) und kann mit der hold-down-interval Anweisung auf bis zu 1800 Sekunden konfiguriert werden. Bei einigen Konfigurationen, z. B. mit einer großen Anzahl von Routen oder logischen Schnittstellen, ist das Standardintervall oder das vom Benutzer konfigurierte Intervall möglicherweise nicht ausreichend. In solchen Fällen verlängert das System automatisch die Dämpfungszeit in Schritten von 60 Sekunden, bis das System für ein Failover bereit ist.

Redundanzgruppen (Redundanzgruppen x mit den Nummern 1 bis 128) haben eine standardmäßige Dämpfungszeit von 1 Sekunde mit einem Bereich von 0 bis 1800 Sekunden.

Bei Firewalls der SRX-Serie ist die Failover-Leistung des Chassis-Clusters für die Skalierung mit logischeren Schnittstellen optimiert. Bisher wurde während des Failovers der Redundanzgruppe unentgeltliches ARP (GARP) vom Juniper Services Redundancy Protocol (jsrpd)-Prozess gesendet, der in der Routing-Engine auf jeder logischen Schnittstelle ausgeführt wird, um den Datenverkehr zum entsprechenden Knoten zu leiten. Bei der Skalierung der logischen Schnittstelle wird die Routing-Engine zum Prüfpunkt, und GARP wird direkt von der Services Processing Unit (SPU) gesendet.

Timer für präventive Failover-Verzögerung

Eine Redundanzgruppe befindet sich auf einem Knoten im primären Zustand (aktiv) und auf dem anderen Knoten im sekundären Zustand (Backup).

Sie können das präemptive Verhalten auf beiden Knoten in einer Redundanzgruppe aktivieren und jedem Knoten in der Redundanzgruppe einen Prioritätswert zuweisen. Der Knoten in der Redundanzgruppe mit der höheren konfigurierten Priorität wird zunächst als primärer Knoten in der Gruppe und der andere Knoten zunächst als sekundärer Knoten in der Redundanzgruppe festgelegt.

Wenn eine Redundanzgruppe den Zustand ihrer Knoten zwischen primärem und sekundärem Knoten tauscht, besteht die Möglichkeit, dass ein nachfolgender Zustandsaustausch ihrer Knoten kurz nach dem ersten Zustandsaustausch erneut erfolgen kann. Dieser schnelle Zustandswechsel führt zu einem Flattern des Primär- und Sekundärsystems.

Ab Junos OS Version 17.4R1 wird bei Firewalls der SRX-Serie in einem Chassis-Cluster ein Timer für die Failover-Verzögerung eingeführt, um das Flattern des Redundanzgruppenstatus zwischen dem sekundären und dem primären Knoten bei einem präemptiven Failover zu begrenzen.

Um das Flattern zu verhindern, können Sie die folgenden Parameter konfigurieren:

• Präemptive Verzögerung – Die präemptive Verzögerungszeit ist die Zeitspanne, die eine Redundanzgruppe in einem sekundären Zustand wartet, wenn der primäre Zustand in einem präemptiven Failover ausgefallen ist, bevor sie in den primären Zustand wechselt. Dieser Verzögerungstimer verzögert das sofortige Failover für einen konfigurierten Zeitraum zwischen 1 und 21.600 Sekunden.

• Präemptiver Grenzwert: Der präemptive Grenzwert schränkt die Anzahl der präemptiven Failover (zwischen 1 und 50) während eines konfigurierten präemptiven Zeitraums ein, wenn preemption er für eine Redundanzgruppe aktiviert ist.

• Präemptiver Zeitraum: Zeitraum (1 bis 1440 Sekunden), in dem der Preemptive Limit angewendet wird, d. h. die Anzahl der konfigurierten präemptiven Failover, die angewendet werden, wenn Preempt für eine Redundanzgruppe aktiviert ist.

Stellen Sie sich das folgende Szenario vor, in dem Sie einen präemptiven Zeitraum auf 300 Sekunden und ein präemptives Limit auf 50 konfiguriert haben.

Wenn der präemptive Grenzwert auf 50 konfiguriert ist, beginnt die Anzahl bei 0 und erhöht sich mit einem ersten präemptiven Failover. Dieser Vorgang wird fortgesetzt, bis die Anzahl den konfigurierten präemptiven Grenzwert erreicht, d. h. 50, bevor der präemptive Zeitraum abläuft. Wenn der präemptive Grenzwert (50) überschritten wird, müssen Sie die Anzahl der präemptiven Failover manuell zurücksetzen, damit präemptive Failover erneut auftreten können.

Wenn Sie den präemptiven Zeitraum auf 300 Sekunden konfiguriert haben und wenn der Zeitunterschied zwischen dem ersten präemptiven Failover und dem aktuellen Failover bereits 300 Sekunden überschritten hat und der präemptive Grenzwert (50) noch nicht erreicht ist, wird der präemptive Zeitraum zurückgesetzt. Nach dem Zurücksetzen wird das letzte Failover als erstes präemptives Failover des neuen präemptiven Zeitraums betrachtet, und der Prozess beginnt von vorne.

Die präemptive Verzögerung kann unabhängig von der Failover-Grenze konfiguriert werden. Durch die Konfiguration des Timers für die präventive Verzögerung wird das vorhandene präventive Verhalten nicht geändert.

Diese Erweiterung ermöglicht es dem Administrator, eine Failover-Verzögerung einzuführen, die die Anzahl der Failover reduzieren und zu einem stabileren Netzwerkstatus führen kann, da das aktive /Standby-Flapping innerhalb der Redundanzgruppe reduziert wird.

• Grundlegendes zum Übergang vom primären zum sekundären Zustand mit präemptiver Verzögerung
• Konfigurieren des Timers für präventive Verzögerungen

Grundlegendes zum Übergang vom primären zum sekundären Zustand mit präemptiver Verzögerung

Betrachten Sie das folgende Beispiel, in dem eine Redundanzgruppe, die primär auf dem Knoten 0 ist, während eines Failovers für den präventiven Übergang in den sekundären Zustand bereit ist. Jedem Knoten wird eine Priorität zugewiesen und die Option ist auch für die preemptive Knoten aktiviert.

Abbildung 1 veranschaulicht die Abfolge der Schritte beim Übergang vom primären zum sekundären Zustand, wenn ein Timer für die präventive Verzögerung konfiguriert ist.

Abbildung 1: Übergang vom primären zum sekundären Zustand mit präemptiver Verzögerung

1. Der Knoten im primären Zustand ist bereit für den präventiven Übergang in den sekundären Zustand, wenn die Option konfiguriert ist und der Knoten im sekundären Zustand die preemptive Priorität vor dem Knoten im primären Zustand hat. Wenn die präemptive Verzögerung konfiguriert ist, wechselt der Knoten im primären Zustand in den primären Preempt-Hold-Zustand. Wenn die präemptive Verzögerung nicht konfiguriert ist, erfolgt ein sofortiger Übergang in den sekundären Zustand.

2. Der Knoten befindet sich im Status "Primary Preempt-Hold" und wartet darauf, dass der Timer für die präventive Verzögerung abläuft. Der Timer für die präventive Verzögerung wird überprüft, und der Übergang wird angehalten, bis der Timer abläuft. Der primäre Knoten verbleibt bis zum Ablauf des Timers im Status "Primary Preempt-Hold", bevor er in den sekundären Zustand übergeht.

3. Der Knoten wechselt vom primären Preempt-Hold-Zustand in den sekundären Hold-Zustand und dann in den sekundären Zustand.

4. Der Knoten bleibt für die Standardzeit (1 Sekunde) oder die konfigurierte Zeit (mindestens 300 Sekunden) im sekundären Hold-Zustand, und dann wechselt der Knoten in den sekundären Zustand.

Wenn Ihr Chassis-Cluster-Setup eine ungewöhnliche Anzahl von Landeklappen aufweist, müssen Sie Ihre Verbindungs- und Überwachungstimer überprüfen, um sicherzustellen, dass sie richtig eingestellt sind. Seien Sie vorsichtig, wenn Sie Timer in Netzwerken mit hoher Latenz einstellen, um Fehlalarme zu vermeiden.

Konfigurieren des Timers für präventive Verzögerungen

In diesem Thema wird erläutert, wie der Verzögerungstimer bei Firewalls der SRX-Serie in einem Chassis-Cluster konfiguriert wird. Back-to-Back-Redundanzgruppen-Failovers, die zu schnell erfolgen, können dazu führen, dass ein Chassis-Cluster ein unvorhersehbares Verhalten aufweist. Durch die Konfiguration des Verzögerungstimers und der Begrenzung der Failoverrate wird das sofortige Failover für einen konfigurierten Zeitraum verzögert.

So konfigurieren Sie den Timer für die präventive Verzögerung und die Begrenzung der Failover-Rate zwischen Redundanzgruppen-Failovern:

1. Aktivieren Sie ein präemptives Failover für eine Redundanzgruppe.

   Sie können den Verzögerungstimer zwischen 1 und 21.600 Sekunden einstellen. Der Standardwert ist 1 Sekunde.

2. Richten Sie einen Grenzwert für das präemptive Failover ein.

   Sie können die maximale Anzahl von präemptiven Failovern zwischen 1 und 50 und den Zeitraum, in dem der Grenzwert angewendet wird, zwischen 1 und 1440 Sekunden festlegen.

Im folgenden Beispiel legen Sie den Timer für die präemptive Verzögerung auf 300 Sekunden und den Grenzwert für die präemptive Verzögerung auf 10 für einen Zeitraum von 600 Sekunden fest. Das heißt, diese Konfiguration verzögert das sofortige Failover um 300 Sekunden und begrenzt maximal 10 präemptive Failover in einer Dauer von 600 Sekunden.

Sie können den Befehl verwenden, um den clear chassis clusters preempt-count Failover-Zähler für vorzeitiges Entfernen für alle Redundanzgruppen zu löschen. Wenn ein Preempt-Limit konfiguriert ist, beginnt der Zähler mit einem ersten präemptiven Failover, und die Anzahl wird reduziert. Dieser Vorgang wird fortgesetzt, bis der Zähler Null erreicht, bevor der Timer abläuft. Sie können diesen Befehl verwenden, um den Failover-Zähler für die Vorabschaltung zu löschen und ihn zurückzusetzen, um ihn erneut zu starten.

Sie können ein Failover der Redundanzgruppe x (Redundanzgruppen mit den Nummern 1 bis 128) manuell initiieren. Ein manuelles Failover wird angewendet, bis ein Failback-Ereignis eintritt.

Angenommen, Sie führen manuell ein Failover der Redundanzgruppe 1 von Knoten 0 zu Knoten 1 durch. Dann fällt eine Schnittstelle, die von Redundanzgruppe 1 überwacht wird, aus, wodurch der Schwellenwert der neuen primären Redundanzgruppe auf Null zurückgesetzt wird. Dieses Ereignis wird als Failback-Ereignis betrachtet, und das System gibt die Steuerung an die ursprüngliche Redundanzgruppe zurück.

Sie können ein Failover der Redundanzgruppe 0 auch manuell initiieren, wenn Sie den primären Knoten für Redundanzgruppe 0 ändern möchten. Sie können die vorzeitige Entfernung für Redundanzgruppe 0 nicht aktivieren.

Wenn preempt zu einer Redundanzgruppenkonfiguration hinzugefügt wird, kann das Gerät mit der höheren Priorität in der Gruppe ein Failover initiieren, um primär zu werden. Standardmäßig ist die vorzeitige Entfernung deaktiviert. Weitere Informationen zur Voreinstellung finden Sie unter preempt (Chassis-Cluster).

Wenn Sie ein manuelles Failover für die Redundanzgruppe 0 durchführen, wechselt der Knoten im primären Zustand in den sekundären Hold-Zustand. Der Knoten verbleibt für die standardmäßige oder konfigurierte Zeit (mindestens 300 Sekunden) im sekundären Haltezustand und wechselt dann in den sekundären Zustand.

Zustandsübergänge in Fällen, in denen sich ein Knoten im sekundären Hold-Zustand befindet und der andere Knoten neu gestartet wird oder die Control-Link- oder Fabric-Link-Verbindung zu diesem Knoten verloren geht, werden wie folgt beschrieben:

• Neustartfall: Der Knoten im sekundären Haltezustand geht in den primären Zustand über. Der andere Knoten ist tot (inaktiv).

• Fall eines Ausfalls der Steuerungsverbindung: Der Knoten im Status "Secondary Hold" wechselt in den nicht zulässigen Zustand und dann in den deaktivierten Zustand. Der andere Knoten wechselt in den primären Zustand.

• Ausfall der Fabric-Verbindung: Der Knoten im Status "Secondary Hold" wechselt direkt in den nicht zulässigen Zustand.

  Ab Junos OS Version 12.1X46-D20 und Junos OS Version 17.3R1 ist die Fabric-Überwachung standardmäßig aktiviert. Mit dieser Aktivierung wechselt der Knoten bei Ausfällen der Fabric-Verbindung direkt in den nicht zulässigen Zustand.

  Ab Junos OS Version 12.1X47-D10 und Junos OS Version 17.3R1 ist die Fabric-Überwachung standardmäßig aktiviert. Mit dieser Aktivierung wechselt der Knoten bei Ausfällen der Fabric-Verbindung direkt in den nicht zulässigen Zustand.

Beachten Sie, dass während eines In-Service-Softwareupgrades (In-Service Software Upgrade, ISSU) die hier beschriebenen Übergänge nicht stattfinden können. Stattdessen geht der andere (primäre) Knoten direkt in den sekundären Zustand über, da Juniper Networks-Versionen vor 10.0 den sekundären Haltestatus nicht interpretieren. Wenn beim Starten einer ISSU einer der Knoten über eine oder mehrere Redundanzgruppen im sekundären Haltestatus verfügt, müssen Sie warten, bis sie in den sekundären Zustand übergegangen sind, bevor Sie manuelle Failover durchführen können, um alle Redundanzgruppen auf einem Knoten als primär zu machen.

Seien Sie vorsichtig und umsichtig bei der Verwendung manueller Failover der Redundanzgruppe 0. Ein Failover der Redundanzgruppe 0 impliziert ein Routing-Engine-Failover, in diesem Fall werden alle Prozesse, die auf dem primären Knoten ausgeführt werden, beendet und dann auf der neuen primären Routing-Engine erzeugt. Dieses Failover kann zu einem Verlust des Zustands, z. B. des Routingstatus, führen und die Leistung durch Systemänderung beeinträchtigen.

In einigen Junos OS-Versionen ist es für Redundanzgruppen xmöglich, ein manuelles Failover auf einem Knoten mit der Priorität 0 durchzuführen. Es wird empfohlen, dass Sie den show chassis cluster status Befehl verwenden, um die Knotenprioritäten der Redundanzgruppe zu überprüfen, bevor Sie das manuelle Failover durchführen. Ab den Junos OS-Versionen 12.1X44-D25, 12.1X45-D20, 12.1X46-D10 und 12.1X47-D10 und höher wurde der Bereitschaftsprüfungsmechanismus für manuelles Failover jedoch erweitert, um restriktiver zu sein, sodass Sie das manuelle Failover nicht auf einen Knoten in einer Redundanzgruppe mit der Priorität 0 festlegen können. Diese Verbesserung verhindert, dass Datenverkehr unerwartet aufgrund eines Failover-Versuchs auf einen Knoten der Priorität 0 verworfen wird, der nicht bereit ist, Datenverkehr anzunehmen.

In diesem Beispiel wird gezeigt, wie die Dämpfungszeit zwischen aufeinanderfolgenden Redundanzgruppen-Failovers für einen Chassis-Cluster konfiguriert wird. Back-to-Back-Redundanzgruppen-Failovers, die zu schnell erfolgen, können dazu führen, dass ein Chassis-Cluster ein unvorhersehbares Verhalten aufweist.

Chassis-Clustering unterstützt SNMP-Traps, die bei jedem Failover einer Redundanzgruppe ausgelöst werden.

Die Trap-Meldung kann Ihnen bei der Fehlerbehebung bei Failovern helfen. Es enthält die folgenden Informationen:

• Die Cluster-ID und die Knoten-ID

• Der Grund für das Failover

• Die Redundanzgruppe, die am Failover beteiligt ist

• Vorheriger Status und aktueller Status der Redundanzgruppe

Dies sind die verschiedenen Zustände, in denen sich ein Cluster zu einem bestimmten Zeitpunkt befinden kann: "Hold", "Primär", "Sekundär", "Sekundär", "Nicht geeignet" und "Deaktiviert". Traps werden für die folgenden Zustandsübergänge generiert (nur ein Übergang aus einem Hold-Zustand löst keinen Trap aus):

• Primäre <–> Sekundarstufe

• primär – > sekundärer Haltebereich

• sekundärer Haltebereich – > sekundär

• sekundär – > nicht förderfähig

• Nicht förderfähig – > Behinderte

• Nicht förderfähig – > Grundschule

• sekundär – > deaktiviert

Ein Übergang kann aufgrund eines beliebigen Ereignisses ausgelöst werden, z. B. durch Schnittstellenüberwachung, SPU-Überwachung, Fehler und manuelle Failover.

Der Trap wird über die Steuerverbindung weitergeleitet, wenn sich die ausgehende Schnittstelle auf einem anderen Knoten befindet als der Knoten der Routing-Engine, die den Trap generiert.

Sie können angeben, dass ein Ablaufverfolgungsprotokoll generiert werden soll, indem Sie die traceoptions flag snmp Anweisung festlegen.

• Zweck
• Aktion