Grundlegendes zu Nonstop-Softwareupgrades auf einem Virtual Chassis und einem gemischten Virtual Chassis

Vorteile von NSSU

• Keine Unterbrechung der Steuerungsebene – NSSU verwendet Graceful Routing-Engine Switchover (GRES) (und Nonstop Active Routing (NSR) auf entsprechenden Plattformen), um sicherzustellen, dass keine Unterbrechung der Steuerungsebene auftritt. Während des Upgrade-Vorgangs behält das Virtual Chassis Schnittstellen-, Kernel- und Routing-Protokollinformationen bei.

• Minimale Unterbrechung des Netzwerkdatenverkehrs – NSSU minimiert die Unterbrechung des Netzwerkverkehrs, indem Mitglieds-Switches nacheinander aktualisiert werden, sodass die primären und Backup-Mitglieder ihre primären und Backup-Rollen beibehalten können (obwohl sich die primäre Rolle ändert), ohne den Datenverkehr zu unterbrechen, und der Datenverkehr weiterhin durch Mitglieder in der Linecard-Rolle fließen kann, die nicht aktualisiert werden.

Anforderungen für die Durchführung einer NSSU

Zu den Anforderungen für die Durchführung von NSSU für ein Virtual Chassis gehören:

• Auf allen Virtual Chassis-Mitgliedern und allen Routing-Engines muss dieselbe Version von Junos OS ausgeführt werden.

• Sie müssen Graceful Routing-Engine Switchover (GRES) aktivieren.

• Sie müssen Nonstop Active Routing (NSR) für die entsprechenden Plattformen aktivieren.

  Obwohl Nonstop Bridging (NSB) für die Durchführung einer NSSU nicht erforderlich ist, empfehlen wir außerdem, NSB zu aktivieren, bevor Sie eine NSSU auf den entsprechenden Plattformen durchführen. NSB stellt sicher, dass alle von NSB unterstützten Layer 2-Protokolle nahtlos funktionieren, wenn die Routing-Engine während der NSSU umschaltet. Weitere Informationen finden Sie unter Konfigurieren von Nonstop-Bridging auf Switches (CLI-Verfahren).

• Um die Unterbrechung des Datenverkehrs zu minimieren, müssen Sie Link Aggregation Groups (LAGs) so konfigurieren, dass sich die Mitgliedsverbindungen der einzelnen LAG auf verschiedenen Virtual Chassis-Mitgliedern befinden, und Link Aggregation Control Protocol (LACP) konfigurieren, um den Verbindungsstatus der LAG-Mitglieder zu überwachen. Wenn ein Mitgliedslink einer LAG ausfällt, sind die verbleibenden Links aktiv, und der Datenverkehr fließt weiterhin durch die LAG. Weitere Informationen zum Konfigurieren von LAGs und LACP finden Sie unter Konfigurieren von Link-Aggregation und Konfigurieren von aggregiertem Ethernet-LACP (CLI-Verfahren).

  Anmerkung:

  Wenn Sie für einen Switch der EX-Serie in einem gemischten Virtual Chassis von einer Version vor Version 15.1 auf Junos OS Version 15.1 oder höher aktualisieren, kann es zu einem Rückgang des Datenverkehrs für bis zu 60 Sekunden kommen.

  Anmerkung:

  Wenn Sie während eines NSSU-Vorgangs versuchen, den LAG-Schnittstellenstatus auf dem primären Routing-Engine-Mitglied mit dem show interfaces ae-ae-interface-number CLI-Befehl anzuzeigen, wird möglicherweise eine falsche oder gar keine Datenverkehrsanzahl angezeigt. Um dieses Problem zu umgehen, führen Sie stattdessen den Befehl für das Sicherungsmitglied der Routing-Engine aus, wenn dieses Mitglied bereits geladen ist und ausgeführt wird.

Anforderungen für das Virtual Chassis oder gemischte Virtual Chassis-Mitglieder, die mithilfe von NSSU aktualisiert werden:

• Die Member-Switches müssen in einer Ringtopologie verbunden sein, sodass kein Member durch einen Neustart eines anderen Members isoliert wird. Diese Topologie verhindert, dass sich das Virtual Chassis während einer NSSU aufteilt.

• Die Switches des primären und des Backup-Mitglieds müssen in der Ringtopologie nebeneinander liegen. Durch die benachbarte Platzierung wird sichergestellt, dass der primäre Server und die Sicherung immer synchronisiert sind, während die Mitgliedsswitches in den Linecardrollen neu gestartet werden.

• Das Virtual Chassis ist vorab bereitgestellt, und Sie haben den Mitglieds-Switches, die in einer Linecard-Rolle agieren, explizit die Linecard-Rolle zugewiesen. Die primären und Backup-Member-Switches von Virtual Chassis ändern die primäre Rolle, während der eine oder der andere während der NSSU aktualisiert wird, aber sie müssen ihre primären und Backup-Routing-Engine-Rollen beibehalten, und die übrigen Switches müssen ihre Linecard-Rollen beibehalten.

• Ein Virtual Chassis mit zwei Mitgliedern muss so konfiguriert sein, dass das Virtual Chassis nicht geteilt wird no-split-detection , wenn eine NSSU ein Mitglied aktualisiert. Weitere Informationen finden Sie unter Grundlegendes zum Teilen und Zusammenführen in einem Virtual Chassis.

Funktionsweise einer NSSU in einem Virtual Chassis und einem gemischten Virtual Chassis

Wenn Sie eine NSSU für ein Virtual Chassis oder gemischtes Virtual Chassis anfordern:

1. Das primäre Virtual Chassis überprüft, dass:

   • Das Backup ist online und führt dieselbe Softwareversion aus.

   • Sie haben Graceful Routing-Engine Switchover (GRES) und ggf. Nonstop Active Routing (NSR) aktiviert.

   • Sie haben eine vorab bereitgestellte Konfiguration verwendet, um das Virtual Chassis einzurichten.

2. Der primäre Server kopiert das neue Softwareabbild nacheinander mit rcp.

   (Nur für QFX5100 Virtual Chassis) Ab Junos OS Version 14.1X53-D40 verwendet das primäre System parallele rcp Sitzungen, um die neue Software auf mehrere Mitglieder gleichzeitig zu kopieren, um die Zeit zu optimieren, die zum Abschließen eines NSSU-Vorgangs für ein Virtual Chassis benötigt wird (anstatt zu warten, bis der Kopiervorgang für jedes Mitglied abgeschlossen ist, bevor mit dem Kopieren des Software-Images auf das nächste Mitglied begonnen wird). Das primäre System verwendet einen Standardalgorithmus, um die Anzahl der parallelen Kopiervorgänge basierend auf der Anzahl der Mitglieder im Virtual Chassis zu bestimmen, oder Sie können mithilfe der rcp-count Konfigurationsanweisung eine bestimmte Anzahl konfigurieren. Weitere Informationen finden Sie unter rcp-count .

   Anmerkung:

   Wenn das Kopieren der neuen Software auf ein Mitglied fehlschlägt, beendet NSSU den Upgradevorgang für das gesamte Virtual Chassis, ohne Mitglieder neu zu starten, und protokolliert die Fehlerbedingung. Ab Junos OS Version 14.1X53-D40 führt der primäre Server eine zusätzliche Fehlerwiederherstellungsmaßnahme durch, um die neue Software von den Mitgliedern zu entfernen, auf die sie bereits übertragen wurde, wenn ein NSSU-Kopiervorgang auf ein Mitglied fehlschlägt.

3. Der primäre Server startet den Backup-Mitglieds-Switch mit der neuen Software neu, und die Sicherung wird erneut mit dem primären Server synchronisiert.

4. Der primäre Server lädt und startet die Member-Switches, die sich in der Linecard-Rolle befinden, nacheinander neu. Der primäre Server wartet, bis jedes Mitglied online ist und die neue Software aktiv ausführt, bevor das nächste Mitglied neu gestartet wird.

   • Wenn Sie Upgradegruppen konfiguriert haben, laden die Virtual Chassis-Mitglieder in der ersten Upgradegruppe das neue Image und starten Sie neu. Wenn die Mitglieder in dieser Upgradegruppe wieder online sind, laden die Mitglieder in der nächsten Upgradegruppe das neue Image und starten neu. (NSSU aktualisiert die Gruppen in der Reihenfolge, in der sie in der Konfiguration angezeigt werden.)

   • Der Datenverkehr fließt während dieses Prozesses weiterhin durch die anderen Mitglieder.

5. Der Neustart wird fortgesetzt, bis alle aktiven Mitglieder mit der neuen Software neu gestartet wurden.

   Anmerkung:

   Wenn ein Linecardrollenmitglied nicht erfolgreich neu gestartet werden kann, beendet NSSU den Upgradevorgang und protokolliert die Fehlerbedingung. Um eine Instabilität des Virtual Chassis zu vermeiden, sollten Sie in diesem Fall entweder das teilweise Upgrade rückgängig machen, indem Sie die alte Software wiederherstellen und die Mitglieder neu starten, die bereits mit der neuen Software neu gestartet wurden, oder versuchen, alle Mitglieder manuell mit der neuen Software neu zu starten, die auf sie kopiert wurde, sodass alle Mitglieder mit derselben Version der Software wieder online gehen.

   Beginnend mit Junos OS-Version 14.1X53-D40 ruft NSSU automatisch Wiederherstellungsmaßnahmen auf, wenn der Neustart bei einem Linecard-Rollenmitglied fehlschlägt, wodurch der sequenzielle Neustartvorgang gestoppt und das gesamte Virtual Chassis heruntergefahren und neu gestartet wird. Das Virtual Chassis ruft dann alle Mitglieder sauber zur gleichen Zeit auf, auf der die neue Software ausgeführt wird, wodurch die Stabilität des Virtual Chassis schneller wiederhergestellt wird als mit einem instabilen Virtual Chassis, auf dem verschiedene Versionen der Software ausgeführt werden, die versuchen, zusammenzulaufen.

6. Nachdem der primäre Server alle Mitglieder in der Linecard-Rolle aktualisiert hat, führt er einen ordnungsgemäßen Routing-Engine-Switchover durch, und der aktualisierte Backup-Mitglieds-Switch wird zum neuen primären Switch.

7. Die neue primäre Datenbank aktualisiert die Software auf der ursprünglichen primären Datenbank und startet sie automatisch neu. Nachdem der ursprüngliche primäre Server wieder dem Virtual Chassis beigetreten ist, können Sie optional die primäre Rolle auf diesen Switch zurücksetzen, indem Sie explizit einen weiteren ordnungsgemäßen Wechsel der Routing-Engine anfordern.

NSSU-Einschränkungen

Sie können NSSU nicht für ein Downgrade der Software verwenden, d. h. um eine frühere Version der Software zu installieren, als sie derzeit auf dem Switch ausgeführt wird. Um eine frühere Softwareversion zu installieren, verwenden Sie den request system software add Befehl.

Sie können nach dem Ausführen eines Upgrades mit NSSU kein Rollback auf die vorherige Softwareversion durchführen. Wenn Sie ein Rollback auf die vorherige Softwareversion durchführen müssen, können Sie von der alternativen Stammpartition aus neu starten, sofern Sie die neue Softwareversion nicht bereits in die alternative Stammpartition kopiert haben.

NSSU und Support für Junos OS-Versionen

NSSU funktioniert nur auf einigen Virtual Chassis mit bestimmten Junos OS-Versionen. Wenden Sie sich an das Technical Assistance Center (JTAC) von Juniper Networks, um zu erfahren, welche Versionen unterstützt werden, wenn Sie ein Upgrade Ihres Virtual Chassis mit NSSU in Erwägung ziehen.

Wenn auf Ihrem Virtual Chassis eine Softwareversion ausgeführt wird, die NSSU nicht unterstützt oder die Kombination von Von - und Bis-Releases mit NSSU nicht unterstützt, verwenden Sie den request system software add Befehl, um die Mitglieds-Switches im Virtual Chassis einzeln zu aktualisieren.

Sie können sich auch auf dieses Netzwerkkonfigurationsbeispiel beziehen, um zu erfahren, wie Sie ein Virtual Chassis der QFX-Serie mit zwei Komponenten manuell mit minimalen Auswirkungen auf den Datenverkehrsfluss aktualisieren, wenn NSSU nicht unterstützt wird:

• Virtual Chassis-Upgrade-Verfahren für die QFX-Serie mit zwei Komponenten

Überblick über die Konfiguration und den Betrieb von NSSU

Damit NSSU erfolgreich sein kann, müssen das Virtual Chassis und die Mitglieds-Switches die Anforderungen in Anforderungen für die Durchführung einer NSSU erfüllen. NSSU erfordert nur diese Konfigurationsschritte.

Wenn Ihr Virtual Chassis die NSSU-Anforderungen erfüllt, geben Sie einfach den request system software nonstop-upgrade Befehl ein, um NSSU zu starten. Weitere Informationen finden Sie unter Aktualisieren von Software auf einem Virtual Chassis und einem gemischten Virtual Chassis mit Nonstop-Softwareupgrades .