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 Apstra auf neuer VM (VM-VM) (empfohlen)

Wir empfehlen Ihnen, Apstra auf einer neuen VM zu aktualisieren (anstatt direkt auf derselben VM), damit Sie Fixes für Ubuntu Linux OS erhalten, einschließlich Updates für Sicherheitslücken. Um den Apstra-Server zu aktualisieren, benötigen Sie Apstra OS-Administrator-Benutzerrechte und Apstra-Admin-Benutzergruppenberechtigungen.

Schritt 1: Validierung vor dem Upgrade

  1. Unter Upgrade-Pfade erfahren Sie, ob Sie ein Upgrade auf eine unterstützte Version durchführen. (Sie finden Ihre aktuelle Apstra-Version, indem Sie in der Apstra-GUI zu Platform > Info navigieren. Ab Apstra-Version 4.2.1 wird die Apstra-Version auch im linken Navigationsmenü der GUI unter dem Juniper Apstra-Logo angezeigt.)
  2. Melden Sie sich beim Apstra-Server als Administrator an (wenn Ihre Apstra-Server-IP-Adresse beispielsweise 10.28.105.3 lautet, lautet der Befehl ).ssh admin@10.28.105.3
  3. Führen Sie den Befehl service aos status aus, um zu überprüfen, ob der Server aktiv ist und keine Probleme aufweist.
  4. In den Versionshinweisen der neuen Apstra-Version finden Sie Änderungen beim Konfigurationsrendering, die sich auf die Data Plane auswirken könnten.
  5. Überprüfen Sie jeden Blueprint, um sicherzustellen, dass sich alle Servicekonfigurationen im Status SUCCEEDED befinden. Falls erforderlich, heben Sie die Bereitstellung der Geräte auf und entfernen Sie sie aus der Blaupause, um alle ausstehenden oder fehlgeschlagenen Servicekonfigurationen aufzulösen.
  6. Überprüfen Sie jeden Blueprint auf Probe-Anomalien und beheben Sie diese so weit wie möglich. Notieren Sie sich alle verbleibenden Anomalien.
  7. Lesen Sie das Apstra-Benutzerhandbuch (Referenzen > Geräte > qualifizierte Geräte und NOS-Versionen), um zu überprüfen, ob die Gerätemodelle und NOS-Versionen für die neue Apstra-Version qualifiziert sind. Führen Sie nach Bedarf ein Upgrade oder Downgrade auf eine der unterstützten Versionen durch. (Ab Version 4.2.0 von Apstra ist der EX4300 veraltet. Ab Apstra-Version 4.2.1 wird das Upgrade blockiert, wenn EX4300-Switches in aktiven Blueprints vorhanden sind.)
  8. Wenn Sie Junos-Geräte verwenden und ein Upgrade auf Apstra Version 4.2.1 durchführen, muss die ursprüngliche Konfiguration die wesentlichen mgmt_junos VRF. Weitere Informationen finden Sie in Artikel KB77094 der Juniper Support Knowledge Base.
    VORSICHT:

    Wenn die ursprüngliche Konfiguration das VRF nicht enthält, schlägt die mgmt_junos Bereitstellung fehl.
  9. Entfernen Sie alle Geräte-AAA-Konfigurationen. Während des Geräteupgrades sind konfigurierte Anmeldeinformationen für den Geräte-Agent für den SSH-Zugriff erforderlich.
  10. Entfernen Sie alle Configlets, die zum Konfigurieren von Firewalls verwendet werden. Wenn Sie die Routing-Engine-Filter der FW auf Geräten verwenden, müssen Sie diese aktualisieren, um die IP-Adresse des neuen Controllers und der Worker-VMs einzuschließen.
  11. Um ein Upgrade der Gerätesystem-Agenten durchzuführen, muss Apstra in der Lage sein, eine SSH-Verbindung zu allen Geräten herzustellen und dabei die Anmeldedaten zu verwenden, die bei der Erstellung der Agenten konfiguriert wurden. Um dies über die Apstra-GUI zu überprüfen, navigieren Sie zu Geräte > verwaltete Geräte, aktivieren Sie die Kontrollkästchen für das/die zu überprüfende(n) Gerät(e) und klicken Sie dann im Menü "Agent" auf die Schaltfläche "Prüfen". Vergewissern Sie sich, dass der Status aller Aufträge SUCCESS ist. Wenn ein Prüfauftrag fehlschlägt, beheben Sie das Problem, bevor Sie mit dem Upgrade von Apstra fortfahren.
  12. Führen Sie als root-Benutzer den Befehl sudo aos_backup aus, um den Apstra-Server zu sichern.
    VORSICHT:

    Der aktualisierte Apstra-Server enthält keine Time Voyager-Revisionen, wenn Sie also zu einem früheren Zustand zurückkehren müssen, ist dieses Backup erforderlich. Frühere Status sind aufgrund der engen Kopplung mit den Referenzdesigns, die sich zwischen den Apstra-Versionen ändern können, nicht enthalten.
  13. Kopieren Sie die Sicherungsdateien von /var/lib/aos/snapshot/<shapshot_name> einem externen Speicherort.
  14. Stellen Sie sicher, dass die neue VM über die erforderlichen Serverressourcen für den Apstra-Server verfügt.

Schritt 2: Bereitstellen des neuen Apstra-Servers

Anmerkung:

Wenn Sie die /etc/aos/aos.conf Datei auf dem alten Apstra-Server angepasst haben (z. B. wenn Sie das metadb Feld aktualisiert haben, um eine andere Netzwerkschnittstelle zu verwenden), müssen Sie die Änderungen erneut auf dieselbe Datei in der neuen Apstra-Server-VM anwenden. Es wird nicht automatisch migriert.
  1. Laden Sie als registrierter Support-Benutzer das Apstra-VM-Image von Juniper Support Downloads (for example, aos_server_4.1.2-269) herunter und übertragen Sie es auf den neuen Apstra-Server.
  2. Installieren und konfigurieren Sie das neue Apstra-VM-Image mit der neuen IP-Adresse (es kann derselbe oder ein neuer FQDN verwendet werden).
  3. Wenn Sie einen Apstra-Cluster (Offbox-Agenten, IBA-Probes) verwenden und Ihre Worker-VMs wiederverwenden möchten, installieren Sie die neue Software, indem Sie .sudo bash aos_<aos_version>.run Wenn Sie neue Worker-VMs verwenden, überspringen Sie diesen Schritt.
    Anmerkung:

    Beispiel für das Ersetzen aller VMs: Wenn Sie einen Controller und 2 Workerknoten haben und alle auf neue VMs aktualisieren möchten, erstellen Sie 3 VMs mit der neuen Apstra-Version und legen eine davon als Controller fest.
  4. Stellen Sie sicher, dass der neue Apstra-Server SSH-Zugriff auf den alten Apstra-Server hat.
  5. Vergewissern Sie sich, dass der neue Apstra-Server die Systemagenten erreichen kann. (Siehe Erforderliche Kommunikationsports.)
  6. Stellen Sie sicher, dass der neue Apstra-Server die entsprechenden externen Systeme (wie NTP, DNS, vSphere-Server, LDAP/TACACs+-Server usw.) erreichen kann.

Schritt 3: Status importieren

VORSICHT:

Wenn Sie API-/GUI-Schreibvorgänge auf dem alten Apstra-Server durchführen, nachdem Sie mit dem Importieren der neuen VM begonnen haben, werden diese Änderungen nicht auf den neuen Apstra-Server kopiert.
  1. Melden Sie sich beim neuen Apstra-Server als Benutzeradministrator an.
  2. Führen Sie den Befehl aus, um SysDB vom alten Server zu importieren, die erforderlichen Übersetzungen anzuwenden und die sudo aos_import_state Konfiguration zu importieren. Geben Sie ggf. die folgenden Argumente an:
    • --ip-address <old-apstra-server-ip>
    • --username <admin-username>
    • Geben Sie für Apstra-Cluster mit neuen Workerknoten-IP-Adressen Folgendes an: --cluster-node-address-mapping <old-node-ip> <new-node-ip>

    • Verwenden Sie Folgendes, um die Überprüfungen der Upgradevoraussetzungen auszuführen, ohne das eigentliche Upgrade auszuführen:--dry-run-connectivity-validation

    • Um die Konnektivitätsüberprüfung nicht zu überprüfen, sollten Sie Folgendes tun: --skip-connectivity-validation

    • Wenn die SSH-Anmeldeinformationen in Ihrer älteren Apstra-Version nicht so streng sind wie die Anforderungen für die neue Apstra-Version, müssen Sie das --override-cluster-node-credentials Argument dem aos_import_state Befehl hinzufügen, wenn Sie Ihre Datenbank in die neue Apstra-Version importieren. Andernfalls schlägt das Upgrade fehl.

    Beispielbefehl: Einzelne VM oder Apstra-Cluster mit denselben Workerknoten

    Beispielbefehl: Apstra-Cluster mit neuen Worker-Knoten

    Im obigen 10.28.105.4 10.28.105.7 Beispiel handelt es sich um alte Workerknoten-IP-Adressen; 10.28.105.6 und 10.28.105.8 sind neue Workerknoten-IP-Adressen.

    Da Root für den Import der Datenbank erforderlich ist, werden Sie zur Eingabe des SSH-Kennworts und des Root-Kennworts für die Remote-Apstra-VM aufgefordert.

    Anmerkung:

    Wenn Sie ein Upgrade eines Apstra-Clusters durchführen, muss das SSH-Passwort für den alten Controller, den alten Worker und den neuen Worker identisch sein, andernfalls schlägt die Authentifizierung fehl. Im obigen Beispiel wird das Kennwort, das Sie für "SSH-Kennwort für Remote-AOS-VM" eingeben, für Remotecontroller-, alte und neue Worker-VMs verwendet. (AOS-27351)

    Wenn Sie das SSH-Kennwort der Worker-VMs nach dem Upgrade ändern, müssen Sie auch das Kennwort des Workers in der Apstra-GUI (Platform > Apstra Cluster > Nodes) aktualisieren.
    Anmerkung:

    Die Größe des Blueprints und die Ressourcen der Apstra-Server-VM bestimmen, wie lange es dauert, bis der Import abgeschlossen ist. Wenn der Datenbankimport den Standardwert überschreitet, kann es zu einer Zeitüberschreitung des Vorgangs kommen. (Der Standardwert ab Apstra 4.1.2 beträgt 40 Minuten oder 2400 Sekunden). In diesem Fall können Sie den Timeout-Wert mit dem AOS_UPGRADE_DOCKER_EXEC_TIMEOUT Befehl erhöhen.

    Mit dem folgenden Befehl wird z. B. die Zeit vor dem Timeout auf 2 Stunden (7200 Sekunden) erhöht.

    admin@aos-server:~$ sudo AOS_UPGRADE_DOCKER_EXEC_TIMEOUT=7200 aos_import_state --ip-address 10.10.10.10 --username admin

    Das Upgradeskript zeigt eine Übersicht der Geräte innerhalb der Fabric, die während des Upgrades Konfigurationsänderungen erhalten. Ab Apstra Version 4.1.2 wird eine Warnung auf dem Bildschirm angezeigt, die empfiehlt, die Versionshinweise und die Dokumentation zu den Upgrade-Pfaden zu lesen, bevor Sie fortfahren. Die Versionshinweise enthalten eine Kategorie für Änderungen beim Konfigurationsrendering ab Version 4.1.2 von Apstra. Konfigurations-Rendering-Änderungen werden oben klar dokumentiert und die Auswirkungen jeder Änderung auf das Netzwerk erläutert.

    Ab Apstra-Version 4.0.1 werden in der Apstra-Upgrade-Zusammenfassung Informationen getrennt nach Geräterollen (z. B. Superspine, Spine, Leaf, Leaf-Paar und Zugriffs-Switch) angezeigt. Wenn anstelle einer vollständigen Konfiguration eine inkrementelle Konfiguration angewendet wurde, werden weitere Details zu den Änderungen angezeigt.

  3. Nachdem Sie die Zusammenfassung überprüft haben, geben Sie die Eingabetaste q ein, um die Zusammenfassung zu beenden. Das Menü AOS-Upgrade: Interaktiv wird angezeigt, in dem Sie die genauen Konfigurationsänderungen auf jedem Gerät überprüfen können. Wenn Sie Configlets verwenden, stellen Sie sicher, dass die neue Konfiguration, die durch das Upgrade per Push übertragen wird, nicht mit vorhandenen Configlets in Konflikt steht.
    VORSICHT:

    Das Apstra-Referenzdesign in der neuen Apstra-Version hat sich möglicherweise so geändert, dass Configlets ungültig werden. Um unerwartete Ergebnisse zu vermeiden, stellen Sie sicher, dass Ihre Configlets nicht mit der neu gerenderten Konfiguration in Konflikt stehen. Wenn Sie Ihre Configlets aktualisieren müssen, beenden Sie das Upgrade, aktualisieren Sie Ihre Configlets, und führen Sie das Upgrade dann erneut aus.
  4. Wenn Sie mit dem Upgrade fortfahren möchten, nachdem Sie ausstehende Änderungen überprüft haben, geben Sie cein.
  5. Wenn Sie das Upgrade beenden möchten, geben q Sie ein, um den Vorgang abzubrechen. Wenn Sie an dieser Stelle kündigen und sich später für ein Upgrade entscheiden, müssen Sie den Prozess von vorne beginnen.
    Anmerkung:

    Wenn das Upgrade von Apstra fehlschlägt (oder bei einer anderen Fehlfunktion), können Sie den neuen Apstra-Server ordnungsgemäß herunterfahren und den alten Apstra-Server neu starten, um den Betrieb fortzusetzen.

Schritt 4: Beibehalten der IP-Adresse der alten VM (optional)

Wenn Sie die IP-Adresse der alten VM beibehalten möchten, müssen Sie die folgenden zusätzlichen Schritte ausführen, bevor Sie den Betriebsmodus ändern und den Agent der Geräte aktualisieren.

  1. Fahren Sie die alte VM herunter, oder ändern Sie ihre IP-Adresse in eine andere Adresse, um die IP-Adresse freizugeben. Dies ist erforderlich, um Probleme mit doppelten IP-Adressen zu vermeiden.
  2. Rufen Sie über die CLI das interaktive Apstra-Menü der neuen VM auf.
  3. Klicken Sie auf Netzwerk, um die IP-Adresse zu aktualisieren und die anderen Parameter zu bestätigen.
  4. Damit die neue IP-Adresse wirksam wird, starten Sie den Netzwerkdienst neu, entweder über dasselbe Menü vor dem Beenden oder über die CLI, nachdem Sie das Menü verlassen haben.

Schritt 5: Ändern Sie den Betriebsmodus auf "Normal"

Wenn Sie ein Apstra-Server-Upgrade initiieren, ändert sich der Betriebsmodus automatisch von "Normal " in "Wartung ". Der Wartungsmodus verhindert, dass Offbox-Agenten vorzeitig online gehen. Es werden keine Konfigurationen gepusht und keine Telemetriedaten abgerufen. Wenn Sie an dieser Stelle die vorherige Apstra-Version weiterhin verwenden möchten, anstatt ein Upgrade durchzuführen, können Sie einfach den neuen Apstra-Server herunterfahren. Wenn Sie sich entscheiden, das Upgrade abzuschließen, ändern Sie den Modus wieder in Normal.

  1. Melden Sie sich bei der Apstra-GUI an.
  2. Wenn Sie ausstehende Änderungen an der Servicekonfiguration anzeigen möchten, navigieren Sie zum Dashboard des Blueprints, und klicken Sie auf AUSSTEHEND, um die betroffenen Geräte anzuzeigen.
  3. Navigieren Sie im linken Navigationsmenü zu Platform > Apstra Cluster > Cluster Management.
  4. Klicken Sie auf die Schaltfläche "Betriebsmodus ändern", wählen Sie "Normal" aus und klicken Sie dann auf "Aktualisieren". Alle Offbox-Agenten, unabhängig davon, ob sie sich auf dem Controller oder in Worker-VMs befinden, gehen automatisch online, verbinden die Geräte erneut und pushen alle ausstehenden Konfigurationsänderungen. Nach einigen Augenblicken werden die temporären Anomalien auf dem Dashboard behoben, und der Abschnitt "Dienstkonfiguration" zeigt an, dass der Vorgang ERFOLGREICH war.

    Sie können auch über den unteren linken Bereich einer beliebigen Seite auf die Seite "Clusterverwaltung " zugreifen. Von hier aus haben Sie auch eine kontinuierliche Sichtbarkeit des Plattformzustands auf der Grundlage von Farben.

    Klicken Sie unten im linken Navigationsmenü auf einen der Punkte und dann auf Betriebsmodus , um zur Clusterverwaltung zu gelangen. Klicken Sie auf die Schaltfläche "Betriebsmodus ändern ", wählen Sie "Normal" aus und klicken Sie dann auf "Aktualisieren".

Schritt 6: Upgrade der Onbox-Agents

Auf dem Apstra-Server und den Onbox-Agenten muss dieselbe Apstra-Version ausgeführt werden. Bei unterschiedlichen Versionen stellen die Agenten keine Verbindung zum Apstra-Server her.

Wenn Sie einen Blueprint für mehrere Bundesstaaten ausführen, insbesondere für 5 Phasen, empfehlen wir, dass Sie die Agents stufenweise aktualisieren: zuerst Superspines, dann Spines, dann Leafs. Wir empfehlen diese Reihenfolge wegen der Pfadsuche. Anstatt alles zu einem Spine oder von einem Spine zu einem Superspine zu leiten, kann das Routing vorübergehend von Leaf zu Spine wieder hinunter zu einem anderen Leaf und dann wieder nach oben zu einem anderen Spine gehen. Um die Wahrscheinlichkeit zu minimieren, dass dies geschieht, empfehlen wir, die Geräte schrittweise zu aktualisieren.

  1. Melden Sie sich bei der Apstra-GUI als Benutzeradministrator an.
  2. Navigieren Sie im linken Navigationsmenü zu Geräte > verwaltete Geräte, und aktivieren Sie die Kontrollkästchen für die zu aktualisierenden Geräte (bis zu 100 Geräte gleichzeitig). Sie können mehrere Onbox-Agenten gleichzeitig aktualisieren, aber die Reihenfolge der Geräteaktualisierung ist wichtig.
    • Aktualisieren Sie zuerst die Agenten für Superspines.
    • Upgrade-Agenten für Spines an zweiter Stelle.
    • Upgrade-Agenten für Leafs drittens.
    Wenn Sie ein oder mehrere Geräte auswählen, werden die Menüs "Gerät" und " Agent" über der Tabelle angezeigt.
  3. Klicken Sie auf die Schaltfläche Installieren, um den Installationsvorgang zu starten.
    Der Auftragsstatus ändert sich in IN BEARBEITUNG. Wenn Agenten eine frühere Version der Apstra-Software verwenden, werden sie automatisch auf die neue Version aktualisiert. Dann stellen sie eine Verbindung zum Server her und übertragen alle anstehenden Konfigurationsänderungen an die Geräte. Die Telemetrie wird ebenfalls fortgesetzt, und der Auftragsstatus ändert sich in SUCCESS.
  4. Vergewissern Sie sich im Abschnitt "Liveness" des Blueprint-Dashboards, dass keine Geräteanomalien vorhanden sind.
    Anmerkung:

    Wenn Sie nach dem Initiieren des Agent-Upgrades ein Rollback auf die vorherige Apstra-Version durchführen müssen, müssen Sie eine neue VM mit der vorherigen Apstra-Version erstellen und die Konfiguration auf dieser VM wiederherstellen. Wenn Sie Unterstützung benötigen, wenden Sie sich an den technischen Support von Juniper.

Schritt 7: Fahren Sie den alten Apstra-Server herunter

  1. Aktualisieren Sie alle DNS-Einträge, um die neue IP/FQDN des Apstra-Servers basierend auf Ihrer Konfiguration zu verwenden.
  2. Wenn Sie einen Proxy für den Apstra-Server verwenden, stellen Sie sicher, dass dieser auf den neuen Apstra-Server verweist.
  3. Fahren Sie den alten Apstra-Server ordnungsgemäß herunter. Ab Apstra Version 4.2.1 wurden Sie gefragt, ob Sie den alten Apstra-Server herunterfahren möchten. Wenn Sie mit Ja geantwortet haben, wird der service aos stop Befehl automatisch ausgeführt, um den alten Apstra-Server für Sie herunterzufahren.
  4. Wenn Sie ein Upgrade für einen Apstra-Cluster durchführen und Ihre Workerknoten durch neue VMs ersetzt haben, fahren Sie auch die alten Worker-VMs herunter.
Nächste Schritte:

Wenn die NOS-Versionen Ihrer Geräte nicht für die neue Apstra-Version qualifiziert sind, führen Sie ein Upgrade auf eine qualifizierte Version durch. (Weitere Informationen finden Sie im Juniper Apstra-Benutzerhandbuch .)