NSX-T Data Center für mehrere Sites

NSX-T Data Center unterstützt Bereitstellungen für mehrere Sites. Dabei können Sie alle Sites von einem zentralen NSX Manager-Cluster aus verwalten.

Zwei Arten von Bereitstellungen für mehrere Sites werden unterstützt:

• Notfallwiederherstellung
• Aktiv-Aktiv

Das folgende Diagramm veranschaulicht eine Bereitstellung für die Notfallwiederherstellung.

In einer Bereitstellung für die Notfallwiederherstellung verarbeitet NSX-T Data Center an der primären Site Netzwerke für das Unternehmen. Die sekundäre Site steht bereit, um zu übernehmen, wenn ein schwerwiegender Fehler an der primären Site auftritt.

Das folgende Diagramm veranschaulicht eine Aktiv-Aktiv-Bereitstellung.

Sie können zwei Sites für die automatische oder manuelle/skriptbasierte Wiederherstellung der Management Plane und der Data Plane bereitstellen.

Automatische Wiederherstellung der Management Plane

Anforderungen:

• Ein ausgeweiteter vCenter-Cluster mit Konfiguration für siteübergreifende Hochverfügbarkeit (HA).
• Ein ausgeweitetes Management-VLAN.

Der NSX Manager-Cluster wird im Management-VLAN bereitgestellt und befindet sich physisch in der primären Site. Wenn eine primäre Site ausfällt, werden die NSX Manager auf der sekundären Site von vSphere HA neu gestartet. Alle Transportknoten werden automatisch erneut mit den neu gestarteten NSX Managern verbunden. Dieser Vorgang dauert ca. 10 Minuten. Während dieser Zeit ist die Management Plane nicht verfügbar. Dies hat keine Auswirkungen auf die Data Plane.

Das folgende Diagramm veranschaulicht die automatische Wiederherstellung der Management Plane.

Vor dem Notfall:

Nach der Notfallwiederherstellung:

Automatische Wiederherstellung der Data Plane

Durch eine automatische Wiederherstellung der Datenebene können Sie Fehlerdomänen für Edge-Knoten konfigurieren. Sie können Edge-Knoten innerhalb eines Edge-Clusters in unterschiedlichen Fehlerdomänen bereitstellen. Der NSX Manager platziert automatisch ein neues aktives Tier-1-Gateway in der bevorzugten Fehlerdomäne und das Standby-Tier-1-Gateway in der anderen Domäne. Tier-1-Gateways, die vor der Erstellung der Fehlerdomäne bereitgestellt wurden, behalten ihre ursprüngliche Edge-Knotenplatzierung bei und werden möglicherweise nicht am gewünschten Ort ausgeführt. Wenn Sie deren Platzierung korrigieren möchten, bearbeiten Sie T1 und wählen Sie die Edge-Knoten für T1-Aktive und T1-Standby-Gateways manuell aus.

Anforderungen:

• Die maximale Latenz zwischen Edge-Knoten beträgt 10 ms.
• Wenn das asymmetrische vertikale Routing nicht möglich ist, z. B. wenn eine physische Firewall in Northbound-Richtung zum NSX Edge-Knoten verwendet wird, muss der HA-Modus für das Tier-0-Gateway Aktiv/Standby sein und der Failover-Modus muss als „Vorbeugend“ festgelegt sein.
• Wenn asymmetrisches North-South-Routing möglich ist, z. B. wenn die beiden Standorte zwei Gebäude ohne zwischengeschaltete physische Firewall sind, kann der HA-Modus für das Tier-0-Gateway „Aktiv/Aktiv“ sein.

Die Edge-Knoten können VMs oder Bare Metal sein. Der Failover-Modus des Tier-1-Gateways kann „Vorbeugend“ oder „Nicht vorbeugend“ sein, aber „Vorbeugend“ wird empfohlen, um sicherzustellen, dass sich die Tier-0- und Tier-1-Gateways am selben Speicherort befinden.

Konfigurationsschritte:

• Erstellen Sie mithilfe der API Fehlerdomänen für die beiden Sites, z. B. FD1A-Preferred_Site1 und FD2A-Preferred_Site1. Setzen Sie den Parameter preferred_active_edge_services auf true für die primäre Site und setzen Sie ihn auf false für die sekundäre Site.

  POST /api/v1/failure-domains
  {
  "display_name": "FD1A-Preferred_Site1",
  "preferred_active_edge_services": "true"
  }
  
  POST /api/v1/failure-domains
  {
  "display_name": "FD2A-Preferred_Site1",
  "preferred_active_edge_services": "false"
  }

• Konfigurieren Sie mithilfe der API einen Edge-Cluster, den Sie über die beiden Sites ausgeweitet haben. Beispielsweise verfügt der Cluster über die Edge-Knoten EdgeNode1A und EdgeNode1B auf der primären Site und die Edge-Knoten EdgeNode2A und EdgeNode2B auf der sekundären Site. Das aktive Tier-0- und das aktive Tier-1-Gateway werden auf EdgeNode1A und EdgeNode1B ausgeführt. Das Standby-Tier-0- und das Standby-Tier-1-Gateway werden auf EdgeNode2A und EdgeNode2B ausgeführt.
• Verknüpfen Sie mithilfe der API jeden Edge-Knoten mit der Fehlerdomäne für die Site. Um die Daten über den Edge-Knoten abzurufen, führen Sie die GET /api/v1/transport-nodes/<transport-node-id>-API aus. Verwenden Sie die GET-API als Eingabe für die PUT /api/v1/transport-nodes/<transport-node-id>-API, wobei die Eigenschaft failure_domain_id entsprechend festgelegt ist. Beispiel:

  GET /api/v1/transport-nodes/<transport-node-id>
  Response:
  
      "resource_type": "TransportNode", 
      "description": "Updated NSX configured Test Transport Node",
      "id": "77816de2-39c3-436c-b891-54d31f580961",
      ...
  }
  
  PUT /api/v1/transport-nodes/<transport-node-id>
  {
      "resource_type": "TransportNode",
      "description": "Updated NSX configured Test Transport Node",
      "id": "77816de2-39c3-436c-b891-54d31f580961",
      ...
      "failure_domain_id": "<UUID>",
  }

• Konfigurieren Sie mithilfe der API den Edge-Cluster, um Knoten basierend auf der Fehlerdomäne zuzuteilen. Um die Daten über den Edge-Cluster abzurufen, führen Sie die GET /api/v1/edge-clusters/<edge-cluster-id>-API aus. Verwenden Sie die GET-API als Eingabe für die PUT /api/v1/edge-clusters/<edge-cluster-id>-API, wobei die zusätzliche Eigenschaft allocation_rules entsprechend festgelegt ist. Beispiel:

  GET /api/v1/edge-clusters/<edge-cluster-id>
  Response:
  {
      "_revision": 0,
      "id": "bf8d4daf-93f6-4c23-af38-63f6d372e14e",
      "resource_type": "EdgeCluster",
      ...
  }
  
  PUT /api/v1/edge-clusters/<edge-cluster-id>
  {
      "_revision": 0,
      "id": "bf8d4daf-93f6-4c23-af38-63f6d372e14e",
      "resource_type": "EdgeCluster",
      ...
      "allocation_rules": [
          {
              "action": {
                        "enabled": true,
                        "action_type": "AllocationBasedOnFailureDomain"
                        }
          }
      ],
  }

• Erstellen Sie Tier-0- und Tier-1-Gateways mithilfe der API oder der NSX Manager-Benutzeroberfläche.

Bei einem vollständigen Ausfall der primären Site übernehmen das Tier-0- und Tier-1-Standby auf der sekundären Site automatisch und werden zu den neuen aktiven Gateways.

Die folgenden Diagramme veranschaulichen die automatische Wiederherstellung der Datenebene.

Vor dem Notfall:

Nach der Notfallwiederherstellung:

Wichtig: Dasselbe Prinzip gilt, wenn einer der Edge-Knoten auf der primären Site, nicht aber die gesamte Site ausfällt. Beispiel: Im Diagramm „Vor dem Ausfall“ wird davon ausgegangen, dass Edge-Knoten 1B „tier-1“(blau) aktiv hostet und dass Edge-Knoten 2B „tier-1“ (blau) im Standby-Modus hostet. Wenn der Edge-Knoten 1B ausfällt, übernimmt das im Standby-Modus gehostete Gateway „tier-1“ (blau) auf Edge-Knoten 2B und wird zum neuen aktiven Gateway „tier-1“ (blau).

Manuelle/skriptbasierte Wiederherstellung der Management Plane

Anforderungen:

• DNS für NSX Manager mit einer kurzen TTL (z. B. 5 Minuten).
• Kontinuierliche NSX Manager-Sicherung.

Weder vSphere HA noch ein ausgeweitetes Management-VLAN sind erforderlich. NSX-T Data Center Manager müssen mit einem DNS-Namen mit einer kurzen TTL verknüpft sein. Alle Transportknoten (Edge-Knoten und Hypervisoren) müssen mit ihrem DNS-Namen eine Verbindung mit dem NSX Manager herstellen. Um Zeit zu sparen, können Sie optional einen NSX Manager-Cluster auf der sekundären Site vorab installieren.

Die Wiederherstellung erfolgt mit den folgenden Schritten:

1. Ändern des DNS-Eintrags, sodass der NSX Manager-Cluster unterschiedliche IP-Adressen hat.
2. Wiederherstellen des NSX Manager-Clusters aus einer Sicherung.
3. Verbinden der Transportknoten mit dem neuen NSX Manager-Cluster.

Die folgenden Diagramme veranschaulichen die manuelle/skriptbasierte Wiederherstellung der Management Plane.

Vor dem Notfall:

Nach dem Ausfall:

Manuelle/skriptbasierte Wiederherstellung der Data Plane

Anforderung: Die maximale Latenz zwischen Edge-Knoten beträgt 150 ms.

Die Edge-Knoten können VMs oder Bare Metal sein. Die Tier-0-Gateways an jedem Standort können „Aktiv/Standby“ oder „Aktiv/Aktiv“ sein. Sie können Edge-Knoten-VMs in verschiedenen vCenter-Servern installieren. vSphere HA ist nicht erforderlich.

Die Wiederherstellung erfolgt mit den folgenden Schritten:

• Aktualisieren Sie für alle „tier-1“-Instanzen auf der primären Site (blau) die Edge-Clusterkonfiguration als sekundäre Edge-Cluster-Site.
• Verbinden Sie sie alle „tier-1“-Instanzen auf der primären Site (blau) erneut mit der sekundären Site „T0“ (grün).

Die folgenden Diagramme veranschaulichen die manuelle/skriptbasierte Wiederherstellung der Datenebene sowohl mit der logischen als auch mit der physischen Netzwerkansicht.

Vor dem Ausfall (logische und physische Ansichten):

Nach dem Ausfall (logische und physische Ansichten):

Voraussetzungen für Bereitstellungen für mehrere Sites

Site-übergreifende Kommunikation

• Die Bandbreite muss mindestens 1 GBit/s betragen und die Latenz (RTT) muss kleiner als 150 ms sein.
• Legen Sie die MTU auf 9000 fest. Der Wert muss mindestens auf 1600 festgelegt sein.

NSX Manager

• Mit automatischer Wiederherstellung der Management Plane mit einer VLAN-Verwaltung, die sich über mehrere Sites erstreckt. vSphere HA über Sites hinweg für NSX Manager-VMs.
• Mit manueller/skriptgestützter Wiederherstellung der Management Plane mit VLAN-Verwaltung, die sich über mehrere Sites erstreckt. VMware SRM für NSX Manager VMs.
• Mit manueller/skriptbasierter Wiederherstellung der Management Plane, ohne dass die VLAN-Verwaltung zwischen den Sites ausgeweitet wird.
  • Kontinuierliche NSX Manager-Sicherung.
  • NSX Manager muss eingerichtet werden, um FQDN verwenden zu können.

Data Plane

• Derselbe Internetanbieter muss verwendet werden, wenn öffentliche IP-Adressen über Dienste wie NAT oder den Load Balancer verfügbar gemacht werden.
• Mit automatischer Wiederherstellung der Management Plane
  • Die maximale Latenz zwischen Standorten beträgt 10 ms.
  • Der HA-Modus für das Tier-0-Gateway muss „Aktiv/Standby“ sein und der Failover-Modus muss „Vorbeugend“ sein, um ein asymmetrisches Routing garantiert auszuschließen.
  • Der HA-Modus für das Tier-0-Gateway kann „Aktiv/Aktiv“ sein, wenn asymmetrisches Routing akzeptabel ist (z. B. verschiedene Gebäude in einer Metropolregion).
• Bei manueller/skriptbasierter Wiederherstellung der Management Plane
  • Die maximale Latenz zwischen Standorten beträgt 150 ms.

Cloud Management System (CMS)

• Das CMS muss ein NSX-T Data Center-Plug-In unterstützen. In dieser Version erfüllen VMware Integrated OpenStack (VIO) und vRealize Automation (vRA) diese Anforderung.

Einschränkungen

• Keine lokalen Egress-Funktionen. Der gesamte Nord-Süd-Datenverkehr muss innerhalb derselben Site stattfinden.
• Die Software für die Notfallwiederherstellungsberechnung muss NSX-T Data Center unterstützen, z. B. VMware Site Recovery Manager 8.1.2 oder höher.
• Führen Sie beim Wiederherstellen des NSX Managers in einer Umgebung mit mehreren Sites auf der sekundären/primären Site die folgenden Schritte aus:
  • Nachdem der Wiederherstellungsvorgang im Schritt AddNodeToCluster angehalten wurde, müssen Sie zuerst die vorhandene VIP entfernen und die neue virtuelle IP auf der Seite System > Appliances-Benutzeroberfläche festlegen.
  • Fügen Sie einem wiederhergestellten Cluster mit einem Knoten neue Knoten hinzu, nachdem die VIP aktualisiert wurde.