Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Aktualisieren eines Gehäuse-Clusters mithilfe eines In-Service-Softwareupgrades

Verwenden Sie Funktionen entdecken, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen.

Lesen Sie den Abschnitt Plattformspezifisches Verhalten bei Software-Upgrades während des Betriebs , um Hinweise zu Ihrer Plattform zu erhalten.

In-Service-Software-Upgrade (ISSU) ermöglicht ein Software-Upgrade von einer Junos OS-Version auf eine neuere Junos OS-Version mit minimalen Ausfallzeiten. Weitere Informationen finden Sie in den folgenden Themen:

Grundlegendes zu ISSU für einen Chassis-Cluster

In-Service-Software-Upgrade (ISSU) ermöglicht ein Software-Upgrade von einer Junos OS-Version auf eine neuere Junos OS-Version mit geringen oder ganz ohne Ausfallzeiten. ISSU wird ausgeführt, wenn die Geräte nur im Chassis-Cluster-Modus betrieben werden.

Mit der Chassis-Cluster-ISSU-Funktion können beide Geräte in einem Cluster von unterstützten Junos OS-Versionen mit minimaler Unterbrechung des Datenverkehrs und ohne Unterbrechung des Dienstes aktualisiert werden.

ISSU bietet die folgenden Vorteile:

  • Eliminiert Netzwerkausfälle während Software-Image-Upgrades

  • Senkt die Betriebskosten und bietet gleichzeitig höhere Servicelevel

  • Ermöglicht die schnelle Implementierung neuer Funktionen

Für ISSU gelten die folgenden Einschränkungen:

  • ISSU ist nur für Junos OS Version 10.4R4 oder höher verfügbar.

  • ISSU unterstützt keine Software-Downgrades.

  • Wenn Sie ein Upgrade von einer Junos OS-Version, die nur IPv4 unterstützt, auf eine Version, die sowohl IPv4 als auch IPv6 unterstützt, durchführen, funktioniert der IPv4-Datenverkehr während des Upgrade-Vorgangs weiter. Wenn Sie ein Upgrade von einer Junos OS-Version, die sowohl IPv4 als auch IPv6 unterstützt, auf eine Version, die sowohl IPv4 als auch IPv6 unterstützt, durchführen, funktionieren sowohl der IPv4- als auch der IPv6-Datenverkehr während des Upgrade-Vorgangs weiterhin. Junos OS Version 10.2 und höher unterstützen die ablaufbasierte Verarbeitung von IPv6-Datenverkehr.

  • Während einer ISSU können Sie keine PICs online schalten. Sie können keine Vorgänge wie Commit, Neustart oder Anhalten ausführen.

  • Während einer ISSU werden Vorgänge wie Fabric-Überwachung, Wiederherstellung von Steuerverbindungen und RGX-Unterbrechung angehalten.

  • Während einer ISSU können Sie keine Konfigurationen übernehmen.

Weitere Informationen zum ISSU-Supportstatus finden Sie im Knowledgebase-Artikel KB17946.

Der folgende Vorgang wird während einer ISSU für Geräte in einem Chassiscluster ausgeführt. Die unten angegebenen Sequenzen sind anwendbar, wenn RG-0 Knoten 0 (primärer Knoten) ist. Beachten Sie, dass Sie eine ISSU vom primären RG-0-Server aus initiieren müssen. Wenn Sie das Upgrade auf Knoten 1 (RG-0 sekundär) initiieren, wird eine Fehlermeldung angezeigt.

  1. Zu Beginn einer Chassis-Cluster-ISSU führt das System automatisch ein Failover für alle RG-1+-Redundanzgruppen durch, die nicht primär auf dem Knoten sind, von dem aus die ISSU initiiert wird. Durch diese Aktion wird sichergestellt, dass alle Redundanzgruppen nur auf dem primären RG-0-Knoten aktiv sind.

    Das automatische Failover aller RG-1+-Redundanzgruppen ist ab Junos OS Version 12.1 oder höher verfügbar. Wenn Sie Junos OS Version 11.4 oder früher verwenden, stellen Sie vor dem Starten der ISSU sicher, dass alle Redundanzgruppen nur auf dem primären RG-0-Knoten aktiv sind.

    Nachdem das System ein Failover für alle RG-1+-Redundanzgruppen ausgeführt hat, legt es das manuelle Failover-Bit fest und ändert alle Prioritäten des primären RG-1+-Knotens auf 255, unabhängig davon, ob die Redundanzgruppe ein Failover auf den primären RG-0-Knoten ausgeführt hat.

  2. Der primäre Knoten (Knoten 0) validiert die Gerätekonfiguration, um sicherzustellen, dass sie mit der neuen Softwareversion festgeschrieben werden kann. Es werden Überprüfungen auf die Verfügbarkeit von Speicherplatz für das /var-Dateisystem auf beiden Knoten, nicht unterstützte Konfigurationen und nicht unterstützte physische Schnittstellenkarten (PICs) durchgeführt.

    Wenn der auf einem der Routingmodule verfügbare Speicherplatz nicht ausreicht, schlägt der ISSU-Prozess fehl und gibt eine Fehlermeldung zurück. Nicht unterstützte PICs verhindern die ISSU jedoch nicht. Die Software gibt eine Warnung aus, um darauf hinzuweisen, dass diese PICs während des Upgrades neu gestartet werden. Ebenso verhindert eine nicht unterstützte Protokollkonfiguration nicht die ISSU. Die Software gibt jedoch eine Warnung aus, dass während des Upgrades Paketverluste für das Protokoll auftreten können.

  3. Wenn die Validierung erfolgreich war, synchronisiert der Kernel State Synchronization Daemon (ksyncd) den Kernel auf dem sekundären Knoten (Knoten 1) mit dem Knoten 0.

  4. Knoten 1 wird mit dem neuen Software-Image aktualisiert. Vor dem Upgrade ruft der Knoten 1 die Konfigurationsdatei von Knoten 0 ab und überprüft die Konfiguration, um sicherzustellen, dass sie mit der neuen Softwareversion übergeben werden kann. Nach dem Upgrade wird er erneut mit Knoten 0 synchronisiert.

  5. Der Chassis-Cluster-Prozess (Chassisd) auf Knoten 0 bereitet andere Softwareprozesse für die lSSU vor. Wenn alle Prozesse bereit sind, sendet chassisd eine Nachricht an die im Gerät installierten PICs.

  6. Die Packet Forwarding Engine auf jedem Flexible PIC Concentrator (FPC) speichert seinen Status und lädt das neue Software-Image von Knoten 1 herunter. Als Nächstes sendet jede Packet Forwarding Engine eine Nachricht (unified-ISSU-fähig) an das Chassisd.

  7. Nach dem Empfang der Nachricht (Unified-ISSU-fähig) von einer Packet Forwarding Engine sendet das Chassisd eine Neustartnachricht an den FPC, auf dem sich die Packet Forwarding Engine befindet. Der FPC wird mit dem neuen Software-Image neu gestartet. Nach dem Neustart des FPC stellt die Packet Forwarding Engine den FPC-Status wieder her und es wird eine interne Hochgeschwindigkeitsverbindung hergestellt, auf der auf Knoten 1 die neue Software ausgeführt wird. Das Chassisd wird ebenfalls mit Knoten 0 wiederhergestellt.

  8. Nachdem alle Packet Forwarding Engines eine Ready-Message über das Chassis auf Knoten 0 gesendet haben, werden andere Softwareprozesse für einen Knoten-Switchover vorbereitet. Zu diesem Zeitpunkt ist das System bereit für eine Umstellung.

  9. Es kommt zu einem Knotenwechsel und Knoten 1 wird zum neuen primären Knoten (bisher sekundärer Knoten 1).

  10. Der neue sekundäre Knoten (bisher primärer Knoten 0) wird nun auf das neue Software-Image aktualisiert.

Wenn beide Knoten erfolgreich aktualisiert wurden, ist die ISSU abgeschlossen.

Wenn Sie einen Versionscluster, der keine Verschlüsselung unterstützt, auf eine Version aktualisieren, die Verschlüsselung unterstützt, aktualisieren Sie den ersten Knoten auf die neue Version. Wenn die Verschlüsselung nicht konfiguriert und aktiviert ist, können zwei Knoten mit unterschiedlichen Versionen weiterhin miteinander kommunizieren, ohne dass der Dienst unterbrochen wird. Führen Sie nach dem Upgrade des ersten Knotens für den zweiten Knoten ein Upgrade auf die neue Version durch. Benutzer können entscheiden, ob die Verschlüsselungsfunktion nach Abschluss des Upgrades aktiviert werden soll. Die Verschlüsselung muss deaktiviert werden, bevor ein Downgrade auf eine Version durchgeführt werden kann, die keine Verschlüsselung unterstützt. Dadurch wird sichergestellt, dass die Kommunikation zwischen einem Knoten mit aktivierter Version und einem herabgestuften Knoten nicht unterbrochen wird, da beide nicht mehr verschlüsselt sind.

Anmerkung:

Die Richtlinien in der Routing-Engine und der Packet Forwarding Engine müssen synchronisiert sein, damit für die Konfiguration ein Commit ausgeführt werden kann. Wenn die Richtlinienkonfigurationen geändert werden und die Richtlinien nicht synchronisiert sind, zeigt das System eine Fehlermeldung an.

Um dieses Problem zu umgehen, müssen Sie den Befehl request security policies resync verwenden, um die Konfiguration der Sicherheitsrichtlinien in der Routing-Engine und der Packet Forwarding Engine zu synchronisieren, falls Sie feststellen, dass die Sicherheitsrichtlinien nach einem Upgrade nicht mehr synchron sind.

ISSU-Systemanforderungen

Sie können ISSU verwenden, um ein Upgrade von einer ISSU-fähigen Softwareversion auf eine neuere Version durchzuführen.

Um eine ISSU durchführen zu können, muss auf Ihrem Gerät eine Junos OS-Version ausgeführt werden, die ISSU für die jeweilige Plattform unterstützt. Weitere Informationen zur Plattformunterstützung finden Sie in Tabelle 1 .

Tabelle 1: Unterstützung der ISSU-Plattform

Gerät

Junos OS-Version

SRX5800 und SRX5600

10.4R4 oder höher

SRX5400

12.1X46-D20 oder höher

SRX1500

15.1X49-D70 oder höher

SRX1600 und SRX2300

23.4R1 oder höher

SRX4100 und SRX4200

15.1X49-D80 oder höher

SRX4300

24.2R1 oder höher

SRX4600

17.4R1 oder höher

Weitere Informationen zur ISSU-Unterstützung und zu den Einschränkungen finden Sie unter ISSU/ICU-Upgrade-Einschränkungen für Geräte der SRX-Serie.

Beachten Sie die folgenden Einschränkungen im Zusammenhang mit einer ISSU:

  • Der ISSU-Prozess wird beendet, wenn die für die Installation angegebene Junos OS-Version eine frühere Version ist als diejenige, die derzeit auf dem Gerät ausgeführt wird.

  • Der ISSU-Prozess wird beendet, wenn das angegebene Upgrade mit der aktuellen Konfiguration, den unterstützten Komponenten usw. in Konflikt steht.

  • ISSU unterstützt keine Erweiterungsanwendungspakete, die mit dem Junos OS SDK entwickelt wurden.

  • ISSU unterstützt keine Versionsherabstufung auf allen unterstützten Firewalls der SRX-Serie.

  • ISSU schlägt gelegentlich unter hoher CPU-Last fehl.

Verwenden Sie den request system software add Befehl, um ein Downgrade von einer ISSU-fähigen Version auf eine frühere Version (ISSU-fähig oder nicht) durchzuführen. Im Gegensatz zu einem Upgrade mithilfe des ISSU-Prozesses kann ein Downgrade mit dem request system software add Befehl zu Netzwerkunterbrechungen und Datenverlusten führen.

Es wird dringend empfohlen, ISSU unter den folgenden Bedingungen durchzuführen:

  • Wenn sowohl der primäre als auch der sekundäre Knoten fehlerfrei sind

  • Während der Systemwartungsphase

  • Während der geringstmöglichen Verkehrszeit

  • Wenn die CPU-Auslastung der Routing-Engine weniger als 40 Prozent beträgt

In Fällen, in denen ISSU nicht unterstützt oder empfohlen wird, obwohl die Ausfallzeiten während des Systemupgrades minimiert werden müssen, kann das Verfahren der minimalen Ausfallzeit verwendet werden, siehe Knowledge Base-ArtikelKB17947.

Aktualisieren beider Geräte in einem Gehäusecluster mithilfe von ISSU

Bevor Sie mit der ISSU für das Upgrade beider Geräte beginnen, beachten Sie die folgenden Richtlinien:

  • Stellen Sie sicher, dass die folgenden ISSU-Anforderungen für die Vorabprüfung erfüllt sind:

    • Die Priorität aller Redundanzgruppen ist größer als 0

    • Alle Redundanzgruppen sind entweder primär oder sekundär im Zustand

    • Es ist genügend (doppelte Bildgröße) Speicherplatz in /var/tmp verfügbar

    • Die CPU-Auslastung liegt innerhalb von 5 Sekunden unter 80 %

    Wenn die Anforderungen an die Vorabprüfung nicht erfüllt sind, wird die ISSU von Anfang an beendet.

  • Sichern Sie die Software mit dem Befehl auf jeder request system snapshot Routing-Engine, um die Systemsoftware auf der Festplatte des Geräts zu sichern.

  • Wenn Sie Junos OS Version 11.4 oder früher verwenden, legen Sie vor dem Starten der ISSU das Failover für alle Redundanzgruppen so fest, dass sie alle nur auf einem Knoten (primär) aktiv sind. Weitere Informationen finden Sie unter Initiieren eines manuellen Failovers für Chassis-Cluster-Redundanzgruppen.

    Wenn Sie Junos OS Version 12.1 oder höher verwenden, führt Junos OS automatisch ein Failover aller RGs auf das primäre RG0 durch.

  • Es wird empfohlen, den ordnungsgemäßen Neustart für Routingprotokolle zu aktivieren, bevor Sie eine ISSU starten.

Für alle unterstützten Firewalls der SRX-Serie ist die erste empfohlene ISSU ab Version 10.4R4 von Junos OS.

Die ISSU-Funktion für Chassis-Cluster ermöglicht das Upgrade beider Geräte in einem Cluster von unterstützten Junos OS-Versionen mit ähnlichen Auswirkungen auf den Datenverkehr wie bei einem Redundanzgruppen-Failover.

So führen Sie eine ISSU über die CLI auf Routing-Engine2 aus:

  1. Laden Sie das Softwarepaket von der Juniper Networks Support-Website herunter: https://www.juniper.net/support/downloads/
  2. Kopieren Sie das Paket auf den primären Knoten des Clusters. Es wird empfohlen, das Paket in das Verzeichnis /var/tmp zu kopieren, das ein großes Dateisystem auf der Festplatte ist. Beachten Sie, dass der Knoten, von dem aus Sie die ISSU initiieren, über das Software-Image verfügen muss.

    user@host>file copy ftp://username:prompt@ftp.hostname.net/filename /var/tmp/filename

  3. Überprüfen Sie die aktuelle Softwareversion, die auf beiden Knoten ausgeführt wird, indem Sie den show version Befehl auf dem primären Knoten ausführen.
  4. Starten Sie die ISSU auf dem Knoten, der für alle Redundanzgruppen primär ist, indem Sie den folgenden Befehl eingeben:

    Warten Sie, bis beide Knoten das Upgrade abgeschlossen haben (danach werden Sie vom Gerät abgemeldet).

  5. Warten Sie einige Minuten, und melden Sie sich dann erneut beim Gerät an. Vergewissern Sie sich mithilfe des show version Befehls, dass auf beiden Geräten im Cluster die neue Version von Junos OS ausgeführt wird.
  6. Stellen Sie sicher, dass alle Richtlinien, Zonen, Redundanzgruppen und andere Echtzeitobjekte (RTOs) wieder in ihren korrekten Zustand zurückkehren.
  7. Machen Sie Knoten 0 wieder zum primären Knoten, indem Sie den request chassis cluster failover node node-number redundancy-group group-number Befehl ausführen.

Wenn Sie möchten, dass Redundanzgruppen nach einem In-Service-Softwareupgrade (ISSU) automatisch zu Knoten 0 als primären Knoten zurückkehren, müssen Sie die Priorität der Redundanzgruppe so festlegen, dass Knoten 0 primär ist, und die preempt Option aktivieren. Beachten Sie, dass diese Methode für alle Redundanzgruppen mit Ausnahme der Redundanzgruppe 0 funktioniert. Sie müssen das Failover für die Redundanzgruppe 0 manuell festlegen.

Informationen zum Festlegen der Redundanzgruppenpriorität und Aktivieren der preempt Option finden Sie unter Beispiel: Konfigurieren von Chassis-Cluster-Redundanzgruppen.

Informationen zum manuellen Festlegen des Failovers für eine Redundanzgruppe finden Sie unter Initiieren eines manuellen Failovers für eine Chassis-Cluster-Redundanzgruppe.

Während des Upgrades kann es bei beiden Geräten zu Redundanzgruppen-Failovers kommen, der Datenverkehr wird jedoch nicht unterbrochen. Jedes Gerät validiert das Paket und prüft die Versionskompatibilität, bevor es mit dem Upgrade beginnt. Wenn das System feststellt, dass die neue Paketversion nicht mit der aktuell installierten Version kompatibel ist, lehnt das Gerät das Upgrade ab oder fordert Sie auf, Korrekturmaßnahmen zu ergreifen. Manchmal ist eine einzelne Funktion nicht kompatibel. In diesem Fall werden Sie von der Upgradesoftware aufgefordert, entweder das Upgrade zu beenden oder die Funktion zu deaktivieren, bevor Sie mit dem Upgrade beginnen.

Wenn Sie die Firewall der SRX-Serie wieder als eigenständiges Gerät betreiben oder einen Knoten aus einem Chassis-Cluster entfernen möchten, stellen Sie sicher, dass Sie den ISSU-Vorgang auf beiden Knoten beendet haben (falls ein ISSU-Vorgang eingeleitet wird)

So starten Sie den ISSU-Prozess auf SRX5K-Geräten mit Routing-Engine3 und auf SRX1600-, SRX2300- und SRX4300-Geräten:

  1. Führen Sie den folgenden Befehl aus, um ISSU zu starten:

Siehe auch

Zurücksetzen von Geräten in einem Chassis-Cluster nach einer ISSU

Wenn ein ISSU nicht abgeschlossen werden kann und nur ein Gerät im Cluster aktualisiert wird, können Sie die vorherige Konfiguration nur auf dem aktualisierten Gerät wiederherstellen, indem Sie einen der folgenden Befehle auf dem aktualisierten Gerät ausführen:

  • request chassis cluster in-service-upgrade abort

  • request system software rollback node node-id reboot

  • request system reboot

Aktivieren eines automatischen Chassis-Clusterknoten-Failbacks nach einer ISSU

Wenn Sie möchten, dass Redundanzgruppen nach einem In-Service-Softwareupgrade (ISSU) automatisch zu Knoten 0 als primären Knoten zurückkehren, müssen Sie die Redundanzgruppenpriorität so festlegen, dass Knoten 0 primär ist, und die preempt Option aktivieren. Beachten Sie, dass diese Methode für alle Redundanzgruppen mit Ausnahme der Redundanzgruppe 0 funktioniert. Sie müssen das Failover für eine Redundanzgruppe manuell auf 0 festlegen. Informationen zum Festlegen der Redundanzgruppenpriorität und Aktivieren der preempt Option finden Sie unter Beispiel: Konfigurieren von Chassis-Cluster-Redundanzgruppen. Informationen zum manuellen Festlegen des Failovers für eine Redundanzgruppe finden Sie unter Initiieren eines manuellen Failovers für eine Chassis-Cluster-Redundanzgruppe.

Um Knoten 0 zu aktualisieren und im Gehäusecluster verfügbar zu machen, starten Sie Knoten 0 manuell neu. Knoten 0 wird nicht automatisch neu gestartet.

Protokollieren von Fehlermeldungen, die für die Fehlerbehebung bei Problemen im Zusammenhang mit ISSU verwendet werden

Die folgenden Probleme können während eines ISSU-Upgrades auftreten. Sie können die Fehler anhand der Details in den Protokollen identifizieren. Ausführliche Informationen zu bestimmten Systemprotokollmeldungen finden Sie unter Systemprotokoll-Explorer.

Chassis-Prozessfehler

Problem

Beschreibung

Fehler im Zusammenhang mit dem Chassisd.

Lösung

Verwenden Sie die Fehlermeldungen, um die Probleme im Zusammenhang mit dem Chassisd zu verstehen.

Wenn ISSU gestartet wird, wird eine Anforderung an Chassisd gesendet, um zu prüfen, ob es Probleme im Zusammenhang mit der ISSU aus Chassis-Perspektive gibt. Wenn ein Problem auftritt, wird eine Protokollmeldung erstellt.

Grundlegendes zur allgemeinen Fehlerbehandlung für ISSU

Problem

Beschreibung

Im Verlauf einer ISSU können Probleme auftreten. In diesem Abschnitt finden Sie Details dazu, wie Sie damit umgehen.

Lösung

Alle Fehler, die während einer ISSU auftreten, führen zur Erstellung von Protokollmeldungen, und ISSU funktioniert weiterhin ohne Auswirkungen auf den Datenverkehr. Wenn eine Wiederherstellung auf frühere Versionen erforderlich ist, wird das Ereignis entweder protokolliert oder die ISSU wird angehalten, um keine nicht übereinstimmenden Versionen auf beiden Knoten des Chassis-Clusters zu erstellen. Tabelle 2 enthält einige der häufigsten Fehlerbedingungen und die Problemumgehungen dafür. Die in Tabelle 2 verwendeten Beispielmeldungen stammen vom SRX1500 Gerät und gelten auch für alle unterstützten SRX-Serie-Firewalls.

Tabelle 2: ISSU-bezogene Fehler und Lösungen

Fehlerbedingungen

Lösungen

Versuch, eine ISSU zu initiieren, wenn die vorherige Instanz einer ISSU bereits ausgeführt wird

Die folgende Meldung wird angezeigt:

warning: ISSU in progress

Sie können den aktuellen ISSU-Prozess abbrechen und mit dem request chassis cluster in-service-upgrade abort Befehl erneut initiieren.

Fehler beim Neustart auf dem sekundären Knoten

Es treten keine Serviceausfallzeiten auf, da der primäre Knoten weiterhin erforderliche Services bereitstellt. Es werden detaillierte Konsolenmeldungen angezeigt, in denen Sie aufgefordert werden, vorhandene ISSU-Status manuell zu löschen und den Chassis-Cluster wiederherzustellen.

error: [Oct  6 12:30:16]: Reboot secondary node failed (error-code: 4.1)

       error: [Oct  6 12:30:16]: ISSU Aborted! Backup node maybe in inconsistent state, Please restore backup node
       [Oct  6 12:30:16]: ISSU aborted. But, both nodes are in ISSU window.
       Please do the following:
       1. Rollback the node with the newer image using rollback command
          Note: use the 'node' option in the rollback command
          otherwise, images on both nodes will be rolled back
       2. Make sure that both nodes (will) have the same image
       3. Ensure the node with older image is primary for all RGs
       4. Abort ISSU on both nodes
       5. Reboot the rolled back node

Ab Junos OS Version 17.4R1 wird der Hold-Timer für den ersten Neustart des sekundären Knotens während des ISSU-Prozesses von 15 Minuten (900 Sekunden) auf 45 Minuten (2700 Sekunden) in Gehäuse-Clustern auf SRX1500-, SRX4100-, SRX4200- und SRX4600-Geräten erweitert.

Der sekundäre Knoten konnte die kalte Synchronisierung nicht abschließen.

Beim primären Knoten tritt eine Zeitüberschreitung auf, wenn der sekundäre Knoten die kalte Synchronisierung nicht abschließen kann. Es werden detaillierte Konsolenmeldungen angezeigt, in denen Sie aufgefordert werden, vorhandene ISSU-Status manuell zu löschen und den Chassis-Cluster wiederherzustellen. In diesem Szenario treten keine Serviceunterbrechungen auf.

[Oct  3 14:00:46]: timeout waiting for secondary node node1 to sync(error-code: 6.1)
        Chassis control process started, pid 36707 

       error: [Oct  3 14:00:46]: ISSU Aborted! Backup node has been upgraded, Please restore backup node 
       [Oct  3 14:00:46]: ISSU aborted. But, both nodes are in ISSU window. 
       Please do the following: 
      1. Rollback the node with the newer image using rollback command 
          Note: use the 'node' option in the rollback command 
          otherwise, images on both nodes will be rolled back 
      2. Make sure that both nodes (will) have the same image 
      3. Ensure the node with older image is primary for all RGs 
      4. Abort ISSU on both nodes 
      5. Reboot the rolled back node

Failover der neu aktualisierten sekundären Datenbank ist fehlgeschlagen

Es treten keine Serviceausfallzeiten auf, da der primäre Knoten weiterhin erforderliche Services bereitstellt. Es werden detaillierte Konsolenmeldungen angezeigt, in denen Sie aufgefordert werden, vorhandene ISSU-Status manuell zu löschen und den Chassis-Cluster wiederherzustellen.

[Aug 27 15:28:17]: Secondary node0 ready for failover.
[Aug 27 15:28:17]: Failing over all redundancy-groups to node0
ISSU: Preparing for Switchover
error: remote rg1 priority zero, abort failover.
[Aug 27 15:28:17]: failover all RGs to node node0 failed (error-code: 7.1)
error: [Aug 27 15:28:17]: ISSU Aborted!
[Aug 27 15:28:17]: ISSU aborted. But, both nodes are in ISSU window.
Please do the following:
1. Rollback the node with the newer image using rollback command
    Note: use the 'node' option in the rollback command
           otherwise, images on both nodes will be rolled back
2. Make sure that both nodes (will) have the same image
3. Ensure the node with older image is primary for all RGs
4. Abort ISSU on both nodes
5. Reboot the rolled back node
{primary:node1}

Upgradefehler auf primärer Ebene

Es kommt zu keiner Ausfallzeit des Dienstes, da für den sekundären Knoten ein Failover als primärer Knoten ausgeführt wird und weiterhin die erforderlichen Dienste bereitgestellt werden.

Fehler beim Neustart auf dem primären Knoten

Vor dem Neustart des primären Knotens werden keine ISSU-bezogenen Fehlermeldungen angezeigt, da sich die Geräte außerhalb des ISSU-Setups befinden. Die folgende Fehlermeldung beim Neustart wird angezeigt, wenn ein anderer Fehler erkannt wird:

Reboot failure on     Before the reboot of primary node, devices will be out of ISSU setup and no primary node error messages will be displayed.
Primary node

Fehler im Zusammenhang mit dem ISSU-Support

Problem

Beschreibung

Installationsfehler treten aufgrund nicht unterstützter Software und nicht unterstützter Funktionskonfiguration auf.

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die kompatibilitätsbezogenen Probleme zu verstehen:

Fehler bei ersten Validierungsprüfungen

Problem

Beschreibung

Die anfänglichen Validierungsprüfungen schlagen fehl.

Lösung

Die Validierungsprüfungen schlagen fehl, wenn das Image nicht vorhanden ist oder wenn die Image-Datei beschädigt ist. Die folgenden Fehlermeldungen werden angezeigt, wenn anfängliche Validierungsprüfungen fehlschlagen, wenn das Image nicht vorhanden ist und die ISSU abgebrochen wird:

Wenn kein Bild vorhanden ist

Wenn die Bilddatei beschädigt ist

Wenn die Bilddatei beschädigt ist, wird die folgende Ausgabe angezeigt:

Der primäre Knoten validiert die Gerätekonfiguration, um sicherzustellen, dass sie mit der neuen Softwareversion festgeschrieben werden kann. Wenn etwas schief geht, bricht die ISSU ab und es werden Fehlermeldungen angezeigt.

Fehler bei der Installation

Problem

Beschreibung

Die Installations-Image-Datei ist nicht vorhanden, oder auf die Remote-Site kann nicht zugegriffen werden.

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die installationsbezogenen Probleme zu verstehen:

ISSU lädt das Installationsimage, wie im ISSU-Befehl angegeben, als Argument herunter. Bei der Bilddatei kann es sich um eine lokale Datei handeln oder sich an einem Remote-Standort befinden. Wenn die Datei nicht vorhanden ist oder auf die Remote-Site nicht zugegriffen werden kann, wird ein Fehler gemeldet.

Fehler beim Failover von Redundanzgruppen

Problem

Beschreibung

Problem mit einem Fehler der automatischen Redundanzgruppe (RG).

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um das Problem zu verstehen:

Fehler bei der Kernel-Statussynchronisierung

Problem

Beschreibung

Fehler im Zusammenhang mit ksyncd.

Lösung

Verwenden Sie die folgenden Fehlermeldungen, um die Probleme im Zusammenhang mit ksyncd zu verstehen:

ISSU prüft, ob auf dem sekundären Knoten (Knoten 1) ksyncd-Fehler vorhanden sind, und zeigt die Fehlermeldung an, wenn Probleme vorliegen, und bricht das Upgrade ab.

Plattformspezifisches Software-Upgrade-Verhalten während des Betriebs

Verwenden Sie Funktionen entdecken, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen.

Verwenden Sie die folgende Tabelle, um plattformspezifische Verhaltensweisen für Ihre Plattform zu überprüfen.

Bahnsteig

Unterschied

SRX-Serie

  • SRX1500-, SRX4100- und SRX4200-Firewalls unterstützen Upgrades von Junos OS 17.4 auf nachfolgende 17.4-Versionen und können nicht von früheren Junos OS-Versionen auf 17.4-Versionen durchgeführt werden.

  • SRX5400-, SRX5600- und SRX5800-Firewalls unterstützen Upgrades von Junos OS 17.3 auf nachfolgende 17.3-Versionen und können nicht von früheren Junos OS-Versionen auf 17.3 und höher durchgeführt werden.

  • SRX1500-, SRX1600-, SRX2300-, SRX4100-, SRX4200-, SRX4300- und SRX4600-Firewalls unterstützen den request system snapshot Befehl nicht.

  • SRX1500-, SRX4100- und SRX4200-Firewalls, die ISSU unterstützen, ermöglichen es Ihnen, die ursprüngliche Image-Datei zu entfernen. In den user@host> request system software in-service-upgrade image-name-with-full-path unlink Befehl aufnehmenunlink.

Zugehörige Dokumentation

Tabellarischer Änderungsverlauf

Die Unterstützung der Funktion hängt von der Plattform und der Version ab, die Sie benutzen. Verwenden Sie Funktionen entdecken , um festzustellen, ob eine Funktion auf Ihrer Plattform unterstützt wird.

Loslassen
Beschreibung
17.4R1
Ab Junos OS Version 17.4R1 unterstützen SRX4600 Geräte ISSU.
17.4R1
Ab Junos OS Version 17.4R1 wird der Hold-Timer für den ersten Neustart des sekundären Knotens während des ISSU-Prozesses von 15 Minuten (900 Sekunden) auf 45 Minuten (2700 Sekunden) in Gehäuse-Clustern auf SRX1500-, SRX4100-, SRX4200- und SRX4600-Geräten erweitert.
15,1 x 49-D80
Ab Junos OS Version 15.1X49-D80 unterstützen SRX4100- und SRX4200 Geräte ISSU.
15,1 x 49-D70
Ab Junos OS Version 15.1X49-D70 unterstützen SRX1500 Geräte ISSU.