Upgrade des Virtual Chassis der QFX-Serie mit zwei Mitgliedern
Über dieses Beispiel für eine Netzwerkkonfiguration
Dieses Netzwerkkonfigurationsbeispiel (NCE) zeigt, wie ein Virtual Chassis der QFX-Serie mit zwei Mitgliedern aktualisiert wird, wenn der Nonstop-Software-Upgrade-Prozess (NSSU) entweder nicht verfügbar oder unerwünscht ist. Dieser Prozess minimiert Serviceunterbrechungen und hat minimale Auswirkungen auf die Workloads im Datencenter. Die NSSU-Funktion für die QFX-Serie wird zwischen bestimmten Versionen unterstützt, die im Abschnitt "QFX-Serie" der Versionshinweise von Junos zu finden sind.
Siehe auch
Übersicht über Anwendungsfälle
Die Virtual Chassis-Funktionen sind wichtige Aspekte des Portfolios der QFX-Serie. Ein häufiges Anwendungsszenario für Virtual Chassis in Datencentern ist die Aggregation mehrerer Top-of-Rack-Switches zu einer einzigen logischen Einheit, um die Verwaltung und den Betrieb von Hochverfügbarkeitspaaren zu vereinfachen. In diesem Anwendungsfall sind Server-Racks auf zwei Top-of-Rack-Switches der QFX-Serie ausgerichtet. Die Switches sind in einem Virtual Chassis-Paar konfiguriert und bieten Ausfallsicherheit für den Netzwerkpfad, wenn eines der Geräte der QFX-Serie ausfällt.
Wenn diese Geräte Softwareupdates benötigen, verwenden Sie in der Regel die NSSU-Funktionen des Virtual Chassis, um die Geräte zu aktualisieren. Beim NSSU-Upgrade werden die Virtual Chassis-Mitgliedsgeräte selektiv in einer intelligenten Reihenfolge aktualisiert, um Serviceunterbrechungen für die angeschlossenen Server zu minimieren.
Es gibt jedoch bestimmte Upgradeszenarien, in denen das "von"-Release und das "to"-Release den NSSU-Upgradeprozess nicht unterstützen. Bei einem Upgrade können wir in diesen Szenarien durch eine Reihe manueller Vorgänge ein ähnliches Ergebnis erzielen. Dieser Anwendungsfall deckt den Nicht-NSSU-Upgradepfad zwischen zwei Versionen ab.
Technischer Überblick
Der Prozess zur manuellen Aufrüstung eines Virtual Chassis mit zwei Mitgliedern ahmt die Schritte des automatisierten NSSU-Prozesses stark nach. Die Sequenz nutzt das Hochverfügbarkeitsdesign, um ein Gerät systematisch aus dem Betrieb zu nehmen, um das Upgrade und den Neustart durchzuführen. Wenn die Serverknoten mit jedem der Geräte dual vernetzt sind, kann das Netzwerk dem Entfernen eines der Virtual Chassis-Mitglieder während des Upgrade-Fensters standhalten. Die gesamte Netzwerkbandbreite wird dabei reduziert, das Netzwerk bleibt jedoch verfügbar.
Das Feature Virtual Chassis verwendet ein Primär-/Backup-Konzept, um den Gerätestatus zwischen den Mitgliedern des Virtual Chassis synchron zu halten. Während ein Gerät den Datenverkehr verarbeitet, nehmen wir das andere Gerät offline und rüsten es auf. Um beide Geräte zu aktualisieren, führen wir die folgenden Schritte aus:
Zuerst verlagern wir den gesamten Datenverkehr auf das primäre Gerät.
Sobald das Backup-Gerät keinen Serververkehr mehr verarbeitet, zerlegen wir das Virtual Chassis.
Wenn das Backup-Gerät vollständig isoliert ist, aktualisieren wir die Software auf dem Backup-Gerät und starten es neu. Das Sicherungsgerät speichert eine Kopie der ursprünglichen Netzwerkkonfiguration.
Nachdem das aktualisierte Backup online gegangen ist, verlagern wir den Serverdatenverkehr vom primären Gerät auf das Backup-Gerät. Sobald das Backup die Netzwerklast bewältigt, aktualisieren wir das primäre Gerät und starten es neu.
Nachdem das primäre Gerät online gegangen ist, verlagern wir den Datenverkehr zurück auf das primäre Gerät.
Schließlich aktivieren wir die Virtual Chassis-Links zwischen den beiden Geräten erneut, um das Virtual Chassis-Paar mit der neuen Softwareversion neu zu erstellen.
Konfigurationsbeispiel
Dieses Konfigurationsbeispiel zeigt, wie ein Virtual Chassis mit zwei Mitgliedern von Junos OS Version 14.1X53-D49.1 auf Junos OS Version 18.1R2.6 aktualisiert wird. Zufälligerweise ist dies keine unterstützte Kombination für die NSSU-Funktion, daher verwenden wir den unten beschriebenen manuellen Prozess.
In diesem Beispiel wird eine grundlegende Virtual Chassis-Konfiguration verwendet, aber der Prozess hier kann an eine Reihe verschiedener Anwendungsfälle angepasst werden.
Anforderungen
Gehen Sie wie folgt vor, um beide Mitglieder eines Virtual Chassis mit zwei Mitgliedern, bestehend aus QFX5100-, QFX5110-, QFX5220- oder QFX5200-Switches, auf dieselbe Junos OS Release-Version zu aktualisieren. Es wird dringend empfohlen, dass beide Mitglieder des Virtual Chassis dieselbe Plattform haben, wie in diesem Beispiel.
Bevor Sie beginnen:
-
Stellen Sie sicher, dass das Virtual Chassis aus zwei Mitgliedern besteht, von denen eines als primäres Mitglied und das andere als Backup-Mitglied konfiguriert ist.
-
Konfigurieren Sie das Virtual Chassis im Virtual Chassis-Modus (d. h. nicht im Virtual Chassis-Fabric-Modus)
-
Stellen Sie sicher, dass das Virtual Chassis nur Layer-2-Funktionen ausführt (d. h. keine IRBs oder Routing-Protokolle)
In diesem Beispiel werden die folgenden Hardware- und Softwarekomponenten verwendet:
-
Zwei QFX5100-48S-6Q-Geräte mit Junos OS Version 14.1X53-D49.1
-
Junos OS Version 18.1R2.6
-
Testserver mit Ubuntu Linux 16.04
Überblick
Das Upgrade zwischen den Versionen erfordert eine bestimmte Abfolge von Schritten, die zwischen den Netzwerkelementen koordiniert werden, um ein Minimum an Ausfallzeiten während des Übergangs zu gewährleisten. Wie im Diagramm dargestellt, nutzt das allgemeine Verfahren die Hochverfügbarkeitsmerkmale moderner Server mit redundanten Verbindungen zum Virtual Chassis während des Übergangs.
Zu Beginn des Upgrades beginnen wir mit einem funktionsfähigen zweigliedrigen Virtual Chassis. Unser Ziel ist es, ein Upgrade auf eine neue Version von Junos OS mit minimalen Datenverkehrsunterbrechungen durchzuführen. Um dies zu erreichen, werden wir das Virtual Chassis auseinandernehmen und die Mitgliedsgeräte als eigenständige Einheiten aufrüsten. Nach dem Upgrade der Geräte verbinden wir sie wieder und stellen das Virtual Chassis wieder her.
Topologie
Konfiguration
Vorgehensweise
Schritt-für-Schritt-Anleitung
So aktualisieren Sie die Geräte:
-
Überprüfen Sie den Status des Virtual Chassis. Überprüfen Sie die Parameter des Virtual Chassis und stellen Sie sicher, dass Sie mit einem betriebsbereiten Virtual Chassis mit zwei Mitgliedern arbeiten.
{master:0} user@qfx5100-a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 235e.5bda.52ca Virtual Chassis Mode: Enabled Mstr Mixed Route Neighbor List Member ID Status Serial No Model prio Role Mode Mode ID Interface 0 (FPC 0) Prsnt TA3714120212 qfx5100-48s-6q 129 Master* N Virtual Chassis 1 Virtual Chassisp-255/0/48 1 (FPC 1) Prsnt TA3714120217 qfx5100-48s-6q 129 Backup N Virtual Chassis 0 Virtual Chassisp-255/0/48 -
Laden Sie die neue Software auf die Virtual Chassis Member hoch. Kopieren Sie die neue Software nach /var/tmp auf den primären und Backup-Geräten des Virtual Chassis. In diesem Schritt wird die Software auf beiden Switches für den Upgrade-Vorgang bereitgestellt. Der Kopiervorgang dauert einige Zeit, während die Junos OS-Images übertragen werden.
file copy http://server.example.com/volume/download/software/junos/18.1R2.6/jinstall-host-qfx-5-18.1R2.6-signed.tgz /var/tmp/
-
Wir empfehlen, die Split-Erkennung zu deaktivieren, wenn Sie ein Virtual Chassis mit nur zwei Mitgliedern bilden. Wenn Sie die Split-Erkennung nicht deaktivieren, übernimmt das primäre Gerät möglicherweise eine Linecard-Rolle und beendet die Steuerungs- und Datenebenen, wenn Sie die Backup-Routing-Engine später in diesem Beispiel deaktivieren.
Da Sie dieses NCE mit einem vollständig konfigurierten Virtual Chassis gestartet haben, sollte diese Option bereits konfiguriert sein. Wenn dies aus irgendeinem Grund nicht der Fall ist, konfigurieren Sie es jetzt.
user@qfx5100-a# set virtual-chassis no-split-detection
-
Deaktivieren Sie serverseitige Ports in der Backup-Routing-Engine, um Unterbrechungen während des Switchovers zu minimieren.
user@qfx5100-b# wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
-
Deaktivieren Sie VCP-Ports zur Backup-Routing-Engine. Dadurch wird das Virtual Chassis aufgelöst.
user@qfx5100-b> request virtual-chassis vc-port delete pic-slot 0 port 48 member 1 request virtual-chassis vc-port delete pic-slot 0 port 48 member 0
Aktualisieren Sie die Backup-Routing-Engine. Beim Upgrade auf eine Version 18.2 oder neuer von Junos sollten Sie diese
force-hostOption einbeziehen. Dies stellt sicher, dass sowohl das Host-Betriebssystem als auch die Junos-Binärdateien aktualisiert werden und übereinstimmen.{master:1} user@qfx5100-b> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Tauschen Sie die serverseitigen Ports aus, indem Sie die serverseitigen Ports auf dem primären Gerät deaktivieren und gleichzeitig die serverseitigen Ports in der Sicherung wieder aktivieren. Implementieren Sie dieselbe Konfiguration auf den Backup- und primären Geräten, um jede Konfiguration zu ändern, die aus der Zeit übrig geblieben ist, als die beiden Geräte Teil des Virtual Chassis waren.
Deaktivieren Sie auf dem Backup-QFX zunächst die serverseitigen Ports auf dem primären Gerät. Bestätigen Sie die Konfiguration nicht:
user@qfx5100-b# wildcard range set interfaces ge-0/0/[0-47] disable wildcard range set interfaces xe-0/0/[0-47] disable
Aktivieren Sie dann die serverseitigen Ports in der Sicherung erneut, indem Sie die vorherige Konfiguration löschen. Bestätigen Sie die Konfiguration:
wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
Wiederholen Sie die Konfiguration auf dem primären QFX:
user@qfx5100-a# wildcard range set interfaces ge-0/0/[0-47] disable wildcard range set interfaces xe-0/0/[0-47] disable wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
-
Aktualisieren Sie die primäre Routing-Engine. Beim Upgrade auf eine Version 18.2 oder neuer von Junos sollten Sie diese
force-hostOption einbeziehen. Dies stellt sicher, dass sowohl das Host-Betriebssystem als auch die Junos-Binärdateien aktualisiert werden und übereinstimmen.{master:0} user@qfx5100-a> request system software add /var/tmp/jinstall-host-qfx-5-18.1R2.6-signed.tgz force-host reboot
-
Tauschen Sie die serverseitigen Ports zurück zum primären Gerät. Aktivieren Sie die serverseitigen Ports auf dem primären Gerät erneut, um die LACP-Konvergenz zu beschleunigen, wenn das Virtual Chassis zurückkehrt. Implementieren Sie dieselbe Konfiguration auf den Backup- und primären Geräten, um jede Konfiguration zu ändern, die aus der Zeit übrig geblieben ist, als die beiden Geräte Teil des Virtual Chassis waren.
Aktivieren Sie auf dem Backup-QFX zunächst die serverseitigen Ports auf dem primären Gerät erneut, indem Sie die vorherige Konfiguration löschen. Bestätigen Sie die Konfiguration nicht:
user@qfx5100-b# wildcard range delete interfaces ge-0/0/[0-47] disable wildcard range delete interfaces xe-0/0/[0-47] disable
Deaktivieren Sie dann die serverseitigen Ports im Backup und bestätigen Sie die Konfiguration:
wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
Wiederholen Sie die Konfiguration auf dem primären QFX:
user@qfx5100-a# wildcard range delete interfaces ge-0/0/[0-47] disable wildcard range delete interfaces xe-0/0/[0-47] disable wildcard range set interfaces ge-1/0/[0-47] disable wildcard range set interfaces xe-1/0/[0-47] disable commit and-quit
-
Aktivieren Sie die VCP-Ports auf beiden Boxen erneut, um das Virtual Chassis wiederherzustellen.
user@qfx5100-a> request virtual-chassis vc-port set pic-slot 0 port 48 member 0 request virtual-chassis vc-port set pic-slot 0 port 48 member 1
-
Stellen Sie sicher, dass Sie das Virtual Chassis wiederhergestellt haben.
user@qfx5100-a> show virtual-chassis Preprovisioned Virtual Chassis Virtual Chassis ID: 235e.5bda.52ca Virtual Chassis Mode: Enabled Mstr Mixed Route Neighbor List Member ID Status Serial No Model prio Role Mode Mode ID Interface 0 (FPC 0) Prsnt TA3714120212 qfx5100-48s-6q 129 Master* N Virtual Chassis 1 Virtual Chassisp-255/0/48 1 (FPC 1) Prsnt TA3714120217 qfx5100-48s-6q 129 Backup N Virtual Chassis 0 Virtual Chassisp-255/0/48 -
Aktivieren Sie die Zugriffsports auf beiden Mitgliedern. Nachdem das Virtual Chassis wiederhergestellt wurde, müssen wir die Zugriffsports neu einrichten, damit wir die em0-Adresse der primären Routing-Engine für die Kommunikation mit dem neu aktualisierten Virtual Chassis verwenden können.
Auf der primären QFX:
user@qfx5100-a# wildcard range delete interfaces ge-1/0/[0-47] disable wildcard range delete interfaces xe-1/0/[0-47] disable commit and-quit
Hinweis:Wenn Sie beabsichtigen, Ihrem Virtual Chassis mit zwei Mitgliedern weitere Geräte hinzuzufügen, aktivieren Sie die Split-Erkennung erneut.
Sie haben Ihr zweiköpfiges Virtual Chassis aktualisiert.
Schlussfolgerung
Virtual Chassis ist eine wichtige Architektur für die hohe Verfügbarkeit im Datencenter. Sie wissen jetzt, wie Sie ein Virtual Chassis der QFX-Serie mit zwei Mitgliedern manuell und mit minimalen Auswirkungen auf Ihre Datencenter-Workloads aktualisieren können. Verwenden Sie das in diesem Dokument beschriebene Verfahren, um ein beliebiges Virtual Chassis mit einer ähnlichen Topologie zu aktualisieren, wenn NSSU nicht verfügbar oder nicht wünschenswert ist.