NSX マルチサイト

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

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

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

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

この図は、プライマリサイトと、SRM でレプリケートされた仮想マシンのあるセカンダリサイトを含むマルチサイトのディザスタリカバリの展開を示しています。

ディザスタリカバリの展開では、プライマリサイトの NSX は企業のネットワークを処理します。セカンダリサイトは、プライマリサイトで致命的な障害が発生した場合に引き継ぐ準備をしています。

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

この図では、プライマリとセカンダリの両方のサイトに L2 が拡張されている 2 つのアクティブサイトが、プライマリとセカンダリの両方の T0 ゲートウェイと通信しています。

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

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

要件：

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

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

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

障害発生前：

管理プレーンの自動リカバリ後のセカンダリサイトノードを示しています。プライマリサイトの NSX Manager に再接続しています

ディザスタリカバリ後：

ディザスタリカバリ後にセカンダリサイトを示します。プライマリサイトから NSX Manager が移動され、トランスポートノード接続が再接続されています。

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

Edge ノードに障害ドメインを構成して、データプレーンの自動リカバリを実現できます。異なる障害ドメインで Edge クラスタ内の Edge ノードをグループ化できます。NSX Manager は、優先障害ドメインに新しいアクティブ Tier-1 ゲートウェイを自動的に配置し、もう一方のドメインにスタンバイ Tier-1 ゲートウェイを自動的に配置します。障害ドメインの作成前に展開された T1 ゲートウェイは、元の Edge ノードの配置を維持します。このため、必要な場所で実行されていない可能性があります。配置を修正する場合は、T1 を編集し、T1-Active と T1-Standby の Edge ノードを手動で選択します。

要件：

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

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

構成手順:

API を使用して、2 つのサイト（たとえば、FD1A-Preferred_Site1 と FD2A-Preferred_Site1）に障害ドメインを作成します。
注： Edge ノードの T1-Active と他の Edge ノードの T1-Standby を持つすべての Tier-1 を同じ障害ドメイン（FD1A-Preferred_Site1 および FD2A-Preferred_Site1）の一部にする場合、最初にオプションプリエンプティブを使用して Tier-1 を作成し、次に preferred_active_edge_services = true に設定された障害ドメインプライマリ (FD1A-Preferred_Site1) を作成する必要があります。次はその例です。
```
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",  
    "_revision": 15"
    "description": "Updated NSX configured Test Transport Node",
    "id": "77816de2-39c3-436c-b891-54d31f580961",
    ...
}

PUT /api/v1/transport-nodes/<transport-node-id>
{
    "resource_type": "TransportNode",
    "_revision": 15"
    "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 ノードで障害が発生し、サイト全体の障害ではない場合は、同じ原則が適用されることに注意してください。たとえば、「障害発生前」の図で、Edge ノード 1B がアクティブ Tier-1-blue をホストし、Edge ノード 2B がスタンバイ Tier-1-blue をホストしているとします。Edge ノード 1B に障害が発生すると、Edge ノード 2B のスタンバイ Tier-1-blue が引き継ぎ、新しい Tier-1-blue アクティブゲートウェイになります。

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

要件：

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

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

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

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

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

障害発生前：

管理プレーンのリカバリ前の NSX Manager サイト間の通信を表しています。セカンダリサイトにバックアップが継続的に保存されています

障害発生後：

プライマリサイトがサービス停止状態になり、セカンダリサイトのトランスポートノードがリカバリされた新しい NSX Manager と通信しています。

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

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

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

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

プライマリサイト (blue) のすべての Tier-1 について、Edge クラスタ構成をセカンダリ Edge クラスタサイトに更新します。
プライマリサイト (blue) のすべての Tier-1 について、それらを T0 セカンダリ (green) に再接続します。

次の図に、論理ネットワークビューと物理ネットワークビューの両方を使用したデータプレーンの手動/スクリプトによるリカバリを示します。

障害発生前（論理ビューと物理ビュー）：

DR によるデータプレーンの手動リカバリ前のプライマリサイトとセカンダリサイトの論理ビューを示しています。

DR によるデータプレーンの手動リカバリ前のプライマリサイトとセカンダリサイトの物理ビューを示しています。

障害発生後（論理ビューと物理ビュー）：

DR によるデータプレーンの手動リカバリの後の非アクティブプライマリサイトの論理ビューを示しています。

この図は、DR によるデータプレーンの手動リカバリの後の非アクティブプライマリサイトの物理ビューを示しています。

複数サイトの展開の要件

サイト間の通信

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

NSX Manager

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

データプレーン

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

クラウド管理システム (CMS)

CMS は、NSX プラグインをサポートする必要があります。このリリースでは、VMware Integrated OpenStack (VIO) および vRealize Automation (vRA) がこの要件を満たしています。

制限事項

Local Egress 機能はありません。すべての North-South トラフィックは 1 つのサイト内で発生する必要があります。
コンピューティングディザスタリカバリソフトウェアが VMware SRM 8.1.2 以降などの NSX をサポートしている必要があります。
NSX Manager をマルチサイト環境にリストアする場合は、セカンダリ/プライマリサイトで次の手順を実行します。
- リストアプロセスが [AddNodeToCluster] 手順で一時停止したら、追加のマネージャノードを追加する前に既存の VIP を削除し、[システム] > [アプライアンス]ユーザーインターフェイスページから新しい仮想 IP を設定する必要があります。
- VIP の更新後、リストアされた 1 ノードクラスタに新しいノードを追加します。

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

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

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

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

複数サイトの展開の要件

制限事項

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

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