Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
AUF DIESER SEITE
 

Upgrade von Virtual Chassis der QFX-Serie mit zwei Komponenten

Informationen zu diesem Beispiel für die Netzwerkkonfiguration

Dieses Beispiel für die Netzwerkkonfiguration (NCE) zeigt, wie ein Virtual Chassis der QFX-Serie mit zwei Komponenten aktualisiert wird, wenn der NSSU-Prozess (Nonstop Software Upgrade) 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 Junos-Versionshinweise zu finden sind.

Siehe auch

Anwendungsfallübersicht

Die Virtual Chassis-Funktionen sind wichtige Aspekte des Portfolios der QFX-Serie. Ein gängiger Anwendungsfall für Virtual Chassis in Datencentern besteht darin, mehrere Top-of-Rack-Switches zu einer einzigen logischen Einheit zu aggregieren, um die Verwaltung und den Betrieb von Hochverfügbarkeitspaaren zu vereinfachen. In diesem Anwendungsfall sind Racks von Servern multihomed mit zwei Top-of-Rack-Switches der QFX-Serie. Die Switches werden 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 im Allgemeinen die NSSU-Funktionen des Virtual Chassis, um die Geräte zu aktualisieren. Das NSSU-Upgrade aktualisiert selektiv die Virtual Chassis-Mitgliedergeräte, um Serviceunterbrechungen für die angeschlossenen Server zu minimieren.

Es gibt jedoch bestimmte Upgrade-Szenarien, in denen die Version "von" und "bis" den NSSU-Upgrade-Prozess nicht unterstützen. Bei upgrades in diesen Szenarien können wir ein ähnliches Ergebnis durch eine Reihe manueller Vorgänge erzielen. Dieser Anwendungsfall deckt den Nicht-NSSU-Upgradepfad zwischen zwei Versionen ab.

Technische Übersicht

Der Prozess zum manuellen Upgrade eines zweiköpfigen Virtual Chassis ähnelt genau den Schritten des automatisierten NSSU-Prozesses. Die Sequenz nutzt das Hochverfügbarkeitsdesign, um systematisch ein Gerät aus dem Betrieb zu entfernen, 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. Während des Prozesses wird die gesamte Netzwerkbandbreite reduziert, aber das Netzwerk bleibt verfügbar.

Die Virtual Chassis-Funktion verwendet ein Primär-/Backup-Konzept, um den Gerätestatus zwischen den Mitgliedern des Virtual Chassis zu synchronisieren. Während ein Gerät den Datenverkehr verwaltet, nehmen wir das andere Gerät offline und aktualisieren es. Um beide Geräte zu aktualisieren, führen wir folgende Schritte durch:

  1. Erstens verlagern wir den gesamten Datenverkehr auf das primäre Gerät.

  2. Sobald das Backup-Gerät den Serververkehr nicht mehr bewältigen kann, zerlegen wir das Virtual Chassis.

  3. Da das Backup-Gerät vollständig isoliert ist, aktualisieren wir die Software auf dem Backup-Gerät und starten es neu. Das Backup-Gerät bewahren eine Kopie der ursprünglichen Netzwerkkonfiguration auf.

  4. Nachdem das aktualisierte Backup online ist, verlagern wir den Serverdatenverkehr vom primären Gerät zum Backup-Gerät. Sobald das Backup die Netzwerklast gehandhabt hat, aktualisieren wir das primäre Gerät und starten es neu.

  5. Nachdem das primäre Gerät online ist, verlagern wir den Datenverkehr zurück zum primären Gerät.

  6. Schließlich aktivieren wir die Virtual Chassis-Verbindungen zwischen den beiden Geräten erneut, um das Virtual Chassis-Paar mit der neuen Softwareversion neu zu erstellen.

Konfigurationsbeispiel

Dieses Konfigurationsbeispiel zeigt, wie Sie ein Virtual Chassis mit zwei Komponenten von Junos OS Version 14.1X53-D49.1 auf Junos OS Version 18.1R2.6 aktualisieren. Dies ist keine unterstützte Kombination für die NSSU-Funktion, daher werden wir den unten beschriebenen manuellen Prozess verwenden.

In diesem Beispiel wird eine einfache Virtual Chassis-Konfiguration verwendet, aber der Prozess hier kann an eine Reihe von verschiedenen Anwendungsfällen angepasst werden.

Anforderungen

Verwenden Sie dieses Verfahren, um beide Mitglieder eines zweiköpfigen Virtual Chassis, das aus QFX5100, QFX5110, QFX5220 oder QFX5200 Switches besteht, auf dieselbe Junos OS-Version zu aktualisieren. Wir empfehlen dringend, dass beide Mitglieder des Virtual Chassis dieselbe Plattform sind, wie in diesem Beispiel.

Bevor Sie beginnen:

  • Wenn das Virtual Chassis nicht vorab bereitgestellt wird, konfigurieren Sie ein Mitglied als primäre Routing-Engine, das andere als Backup-Routing-Engine.

  • Stellen Sie sicher, dass das Virtual Chassis aus zwei Mitgliedern besteht

  • Konfigurieren des Virtual Chassis im Virtual Chassis-Modus (d. a. nicht im Virtual Chassis-Fabric-Modus)

  • Stellen Sie sicher, dass Virtual Chassis nur Layer-2-Funktionen ausführt (d. a. 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

Übersicht

Das Upgrade zwischen den Versionen erfordert eine bestimmte Abfolge von Schritten, die zwischen den Netzwerkelementen koordiniert sind, um ein Minimum an Ausfallzeiten während der Umstellung 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 funktionalen zweiköpfigen Virtual Chassis. Unser Ziel ist es, auf eine neue Version von Junos OS mit minimaler Unterbrechung des Datenverkehrs aufzurüsten. Um dies zu erreichen, werden wir das Virtual Chassis voneinander trennen und die angeschlossenen Geräte als eigenständige Einheiten aufrüsten. Nachdem die Geräte aktualisiert wurden, verbinden wir sie erneut und richten das Virtual Chassis neu ein.

Topologie

Konfiguration

Verfahren

Schritt-für-Schritt-Verfahren

So aktualisieren Sie die Geräte:

  1. Überprüfen Sie den Virtual Chassis-Zustand. Überprüfen Sie die Parameter des Virtual Chassis und stellen Sie sicher, dass Sie mit einem zweiköpfigen Virtual Chassis arbeiten, das in Betrieb ist.

  2. Laden Sie die neue Software auf die Virtual Chassis-Mitglieder hoch. Kopieren Sie die neue Software in /var/tmp auf den primären Virtual Chassis- und Backup-Geräten. In diesem Schritt wird die Software auf beiden Switches für den Upgrade-Vorgang ausgeführt. Der Kopiervorgang dauert einige Zeit, während die Junos OS-Images übertragen werden.

  3. Wir empfehlen, die splitte Erkennung zu deaktivieren, wenn Sie ein Virtual Chassis mit nur zwei Mitgliedern bilden. Wenn Sie die geteilte Erkennung nicht deaktivieren, übernimmt das primäre Gerät möglicherweise eine Linecard-Rolle und stoppt die Steuerungs- und Datenebene, wenn Sie die Backup-Routing-Engine später in diesem Beispiel deaktivieren.

    Da Sie diese 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.

  4. Deaktivieren Sie serverorientierte Ports auf der Backup-Routing-Engine, um Unterbrechungen während des Switchovers zu minimieren.

  5. Deaktivieren Sie VCP-Ports für die Backup-Routing-Engine. Dadurch wird das Virtual Chassis durchbrechen.

  6. Aktualisieren Sie die Backup-Routing-Engine. Wenn Sie auf eine Junos-Version 18.2 oder höher aktualisieren, sollten Sie die force-host Option einschließen. Dies setzt fest, dass sowohl das Hostbetriebssystem als auch die Junos-Binärdateien aktualisiert werden und übereinstimmen.

  7. Tauschen Sie die serverbezogenen Ports aus, indem Sie die serverbezogenen Ports auf dem primären Gerät deaktivieren und die serverbezogenen Ports auf dem Backup gleichzeitig erneut aktivieren. Implementieren Sie dieselbe Konfiguration auf dem Backup und den primären Geräten, um alle Konfigurationen zu ändern, die von der Zeit übrig geblieben sind, als die beiden Geräte Teil des Virtual Chassis waren.

    Deaktivieren Sie beim Backup-QFX zuerst die serverbezogenen Ports auf dem primären Gerät. Die Konfiguration darf nicht konfiguriert werden:

    Aktivieren Sie dann die serverbezogenen Ports auf dem Backup erneut, indem Sie die vorherige Konfiguration löschen. Konfiguration festlegen:

    Wiederholen Sie die Konfiguration für den primären QFX:

  8. Aktualisieren Sie die primäre Routing-Engine. Wenn Sie auf eine Junos-Version 18.2 oder höher aktualisieren, sollten Sie die force-host Option einschließen. Dies setzt fest, dass sowohl das Hostbetriebssystem als auch die Junos-Binärdateien aktualisiert werden und übereinstimmen.

  9. Hinweis:

    Führen Sie diesen Schritt nur aus, wenn das Virtual Chassis nicht vorab bereitgestellt wurde. Wenn virtual Chassis vorkonfiguriert wird, erfolgt die Wahl auf der Grundlage der Systemverfügbarkeit, falls die primäre Routing-Engine nicht vorkonfiguriert ist.

  10. Tauschen Sie die servergerichteten Ports wieder mit dem primären Gerät aus. Aktivieren Sie die servergerichteten Ports auf dem primären Gerät erneut, um die LACP-Konvergenz zu beschleunigen, wenn das Virtual Chassis zurückkommt. Implementieren Sie dieselbe Konfiguration auf dem Backup und den primären Geräten, um alle Konfigurationen zu ändern, die von der Zeit übrig geblieben sind, als die beiden Geräte Teil des Virtual Chassis waren.

    Aktivieren Sie beim Backup-QFX zunächst die servergerichteten Ports auf dem primären Gerät, indem Sie die vorherige Konfiguration löschen. Die Konfiguration darf nicht konfiguriert werden:

    Deaktivieren Sie dann die servergerichteten Ports auf dem Backup und bestätigen Sie die Konfiguration:

    Wiederholen Sie die Konfiguration für den primären QFX:

  11. Aktivieren Sie die VCP-Ports auf beiden Feldern erneut, um das Virtual Chassis neu einzurichten.

  12. Stellen Sie sicher, dass Sie das Virtual Chassis neu eingerichtet haben.

  13. Aktivieren Sie Zugriffsports für beide Mitglieder. Jetzt, da Virtual Chassis neu eingerichtet wurde, müssen wir die Access-Ports neu einrichten, damit wir die primäre Adresse der Routing-Engine em0 für die Kommunikation mit dem neu aktualisierten Virtual Chassis verwenden können.

    Auf dem primären QFX:

    Hinweis:

    Wenn Sie Ihrem zweiköpfigen Virtual Chassis weitere Geräte hinzufügen möchten, aktivieren Sie die geteilte Erkennung erneut.

    Sie haben Ihr zweiköpfiges Virtual Chassis aktualisiert.

Schlussfolgerung

Virtual Chassis ist ein wichtiges Architekturdesign für hohe Verfügbarkeit von Datencentern. Sie wissen jetzt, wie Sie ein zweiköpfiges Virtual Chassis der QFX-Serie manuell aktualisieren können, mit minimalen Auswirkungen auf Ihre Datencenter-Workloads. Verwenden Sie die in diesem Dokument beschriebene Prozedur, um Virtual Chassis mit einer ähnlichen Topologie zu aktualisieren, wenn NSSU nicht verfügbar ist oder nicht wünschenswert ist.