In diesem Szenario fällt die primäre Site 1 entweder aufgrund einer geplanten Wartung oder eines ungeplanten Stromausfalls aus. Alle Arbeitslasten werden auf der sekundären Site 2 (heraufgestufte primäre Site) ausgeführt und der Datenverkehr wird über die UDLR und NSX Edges auf Site 2 geleitet. Jetzt ist die ursprüngliche primäre Site 1 wieder verfügbar und der NSX-Administrator möchte NSX-Komponenten sowie alle Arbeitslasten auf der ursprünglichen primären Site 1 wiederherstellen.

Der NSX-Administrator sollte die folgenden wichtigen Ziele erfüllen:
  • Erzielen Sie ein vollständiges Failback aller Arbeitslasten von Site 2 zur ursprünglichen primären Site 1 mit minimaler Ausfallzeit.
  • Behalten Sie die Anwendungs-IP-Adressen nach dem Failback auf Site 1 bei.
  • Automatisches Wiederherstellen aller Edge-Schnittstellen- und BGP-Protokoll-Konfigurationseinstellungen auf Site 1.
Hinweis:
  • Der Administrator kann die Failback-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 APIs zum Ausführen während des Failbacks enthält, einige Failback-Aufgaben automatisieren. In diesem Szenario werden Schritte des manuellen Failbacks 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.

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.
  • Bei Site 2 (heraufgestuft primär) werden vor Initiierung des Failback-Vorgangs keine Änderungen an den universellen logischen Komponenten vorgenommen.

Prozedur

  1. Wenn die primäre Site 1 erneut verfügbar ist, stellen Sie sicher, dass der NSX Manager und die Controller-Cluster-Knoten eingeschaltet sind und ausgeführt werden.
    1. Navigieren Sie zu Netzwerk und Sicherheit (Networking & Security) > Dashboard > Überblick (Overview).
    2. Wählen Sie den primären NSX Manager aus dem Dropdown-Menü aus.
    3. Überprüfen Sie im Fenster Systemüberblick den Status des NSX Manager und der Controller-Cluster-Knoten.
      Ein ausgefüllter grüner Punkt neben dem NSX Manager und den Controller-Knoten bedeutet, dass beide NSX-Komponenten eingeschaltet sind und ausgeführt werden.
  2. Überprüfen Sie vor der Initiierung des Failback-Vorgangs Folgendes:
    1. Navigieren Sie auf der Seite Installation und Upgrade zu Management > NSX Manager (NSX Managers) und stellen Sie sicher, dass die NSX Manager auf beiden Sites eine primäre Rolle haben.
    2. Stellen Sie auf der Seite NSX Controller-Knoten sicher, dass die UCC-Knoten (Universal Controller Cluster) auf beiden Sites vorhanden sind.
  3. Schalten Sie alle drei UCC-Knoten ab, die Site 2 (heraufgestuft primär) zugeordnet sind.
  4. Löschen Sie auf der Seite NSX Controller-Knoten alle drei UCC-Knoten, die Site 2 (heraufgestuft primär) zugeordnet sind.
    Tipp: Sie können die NSX-REST-APIs verwenden, um jeweils einen Controller-Knoten zu entfernen, indem Sie den folgenden API-Aufruf ausführen: https://NSX_Manager_IP/api/2.0/vdn/controller/{controllerID}. Erzwingen Sie jedoch das Löschen des letzten Controller-Knotens durch Ausführen des folgenden API-Aufrufs: https://NSX_Manager_IP/api/2.0/vdn/controller/{controllerID}?forceRemoval=true.
  5. Stellen Sie vor dem Fortfahren mit dem nächsten Schritt sicher, dass keine Änderungen bei den globalen Komponenten auf Site 2 (heraufgestuft primär) vorgenommen wurden.
  6. Entfernen Sie die primäre Rolle des NSX Manager auf Site 2 (heraufgestuft primär).
    1. Navigieren Sie auf der Seite Installation und Upgrade zu Management > NSX Manager (NSX Managers).
    2. Wählen Sie den NSX Manager auf Site 2 und klicken Sie auf Aktionen (Actions) > Primäre Rolle entfernen (Remove Primary Role).
      Sie werden durch eine Meldung dazu aufgefordert, sicherzustellen, dass die Controller im Besitz des NSX Manager auf Site 2 gelöscht werden, bevor Sie die primäre Rolle entfernen.
    3. Klicken Sie auf Ja (Yes).
      Der NSX Manager auf Site 2 wechselt in eine Transit-Rolle.
  7. Entfernen Sie beim primären NSX Manager auf Site 1 den zugeordneten sekundären NSX Manager.
    1. Wählen Sie auf der Seite NSX Manager den NSX Manager, der Site 1 zugeordnet ist.
    2. Klicken Sie auf Aktionen (Actions) > Sekundären Manager entfernen (Remove Secondary Manager).
    3. Aktivieren Sie das Kästchen Vorgang ausführen, auch wenn der Zugriff auf NSX Manager nicht möglich ist (Perform Operation even if NSX Manager is inaccessible).
    4. Klicken Sie auf Entfernen (Remove).
  8. Registrieren Sie den NSX Manager auf Site 2, der sich im Transit befindet, als den sekundären des primären NSX Manager auf Site 1.
    Vorsicht: Da der lokale Ausgang auf der UDLR-Kontroll-VM (Edge-Appliance-VM) deaktiviert ist, wird die Kontroll-VM automatisch gelöscht. Stellen Sie aus diesem Grund vor der Registrierung des NSX Managers auf Site 2 (zurzeit mit Transit-Rolle) mit einer sekundären Rolle sicher, dass die Controller-Cluster-Knoten auf Site 2 gelöscht werden. Wenn die Controller-Cluster-Knoten nicht gelöscht werden, kann eine Unterbrechung des Netzwerkdatenverkehrs auftreten.
    1. Navigieren Sie auf der Seite Installation und Upgrade zu Management > NSX Manager (NSX Managers).
    2. Wählen Sie den NSX Manager, der Site 1 zugeordnet ist.
    3. Klicken Sie auf Aktionen (Actions) > Sekundären Manager hinzufügen (Add Secondary Manager).
    4. Wählen Sie den NSX Manager, der Site 2 zugeordnet ist.
    5. Geben Sie den Benutzernamen und das Kennwort des NSX Manager auf Site 2 ein und akzeptieren Sie das Sicherheitszertifikat.
    6. Klicken Sie auf Hinzufügen (Add).
    Beachten Sie nach Abschluss dieser Unterschritte folgende Ergebnisse:
    • Der NSX Manager auf Site 1 hat eine primäre Rolle und der NSX Manager auf Site 2 eine sekundäre.
    • Beim NSX Manager auf Site 2 werden drei Schatten-Controller-Knoten mit dem Status „Getrennt“ angezeigt. Die folgende Meldung wird angezeigt: Lesen oder Aktualisieren von Controller-Cluster-Eigenschaften nur auf primärem oder eigenständigem Manager möglich.

      Diese Meldung bedeutet, dass der sekundäre NSX Manager auf Site 2 keine Verbindung zu den Universal Controller Cluster-Knoten des primären NSX Managers auf Site 1 herstellen kann. Allerdings wird die Verbindung nach einigen Sekunden erneut hergestellt und der Status ändert sich in „Verbunden“.

  9. Schalten Sie die Kontroll-VM (Edge-Appliance-VM) auf dem UDLR und die NSX Edges auf Site 1 ein.
    1. Navigieren Sie zu Netzwerk (Networking) > VMs > Virtuelle Maschinen (Virtual Machines).
    2. Klicken Sie mit der rechten Maustaste auf den VM-Namen (VM-ID) der UDLR-Kontroll-VM und klicken Sie auf Einschalten (Power on).
    3. Wiederholen Sie Schritt (b) für die Edge-VMs, die Sie einschalten möchten.
    4. Warten Sie, bis die UDLR-Kontroll-VM und die Edge-VMs aktiv sind und ausgeführt werden, bevor Sie mit dem nächsten Schritt fortfahren.
  10. Stellen Sie sicher, dass die UDLR-Kontroll-VM (Edge-Appliance-VM), die dem sekundären NSX Manager auf Site 2 zugeordnet ist, automatisch gelöscht wird.
    1. Navigieren Sie zu Netzwerk und Sicherheit (Networking & Security) > NSX Edges.
    2. Wählen Sie den sekundären NSX Manager und klicken Sie auf einen UDLR.
    3. Beachten Sie auf der Statusseite, dass keine Edge-Appliance-VM auf dem UDLR bereitgestellt wird.
  11. Aktualisieren Sie den NSX Controller-Status auf der primären Site 1, sodass die Controller-Dienste mit der sekundären Site 2 synchronisiert werden.
    1. Klicken Sie auf der Seite Installation und Upgrade auf NSX Manager (NSX Managers).
    2. Wählen Sie den primären NSX Manager auf Site 1 aus.
    3. Klicken Sie auf Aktionen (Actions) > Controller-Status aktualisieren (Update Controller State).
  12. Migrieren Sie die Arbeitslast-VMs von Site 2 auf Site 1.
    Hinweis: Die Arbeitslast-VMs sind weiterhin auf Site 2 vorhanden. Aus diesem Grund müssen Sie die Arbeitslast-VMs manuell auf Site 1 migrieren.

Ergebnisse

Das manuelle Failback aller NSX-Komponenten und Arbeitslasten von der sekundären Site (Site 2) auf die primäre Site (Site 1) ist abgeschlossen.

Nächste Maßnahme

Überprüfen Sie, ob das Failback auf die primäre Site 1 zu 100 % abgeschlossen ist, indem Sie diese Schritte auf Site 1 ausführen:
  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. Führen Sie eine Kommunikations-Systemstatusprüfung auf jedem Host-Cluster durch, der für NSX vorbereitet wurde.
    1. Navigieren Sie zu Installation und Upgrade (Installation and Upgrade) > Hostvorbereitung (Host Preparation).
    2. Wählen Sie den NSX Manager auf Site 1 aus.
    3. Wählen Sie jeweils einen Cluster aus und überprüfen Sie, ob der Kommunikationskanal-Systemzustand des Clusters UP (Aktiv) ist.
    4. Überprüfen Sie für jeden Host im Cluster, ob der Kommunikationskanal-Systemzustand des Clusters UP (Aktiv) ist.
    5. Ü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 Failback auf Site 1 werden alle Arbeitslasten auf der primären Site 1 ausgeführt und der Datenverkehr wird über den UDLR und die NSX Edges auf Site 1 geleitet.