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.


Bereitstellung für mehrere Sites für die Notfallwiederherstellung

In einer Aktiv-Aktiv-Bereitstellung sind alle Sites aktiv, und Datenverkehr der Schicht 2 überschreitet die Site-Grenzen. 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.


Aktiv-aktive Bereitstellung für mehrere Sites

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 siteübergreifende 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, aber die Data Plane wird nicht beeinträchtigt.

Das folgende Diagramm veranschaulicht die automatische Wiederherstellung der Management Plane.

Vor dem Notfall:

Automatische Wiederherstellung der Management Plane – vor der Notfallwiederherstellung

Nach der Notfallwiederherstellung:

Automatische Wiederherstellung der Management Plane – nach der Notfallwiederherstellung

Automatische Wiederherstellung der Data Plane

Sie können Fehlerdomänen für Edge-Knoten konfigurieren, um die automatische Wiederherstellung der Datenebene zu erreichen. Sie können Edge-Knoten innerhalb eines Edge-Clusters in unterschiedlichen Fehlerdomänen bereitstellen. 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.

Anforderungen:
  • Die maximale Latenz zwischen Edge-Knoten beträgt 10 ms.
  • Der HA-Modus für das Tier-0-Gateway muss „Aktiv/Standby“ sein, und der Failover-Modus muss „Vorbeugend“ sein.
  • Wenn asymmetrisches Routing möglich ist (z. B. sind die beiden Standorte zwei Gebäude ohne eine physische Firewall zwischen ihnen), kann der HA-Modus für das Tier-0-Gateway „Aktiv/Aktiv“ sein.

Hinweis: 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, der über die beiden Sites ausgedehnt ist. 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. Die aktiven Tier-0- und Tier-1-Gateways werden auf EdgeNode1A und EdgeNode1B ausgeführt. Die Tier-0- und Tier-1-Gateways im Standby werden auf EdgeNode2A und EdgeNode2B ausgeführt.
  • Verknüpfen Sie mithilfe der API jeden Edge-Knoten mit der Fehlerdomäne für die Site. Rufen Sie zuerst die GET /api/v1/transport-nodes/<transport-node-id>-API auf, um die Daten über den Edge-Knoten abzurufen. Verwenden Sie das Ergebnis der GET-API als Eingabe für die PUT /api/v1/transport-nodes/<transport-node-id>-API, wobei die zusätzliche 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. Rufen Sie zuerst die GET /api/v1/edge-clusters/<edge-cluster-id>-API auf, um die Daten über den Edge-Cluster abzurufen. Verwenden Sie das Ergebnis der 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.

Im Falle eines vollständigen Ausfalls 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. Im Falle eines Ausfalls eines der Edge-Knoten auf der primären Site gilt dasselbe Prinzip. Nehmen Sie beispielsweise im folgenden Diagramm an, dass Edge-Knoten 1B Tier-0-Test und Tier-1-Test hostet, Edge-Knoten 2A das Tier-0-Test-Standby und Edge-Knoten 2B das Tier-1-Test-Standby hostet. Wenn der Edge-Knoten 1B ausfällt, übernehmen der Standby-Tier-0-Test auf dem Edge-Knoten 2A und der Standby-Tier-1-Test auf dem Edge-Knoten 2B und werden die neuen aktiven Gateways.

Die folgenden Diagramme veranschaulichen die automatische Wiederherstellung der Datenebene.

Vor dem Notfall:

Automatische Wiederherstellung der Data Plane – vor der Notfallwiederherstellung

Nach der Notfallwiederherstellung:

Automatische Wiederherstellung der Data Plane – nach der Notfallwiederherstellung

Manuelle/skriptbasierte Wiederherstellung der Management Plane

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

Weder vSphere HA noch ein ausgeweitetes Management-VLAN sind erforderlich. NSX-T-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.

Das folgende Diagramm veranschaulicht die manuelle/skriptbasierte Wiederherstellung der Management Plane.

Manuelle Wiederherstellung der Management Plane

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. Edge-Knoten-VMs können auf unterschiedlichen vCenter-Servern installiert werden. vSphere HA ist nicht erforderlich.

Die Wiederherstellung erfolgt mit den folgenden Schritten:
  1. Verschieben Sie mithilfe der API die Tier-1-Gateways, die mit dem primären Tier-0-Gateway (im Diagramm unten blau) verbunden sind, zum sekundären Tier-0-Gateway (grün).
  2. Verschieben Sie mithilfe der API die eigenständigen Tier-1-Gateways auf die sekundäre Site.
  3. Verschieben Sie mithilfe der API die Layer-2-Bridges auf die sekundäre Site.

Das folgende Diagramm veranschaulicht die manuelle/skriptbasierte Wiederherstellung der Data Plane.

Manuelle Wiederherstellung der Data Plane

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.
  • Die MTU muss mindestens 1600 betragen. 9000 wird empfohlen.
NSX Manager
  • Mit automatischer Wiederherstellung der Management Plane
    • VLAN-Verwaltung zwischen Sites ausgeweitet.
    • vSphere HA über Sites hinweg für NSX Manager-VMs.
  • Bei manueller/skriptbasierter Wiederherstellung der Management Plane
    • Kontinuierliche 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
  • Das Cloud-Management-System (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 SRM 8.1.2 oder höher.