VMware Cloud Foundation® Operation HCX と MON
VMware Cloud Foundation Operation HCX （旧 VMware HCX、以下 HCX と表現します。） とは、異なる仮想基盤間におけるワークロードをできる限り有効に、トラフィックインパクトを抑えながら移行を促す専門のツールとして開発され、主にオンプレミスの vSphere 環境から VMware Cloud™ などの SDDC 環境への移行ツールとして多くのお客様に活用されてきました。製品や技術の概要はこちらのBlogでも紹介されていますのでご参照ください。
https://blogs.vmware.com/vmware-japan/2022/02/vmware-hcx.html
以前は、単体の製品販売よりも、VMware Cloud をご契約のお客様に活用いただけるクラウドリフト用ツールとしての存在意義が高かったソリューションではありますが、VMware Cloud Foundation へ HCX ライセンスが標準搭載されて以降、オンプレミスにおける vSphere によって構築された仮想基盤から、同じくオンプレミス内に構築する次世代プライベートクラウド基盤としての VCF への移行ツールとしての利用が脚光を浴びています。特に HCX 単体販売であったときには、 Add On ライセンスとしての HCX Enterprise を購入いただかないと利用できなかった高度なネットワーク機能である Mobility Optimization Networking（以降、MON） がライセンス上標準搭載されたことにより、 vSphere による仮想基盤を物理的なネットワークで接続していた環境から、コンピュートもネットワークもストレージも仮想化された、いわゆる SDDC 化されたプライベートクラウドへの移行をできる限りインパクト少なく、容易なオペレーションで実現します。
MON についても過去こちらの Blog で解説が行われていますが、
https://blogs.vmware.com/vmware-japan/2023/01/hcx-mon.html
本 Blog では、よりオンプレミス内における基盤移行における動作を想定した MONの動作詳細についてご紹介したいと思います。
MON を利用した Default Gateway の切り替え
先の HCX 概要をご紹介した Blog にもありますとおり、HCX の特徴の一つは、異なる環境間において L2ネットワークの延伸を提供することで、動作するワークロードの IPアドレスを変更することなく vMotion などで環境間をシームレスに移動させることができることです。ネットワークの L2延伸が提供されれば IPアドレスの再設計を行うことなくワークロードをそのまま移行することはイメージいただけると思いますが、ではそのワークロードに設定された Default Gateway の IP はどの様に維持、もしくは切り替えが実施されるのでしょう？
この部分を手動による物理ネットワーク機器のメンテンナンスを必要とすることなく、シームレスに切り替えを提供する機能がHCXにおける MON の役割となります。
まずはオンプレミス内における旧システム（移行元）から移行先（VCF）へワークロードを移設するステップをネットワークの観点から見てみましょう。
Step.1 MON を有効化したネットワークを HCXで L2延伸
まずは移行元にあるネットワーク（この例では192.168.1.0/24）を移行先であるプライベートクラウド上に L2で延伸します。この際に MON のオプションを有効化しておくことで、移行先にあるプライベートクラウド＝VCF 上のコンポーネントである NSX の Gateway（論理ルーター）に旧環境にある物理 Router と“同じ IPアドレス”を利用した Default Gateway アドレスがインストールされます。
Step.2 ワークロードの一部を vMotion で移行先へ移設
次に HCX の Migration 機能（vMotion など）を利用して、移行元のサイトから移行先へワークロードを移設します。このときのトラフィックインパクトは選ぶ Migration 方式にも依存しますが、 vMotion などを利用すればほぼヒットレスに移設が完了します。ただしこの状態では MON による Gateway の切り替えを行っていないため、ワークロードの Default Gateway は、 L2延伸越しで移行元サイトに有る物理ルーターを向いています。
Step.3a MON による Default Gateway の切り替え
ワークロードの Gateway を MON により移行元から移行先へ切り替えます。このときのトラフィックへのインパクトは環境にもよりますが、 ARP の切り替えも含め、およそ 1〜3 秒くらいが想定されます。 Gateway の移行が完了すると、外部への通信は移行先である NSX Gateway を介して行われますし、移行先にある Route への通信（この例では192.168.10.0/24）宛の通信も、移行元サイトに転送されることなく NSX Gateway によるローカルでのルーティングが実施されます。（トロンボーン通信の削減）
※この例では、ワークロードごとの Gateway切り替え（.1のVM）の例で解説していますが、必要であればセグメントごと（例えば192j.168.1.0/24ごと）の切り替えを行うことも可能です。
Step.3b MON による Default Gateway の切り替え
Step.3aの処理を行うと、同時に外部からのトラフィックコントロールへ誘導を行う仕組みが動作します。この例では 192.168.1.1 のワークロードにおける Gateway の切り替えを行いました。この場合、 NSX Gateway は、 “192.168.1.1/32” のホストルートを外部へ BGP 広報します。その先のネットワークでこの広報されたネットワークを処理するデザインがなされていることが前提ですが、そのようなデザイン設計を行うことで、 192.168.0.0/24 宛のネットワークは移行元サイトへ向かいつつ、 192.168.1.1/32 宛の通信のみは移行先へと誘導することが可能となります。
Step.3c MON による Default Gateway の切り替え
また HCX による移行を検討した場合、このようなシステム移行が一晩で完了するとは限らず、場合によっては移行期間が数週間から数ヶ月に及ぶ場合も想定されます。その場合、移行先へ移動したワークロードが引き続き移行元に存在するネットワークへの疎通性を求められることがあります。 HCX では、 Policy Route という設定を行うことで、移行元サイトへのルーティング処理を実行することが可能となっています。
この例では、 MON によって Gateway の切り替えが行われたワークロードが、移行元にある 192.168.2.0/24 というルートあての通信を実施しているイメージで記載していますが、このような通信経路を確保することも MON の機能の一部として動作しています。
※簡略的に書くとこれまでなのですが、ネットワーク上に同一の IP アドレスを所有した異なる 2種の Gateway が存在する前提でこのような通信が問題なく行われるのはよくよく考えるととても不思議なことです。どのような手段でこれを実現するのか、については後ほどもう少し詳しくご紹介いたします。
Step.4 すべてのワークロードが移行元から移行先へと移設完了
延伸を行ったネットワーク上にある全てのワークロードを移行先へ完了させます。HCX では多数あるワークロードを如何に簡略的に移行先へ移行するか、という目的に応じて、 Cold Migration、Bulk Migration、Replication Assisted vMotion、HCX Assisted vMotion、、、 といったようにいくつかの移行オプションが存在しています。それぞれダウンタイムへの影響とメンテナンスウィンドウの短縮化、という 2軸の検討ポイントに応じて手段を選ぶことができるようになっていますので必要に応じて最適な選択をしていただくことが可能です。
Step.5 L2延伸の解除
すべてのワークロードが移行先へと移行が完了したら、対象としていた L2ネットワークの延伸を解除します。このタイミングで外部へ BGP で広報されていたホストルートは解除されます。必要に応じてネットワークルートを外部広報するなどの設定を VCF 上の NSX で行っていただくことで該当ネットワーク宛の通信を移行元から移行先へ切り替えることで移行処理が完了します。
複数の同一IPを維持した Gateway がある構成
ここまで解説してきたように、 HCX は MON を利用することで、ワークロードを L2延伸ネットワーク上で移設するだけではなく、その Default Gateway 切り替えに関しても最小の手間とインパクトで移設をお手伝いできることをご紹介しました。
では、 VRRP のような仮想 Mac Address の仕組みを利用しているわけでもないのに、同一の IPアドレスを Default Gateway として保持した旧物理ルーターと新仮想ルーター（NSX Gateway）が移行期において混在し、なおかつ旧サイトにしか存在しない Route への疎通性も確立する Step.3c でご紹介した動作はどのように実現できるでしょうか？（私同様なネットワークエンジニアの方であれば不思議に思われると思います。）
これは、 HCX‐NE（Network Extension＝L2延伸を担っているアプライアンスの名称）が必要なトラフィックフローに対して Mac Address Translation を行うことによりこのようなイレギュラーな環境であっても問題なく通信ができるような環境を整えています。
これをご理解いただくためにまずは基本的な環境における Mac Address の処理を解説します。
(1) L2延伸を構成している HCX‐NE は、以下の動作を行っています。
移行元に配備された HCX-NEは、移行元 Default Gateway へ ARP Probe を送り物理 Router の Macアドレスを認識
(2) 移行先に配備された HCX-NE は、 RARP を送信し HCX-NE が学習した Macアドレスを NSX に告知
(3) HCX-NE は移行元・移行先間で Broadcast を転送、これによってワークロード間のARP処理（.2宛など）は邪魔しない。
ただし、 Default Gateway （この例では.254宛）へのARPリクエストだけはブロックして転送しない
これらの動作により Mac Address Translation を行う下地が整います。
次に旧環境にしかない Route への疎通性についてです。この例では 192.168.2.0/24 宛の通信をワークロード（IP address 192.168.0.1 Mac address xx.xx.xx.aa.aa.aa）が新環境（NSX Gateway）の Default Gateway に転送した場合の挙動を解説します。
(1) VM ワークロードが Default Gateway（NSX Gateway） にパケットを転送
src: xx:xx:xx:aa:aa:aa dst: xx:xx:xx:bb:bb:bb
(2) NSX Gateway が Policy Route に法り、移設先 HCX-NE にパケットを転送
src: xx:xx:xx:aa:aa:aa dst: xx:xx:xx:cc:cc:cc（Mac Address Translation）
(3) 移設元 HCX-NE が物理 Router にパケットを転送
src: xx:xx:xx:aa:aa:aa dst: xx:xx:xx:xx:xx:xx（Mac Address Translation）
(4) 物理 Router が VM 宛にパケットを送信
src: xx:xx:xx:xx:xx:xx dst: xx:xx:xx:aa:aa:aa
(5) 移行先 HCX-NE が VM宛にパケットを送信
src: xx:xx:xx:cc:cc:cc dst: xx:xx:xx:aa:aa:aa
動作（２）と（３）の部分で、転送先 Mac Address が書き換わっている点にご注目ください。この Mac Address Translation の仕組みを流用することによって、このような物理と仮想環境で同一IPアドレスを保持したゲートウェイが存在しても問題なく両端における通信が実行されます。
ちなみにこの例では物理 Router と NSX Gateway の組み合わせ例での解説でしたが、例えば移行元の Gateway が物理 Router ではなく、 NSXv のような古い仮想Gatewayだと、同一IPアドレス、同一Macアドレス、というネットワークとしては更に困難な環境になるのですが、この仕組みであればそのような環境であっても問題なく動作させることが可能となります。
まとめ
ここまでご紹介した仕組みにより、HCX とその拡張機能である MON を利用することによって L2延伸上でワークロードの IPを維持したままプラットフォーム間で移動させつつ、ネットワーク上の Default Gateway までも維持した移行をサポートすることが可能となります。
VCF には、VCF Import と呼ばれる既存 SDDC 環境を VCF 環境へインポートする手法もあり、こちらをご検討いただくことも可能です。既存環境を VCF Import を利用してそのままプライベートクラウド化するか、ハードウェアリフレッシュのタイミングで新環境に新プライベートクラウドを構成したうえで HCX によりワークロードを移設するか、2つの手法をご用意しておりますので皆さまの環境やお好みに応じた手法で次世代プライベートクラウドへの移行をご検討いただければと思います。
