Verstehen von Nonstop-Software-Upgrades 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 den entsprechenden Plattformen), um sicherzustellen, dass es nicht zu einer Unterbrechung der Steuerungsebene kommt. Während des Upgrade-Vorgangs behält das Virtual Chassis Schnittstellen-, Kernel- und Routing-Protokollinformationen bei.

• Minimale Unterbrechung des Netzwerkdatenverkehrs: NSSU minimiert Unterbrechungen des Netzwerkdatenverkehrs durch ein Upgrade der Switches der Mitglieder nacheinander, sodass die primären und Backup-Mitglieder ihre Primär- 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:

• Alle Virtual Chassis-Mitglieder und alle Routing-Engines müssen dieselbe Version von Junos OS ausführen.

• 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) nicht erforderlich ist, um eine NSSU durchzuführen, empfehlen wir auch, NSB zu aktivieren, bevor eine NSSU auf entsprechenden Plattformen ausgeführt wird. 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 Datenverkehrsunterbrechungen zu minimieren, müssen Sie Link Aggregation Groups (LAGs) so konfigurieren, dass sich die Member Links jeder LAG auf verschiedenen Virtual Chassis-Mitgliedern befinden, und das Link Aggregation Control Protocol (LACP) so konfigurieren, dass der Verbindungsstatus der LAG-Member überwacht wird. Wenn eine Mitgliedsverbindung einer LAG ausfällt, sind die verbleibenden Verbindungen aktiv, und der Datenverkehr fließt weiterhin durch die LAG. Weitere Informationen zum Konfigurieren von LAGs und LACP finden Sie unter Konfigurieren der Linkaggregation und Konfigurieren von aggregiertem Ethernet-LACP (CLI-Verfahren).

  Hinweis:

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

Anforderungen für das Upgrade von Virtual Chassis- oder gemischten Virtual Chassis-Mitgliedern mit NSSU:

• Die Komponenten-Switches müssen in einer Ringtopologie verbunden werden, damit kein Mitglied durch den Neustart eines anderen Mitglieds isoliert wird. Diese Topologie verhindert, dass das Virtual Chassis während einer NSSU geteilt wird.

• Die Switches für das primäre und das Backup-Mitglied müssen in der Ringtopologie nebeneinander liegen. Durch die benachbarte Platzierung wird sichergestellt, dass Primär und Backup immer synchron sind, während die Mitglieds-Switches in Linecard-Rollen neu gestartet werden.

• Das Virtual Chassis ist vorab bereitgestellt und Sie haben die Linecard-Rolle explizit den Mitglieds-Switches zugewiesen, die in einer Linecard-Rolle agieren. Die primären und Backup-Member-Switches von Virtual Chassis ändern ihre 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 verbleibenden 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 Understanding Split and Merge in a Virtual Chassis.

Funktionsweise einer NSSU auf einem Virtual Chassis und einem Mixed Virtual Chassis

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

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

   • Das Backup ist online und läuft mit derselben Softwareversion.

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

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

2. Der primäre kopiert das neue Software-Image nacheinander mithilfe von rcp.

   Um die Zeit zu optimieren, die zum Abschließen eines NSSU-Vorgangs für ein Virtual Chassis benötigt wird, verwendet das primäre Chassis parallele rcp Sitzungen, um die neue Software auf mehrere Mitglieder gleichzeitig zu kopieren (anstatt zu warten, bis der Kopiervorgang für jedes Mitglied abgeschlossen ist, bevor mit dem Kopieren des Softwareabbilds 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 Member im Virtual Chassis zu bestimmen. Sie können auch eine bestimmte Anzahl mit der rcp-count Konfigurationsanweisung konfigurieren. Weitere Informationen finden Sie unter rcp-count .

   Hinweis:

   Wenn das Kopieren der neuen Software auf ein Mitglied fehlschlägt, beendet NSSU den Upgrade-Vorgang für das gesamte Virtual Chassis, ohne ein Mitglied neu zu starten, und protokolliert den Fehlerzustand.

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

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

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

   • Während dieses Vorgangs fließt der Datenverkehr weiter durch die anderen Mitglieder.

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

   Hinweis:

   Wenn ein Linecard-Rollenmitglied nicht erfolgreich neu gestartet werden kann, beendet NSSU den Upgrade-Prozess und protokolliert die Fehlerbedingung. Um eine Instabilität von Virtual Chassis zu vermeiden, sollten Sie in diesem Fall entweder das Teilupgrade zurückziehen, 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 wieder online gehen und dieselbe Version der Software verwenden.

6. Nachdem der primäre Switch alle Mitglieder in der Linecardrolle aktualisiert hat, führt er einen ordnungsgemäßen Routing-Engine-Switchover durch, und der aktualisierte Backup-Mitgliedsswitch 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 Switch wieder dem Virtual Chassis beigetreten ist, können Sie optional die primäre Rolle auf diesen Switch zurücksetzen, indem Sie explizit einen weiteren Graceful Routing-Engine-Switchover anfordern.

NSSU-Einschränkungen

Sie können NSSU nicht für ein Downgrade der Software verwenden, d. h. für die Installation einer früheren Version der Software als die, die 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 kein Rollback auf die vorherige Softwareversion durchführen, nachdem Sie ein Upgrade mit NSSU durchgeführt haben. Wenn Sie ein Rollback zur vorherigen Softwareversion durchführen müssen, können Sie von der alternativen Stammpartition neu starten, wenn Sie die neue Softwareversion noch nicht in die alternative Stammpartition kopiert haben.

Versionssupport für NSSU und Junos OS

NSSU funktioniert nur auf einigen Virtual Chassis, insbesondere von und zu Junos OS Releases. Wenden Sie sich an das Technical Assistance Center (JTAC) von Juniper Networks, um die unterstützten von und zu Versionen zu bestätigen, wenn Sie ein Upgrade Ihres Virtual Chassis mit NSSU in Betracht ziehen.

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

In diesem Beispiel für die Netzwerkkonfiguration erfahren Sie, wie Sie ein Virtual Chassis der QFX-Serie mit zwei Mitgliedern manuell mit minimalen Auswirkungen auf den Datenverkehrsfluss aktualisieren, wenn NSSU nicht unterstützt wird:

• Upgrade-Verfahren für Virtual Chassis der QFX-Serie mit zwei Mitgliedern

Überblick über NSSU-Konfiguration und -Betrieb

Damit NSSU erfolgreich ist, müssen das Virtual Chassis und die Mitglieds-Switches die Anforderungen unter 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 gemischten Virtual Chassis mit Nonstop-Software-Upgrade .