NSX-T Data Center マルチサイト

NSX-T Data Center は複数サイトの展開をサポートしており、1 つの NSX Manager クラスタからすべてのサイトを管理できます。

複数サイトの展開では、2 つのタイプがサポートされています。

ディザスタリカバリ
アクティブ/アクティブ

次の図に、ディザスタリカバリの展開を示します。

アクティブ/アクティブ展開で、すべてのサイトがアクティブであり、レイヤー 2 トラフィックがサイトの境界を越えて広がります。ディザスタリカバリの展開では、プライマリサイトの NSX-T Data Center は企業のネットワークを処理します。セカンダリサイトは、プライマリサイトで致命的な障害が発生した場合に引き継ぐ準備をしています。

次の図に、アクティブ/アクティブ展開を示します。

管理プレーンとデータプレーンのリカバリを自動、手動またはスクリプトで行うため、2 つのサイトを展開できます。

管理プレーンの自動リカバリ

要件：

拡張された vCenter Server クラスタでサイト間の HA が構成されている必要があります。
管理 VLAN が拡張されている必要があります。

NSX Manager クラスタは管理 VLAN に展開され、プライマリサイトに物理的に配置されます。プライマリサイトに障害が発生した場合、vSphere HA はセカンダリサイトの NSX Manager を再起動します。すべてのトランスポートノードが、再起動された NSX Manager に自動的に再接続します。このプロセスには約 10 分間かかります。この間、管理プレーンは使用できませんが、データプレーンは影響を受けません。

次の図に、管理プレーンの自動リカバリを示します。

障害発生前：

管理プレーンの自動リカバリ（ディザスタリカバリ前）

ディザスタリカバリ後：

管理プレーンの自動リカバリ（ディザスタリカバリ後）

データプレーンの自動リカバリ

Edge ノードに障害ドメインを構成して、データプレーンの自動リカバリを実現できます。異なる障害ドメインで Edge クラスタ内の Edge ノードをグループ化できます。NSX Manager は、優先障害ドメインに新しいアクティブ Tier-1 ゲートウェイを自動的に配置し、もう一方のドメインにスタンバイ Tier-1 ゲートウェイを自動的に配置します。

要件：

Edge ノード間の最大遅延が 10 ミリ秒でなければなりません。
Tier-0 ゲートウェイの HA モードがアクティブ/スタンバイで、フェイルオーバーモードがプリエンプティブに設定されている必要があります。
非対称ルーティングが可能な場合（たとえば、2 つの場所が 2 つの建物にあり、その間に物理ファイアウォールがない場合）、Tier-0 ゲートウェイの HA モードをアクティブ/アクティブにすることができます。

注：Tier-1 ゲートウェイのフェイルオーバーモードはプリエンプティブまたは非プリエンプティブのいずれかですが、Tier-0 ゲートウェイと Tier-1 ゲートウェイが同じ場所にあることを保証するために、プリエンプティブを使用することをお勧めします。

構成手順:

API を使用して、2 つのサイト（たとえば、FD1A-Preferred_Site1 と FD2A-Preferred_Site1）に障害ドメインを作成します。プライマリサイトの場合は preferred_active_edge_services パラメータを true に設定し、セカンダリサイトの場合は false に設定します。
```
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"
}
```
API を使用して、2 つのサイト間で拡張された Edge クラスタを構成します。たとえば、クラスタのプライマリサイトに Edge ノード EdgeNode1A と EdgeNode1B があり、セカンダリサイトに Edge ノード EdgeNode2A と EdgeNode2B があるとします。アクティブな Tier-0 および Tier-1 ゲートウェイは EdgeNode1A と EdgeNode1B で実行されます。スタンバイの Tier-0 および Tier-1 ゲートウェイは EdgeNode2A と EdgeNode2B で実行されます。

API を使用して、各 Edge ノードをサイトの障害ドメインと関連付けます。最初に GET /api/v1/transport-nodes/<transport-node-id> API を呼び出して、Edge ノードに関するデータを取得します。GET API の結果を PUT /api/v1/transport-nodes/<transport-node-id> API の入力として使用し、追加のプロパティ failure_domain_id を適切に設定します。次はその例です。

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>",
}

API を使用して、障害ドメインに基づいてノードを割り当てるように Edge クラスタを構成します。最初に GET /api/v1/edge-clusters/<edge-cluster-id> API を呼び出して、Edge クラスタに関するデータを取得します。GET API の結果を PUT /api/v1/edge-clusters/<edge-cluster-id> API の入力として使用し、追加のプロパティ allocation_rules を適切に設定します。次はその例です。

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"
                      }
        }
    ],
}

API または NSX Manager のユーザーインターフェイスを使用して、Tier-0 および Tier-1 ゲートウェイを作成します。

プライマリサイト全体で障害が発生した場合、セカンダリサイトの Tier-0 スタンバイと Tier-1 スタンバイが自動的に処理を引き継ぎ、新しいアクティブゲートウェイになります。プライマリサイトの Edge ノードの 1 つで障害が発生した場合も、同じ原則が適用されます。たとえば、次の図では Edge ノード 1B が Tier-0-Test と Tier-1-Test をホストしています。Edge ノード 2A は Tier-0-Test スタンバイをホストし、Edge ノード 2B は Tier-1-Test スタンバイをホストしています。Edge ノード 1B で障害が発生した場合、Edge ノード 2A とスタンバイ Tier-0-Test と Edge ノード 2B の Tier-1-Test が処理を引き継ぎ、新しいアクティブゲートウェイになります。

次の図に、データプレーンの自動リカバリを示します。

障害発生前：

データプレーンの自動リカバリ（ディザスタリカバリ前）

ディザスタリカバリ後：

データプレーンの自動リカバリ（ディザスタリカバリ後）

手動/スクリプトによる管理プレーンのリカバリ

要件：

NSX Manager の DNS に短い TTL（たとえば 5 分）が設定されている必要があります。
バックアップが継続的に行われている必要があります。

vSphere HA または拡張された管理 VLAN は必要ありません。NSX-T Manager が、短い TTL の DNS 名に関連付けられている必要があります。すべてのトランスポートノード（Edge ノードとハイパーバイザー）が、DNS 名を使用して NSX Manager に接続する必要があります。時間を節約するため、セカンダリサイトに NSX Manager クラスタをプリインストールすることもできます。

リカバリ手順は次のとおりです。

NSX Manager クラスタで異なる IP アドレスを使用できるように DNS レコードを変更します。
NSX Manager クラスタをバックアップからリストアします。
新しい NSX Manager クラスタにトランスポートノードを接続します。

次の図に、手動/スクリプトによる管理プレーンのリカバリを示します。

管理プレーンの手動リカバリ

手動/スクリプトによるデータプレーンのリカバリ

要件：

Edge ノード間の最大遅延が 150 ミリ秒でなければなりません。

Edge ノードには仮想マシンまたはベアメタルを使用できます。各場所の Tier-0 ゲートウェイは、アクティブ/スタンバイまたはアクティブ/アクティブにできます。Edge ノードの仮想マシンは、別の vCenter Server にインストールできます。vSphere HA は必要ありません。

リカバリ手順は次のとおりです。

API を使用して、プライマリ Tier-0 ゲートウェイに接続されている Tier-1 ゲートウェイ（下図の青色）をセカンダリ Tier-0 ゲートウェイ（緑色）に移動します。
API を使用して、スタンドアローン Tier-1 ゲートウェイをセカンダリサイトに移動します。
API を使用して、レイヤー 2 ブリッジをセカンダリサイトに移動します。

次の図に、手動/スクリプトによるデータプレーンのリカバリを示します。

データプレーンの手動リカバリ

複数サイトの展開の要件

サイト間の通信

帯域幅は 1 Gbps 以上で、遅延 (RTT) は 150 ミリ秒未満である必要があります。
MTU は 1,600 以上である必要があります。推奨は 9,000 です。

NSX Manager

管理プレーンの自動リカバリ
- サイト間で拡張された VLAN 管理。
- NSX Manager 仮想マシンのサイト間での vSphere HA。
手動/スクリプトによる管理プレーンのリカバリ
- バックアップが継続的に行われている必要があります。
- FQDN を使用できるように NSX Manager を設定する必要があります。

データプレーン

NAT やロードバランサなどのサービスを介してパブリック IP アドレスを公開する場合は、同じインターネットプロバイダを使用する必要があります。
管理プレーンの自動リカバリ
- 場所間の最大遅延は 10 ミリ秒です。
- 非対称ルーティングが発生しないように、Tier-0 ゲートウェイの HA モードがアクティブ/スタンバイで、フェイルオーバーモードがプリエンプティブに設定されている必要があります。
- 非対称ルーティングが許容される場合（同じ大都市リージョンにある異なる建物など）、Tier-0 ゲートウェイの HA モードをアクティブ/アクティブにすることができます。
手動/スクリプトによる管理プレーンのリカバリ
- 場所間の最大遅延は 150 ミリ秒です。

クラウド管理システム

クラウド管理システム (CMS) は NSX-T Data Center プラグインをサポートする必要があります。このリリースでは、VMware Integrated OpenStack (VIO) および vRealize Automation (vRA) がこの要件を満たしています。

制限事項

Local Egress 機能はありません。すべての North-South トラフィックは 1 つのサイト内で発生する必要があります。
コンピューティングディザスタリカバリソフトウェアが VMware SRM 8.1.2 以降などの NSX-T Data Center をサポートしている必要があります。