異なるネットワークサブネットの複数vMotion VMkernelの追加について

[yi1234]

既存のvMotionネットワークとは別のネットワークサブネットのvMotionのVMkernelを追加する以下の２つの構成は問題ありますでしょうか？

背景

既存vSphere環境(vSAN利用)のHW更改を予定しており、Cross vCenter vMotionで移行を予定しています。

ただ、既存環境のvMotionのVLANは、L2スイッチ内で閉じており、既存ホスト間でのみの通信となっています。

既存のお客様ネットワークスイッチは変更せずに、新しい環境にvMotionするために、以下の２つができないかと考えております。

①新規にvMotionのVMkernelポートを追加して、管理用VLANを設定し、新規環境とvMotionが通信できるようにする

新規のvMotionネットワークと管理ネットワークが同じサブネットになるのですが、TCP/IPスタックが異なっていれば以下のKBの問題には該当しないでしょうか？（管理はデフォルトのTCP/IPスタック、vMotionのTCP/IPスタックはvMotion）

ESXi 上のマルチホーミング

ただ、上記KBの英語の方を参照すると、vSAN環境ではマルチホーミングはサポートしないと記載があり、これはTCP/IPスタックが別でもサポートしないという意味になりますでしょうか？

Multihoming on ESXi

NOTE:

• Configurations with more than one vmknic interface on the same IP subnet is not supported.
• vSAN environment also doesn't support multihoming (same IP subnet) across vmk adapters.

②既存ホストの空きNICポートを新環境のスイッチに接続し、そのNICにvMotion用のVMkernelを設定（既存vMotionとは別サブネット）して新環境とvMotionできるようにする

新環境とのvMotionは、新環境のvMotionのIPアドレスと同じサブネットとなる追加したvMotion VMkernelが利用されると思っているのですが、この構成は特に問題ありませんでしょうか？

[nkaneda1]

仕様についての回答というよりは経験談の共有の側面が強いですがご容赦ください。

> TCP/IPスタックが異なっていれば以下のKBの問題には該当しないでしょうか？
はい。KBの記載的にStackが違えばこの制限には該当しない認識ですね。
同様の構成で移行したことがあります。（vSANクラスタ）

>上記KBの英語の方を参照すると、vSAN環境ではマルチホーミングはサポートしないと記載があり、これはTCP/IPスタックが別でもサポートしないという意味になりますでしょうか？

こちらについては解釈が難しいですが、経験則的にはvSANがあっても問題なく動作はしました。
おそらくは、vSANネットワーク専用のTCP/IP Stackは存在しないので、vSANネットワークは必ず個別のSubnetにせよ、という意味だと思っています。

＞新環境とのvMotionは、新環境のvMotionのIPアドレスと同じサブネットとなる追加したvMotion VMkernelが利用されると思っているのですが、この構成は特に問題ありませんでしょうか？

経験則では、既存vMotionネットワークとは別セグメントのvMotion vmkを追加した場合、疎通がうまくいかないことが多かったため、移行中は既存vMotion vmk のvMotionフラグを削除して、常に1つのvMotion vmkのみが選択されるようにしていました。

個人的には②の手法のほうが良いと思います。ネットワークのホップが少ないですし、TCP/IP StackでvMotionトラフィックを分離する場合、スナップショットなどのオフラインデータは結局管理ネットワーク経由でデフォルトのTCP/IP Stackが利用されてしまいます。

現状VMwareの推奨としては以下のDocにあるUDTを使うのが推奨という認識ですが、そのためにはDefault TCP/IP Stackを利用する必要があるので、②の方法でIPサブネットも分離する必要があると思います。

vSphere vMotion Unified Data Transport

[yi1234]

ご回答ありがとうございます。

②の方がお勧めとのことありがとうございます。UDTを利用するには、ProvisioningサービスをvMotionのVMKernelに入れる（デフォルトTCP/IPスタックが必要）ということですね。

既存環境はまだvSphere 7のため、UDTは利用できないと理解しましたが、オフラインデータの移行が管理ネットワーク経由にならないようにするためにも、ProvisioningサービスをvMotionのVMKernelに入れる（デフォルトTCP/IPスタックが必要）のがよいという理解であっていますでしょうか？

また既存環境はVxRailなのですが、①②の対応するのにVxRail観点で注意すべきことはありますでしょうか？（コミュニティ違いの質問になってしまいすみません。。）

[nkaneda1]

＞オフラインデータの移行が管理ネットワーク経由にならないようにするためにも、ProvisioningサービスをvMotionのVMKernelに入れる（デフォルトTCP/IPスタックが必要）のがよいという理解であっていますでしょうか？

Provisioning用のTCP/IP Stackもあります。
プロビジョニング TCP/IP スタックへのコールド移行、クローン作成、およびスナップショットのトラフィックの配置方法

仮想マシンが起動状態のLive MigrationであったとしてもSnapshotのベースDiskなどはColdデータとして、Provisioningネットワーク（未設定の場合は管理ネットワーク）を経由して転送されます。

Hot and Cold Migrations; Which Network is Used? - VMware Cloud Foundation (VCF) Blog

>た既存環境はVxRailなのですが、①②の対応するのにVxRail観点で注意すべきことはありますでしょうか？（コミュニティ違いの質問になってしまいすみません。。）

VxRailの場合でも同様に実施して問題ないです。
厳密にいえば、VxRailの場合はバージョンによってVxRail Manager側でvMotionネットワークの情報を管理しているため、手動で変更をしてしまうとVxRailとしての管理に弊害が出る可能性もありえます。具体的には将来的なノード追加等の際に正しくvMotionネットワークが新規ノードに反映されない、といった懸念が考えられますが、今回のシナリオではHW更改ということで、そういった懸念は考慮不要であると想定しています。

私のラボ環境もVxRailですが、②の手法で問題なく実施できています。

[yi1234]

ご回答ありがとうございます。

実績あって安心しました。