NSX-T アーキテクチャと原則の概要

I. 概要

NSX-T (Transformer) は、VMware のもう 1 つの NSX プラットフォームであり、VMware Photon プラットフォームと統合されています。VMware NSX-T は、異種エンドポイントとテクノロジー スタックを処理する新しいアプリケーション フレームワークとアーキテクチャのソリューションに焦点を当てています。これらの環境には、vSphere ハイパーバイザーに加えて、他のハイパーバイザー、コンテナ、ベア メタル、パブリック クラウドが含まれる場合があります。NSX-T は、分散ファイアウォール、論理スイッチング、分散ルーティングを提供します。NSX-V と同様、NSX-T アーキテクチャには、独立したデータ プレーン、コントロール プレーン、管理プレーンが組み込まれています。NSX-T Data Center は、管理、制御、データという 3 つの個別の統合された作業面を実装することによって機能します。これらのワークサーフェスは、NSX Manager ノードとトランスポート ノードという 2 種類のノードに配置されるプロセス、モジュール、エージェントのセットとして実装されます。

2. アーキテクチャ

NSX-T アーキテクチャは、4 つの基本的なプロパティを中心に設計されています。上の図は、あらゆるサイト、あらゆるクラウド、あらゆるエンドポイント デバイスにわたるこれらのプロパティの普遍性を示しています。これにより、クロスドメイン実装のためのプラットフォームを維持しながら、インフラストラクチャ レベル (例: ハードウェア、ハイパーバイザー) だけでなく、パブリック クラウド (例: AWS、Azure) およびコンテナ レベル (例: K8、Pivo​​tal) でのより大きな分離が可能になります。。NSX-T アーキテクチャの主要な価値概念と機能には次のものがあります。

● ポリシーと一貫性:今日の自動化環境のニーズを満たすために、RESTful API を介したポリシーの 1 回限りの定義と最終状態の実装が可能です。NSX-T は、複数の独立したシステム インベントリ情報を維持し、さまざまなドメインで望ましい結果を達成するために制御します。

● ネットワーキングと接続: コンピューティング マネージャー/ドメインにバインドすることなく、複数の vSphere および kvm ノードで一貫した論理スイッチングと分散ルーティングを可能にします。異種エンドポイント間の接続を提供しながら、ドメイン固有の実装を通じてコン​​テナとクラウド間の接続がさらに拡張されます。

● セキュリティとサービス: ネットワークと同じ統合セキュリティ ポリシー モデルを使用する接続を許可します。これにより、ロード バランサー、NAT、EDGEfw、dfw などのサービスを複数のコンピューティング ドメインにわたって実装できるようになります。セキュリティ運用ルールでは、フレームワーク全体の整合性を確保するには、仮想マシンとコンテナ ワークロード全体に一貫したセキュリティを提供することが重要であると述べています。

● 可視性: コンピューティング ドメイン全体で共通のツールセットを使用して、一貫したモニタリング、メトリック収集、フロー トレースを可能にします。これは、混合ワークロードを運用する場合に重要です。通常、仮想マシンとコンテナを中心とする両方のワークロードには、同様のタスクを実行するためのまったく異なるツールがあります。

これらのプロパティにより、異種混合性、アプリケーションの一貫性、およびスケーラビリティが可能になり、さまざまなニーズに対応できます。さらに、NSX-Tは DPDK ライブラリをサポートし、ワイヤスピードのステートフル サービス (ロード バランサ、NAT など) を提供します。

2.1 アーキテクチャコンポーネント

NSX-T は、ネットワーク サービスのセット全体 (スイッチング、ルーティング、ファイアウォール、QoS など) をソフトウェアで複製します。これらのサービスをプログラムで任意に組み合わせて、独自の独立した仮想ネットワークを数秒で生成できます。NSX-T は、管理、制御、データという 3 つの個別だが統合されたプレーンを通じてその機能を実行します。これら 3 つのプレーンは、マネージャー、コントローラー、トランスポート デバイスの 3 種類のノード上に常駐するプロセス、モジュール、およびエージェントのセットとして実装されます。

各ノードは管理プレーン エージェントをホストします。

NSX Manager ノードは、API サービスと管理プレーン クラスタ デーモンをホストします。3 つのノードを持つクラスターをサポートし、ポリシー マネージャー、管理、および中央制御サービスをノードのクラスターに統合します。NSX Manager クラスタは、ユーザー インターフェイスと API の高可用性を提供します。管理プレーン ノードとコントロール プレーン ノードの統合により、NSX-T Data Center 管理者が展開および管理する必要がある仮想アプライアンスの数が減ります。

NSX コントローラー ノードは、中央のコントロール プレーン クラスター デーモンをホストします。

トランスポート ノードは、ローカル コントロール プレーン デーモンと転送エンジンをホストします。

● 管理コンポーネントは、最大 16 の vCenter、コンテナ オーケストレーション、パブリック クラウド環境を管理できます。管理プレーン エージェント (MPA) はデータ プレーン (ネットワーク送信ノード) 上に常駐し、ドメイン NSX-T マネージャ通信を完了します。このバージョンでは、2.4 より前の NSX 、各管理コンポーネントは、ロールベースの独立したデバイス、管理デバイスと 3 つのコントローラ デバイスです。NSX では、合計 4 つの管理デバイス + 各サービス デバイスを展開する必要があります。2.4 以降、NSX Manager、NSX Policy Manager、および NSX Controller は共通の仮想マシンに共存します。
また、クラスターの可用性には 3 つの固有の NSX-vm デバイスが必要です。NSX-T は、スケールアウトと冗長性のために、このような 3 つの NSX Manager アプライアンスからなるクラスターに依存します。NSX-T マネージャーはすべての情報をメモリ内のデータベースに保存するため、クラスタ全体を即座に同期できると同時に、ディスクへの書き込み、構成、または読み取り操作を 3 つのデバイスのいずれかで実行できます。ほとんどの操作がメモリ内で行われることを考慮すると、NSX Manager アプライアンス ディスクのパフォーマンス要件は大幅に軽減されます。これら 3 つのアプライアンスのそれぞれには専用の IP アドレスがあり、そのマネージャー プロセスは直接またはロード バランサー経由でアクセスできます。NSX Manager は、NSX-T 環境を管理するための Web ベースのユーザー インターフェイスを提供します。さらに、API 呼び出しを処理する API サーバーをホストします。admin という組み込みのユーザー アカウントがあり、すべてのリソースにアクセスできますが、ソフトウェアをインストールするためのオペレーティング システムにはアクセスできません。NSX-T アップグレード ファイルは、インストールできる唯一のファイルです。管理者のユーザー名とロールの権限は変更できますが、管理者を削除することはできません。NSX Manager では、セッション ID とトークンはセッションごとに一意であり、ユーザーがログオフするか一定期間非アクティブになった後に期限切れになります。さらに、各セッションには、セッションのハイジャックを防ぐためにセッション通信を暗号化するタイムレコードがあります。

● NSX-T は、コントロール プレーンを 2 つの部分に分割します。

● 中央コントロール プレーン (CCP: 中央制御室): これは実際には管理クラスタ内の vm デバイス (一般に CCP デバイスとして知られています) であり、このデバイス (管理ネットワーク) の通信はすべてのデータ プレーン (ビジネス ネットワーク) から論理的に分離されています。 ) トラフィック; したがって、そのトラフィックと障害は実際のビジネス トラフィックには影響せず、ビジネス ネットワーク内のデータは管理ネットワークに浸透せず、管理および制御のリスクが生じません。 / ローカル コントロール プレーン (LCP: エンド コントロール) : このコンポーネント
は
、デプロイ先 - ---送信ノード (データ ノード) は、データ プレーンの送信ノード上でルーティング エントリとファイアウォール ルールを転送する責任を負います
。

● データプレーン

トランスポート ノードは、ローカル コントロール プレーン デーモンと、NSX-T データ プレーンを実装する転送エンジンを実行するホストです。トランスポート ノードで実行されている NSX-T 仮想スイッチは N-VDS です。ESXi ホスト プレーンでは、N-VDS は VDS に接続されています。NSX-T 3.0 以降、N-VDS は OVS に基づいて実装されます (プラットフォームは関係ありません)これは、他のプラットフォームのネットワーク環境に適合する実装でもあります。NSX-T には 2 種類のトランスポート ノードがあります。 ハイパーバイザ トランスポート ノード: VMware ESXi™ および KVM ハイパーバイザをサポートし

、これらのハイパーバイザー上で実行されている VM のネットワーク サービス、
エッジ ノード: VMware NSX-T Edge™ ノードはサービス ゲートウェイ デバイスであり、アプライアンスはベア メタル/VM にすることができます。これらのエッジ デバイスはサービス自体ではなく、サービスであることに注意してください。一部のネットワーク サービスの消費リソース プールにすぎません。そのうち 2 つは、レイヤー ブリッジは、 NSX-T オーバーレイ レイヤーと VLAN 対応の物理ネットワーク間の通信のブリッジングを担当するデバイスです。セカンダリ ブリッジは、ブリッジ専用の 2 つの ESXi ハイパーバイザー (VLAN ごとにアクティブ/スタンバイ) のクラスターを介して実装されます。
スタンバイ エッジ ノードで CLI コマンド set l2bridge-port <uuid> state active を実行することにより、スタンバイ エッジ ノードをアクティブ ノードとして手動で設定できます。このコマンドは非アクティブ モードでのみ適用できます。そうしないとエラーが発生します。非アクティブ モードでは、このコマンドがスタンバイ ノードに適用されると HA フェイルオーバーがトリガーされ、アクティブ ノードに適用されると無視されます。

1) Tier-0 ゲートウェイ

Tier-0 ゲートウェイは、Tier-0 論理ルーターの機能を実行し、論理ネットワークと物理ネットワーク間のトラフィックの処理を担当します。エッジ ノードは、1 つの Tier-0 ゲートウェイまたは論理ルーターのみをサポートできます。したがって、Tier-0 ゲートウェイまたは論理ルーターを作成するときは、作成された Tier-0 ゲートウェイまたは論理ルーターがNSX Edge クラスター内の Edge ノードの数を超えないようにする必要があります。通常、Tier-0 ゲートウェイは Tier-1 ゲートウェイに接続し、外部接続は物理ネットワークに接続します。外部ネットワークへの静的ルートも Tier-0 ゲートウェイで構成できます。静的ルートを構成した後は、Tier-0 から Tier-1 へのルートをアドバタイズする必要はありません。Tier-1 ゲートウェイは、接続されている Tier-0 ゲートウェイの静的デフォルト ルートを自動的に学習します。

2) Tier-1 ゲートウェイ

Tier-1 ゲートウェイにはセグメントへのダウンリンク接続と Tier-0 ゲートウェイへのアップリンク接続があります。Tier-1 ゲートウェイは通常、北方向で Tier-0 ゲートウェイに接続し、南方向でセグメントに接続します。ルート アドバタイズメントと静的ルートは、Tier-1 ゲートウェイで構成できます。再帰的静的ルーティングをサポートします。

3) 論理ルーティング DLR

4) マイクロセグメンテーション

NSX-T Data Center では、セグメントはレイヤー 2 仮想ドメインです。セグメンテーションは、以前は論理スイッチとして知られていました。仮想マシン インターフェイスとゲートウェイ インターフェイスに仮想レイヤ 2 スイッチングを提供するエンティティです。NSX-T Data Center には 2 種類のセグメントがあります。

VLAN サポート セグメンテーション: これは、物理インフラストラクチャ内の従来の VLAN として実装されたレイヤー 2 ブロードキャスト ドメインです。これは、2 つの異なるホスト (同じ VLAN ベースのセグメントに接続されている) 上の 2 つの仮想マシン間のトラフィックが、2 つのホスト間の VLAN を通過することを意味します。その結果、VLAN ベースのセグメンテーションを通じて 2 つの仮想マシンがレイヤー 2 で通信できるように、物理インフラストラクチャに適切な VLAN をプロビジョニングする必要があるという制限が生じます。

オーバーレイ ネットワークでサポートされるセグメント: (同じオーバーレイ ネットワーク セグメントに接続された) 異なるホスト上の 2 つの仮想マシン間のレイヤー 2 トラフィックは、ホスト間のトンネルによって伝送されます。NSX-T Data Center は、物理インフラストラクチャでのセグメンテーション固有の構成を行わずに、この IP トンネルをインスタンス化して維持します。したがって、仮想ネットワーク インフラストラクチャは物理ネットワーク インフラストラクチャから分離されます。つまり、物理ネットワーク インフラストラクチャを構成せずにセグメントを動的に作成できます。

5) ホストスイッチ:

管理するオブジェクトは、ネットワーク内のさまざまなホストにネットワーク接続サービスを提供する仮想ネットワーク スイッチです。このオブジェクトは、NSX-T ネットワーク接続に参加している各ホストでインスタンス化されます。NSX-T では次のホスト スイッチがサポートされています。

1. NSX-T 仮想分散スイッチ: NSX-T では、複数の VMware vCenter Server インスタンス、KVM、コンテナ、その他の外部展開やクラウド実装を含む、さまざまなコンピューティング ドメイン間の接続を標準化するホスト スイッチが導入されています。

NSX-T 仮想分散スイッチは、環境で必要なパフォーマンスに基づいて構成できます。
標準: 通常のトラフィック スループットを必要とする通常のワークロード用に構成されます。
拡張: より高いトラフィック スループットを必要とする通信ワークロード向けに構成されています。

2. vSphere Distributed Virtual Switch : vCenter Server 環境内のスイッチに関連付けられたすべてのホストのネットワーク接続構成の集中管理と監視を提供します。

詳細については、公式ドキュメントを参照してください。

2.2 ポートとプロトコル

3. 関連概念

3.1. 関連概念

1)異質性:

異種環境のニーズを満たすため、NSX-T の基本要件は、コンピューティング マネージャーに依存しないことです。複数のバーチャライザーや複数のワークロードもサポートしているため、 NSX と vCenter の 1:1 マッピングがないことによる制約はなくなりました。NSX-T の管理、制御、データ プレーンのコンポーネントは、柔軟性、拡張性、パフォーマンスを念頭に置いて設計されています。

その管理プレーンは、コンピューティング マネージャー (vSphere を含む) から独立して設計されています。VMware NSX-T® Manager™ は完全に自己完結型であり、NSX 機能の管理はプログラムまたは GUI を通じて簡単に行えます。

コントロール プレーンは、特定のエンドポイントの集中クラスター ( CCP ) とローカル コンポーネント ( LCP )の 2 つのコンポーネントに分割されます。これにより、コントロール プレーンはローカライズされた実装 (データ プレーン実装とセキュリティ実装) に合わせて拡張でき、効率が向上し、異種環境が可能になります。

データ プレーンの場合、特定の正規化されたインスタンスが異なる環境で設計されます。NSX-T では、複数の VMware vCenter® インスタンス、KVM、コンテナ、その他の非ネイティブ実装を含む、さまざまなコンピューティング ドメイン間の接続を標準化するホスト スイッチ(N-VDSと呼ばれます) が導入されています。N-VDS スイッチのすべての機能は ESXi VDS7.0 に完全に実装されているため、ESXi のお客様は VDS を変更せずに完全な NSX-T 機能を最大限に活用でき、一貫したエクスペリエンスを提供できます。

2) アプリケーションの一貫性

MSX-T は、仮想マシンまたはコンテナ上で実行されるワークロードにシームレスなネットワーク仮想化を提供します。NSX は、複数の CaaS (Communications-as-a-Service、関連する MAAS および TAAS) および PaaS ソリューションをサポートします。NSX-T は、主要な構造としてアプリケーションを使用して構築されています。コンテナとクラウド ネイティブ アプリケーションを完全にサポートする; NSX は、物理サーバーから VM やコンテナに至るすべてを含む環境を管理し、可視性を高めるための共通フレームワーク

を提供します; NCP 主要なコンポーネントはコンテナ内で実行され、NSX マネージャーおよび Kubernetes API サーバーと通信します(k8s/openshiftの場合)。NCP は、コンテナーやその他のリソースへの変更を監視します。また、NSX API を介して、論理ポート、スイッチ、ルーター、セキュリティ グループなどのコンテナのネットワーク リソースも管理します。

3.2. VDS NSX-T の注意事項

NSX-T は、vSphere から独立したネットワーク仮想化プラットフォームとして設計されています。もちろん、vSphere を完全に放棄するのではなく、より大きなスパンのネットワークを提供し、vsphere を超えたサービスを提供することが目標です。同じ NSX-T は、たとえば、KVM、クラウド、またはベア メタル サーバーに拡張するなど、複数の vCenter にネットワーク サービスを同時に提供できます。

vSphere から分離するもう 1 つの理由は、NSX-T が独自のリリース サイクルを持つことが、機能やバグ修正が vSphere のタイムラインから独立することです。これを実現するために、NSX-T 仮想スイッチ N-VDS は既存のソフトウェア インフラストラクチャを活用し、vSphere がサードパーティ仮想スイッチへの一連のAPI 呼び出しを通じてネットワークを利用できるようにします。したがって、NSX-T セグメントは「ファジー ネットワーク」として表されます。この名前は、これらのオブジェクトが完全に独立しており、vSphere から管理できないことを明確に示しています。

NSX-T 3.0 では、NSX-T を VDS 上で直接実行できるようになりました (VDS バージョンは少なくとも 7.0 である必要があります)。NSX-T は、複数の vCenter 間でシームレスに動作するため、vCenter から独立したままになります。ただし、NSX-T には VDS が必要なため、ESXi ホスト上で vCenter を実行する必要があります。

NSX-T ネットワーク セグメントのスコープは、それが属するトランスポート ゾーンによって定義されます。これは、「test-segment」がトランスポート ゾーン「オーバーレイ」に定義されている場合、このセグメントはトランスポート ゾーン「オーバーレイ」に接続されているすべてのホストで使用できることを意味します。次の図に示すように、N-VDS (「nvds1」と呼ばれます) ") には 2 つの ESXi ホストが接続 (準備) されており、それらはネットワーク セグメントを共有します。

上の画像の左側は、vCenter の「test-segment」の不透明なネットワーク表現を示しています。管理者は、不透明なネットワークを選択することで、ESXi1 および ESXi2 上の仮想マシンの仮想 NIC をこのセグメントに直接接続できます。以下は、vCenter 上の不透明なネットワークに関する情報を示す MOB (管理対象オブジェクト ブラウザ) スナップショットです。「概要」と「extraConfig」コンテンツの一部に注目してください。

図の主な内容は次のとおりです。

• 論理スイッチの名前は「test-segment」です。
• 論理スイッチ UUID:「7884ca6a-4e8f-4b52-98f6-a265cf0e19f8」。
• 不透明ネットワークがNSX セグメントを表す場合、extraConfig フィールドにはセグメント パス「/infra/segments/test-segment」も指定されます。仮想マシンがこの不透明なネットワークに接続されている場合は、ネットワーク タイプと論理スイッチの UUID を示す詳細情報も表示されます。

● VDS で NSX-T 機能を有効にします。

上の図に示すように、両方のホストで「test-segment」を dvportgroup として提供できます。これは、NSX-T の dvportgroup 表現であるため、「NSX-T dvportgroup」と呼ばれます。dvportgroup アイコンには、NSX-T オブジェクトを扱っていることを示す小さな「N」も表示されます。ただし、ネットワーク ユーザーの観点から見ると、仮想マシンは、前のケースで Opaque ネットワークに接続できたのと同じように、dvportgroup NSX-T に接続できます。dvportgroup は VDS に属しているため、階層の「VDS1」の下に「test-segment」が表示されていることがわかります。MOB での対応する NSX-T dvportgroup は次のとおりです。

上の図の左側の部分は、従来の dvportgroup と同様です。グラフの右側に表示されている「config」部分に注目してください。

• NSX の値を持つ「backingType」があり、これが NSX オブジェクトであることを明示的に示しています。
• セグメント名とセグメント ID、およびセグメントが属するトランスポート領域の NSX-T の名前と UUID を取得できます。この特定のシナリオでは、これら 2 つのフィールドが同じであることに注意してください。
• セグメントに関連付けられた論理スイッチは、「logicalSwitchUuid」フィールドによって参照されます。この値は、前の N-VDS ベースの例で示した「opaqueNetworkId」と同じであることに注意してください。これは、 vCenter で同じオブジェクトを異なる方法で表現しているためです。
• NSX-T の dvportgroup は常に「一時的」です。仮想マシンがこの dvportgroup NSX-T に接続されている場合、バックエンドは上記の NSX-T dvportgroup オブジェクトのみを指します。

● 複数の VDS 上の NSX-T:

上の図は、ESXi1 ホストが VDS1 上で NSX を実行し、ESX2 ホストが VDS2 上で NSX-T を実行する場合に何が起こるかを示しています。図の左側の vCenter ネットワーク ビューには、VDS1 と VDS2 が表示されており、それぞれに「test-segment」という NSX-T dvportgroup が含まれています。VDS 上で NSX-T を実行するということは、基本的に、異なる vCenter で表される NVDS モデルを使用することを意味しますが、機能は同じでなければなりません。したがって、この場合でも、「テストセグメント」の範囲は「オーバーレイ」転送領域によって定義されます。ESXi host1 と host2 は同じ「OverLay」トランスポート ゾーンに接続されているため、「OverLay」で定義されたセグメントは host1 と host2 で使用できる必要があります。dvportgroup は vCenter の VDS で定義されているため、NSX-T dvportgroup を VDS1 と VDS2 にコピーする必要があります。これら 2 つの dvportgroup は、実際には2 つの異なる VDS 内の同じ仮想ポート NSX-Tを表しています。次の図は、MOB の VDS2 にある dvportgroup NSX-T "test-segment" の情報を示しています。


上に示すように、VDS2 にある NSX-T dvportgroup には、VDS1 にあるものとは異なる管理オブジェクト ID があることがわかります (dvportgroup- 57) (dvportgroup-59)。これらのオブジェクトは 2 つの異なる vCenter オブジェクトです。ただし、これらは同じNSX-T セグメントを指しているため、logicalSwitchUuid フィールドとセグメント ID フィールドを確認してください。もちろん、これら 2 つのフィールドは同じです。

次の図は、N-VDS で準備されたホスト 1 とホスト 2 の VDS にインストールされた NSX-T を示しています。この場合、不透明なネットワークとセグメント「test-segment」の NSX-T dvportgroup 表現の両方が vCenter に表示されます。

NSX-T 2.3 より前は、レイヤ 2 ブロードキャスト ドメインを表すオブジェクトは論理スイッチであり、論理スイッチ UUID 内の NSX によって一意に識別されました。
NSX-T 2.4 では、同じ目的でセグメンテーションの概念が導入されました。セグメントは、論理スイッチと次のいくつかの追加パラメータを含むオブジェクトです。

セグメントはセグメント パスによって一意に識別されます。上記の例で使用されているセグメンテーションには、セグメント パスとして「/infra/segments/test-segment」が含まれています。パスの最後の部分 (ここでは「テストセグメント」) はセグメント ID と呼ばれます。ほとんどの場合、セグメント ID はセグメントの名前です。

同じセグメントは複数の VDS にまたがり、トランスポート ゾーンが NSX 用に準備された複数の VDS に拡張されると、各 VDS にはトランスポート ゾーンのセグメントごとに NSX-T dvportgroup が存在します。これらの NSX-T dvportgroup は、それらが表すセグメントに応じて名前が付けられます。これは、同じ名前を持つ複数の dvportgroup を意味します。これは、以前は vCenter で利用できなかった情報です。dvportgroups は、以前は vCenter で一意でした。

NSX-T セグメントの場合、セグメント パスはセグメントの一意の識別子であり、この識別子は NSX-T です。ネットワーク管理者は、複数のセグメントに同じ名前を使用できます。NSX-T は、セグメント ID が異なることを保証します。2 番目の「テストセグメント」が「オーバーレイ」転送領域に作成されたとします。この新しいセグメントには、既存の文字列とは異なるように、セグメント ID に追加の文字列が追加されていることに注意してください。


vCenter では、dvportgroup 内の既存の dvportgroup と同じ名前で NSX-T dvportgroup を作成できないことに注意してください。ただし、dvportgroup が VDS の下に「test」がすでに存在することを示している場合、NSX-T は NSX-T を作成します。 dvportgroup "test"、両方 ここでの "test"dvportgroup は同じタイプではありません。

PowerCLI の NSX 分散ポート グループ クエリ:

Get-VDPortGroup -Name "MyVDPortGroup" -VDSwitch "MyVDSwitch"
//如果某个特定的分布式端口组需要使用 LogicalSwitch UUID 进行引用，则可以使用 ExtensionData 过滤特定的 UUID。
Get-VDPortGroup -VDSwitch "MyVDSwitch" | where {
   
    
     $_.ExtensionData.Config.LogicalSwitchUuid -eq ‘9c6388c3-2ad6-41c6-bcaa-a23edefcea38’}

3.3. VMkernel を vss から N-VDS スイッチに移行する

NSX-T Data Center 3.0 以降では、vSphere Distributed Switch を使用してトランスポート ノードを作成できるようになりました。インストール中に VMkernel を N-VDS スイッチに移行するには、VMkernel を既存の論理スイッチにマッピングします。NSX Manager は、VMkernel を N-VDS 上のマップされた論理スイッチに移行します。VMkernel インターフェイスを VSS または DVS スイッチから N-VDS スイッチにクラスタ レベルで移行するには、移行に必要なネットワーク マッピングの詳細を使用してトランスポート ノード プロファイルを構成します (VMkernel インターフェイスを論理スイッチにマップします)。同様に、ホスト ノード上の VMkernel インターフェイスを移行するには、トランスポート ノード構成を構成します。VMkernel インターフェイスを VSS または DVS スイッチに移行するには、オフロード プロセス中に実装されるトランスポート ノード構成ファイルでオフロード ネットワーク マッピング (VMkernel インターフェイスへの論理ポートのマッピング) を構成します。移行中、現在使用中の物理 NIC は N-VDS スイッチに移行されますが、移行後は、使用可能な物理 NIC またはアイドル状態の物理 NIC が N-VDS スイッチに接続されます。トランスポート ノード構成ファイルは、クラスターのすべてのメンバー ホストに適用されます。ただし、特定のホスト上の VMkernel インターフェイスの移行を制限したい場合は、ホストを直接構成できます。移行後、N-VDS は、N-VDS スイッチに接続されているインターフェイスの VLAN およびオーバーレイ上のトラフィックを処理します。NSX-T UI またはトランスポート ノード API を使用して VMkernel インターフェイスと PNIC を VDS から N-VDS スイッチに移行した後、vCenter Server で VDS に関する警告が表示される。ホストが VDS に接続する必要がある場合は、VDS からホストを削除します。vCenter Server は、VDS に関する警告を表示しなくなります。対象: VMkernel インターフェイスを VSS または DVS スイッチに戻す場合、NSX-T Data Center をアンインストールする場合、VMkernel インターフェイスを N-VDS スイッチから VSS または DVS スイッチに戻す場合、VMkernel をポート グループに戻す場合DVS スイッチ。グループ タイプが一時的に設定されていることを確認してください。

試験条件：

vmk0 と vmk1 は vSwitch0 に接続されており、vmnic0 と vmnic1 はそれぞれ vSwitch0 上のアップリンク 1 とアップリンク 2 として構成されています。

NVSX スイッチには、vmnic または VMkernel アダプタが構成されていません。

移行前に、ESXi ホストには 2 つの物理ポート vmnic0 および vmnic1 からの2 つのアップリンクが必要です。ここでは、vmnic0 はアクティブで VSS に接続されるように構成されていますが、vmnic1 は使用されていません。さらに、vmk0、vmk1、および vmk2 という 3 つの VMkernel インターフェイスがあります。NSX-T Data Center Manager UI または NSX-T Data Center API を使用して VMkernel インターフェイスを移行できます。移行後、vmnic0、vmnic1、およびそれらの VMkernel インターフェイスは N-VDS スイッチに移行されます。vmnic0 と vmnic1 は、VLAN およびオーバーレイ トランスポート ゾーンを介して接続されます。

VMkernel の移行に関する注意事項:

• 物理 NIC と VMkernel の移行: 固定物理 NIC と関連する VMkernel インターフェイスを N-VDS スイッチに移行する前に、ホスト スイッチ上のネットワーク マッピング (物理 NIC からポート グループへのマッピング) に注意してください。
• 物理 NIC の移行のみ: 物理 NIC のみを移行する場合は、管理 VMkernel インターフェイスに接続されている管理物理 NIC は移行しないでください。これにより、ホストへの接続が失われます。この関連付けにより、トランスポート ノード構成ファイルに Migrate-Only PNIC フィールドが追加されます。
• 移行を再開する: VMkernel インターフェイスを固定物理 NIC を備えた VSS または DVS ホスト スイッチに移行することを計画する前に、ホスト スイッチ上のネットワーク マッピング (物理 NIC からポート グループへのマッピング) を必ず書き留めてください。これは、[オフロード ネットワーク マッピング] フィールドでホスト スイッチ マッピングを使用してトランスポート ノード プロファイルを設定するための前提条件です。このマッピングがないと、NSX-T Data Center は、VMkernel インターフェイスを移行して戻す必要があるポート グループを認識できません。この状況により、vSAN ネットワークへの接続が失われる可能性があります。
• 移行前に vCenter Server を登録する: DVS スイッチに接続されている VMkernel または物理 NIC を移行する予定がある場合は、必ず vCenter Server を NSX Manager に登録してください。
• VLAN ID の一致: 移行後、管理 NIC と管理 VMkernel インターフェイスは、移行前に管理 NIC が接続されていたのと同じ VLAN 上に存在する必要があります。vmnic0 と vmk0 がすでに管理ネットワークに接続されており、別の VLAN に移行すると、ホストへの接続が失われます。
• VSS スイッチへの移行: 2 つの VMkernel インターフェイスを VSS スイッチの同じポート グループに戻すことができません。
• vMotion: VMkernel や PNIC の移行前に、vMotion を実行して仮想マシンのワークロードを別のホストに移動します。移行が失敗しても、ワークロード VM は影響を受けません。
• vSAN: ホスト上で vSAN トラフィックを実行している場合は、VMkernel や PNIC の移行前に、vCenter Server を通じてホストをメンテナンス モードにし、vMotion 機能を使用して仮想マシンをホストから移動します。
• 移行: VMkernel がすでにターゲット スイッチに接続されている場合でも、同じスイッチへの移行対象として VMkernel を選択できます。このプロパティにより、べき等な VMK および/または PNIC の移行操作が可能になります。これは、PNIC のみをターゲット スイッチに移行する場合に便利です。移行には常に少なくとも 1 つの VMkernel と 1 つの PNIC が必要であるため、PNIC のみをターゲット スイッチに移行する場合は、ターゲット スイッチに移行済みの VMkernel を選択できます。移行する必要がある VMkernel がない場合は、 vCenter Server を介してソースまたはターゲット スイッチに一時的な VMkernelを作成します。次に、それを PNIC とともに移行し、移行が完了したら vCenter Server 経由で一時 VMkernel を削除します。
• MAC 共有: VMkernel インターフェイスと PNIC が同じ MACを持ち、同じスイッチ内にある場合、移行後に使用する場合は、それらを同じターゲット スイッチに一緒に移行する必要があります。vmk0 と vmnic0 は常に同じスイッチ上に維持してください。次のコマンドを実行して、ホスト内のすべての VMK および PNIC によって使用されている MAC を確認できます:
  
  esxcfg-vmknic -l
  
  esxcfg-nics -l
  \
• 移行後に作成されたVIF 論理ポート: VMkernel を VSS または DVS スイッチから N-VDS スイッチに移行した後、 VIF タイプの論理スイッチ ポートが NSX Manager 上に作成されます。これらの VIF 論理スイッチ ポートでは分散ファイアウォール ルールを作成できません。
  
  VDS バージョン 7.0 および NSX-T3.2 バージョンは、VDS 上で NSX-T を直接実行できます。

トランスポート ノード構成ファイルは、クラスターに適用される構成を定義するテンプレートです。スタンドアロン ホストの準備には適していません。トランスポート ノード構成ファイルを適用して、vCenter Server クラスタ ホストがトランスポート ノードとして機能するように準備します。トランスポート ノード プロファイルは、トランスポート ゾーン、メンバー ホスト、および N-VDS スイッチ構成 (アップリンク プロファイル、IP 割り当て、アップリンク仮想インターフェイスへの物理 NIC のマッピングなどを含む) を定義します。トランスポート ノード プロファイルはホストでのみ使用できます。NSX Edge トランスポート ノードには適用できません。トランスポート ノードの作成は、トランスポート ノード構成ファイルが vCenter Server クラスタに適用されるときに開始されます。NSX Manager はクラスタ内のホストを準備し、すべてのホストに NSX-T Data Center コンポーネントをインストールします。ホストのトランスポート ノードは、トランスポート ノード構成ファイルで指定された構成に基づいて作成されます。知らせ：

NSX-T Data Center は、最初の N-VDS を通過するトラフィックが 2 番目の N-VDS を通過するトラフィックから分離されるように、トラフィック分離を提供します。外部への North-South トラフィックを許可するには、各 N-VDS 上の物理 NIC をホスト上の Edge VM にマッピングする必要があります。最初のトランスポート ゾーン上の仮想マシンから移動するパケットは、外部ルーターまたは外部仮想マシンを介して 2 番目のトランスポート ゾーン上の仮想マシンにルーティングされる必要があります。
各 N-VDS スイッチには一意の名前が必要です。NSX-T Data Center では、スイッチ名の重複は許可されません。
トランスポート ノード構成またはトランスポート ノード プロファイル構成内の各 N-VDS または VDS ホストに関連付けられた各トランスポート ゾーン ID は一意である必要があります。

ブラウザで、管理者権限を使用して https:// で NSX Manager にログインします。つまり、NSX-T の独立したページ、[システム] > [ファブリック] > [構成ファイル] > [トランスポート ノード構成ファイル] >:

ホストがトランスポート ノードとして構成されている場合は、[ESXi VMkernel と物理アダプタの移行] を使用し、[システム] > [ファブリック] > [ホスト トランスポート ノード] に移動し、トランスポート ノードを選択して、[アクション] > [ESX VMkernel と物理アダプタの移行] をクリックします。更新された VMkernel アダプタと物理アダプタは N-VDS スイッチに移行されるか、移行されたアイテムは ESXi ホストの VSS または VDS スイッチに復元されます。

注: 上記の 2 つの vmnic とアップリンクの間のマッピング関係は一貫している必要があります。一貫していない場合、移行は失敗します。

VMkernel インターフェイスを N-VDS スイッチに移行するためのワークフローの概要:

必要に応じて、論理スイッチを作成します。VMkernel インターフェイスと物理 NIC を N-VDS スイッチに移行するホスト上の仮想マシンをパワーオフします。

トランスポート ノードの作成時に VMkernel インターフェイスの移行に使用されるネットワーク マップを使用してトランスポート ノード構成ファイルを構成します。ネットワーク マッピングとは、VMkernel インターフェイスを論理スイッチにマッピングすることを意味します。

vCenter Server のネットワーク アダプタ マッピングに、 VMkernel スイッチと N-VDS スイッチの新しい関連付けが反映されていることを確認します。物理 NIC が固定されている場合は、NSX-T Data Center のマッピングが、vCenter Server の物理 NIC に固定されている VMkernel を反映していることを確認します。
NSX Manager で、[ネットワーク] → [セグメンテーション] に移動します。[セグメント] ページで、VMkernel インターフェイスが新しく作成された論理ポートを介してセグメントに接続されていることを確認します。
[システム] > [ノード] > [ホスト トランスポート ノード] に移動します。各トランスポート ノードについて、ノード ステータス列のステータスが成功であることを確認して、トランスポート ノード構成が正常に検証されたことを確認します。
[ホスト トランスポート ノード] ページで、[構成ステータス] のステータスが [成功] になっていることを確認し、指定された構成でホストが正常に実装されたことを確認します。

ネットワーク インターフェイスを N-VDS に移行する前後:

VMkernel インターフェイスと物理 NIC を VSS または DVS スイッチから N-VDS スイッチに移行するとき、またはインターフェイスを VSS または DVS ホスト スイッチに移行するときに、次のエラーが発生する場合があります。

エラーコード	質問	理由	解決
8224	トランスポート ノード設定で指定されたホスト スイッチが見つかりません。	ホスト スイッチ ID が見つかりません。	※必ずホストスイッチ名でトランスポートゾーンを作成してから、トランスポートノードを作成してください。 * トランスポート ノード構成では必ず有効なホスト スイッチを使用してください。
8225	VMkernel の移行が進行中です。	移行が進行中です。	移行が完了するまで待ってから、他の操作を実行してください。
8226	VMkernel の移行は、ESXi ホストでのみサポートされます。	移行は ESXi ホストに対してのみ有効です。	移行を開始する前に、ホストが ESXi ホストであることを確認してください。
8227	ホスト スイッチ名には VMkernel インターフェイスが追加されていません。	複数のホスト スイッチを備えたホストでは、NSX-T Data Center は各 VMkernel インターフェイスとそのホスト スイッチの関連付けを認識しません。	* ホストに複数の N-VDS ホスト スイッチがある場合は、ホストが接続されている N-VDS のホスト スイッチ名に VMkernel インターフェイスが付加されていることを確認してください。 * たとえば、N-VDS ホスト スイッチ名 nsxvswitch1 および VMkernel1 と、別の N-VDS ホスト スイッチ名 nsxvswitch2 および VMkernel2 を持つホストをオフロードするためのネットワーク マッピングは、次のように定義する必要があります: device_name: VMkernel1@nsxvswitch1、destination_network: DPortGroup。
8228	device_name フィールドで使用されているホスト スイッチがホスト上に見つかりませんでした。	ホストスイッチ名が間違っています。	正しいホストスイッチ名を入力してください。
8229	トランスポート ノードは、論理スイッチのトランスポート ゾーンを指定しません。	転送ゾーンは追加されません。	トランスポート ゾーンをトランスポート ノード構成に追加します。
8230	ホスト スイッチには物理ネットワーク カードがありません。	ホスト スイッチには少なくとも 1 つの物理 NIC が必要です。	アップリンク プロファイルに少なくとも 1 つの物理 NIC を指定し、論理スイッチに VMkernel ネットワーク マッピング構成を指定します。<