In diesem Szenario führt der NSX-Administrator eine geplante Wartung der Netzwerkinfrastruktur auf Site 1 durch. Während des geplanten Wartungsfensters fährt der Administrator Site 1 herunter und führt einen reibungslosen Failover auf die sekundäre Site 2 durch.

Der NSX-Administrator sollte die folgenden wichtigen Ziele erfüllen:
  • Erreichen eines vollständigen Site-Failovers auf Site 2 mit minimalem Ausfall.
  • Beibehalten der Anwendungs-IP-Adressen von Site 1 auf Site 2 nach dem Failover.
  • Automatisches Wiederherstellen aller Edge-Schnittstellen- und BGP-Protokoll-Konfigurationseinstellungen auf Site 2.
Hinweis:
  • Der Administrator kann die Failover-Aufgaben manuell mithilfe von vSphere Web Client oder durch Ausführen der NSX-REST-APIs durchführen. Darüber hinaus kann der Administrator durch Ausführen einer Skriptdatei, die die während des Failovers auszuführenden APIs enthält, einige Failover-Aufgaben automatisieren. In diesem Szenario werden Schritte des manuellen Failovers erklärt, die vSphere Web Client verwenden. Wenn bei einem Schritt allerdings die Verwendung der CLI oder der NSX-REST-APIs erforderlich ist, werden angemessene Anweisungen bereitgestellt.
  • In diesem Szenario bezieht sich der Workflow zur Notfallwiederherstellung speziell auf die zuvor erläuterte Topologie mit einem primären NSX Manager und einem einzelnen sekundären NSX Manager. Der Workflow mit mehreren sekundären NSX Manager wird bei diesem Szenario nicht abgedeckt.
Wichtig: Wenn das Failover auf die sekundäre Site 2 ausgeführt wird oder teilweise abgeschlossen ist, vermeiden Sie, NSX Manager auf Site 1 zum Failback auf die primäre Site 1 einzuschalten. Stellen Sie sicher, dass der Failover-Vorgang zuerst mithilfe des Verfahrens in diesem Szenario abgeschlossen wird. Stellen Sie erst nach einem fehlerfreien Failover zur sekundären Site 2 alle Arbeitslasten auf der ursprünglichen primären Site 1 wieder her bzw. führen Sie für sie ein Failback durch. Detaillierte Anweisungen zum Failback-Prozess finden Sie unter Szenario 3: Vollständiges Failback zur primären Site.

Voraussetzungen

  • NSX Data Center 6.4.5 oder höher ist auf den Sites 1 und 2 installiert.
  • vCenter Server auf den Sites 1 und 2 wird im erweiterten verknüpften Modus bereitgestellt.
  • Sites 1 und 2 erfüllen folgende Bedingungen:
    • Keine anwendungsspezifischen Sicherheitsrichtlinien sind für eine etwaige Nicht-NSX-Firewall konfiguriert.
    • Keine anwendungsspezifischen Firewallregeln sind für eine etwaige Nicht-NSX-Firewall konfiguriert.
    • Firewall ist auf beiden ESGs deaktiviert, da ECMP auf den UDLRs aktiviert ist und um sicherzustellen, dass jeder Datenverkehr zugelassen wird.
  • Site 2 erfüllt folgende Bedingungen vor dem Failover:
    • Ähnliche Downlink-Schnittstellen werden auf den ESGs manuell wie bei Site 1 konfiguriert.
    • Ähnliche BGP-Konfigurationen wie bei Site 1 werden auf den ESGs manuell vorgenommen.
    • ESGs befinden sich im ausgeschalteten Zustand, wenn die primäre Site 1 aktiv ist oder ausgeführt wird.

Prozedur

  1. Fahren Sie Site 1 zum geplanten Datum herunter.
    1. Schalten Sie den primären NSX Manager und alle drei Controller-Knoten ab, die dem primären NSX Manager zugeordnet sind.
    2. Navigieren Sie auf der Seite Installation und Upgrade zu Management > NSX Manager (NSX Managers).
      • Wenn Sie die Seite NSX Manager in der aktuellen Browsersitzung aktualisieren, ändert sich die Rolle des primären NSX Manager in Unbekannt.
      • Wenn Sie sich bei vSphere Web Client abmelden und erneut anmelden oder eine neue vSphere Web Client-Browsersitzung starten, wird der primäre NSX Manager nicht mehr auf der Seite NSX Manager angezeigt.
    3. Navigieren Sie zu Netzwerk und Sicherheit (Networking & Security) > Dashboard > Überblick (Overview).
      • Wenn Sie die Seite Dashboard in der aktuellen Browsersitzung aktualisieren, wird folgende Fehlermeldung angezeigt: Es konnte keine Verbindung mit NSX Manager hergestellt werden. Wenden Sie sich an den Administrator.. Dieser Fehler bedeutet, dass der primäre NSX Manager nicht mehr erreichbar ist.
      • Wenn Sie sich bei vSphere Web Client abmelden und erneut anmelden oder eine neue vSphere Web Client-Browsersitzung starten, ist der primäre NSX Manager nicht mehr im NSX Manager-Dropdown-Menü verfügbar.
    4. Navigieren Sie zu Netzwerk und Sicherheit (Networking & Security) > Installation und Upgrade (Installation and Upgrade) > Management > NSX Controller-Knoten (NSX Controller Nodes). Wählen Sie den sekundären NSX Manager und stellen Sie sicher, dass der Status aller drei Controller-Knoten Getrennt ist.
    5. Schalten Sie alle NSX Edges und die UDLR-Kontroll-VM (Universal Distributed Logical Router) aus.
  2. Heraufstufen eines sekundären NSX Manager zu einer primären Rolle
    1. Navigieren Sie auf der Seite Installation und Upgrade zu Management > NSX Manager (NSX Managers).
    2. Wählen Sie den sekundären NSX Manager.
    3. Klicken Sie auf Aktionen (Actions) > Von primärem NSX Manager trennen (Disconnect from Primary NSX Manager). Wenn Sie dazu aufgefordert werden, mit dem Trennvorgang fortzufahren, klicken Sie auf Ja (Yes).
      Der sekundäre NSX Manager wird vom primären NSX Manager getrennt und erhält eine Transit-Rolle.
    4. Klicken Sie auf Aktionen (Actions) > Primäre Rolle zuweisen (Assign Primary Role).
      Der sekundäre NSX Manager auf Site 2 wird zu einer primären Rolle heraufgestuft.
    Vorsicht: Durch Deaktivieren des lokalen Ausgangs auf dem UDLR wird die UDLR-Kontroll-VM (Edge-Appliance-VM) nur auf der ursprünglichen primären Site (Site 1) bereitgestellt. Vor dem Fehlschlagen von Site 1 ist die UDLR-Kontroll-VM auf der sekundären Site (Site 2) nicht verfügbar, die jetzt zur primären Rolle heraufgestuft wird. Stellen Sie aus diesem Grund die UDLR-Kontroll-VM auf der heraufgestuften primären Site (Site 2) erneut bereit, bevor Sie das NSX Controller-Cluster erneut bereitstellen.

    Wenn die Controller-Knoten vor der Bereitstellung der UDLR-Kontroll-VM bereitgestellt werden, werden die Weiterleitungstabellen auf dem UDLR geleert. Dies führt zu einem Ausfall unmittelbar nach der Bereitstellung des ersten Controller-Knotens auf Site 2. Diese Situation kann zu Kommunikationsausfällen führen. Um das zu vermeiden, stellen Sie die UDLR-Kontroll-VM vor der Bereitstellung der NSX Controller-Knoten bereit.

  3. Schalten Sie die NSX Edge ein, die sich im heruntergefahrenen Zustand befinden, und stellen Sie die UDLR-Kontroll-VM (Edge-Appliance-VM) auf der sekundären Site 2 (heraufgestuft primär) bereit.
    Anweisungen zum Bereitstellen der UDLR-Kontroll-VM finden Sie im NSXCross-vCenter-Installationshandbuch.
    Während der Bereitstellung der UDLR-Kontroll-VM konfigurieren Sie die folgenden Ressourceneinstellungen:
    • Wählen Sie das Datencenter als Site 2 aus.
    • Wählen Sie des Cluster/den Ressourcenpool.
    • Wählen Sie den Datenspeicher aus.
    Hinweis: Nach der Bereitstellung der UDLR-Kontroll-VM werden folgende Konfigurationseinstellungen auf Site 2 automatisch wiederhergestellt:
    • BGP-Protokoll-Routing-Konfiguration
    • BGP-Kennwortkonfiguration
    • Uplink- und interne Schnittstelleneinstellungen
  4. Stellen Sie die drei NSX Controller-Cluster-Knoten auf Site 2 (heraufgestuft primär) bereit.
    Detaillierte Anweisungen zum Bereitstellen von NSX Controller finden Sie im NSXCross-vCenter-Installationshandbuch.
  5. Aktualisieren Sie den NSX Controller-Cluster-Zustand.
    1. Klicken Sie auf der Seite Installation und Upgrade auf NSX Manager (NSX Managers).
    2. Wählen Sie den heraufgestuften primären NSX Manager.
    3. Klicken Sie auf Aktionen (Actions) > Controller-Status aktualisieren (Update Controller State).
  6. Erzwingen Sie den Synchronisierungs-Routing-Dienst auf jedem Cluster auf Site 2.
    1. Klicken Sie auf der Seite Installation und Upgrade auf Hostvorbereitung (Host Preparation).
    2. Wählen Sie den heraufgestuften primären NSX Manager.
    3. Wählen Sie gleichzeitig einen Cluster aus und klicken Sie auf Aktionen (Actions) > ForceSync-Dienste (Force Sync Services).
    4. Wählen Sie Routing aus und klicken Sie auf OK.
  7. Migrieren Sie die Arbeitslast-VMs von Site 1 auf Site 2.
    Hinweis: Die Arbeitslast-VMs sind weiterhin auf Site 1 vorhanden. Aus diesem Grund müssen Sie die Arbeitslast-VMs manuell auf Site 2 migrieren.

Ergebnisse

Die manuelle Wiederherstellung von NSX-Komponenten und das Failover von der primären Site (Site 1) auf die sekundäre Site (Site 2) ist abgeschlossen.

Nächste Maßnahme

Überprüfen Sie, ob das Failover auf Site 2 zu 100 % abgeschlossen ist, indem Sie diese Schritte auf Site 2 ausführen (heraufgestufte primäre Site):
  1. Überprüfen Sie, ob der NSX Manager über die primäre Rolle verfügt.
  2. Überprüfen Sie, ob die Kontroll-VM (Edge-Appliance-VM) auf dem UDLR bereitgestellt wird.
  3. Überprüfen Sie, ob der Status aller Controller-Cluster-Knoten Verbunden ist.
  4. Überprüfen Sie, ob der Hostvorbereitungsstatus Grün ist.
  5. Melden Sie sich bei der CLI-Konsole der UDLR-Kontroll-VM (Edge-Appliance-VM) an und führen Sie diese Schritte aus:
    1. Prüfen Sie, ob alle BGP-Nachbarn eingerichtet sind und der Status UP (Aktiv) ist, indem Sie den Befehl show ip bgp neighbors ausführen.
    2. Überprüfen Sie, ob alle BGP-Routen über alle BGP-Nachbarn abgerufen werden, indem Sie den Befehl show ip route bgp ausführen.

Nach einem abgeschlossenen Failover auf Site 2 werden alle Arbeitslasten auf der sekundären Site (heraufgestuft primär) ausgeführt und der Datenverkehr wird über den UDLR und die NSX Edges auf Site 2 geleitet.

Nach Abschluss der geplanten Wartung schaltet der Administrator die NSX Manager- und Controller-Cluster-Knoten auf der primären Site 1 ein und stellt alle Arbeitslasten auf der ursprünglichen primären Site 1 wieder her. Detaillierte Anweisungen zur Durchführung eines manuellen Failback zur primären Site finden Sie unter Szenario 3: Vollständiges Failback zur primären Site.