Konfigurieren von Cluster-Failover-Parametern
Geräte der SRX-Serie in einem Gehäuse-Cluster verwenden Heartbeat-Übertragungen, um den "Zustand" der Steuerverbindung zu bestimmen. Wenn die Anzahl der verpassten Takte den konfigurierten Schwellenwert erreicht hat, prüft das System, ob eine Fehlerbedingung vorliegt. Weitere Informationen finden Sie in den folgenden Themen:
Grundlegendes zu Heartbeats, Ausfällen und Wiederherstellungen der Chassis-Cluster-Steuerung
- Grundlegendes zu Gehäuse-Cluster-Steuerungslink-Heartbeats
- Grundlegendes zu Fehlern und Wiederherstellungen bei der Chassis-Cluster-Steuerverbindung
Grundlegendes zu Gehäuse-Cluster-Steuerungslink-Heartbeats
Sie geben den Heartbeat-Schwellenwert und das Heartbeat-Intervall an, wenn Sie den Chassis-Cluster konfigurieren.
Das System überwacht standardmäßig den Status der Steuerverbindung.
Bei dualen Steuerverbindungen, die auf SRX5600- und SRX5800-Leitungen unterstützt werden, sendet und empfängt der Juniper Services Redundancy Protocol-Prozess (jsrpd) die Steuertaktmeldungen auf beiden Steuerlinks. Solange Taktsignale auf einer der Steuerverbindungen empfangen werden, betrachtet Junos OS den anderen Knoten als aktiv.
Das Produkt aus Option heartbeat-threshold und Option heartbeat-interval definiert die Wartezeit, bevor ein Failover ausgelöst wird. Die Standardwerte dieser Optionen führen zu einer Wartezeit von 3 Sekunden. Bei einem Heartbeat-Schwellenwert von 5 und einem Heartbeat-Intervall von 1000 Millisekunden ergibt sich eine Wartezeit von 5 Sekunden. Wenn Sie den Heartbeat-Schwellenwert auf 4 und das Heartbeat-Intervall auf 1250 Millisekunden festlegen, ergibt sich ebenfalls eine Wartezeit von 5 Sekunden.
Wenn in einer Chassis-Cluster-Umgebung mehr als 1000 logische Schnittstellen verwendet werden, wird empfohlen, die Taktgeber des Clusters von der Standardeinstellung von 3 Sekunden zu erhöhen. Bei maximaler Kapazität auf einer SRX4600-, SRX5400-, SRX5600- oder SRX5800-Firewall empfehlen wir, die konfigurierte Zeit vor dem Failover auf mindestens 5 Sekunden zu erhöhen.
Grundlegendes zu Fehlern und Wiederherstellungen bei der Chassis-Cluster-Steuerverbindung
Wenn die Steuerverbindung ausfällt, ändert Junos OS den Betriebszustand des sekundären Knotens in "Nicht berechtigt" für einen 180-Sekunden-Countdown. Wenn der Fabric-Link während der 180 Sekunden ebenfalls fehlschlägt, ändert Junos OS den sekundären Knoten in den primären. Andernfalls ändert sich der Status des sekundären Knotens nach 180 Sekunden in Deaktiviert.
Wenn die Steuerverbindung ausgefallen ist, wird eine Systemprotokollmeldung generiert.
Ein Fehler bei der Steuerverbindung ist definiert als der Empfang von Taktsignalen über die Steuerverbindung, während weiterhin Frequenzschläge über die Fabric-Verbindung empfangen werden.
Im Falle eines Ausfalls einer legitimen Steuerverbindung bleibt die Redundanzgruppe 0 auf dem Knoten, auf dem sie sich derzeit befindet, primär, die inaktiven Redundanzgruppen x auf dem primären Knoten werden aktiv, und der sekundäre Knoten wechselt in einen deaktivierten Zustand.
Wenn der sekundäre Knoten deaktiviert ist, können Sie sich weiterhin am Verwaltungsport anmelden und die Diagnose ausführen.
Um festzustellen, ob ein legitimer Fehler in der Steuerverbindung aufgetreten ist, stützt sich das System auf redundante Lebendigkeitssignale, die sowohl über die Steuerverbindung als auch über die Fabric-Verbindung gesendet werden.
Das System überträgt in regelmäßigen Abständen Sonden über die Fabric-Verbindung und Heartbeat-Signale über die Steuerverbindung. Sondierungen und Heartbeatsignale haben eine gemeinsame Sequenznummer, die sie einem eindeutigen Zeitereignis zuordnet. Junos OS identifiziert einen Fehler einer legitimen Steuerverbindung, wenn die folgenden beiden Bedingungen erfüllt sind:
Die Schwellenwertzahl der Herzschläge ging verloren.
Mindestens eine Sondierung mit einer Sequenznummer, die der eines fehlenden Heartbeat-Signals entspricht, wurde auf der Fabric-Verbindung empfangen.
Wenn die Steuerverbindung ausfällt, beginnt der 180-Sekunden-Countdown, und der Status des sekundären Knotens ist nicht zulässig. Wenn die Fabric-Verbindung ausfällt, bevor der 180-Sekunden-Countdown Null erreicht, wird der sekundäre Knoten zum primären Knoten, da der Verlust beider Verbindungen vom System so interpretiert wird, dass der andere Knoten tot ist. Da der gleichzeitige Verlust von Kontroll- und Fabric-Verbindungen dazu führt, dass die Knoten keine Zustände mehr synchronisieren und keine Prioritäten mehr vergleichen, können beide Knoten vorübergehend zu primären Knoten werden, was kein stabiler Betriebszustand ist. Sobald die Steuerverbindung jedoch wiederhergestellt ist, wird der Knoten mit dem höheren Prioritätswert automatisch zum primären Knoten, der andere Knoten zum sekundären Knoten, und der Cluster kehrt zum normalen Betrieb zurück.
Wenn ein legitimer Fehler in der Steuerverbindung auftritt, gelten die folgenden Bedingungen:
Redundanzgruppe 0 bleibt primär auf dem Knoten, auf dem sie sich derzeit befindet (und daher bleibt ihre Routing-Engine aktiv), und alle Redundanzgruppen x auf dem Knoten werden primär.
Wenn das System nicht ermitteln kann, welche Routing-Engine primär ist, ist der Knoten mit dem höheren Prioritätswert für die Redundanzgruppe 0 primär und seine Routing-Engine ist aktiv. (Sie konfigurieren die Priorität für jeden Knoten, wenn Sie die Anweisung für die
redundancy-groupRedundanzgruppe 0 konfigurieren.)Das System deaktiviert den sekundären Knoten.
Um ein Gerät aus dem deaktivierten Modus wiederherzustellen, müssen Sie das Gerät neu starten. Wenn Sie den deaktivierten Knoten neu starten, synchronisiert der Knoten seinen dynamischen Zustand mit dem primären Knoten.
Wenn Sie Änderungen an der Konfiguration vornehmen, während der sekundäre Knoten deaktiviert ist, führen Sie den Befehl commit aus, um die Konfiguration nach dem Neustart des Knotens zu synchronisieren. Wenn Sie keine Konfigurationsänderungen vorgenommen haben, bleibt die Konfigurationsdatei mit der des primären Knotens synchronisiert.
Sie können die vorzeitige Trennung für Redundanzgruppe 0 nicht aktivieren. Wenn Sie den primären Knoten für die Redundanzgruppe 0 ändern möchten, müssen Sie ein manuelles Failover durchführen.
Beachten Sie bei der Verwendung von dualen Steuerverbindungen (unterstützt auf SRX5600- und SRX5800-Geräten) die folgenden Bedingungen:
Der eingehende oder ausgehende Datenverkehr des Hosts kann während eines Ausfalls der Steuerverbindung bis zu 3 Sekunden lang beeinträchtigt werden. Stellen Sie sich beispielsweise einen Fall vor, in dem die Redundanzgruppe 0 auf Knoten 0 primär ist und über einen Netzwerkschnittstellenport auf Knoten 1 eine Telnet-Sitzung mit der Routing-Engine besteht. Wenn die derzeit aktive Steuerverbindung ausfällt, verliert die Telnet-Sitzung 3 Sekunden lang Pakete, bis dieser Fehler erkannt wird.
Ein Fehler bei der Steuerverbindung, der auftritt, während der Commit-Prozess über zwei Knoten ausgeführt wird, kann zu einem Commit-Fehler führen. Führen Sie in diesem Fall den Commit-Befehl nach 3 Sekunden erneut aus.
Für SRX5600- und SRX5800 Geräte erfordern duale Steuerverbindungen eine zweite Routing-Engine auf jedem Knoten des Gehäuse-Clusters.
Sie können festlegen, dass die Wiederherstellung der Steuerverbindung automatisch vom System durchgeführt wird, indem Sie die control-link-recovery Anweisung setzen. Sobald das System in diesem Fall feststellt, dass die Steuerverbindung fehlerfrei ist, gibt es einen automatischen Neustart auf dem deaktivierten Knoten aus. Wenn der deaktivierte Knoten neu gestartet wird, tritt der Knoten dem Cluster erneut bei.
Beispiel: Konfigurieren der Wiederherstellung von Chassis-Cluster-Steuerungsverbindungen
In diesem Beispiel wird gezeigt, wie Sie die Wiederherstellung der Steuerverbindung aktivieren, die es dem System ermöglicht, die Wiederherstellung der Steuerverbindung nach einem Ausfall automatisch zu übernehmen.
Anforderungen
Bevor Sie beginnen:
Grundlegendes zu den Steuerverbindungen von Gehäuse-Clustern. Weitere Informationen finden Sie unter Grundlegendes zu Chassis-Clustern, Steuerungsebene und Steuerlinks.
Grundlegendes zu den dualen Steuerverbindungen von Gehäuse-Clustern. Weitere Informationen finden Sie unter Grundlegendes zu dualen Steuerverbindungen von Gehäuse-Clustern.
Verbinden Sie zwei Steuerverbindungen in einem Gehäuse-Cluster. Weitere Informationen finden Sie unter Dual-Control-Link-Verbindungen für Firewalls der SRX-Serie in einem Gehäuse-Cluster.
Überblick
Sie können das System so aktivieren, dass die Wiederherstellung der Steuerverbindung automatisch durchgeführt wird. Nachdem die Steuerverbindung wiederhergestellt wurde, führt das System die folgenden Aktionen aus:
Er prüft, ob er mindestens drei aufeinanderfolgende Heartbeats auf der Steuerverbindung empfängt oder, im Falle von dualen Steuerverbindungen (nur SRX5600 und SRX5800 Geräte), auf einer der Steuerverbindungen. Dadurch soll sichergestellt werden, dass die Steuerverbindung nicht flattert und fehlerfrei ist.
Nachdem festgestellt wurde, dass die Steuerverbindung fehlerfrei ist, gibt das System einen automatischen Neustart aus, unabhängig davon, in welchem Zustand sich der Knoten befindet (nicht geeignet oder deaktiviert), wenn die Steuerverbindung fehlgeschlagen ist. Wenn der Knoten neu gestartet wird, kann er dem Cluster erneut beitreten. Ein manueller Eingriff ist nicht erforderlich.
In diesem Beispiel aktivieren Sie die Wiederherstellung der Chassis-Cluster-Steuerverbindung.
Konfiguration
Verfahren
Schritt-für-Schritt-Anleitung
So aktivieren Sie Chassis-Cluster Control-Link-Recovery:
Aktivieren Sie die Wiederherstellung der Steuerverbindung.
{primary:node0}[edit] user@host# set chassis cluster control-link-recoveryWenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
{primary:node0}[edit] user@host# commit