Konfigurieren von Cluster-Failover-Parametern
Geräte der SRX-Serie in einem Gehäuse-Cluster verwenden Herzschlagübertragungen, um den "Zustand" der Steuerverbindung zu bestimmen. Wenn die Anzahl der verpassten Herzschläge den konfigurierten Schwellenwert erreicht hat, bewertet das System, ob eine Fehlerbedingung vorliegt. Weitere Informationen finden Sie in den folgenden Themen:
Grundlegendes zu Chassis Cluster Control Link Heartbeats, Failure und Recovery
- Grundlegendes zu Chassis Cluster Control Link Heartbeats
- Grundlegendes zum Ausfall und zur Wiederherstellung von Chassis-Cluster-Steuerungslinks
Grundlegendes zu Chassis Cluster Control Link Heartbeats
Sie geben bei der Konfiguration des Gehäuseclusters den Schwellenwert für den Herzschlag und das Taktintervall an.
Standardmäßig überwacht das System den Status der Steuerverbindung.
Für Dual-Control-Links, die auf SRX5600- und SRX5800-Zeilen unterstützt werden, sendet und empfängt der Juniper Services Redundanz-Protokollprozess (jsrpd) die Control Heartbeat-Nachrichten auf beiden Steuerlinks. Solange Herzschläge auf einer der Steuerlinks empfangen werden, betrachtet Junos OS den anderen Knoten als am Leben.
Das Produkt der heartbeat-threshold
Option und die heartbeat-interval
Option definiert die Wartezeit, bevor ein Failover ausgelöst wird. Die Standardwerte dieser Optionen erzeugen eine Wartezeit von 3 Sekunden. Eine Herzschlagschwelle von 5 und ein Herzschlagintervall von 1000 Millisekunden würden eine Wartezeit von 5 Sekunden ergeben. Wenn sie den Schwellenwert für den Herzschlag auf 4 und das Herzschlagintervall auf 1250 Millisekunden setzen, würde sich ebenfalls eine Wartezeit von 5 Sekunden ergeben.
Wenn in einer Gehäuse-Cluster-Umgebung mehr als 1000 logische Schnittstellen verwendet werden, wird empfohlen, die Cluster-Herzschlag-Timer von der Standardeinstellung von 3 Sekunden zu erhöhen. Bei maximaler Kapazität auf einem SRX4600, SRX5400, SRX5600 oder einem SRX5800 Gerät empfehlen wir, die konfigurierte Zeit vor dem Failover auf mindestens 5 Sekunden zu erhöhen.
Grundlegendes zum Ausfall und zur Wiederherstellung von Chassis-Cluster-Steuerungslinks
Wenn die Steuerungsverbindung ausfällt, ändert Junos OS den Betriebszustand des sekundären Knotens, um für einen Countdown von 180 Sekunden nicht berechtigt zu sein. Wenn die Fabric-Verbindung während der 180 Sekunden ebenfalls fehlschlägt, ändert Junos OS den sekundären Knoten in den primären; andernfalls ändert sich nach 180 Sekunden der sekundäre Knotenstatus in deaktiviert.
Wenn die Steuerungsverbindung ausfällt, wird eine Systemprotokollmeldung generiert.
Ein Control Link Failure wird definiert, dass keine Herzschläge über die Steuerverbindung empfangen werden, während die Herzschläge immer noch über den Fabric-Link empfangen werden.
Im Falle eines Legitimierungsfehlers bleibt die Redundanzgruppe 0 primär auf dem Knoten, auf dem sie sich derzeit als primärer Knoten befindet, die inaktive Redundanzgruppen x auf dem primären Knoten werden aktiv, und der sekundäre Knoten tritt in einen deaktivierten Zustand ein.
Wenn der sekundäre Knoten deaktiviert ist, können Sie sich weiterhin am Management-Port anmelden und eine Diagnose ausführen.
Um festzustellen, ob ein legitimer Control Link-Ausfall aufgetreten ist, verlässt sich das System auf redundante Liveline-Signale, die sowohl über die Steuerverbindung als auch über die Fabric-Verbindung gesendet werden.
Das System überträgt regelmäßig Sondierungen über den Fabric-Link und Herzschlagsignale über den Steuerlink. Sondierungen und Herzschlagsignale teilen eine gemeinsame Sequenznummer, die sie einem einzigartigen Zeitereignis ordnet. Junos OS identifiziert einen legitimen Control Link-Fehler, wenn die folgenden zwei Bedingungen vorhanden sind:
Die Schwellzahl der Herzschläge ging verloren.
Mindestens eine Probe mit einer Sequenznummer, die der eines fehlenden Herzschlagsignals entspricht, wurde auf dem Fabric-Link empfangen.
Wenn die Steuerungsverbindung fehlschlägt, beginnt der Countdown von 180 Sekunden und der Status des sekundären Knotens ist nicht berechtigt. Wenn der Fabric-Link fehlschlägt, bevor der Countdown von 180 Sekunden null erreicht, wird der sekundäre Knoten zum Primären, weil der Verlust beider Verbindungen vom System interpretiert wird, um anzuzeigen, dass der andere Knoten tot ist. Da der gleichzeitige Verlust von Steuerungs- und Fabric-Verbindungen bedeutet, dass die Knoten nicht mehr Zustände synchronisieren oder Prioritäten vergleichen, können beide Knoten vorübergehend zu primären Knoten werden, was kein stabiler Betriebszustand ist. Sobald die Steuerverbindung erneut hergestellt wird, wird der Knoten mit dem höheren Prioritätswert automatisch primär, der andere Knoten wird sekundär, und der Cluster kehrt zum normalen Betrieb zurück.
Wenn ein legitimer Steuerungslink-Fehler auftritt, gelten die folgenden Bedingungen:
Redundanzgruppe 0 bleibt primär auf dem Knoten, auf dem sie sich derzeit als primärer Knoten befindet (und somit bleibt die Routing-Engine aktiv), und alle Redundanzgruppen x auf dem Knoten werden primär.
Wenn das System nicht feststellen kann, welche Routing-Engine primär ist, ist der Knoten mit dem höheren Prioritätswert für Redundanzgruppe 0 primär und seine Routing-Engine aktiv. (Sie konfigurieren die Priorität für jeden Knoten, wenn Sie die
redundancy-group
Anweisung für Redundanzgruppe 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 Datei des Primären Knotens synchronisiert.
Sie können die Preemption für Redundanzgruppe 0 nicht aktivieren. Wenn Sie den primären Knoten für Redundanzgruppe 0 ändern möchten, müssen Sie ein manuelles Failover durchführen.
Wenn Sie Dual-Control-Links verwenden (die auf SRX5600- und SRX5800-Geräten unterstützt werden), beachten Sie die folgenden Bedingungen:
Der eingehende oder ausgehende Host-Datenverkehr kann während eines Ausfalls der Steuerungsverbindung für bis zu 3 Sekunden beeinträchtigt werden. Beispiel: Redundanzgruppe 0 ist primär auf Knoten 0 und es gibt eine Telnet-Sitzung zur Routing-Engine über einen Netzwerkschnittstellenport auf Knoten 1. Wenn die derzeit aktive Steuerungsverbindung ausfällt, verliert die Telnet-Sitzung Pakete für 3 Sekunden, bis dieser Fehler erkannt wird.
Ein Fehler der Steuerungsverbindung, 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 Chassis-Clusters.
Sie können festlegen, dass die Wiederherstellung von Steuerungslinks automatisch vom System durchgeführt wird, indem Sie die control-link-recovery
Anweisung festlegen. In diesem Fall führt das System einen automatischen Neustart des deaktivierten Knotens aus, sobald das System feststellt, dass die Steuerungsverbindung fehlerfrei ist. Wenn der deaktivierte Knoten neu gestartet wird, tritt er dem Cluster erneut bei.
Beispiel: Konfiguration von Chassis Cluster Control Link Recovery
Dieses Beispiel zeigt, wie Sie die Wiederherstellung von Control Link aktivieren, wodurch das System automatisch übernehmen kann, nachdem sich die Steuerungsverbindung nach einem Ausfall wiederhergestellt hat.
Anforderungen
Bevor Sie beginnen:
Verstehen Sie Die Chassis-Cluster-Steuerungslinks. Siehe Grundlegendes zur Chassis-Cluster-Steuerungsebene und Steuerungslinks.
Verstehen Sie Dual-Control-Verbindungen für Gehäuse-Cluster. Siehe Grundlegendes zu Gehäuse-Cluster-Dual-Control-Verbindungen.
Verbinden Sie Dual-Control-Links in einem Gehäuse-Cluster. Siehe Dual-Control-Link-Verbindungen für Firewalls der SRX-Serie in einem Chassis-Cluster.
Übersicht
Sie können das System aktivieren, die Control Link Recovery automatisch durchzuführen. Nach der Wiederherstellung der Steuerungsverbindung führt das System die folgenden Aktionen aus:
Es prüft, ob er mindestens drei aufeinanderfolgende Herzschläge auf dem Steuerlink oder, im Fall von Dual-Steuerverbindungen (nur SRX5600 und SRX5800-Geräten), auf einer der Steuerlinks empfängt. Dies soll sicherstellen, dass die Steuerverbindung nicht flappt und gesund ist.
Nachdem festgestellt wurde, dass die Steuerungsverbindung fehlerfrei ist, führt das System einen automatischen Neustart aus, unabhängig vom Status des Knotens (nicht zustimmbar oder deaktiviert), wenn die Steuerungsverbindung fehlgeschlagen ist. Wenn der Knoten neu gestartet wird, kann er wieder in den Cluster eintreten. Manuelle Eingriffe sind nicht erforderlich.
In diesem Beispiel aktivieren Sie die Linkwiederherstellung von Chassis-Cluster-Steuerung.
Konfiguration
Verfahren
Schritt-für-Schritt-Verfahren
So aktivieren Sie die Wiederherstellung von Chassis-Cluster-Steuerungslinks:
Ermöglichen Sie die Wiederherstellung von Control Link.
{primary:node0}[edit] user@host# set chassis cluster control-link-recovery
Wenn Sie mit der Konfiguration des Geräts fertig sind, bestätigen Sie die Konfiguration.
{primary:node0}[edit] user@host# commit