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.

Automatische Wiederherstellung der Data Plane

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.

Hinweis: Der Failover-Modus des Ebene-1-Gateways kann präventiv oder nicht präventiv sein.

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.

Wenn ein Edge-Knoten in der primären Site ausfällt, werden die auf diesem Knoten gehosteten Tier-0- und Tier-1-Gateways zu einem Edge-Knoten auf der sekundären Site migriert.

Das folgende Diagramm veranschaulicht die automatische Wiederherstellung der Data Plane.

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/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. Das Tier-0-Gateway kann „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. Erstellen Sie ein Tier-0-Gateway in Standby auf einem vorhandenen Edge-Cluster in der Notfallwiederherstellungs-Site (DR-Site).
  2. Verschieben Sie mithilfe der API die Tier-1-Gateways, die mit einem Tier-0-Gateway verbunden sind, zum Tier-0-Gateway in der DR-Site.
  3. Verschieben Sie die eigenständigen Tier-1-Gateways mithilfe der API in die DR-Site.
  4. Verschieben Sie mithilfe der API die Schicht-2-Bridges auf die DR-Site.

Das folgende Diagramm veranschaulicht die manuelle/skriptbasierte 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-Konfiguration
  • Automatische Sicherung, wenn Änderungen der NSX-T Data Center-Konfiguration aktiviert werden müssen.
  • NSX Manager muss eingerichtet werden, um FQDN verwenden zu können.
Wiederherstellung der Datenebene
  • Derselbe Internetanbieter muss verwendet werden, wenn öffentliche IP-Adressen über Dienste wie NAT oder den Load Balancer verfügbar gemacht werden.
  • Der HA-Modus für das Tier-0-Gateway muss „Aktiv/Standby“ sein, und der Failover-Modus muss „Vorbeugend“ sein.
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 Ausgangsfunktionen. 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.