VMware Cloud on AWS VMware Cloud クラウド クラウド移行

VMware HCX の Mobility Optimization Networking (MON) 機能でトロンボーン現象を回避する！

オンプレミスから VMware Cloud on AWS への移行でよく利用されるのがネットワーク延伸機能です。オンプレミスのネットワークをクラウドへ延伸すると、vMotion を使って仮想マシンを停止せずに移行できます。しかし、大規模な移行環境ではトロンボーン現象（同じ経路を無駄に往復する通信）が問題視されることがあります。今回は、その問題を解決する VMware HCX（HCX） の Mobility Optimization Networking (MON) 機能について解説します。尚、HCX に関してはブログ「VMware HCX とは」および「VMware HCX の移行機能」をご覧ください。

 

 

目次

 

 

 

クラウド移行とネットワーク延伸

HCX を活用すると、素早く簡単に仮想マシンをクラウドへ移行できます。例えば、仮想マシンを停止せずに vMotion を使って移行できます。また、移行プロセスの中で IP アドレスを自動的に変更して別なネットワークに移行することもできます（図1）。

図１　様々な移行方法に対応できる VMware HCX の移行機能

 

vMotion を使ってクラウドへ移行する時に役立つのがネットワーク延伸機能です。vMotion は OS を起動したまま仮想マシンごと移行させるので、ネットワーク設定（IP アドレスや MAC アドレスなどの情報）は変更されずに移行先でも使われます。移行前に使っていたオンプレミス側の既設ネットワークをクラウドに延伸しておけば、vMotion で移行してもオンライン状態が維持でき、通信を継続できます（図2）。

図２　ネットワーク延伸環境で vMotion を使ったクラウド移行

 

HCX が提供するネットワーク延伸機能については、ブログ「無停止クラウド移行のシンプルなオペレーション（VMware HCX のライブマイグレーション）」をご覧ください。

 

 

 

気になるトロンボーン現象

ネットワーク延伸機能を利用する時に、しばしば懸念されるのがトロンボーン現象です。オンプレミスに存在するネットワークをクラウドに延伸しても、そのネットワークの Default Gateway（ルータ）はオンプレに存在しています。つまり、延伸したネットワークを使っている限り、仮想マシンがクラウド側に存在していても外部ネットワークへの通信は Default Gateway を経由するのでオンプレミスに戻ります（図3）。

図３　Default Gateway がオンプレミス存在している通信経路

 

さらに、ネットワーク延伸を２つ構成した環境を見てみましょう（図4）。延伸した２つのネットワークには、それぞれ仮想マシンが接続されています。この時、クラウド側に存在する仮想マシン同士の通信はオンプレミスを経由します。このようなクラウドとオンプレミスを往復する非効率な通信を「トロンボーン現象」と呼びます。

図４　ネットワーク延伸環境のトロンボーン現象

 

トロンボーン現象は、通信がほとんど発生しなければ大きな問題にはなりません。しかし、通信量が増加すると通信コストの増加などが問題視されることがあります。

 

 

 

MON で悩みを解決！

HCX を活用するとトロンボーン現象を回避できます。それを実現するのが「Mobility Optimization Networking  (MON)」という機能です。MON は、HCX で延伸したネットワーク上に存在する仮想マシンの中でクラウド側に存在している仮想マシンに対して有効に働き、トロンボーン現象を回避する仕組みを提供します。

仕組みについて簡単に説明しましょう。HCX を活用してクラウドに延伸したネットワークで MON 機能を有効化すると、クラウド側のルータが Default Gateway として使えるようになります。クラウド側に移行した仮想マシンを MON の対象に含めると、そのクラウド側のルータを Default Gateway として選択できるようになります（図5）。

図５　MON を活用した通信経路

 

クラウド側に存在する他の仮想マシンの Default Gateway もクラウド側のルータに切り替えておけば、本来オンプレミスに戻るはずだった通信は、クラウド内でルーティングされます。これで、クラウドとオンプレミスを無駄に往復するようなトロンボーン現象は発生しなくなります。

 

 

 

HCX と NSX の連携

MON の設定を含め、もう少し詳しく説明しましょう。MON を利用するには、クラウド側に VMware NSX（NSX） が必要です。ちなみに、VMware Cloud on AWS をはじめとした VMware Cloud サービスが提供するクラウドインフラには NSX が実装されており、MON が利用できる環境が整えられています。HCX でネットワーク延伸環境を作成した後に MON を有効化すると、NSX と連携して以下の制御が可能になります（図6）。

  • 延伸したネットワークでクラウド側のルータ（T1 Router）が使える
  • ルーティング制御を目的としてクラウド側のルータにスタティックルートを定義できる
  • 仮想マシン単位で Default Gateway をクラウド側のルータに切り替えられる
図６　NSX のネットワーク環境における MON の連携/制御ポイント

 

MON を有効化した仮想マシンは、Default Gateway をオンプレミスからクラウド側に切り替えることができるようになります。クラウド側に Default Gateway を切り替えた場合、延伸されたネットワークから外部への通信は、クラウド側のルータに送られます。この切り替え操作は、HCX の管理インターフェイスから実行します（図7）。

図７　仮想マシンに対する Default Gateway を切り替える設定（HCX の管理インターフェイス画面）

 

一方、MON を有効化するとクラウド側のルータ（T1 Router）にスタティックルートが定義できるようになります（図8）。このスタティックルート（MON の機能では「Policy Routes」と呼びます）には、オンプレミスへのルート情報を定義しておきます。 MON を有効化した仮想マシンから外部ネットワークへの通信は、必ずこの Policy Route で検査されます。

図８　スタティックルート「Policy Routes」の定義（HCX の管理インターフェイス画面）

 

クラウド側のルータに Default Gateway を切り替えた 仮想マシンの通信は、Policy Route の定義に従ってルーティングされます。これによって、オンプレミスへの通信も制御できるようになります（図9）。尚、この Policy Route に適合しない宛先（登録されていないルート）は、アップリンクに相当する Edge Gateway Router（T0 Router）にルーティングされます。

図９　MON を有効化した環境とスタティックルートの活用例

 

尚、MON を有効化した仮想マシンのホスト情報は、自動的にクラウド側のルータのルートテーブルに登録されます（「/32」のアドレスの形式で登録）。これによって、MON を有効化した仮想マシン同士はクラウド側のルータによって認識されるので、最短経路で通信できるようになります（図9）。

 

 

 

MON は万能か？

このように MON は非常に便利な機能ではあります。しかし、さすがに万能ではありません。MON を利用する場合、いくつかのシステム要件や留意点がありますので、導入を検討する際にそちらをご確認ください。詳細は ドキュメント「VMware HCX Mobility Optimized Networking for VMware Cloud on AWS」- VMware Tech Zone および「HCX User Guide」をご覧ください。代表的な留意点を挙げてみましょう。

 

VMware Tools が必要

MON を利用する仮想マシンの OS には、VMware Tools をインストールしておくことが必要です。

 

有効化できる仮想マシンの上限

MON を有効化して利用できる仮想マシンの最大数にも配慮してください。2022年12月時点では、標準環境で最大400まで有効化できます（詳細は「VMware Configuration Maximum」でご確認ください）。

 

Connected VPC との通信は未サポート

VMware Cloud on AWS の環境で使用する場合、Connected VPC への通信に対して MON は機能しません。Connected VPC については「VMware Cloud on AWS スタートガイド」をご覧ください。

 

マニュアル操作が必要

MON を有効/無効化する設定やルート切り替える設定は、HCX の管理インターフェイスからマニュアル操作で行います。特にルーティングについては慎重に定義した上で切り替えを行う必要がありますので、操作手順の確認および動作検証を強くおすすめします。

 

インターネット間の通信には考慮が必要

MON は、インターネットからデータセンターに入ってくる通信など、延伸されたネットワークの外部から入ってくる通信に対して制御できません。クラウド移行の前後でインターネット間との通信に対しても MON と併用させたい場合は、データセンターのネットワーク設計変更やクラウド上で SNAT を適用するなどの合わせ技が必要です。

 

MON は、クラウド移行の過程で発生する非効率な通信を最適化できる機能ですが「必須機能」ではありません。MON の効果は企業の既設ネットワーク設計に大きく左右される場合がありますので、事前に検証してから導入可否を判断することをおすすめします。

何らかの理由で MON が利用できずトロンボーン現象が気になる場合は、クラウド移行自体を短期間で終わらせて、Default Gateway をクラウド側に素早く切り替えてしまう方法も検討しましょう。クラウド側に Default Gateway を切り替えてネットワーク延伸を解除してしまえば、トロンボーン現象は発生しません。また、クラウド移行が終わればネットワーク延伸機能を残し続ける理由はほとんどなくなります。MON には過度な期待をせずに、活用する場所や期間にも配慮しながらご利用ください。

 

 

 

まとめ

今回は、ネットワーク延伸環境でのクラウド移行をより効率化する機能「Mobility Optimization Networking」をご紹介しました。クラウド移行をよりスムーズかつ効率的に実現できることがお分かりいただけたら幸いです。より詳しい情報は、VMware の営業または VMware の各社パートナー様にご相談ください。

 

 

 

関連情報リンク

吉田 尚壮

プリンシパル ソリューション アーキテクト｜ヴイエムウェア にて VMware Cloud Foundation の技術担当として営業支援活動に従事しています。

関連記事