VMware HCXのMobility Optimized Networking (MON)を使用しトロンボーントラフィックを解消

# はじめに
<!-- 発端や概要を記載 -->
[VMware HCX](https://www.vmware.com/jp/products/hcx.html)ではAdvancedエディションとEnterpriseエディションという2つのエディションがあり、Enterpriseエディションでは移行だけではなく、オンプレミスのVMware環境とクラウド間の接続環境で運用の効率性を高める便利な機能も含まれています。

今回はそのEnterpriseエディションの中でも特にL2延伸をする際に有用なMobility Optimized Networkingについて紹介をいたします！

# 目次
<!-- タイトルとアンカー名を編集 -->
1. [L2延伸時の一般的な考慮点](#l2延伸時の一般的な考慮点)
1. [Mobility Optimized Networking (MON)](#mobility-optimized-networking)
1. [MONを使ってみる](#monを使ってみる)
1. [まとめ](#まとめ)
1. [参考文献](#参考文献)

<!-- 各チャプター -->
<a id="#l2延伸時の一般的な考慮点"></a>
# L2延伸時の一般的な考慮点
通常、サイト間でネットワークを延伸している（L2延伸 / L2VPN）環境おける一般的な考慮事項として、延伸したセグメントのデフォルトゲートウェイがオンプレミス側に残ってしまうという事が挙げられます。
これは何を意味しているかというとネットワークが延伸された先のVMwareの環境（例えばクラウド上のVMware環境）上の仮想マシン間の通信の場合、クラウド内で通信を完了させたいですが、例えばVM AとVM Bが別セグメントに接続していて、AからBに通信する場合、一旦オンプレミス側にあるVM Aが接続しているセグメントのゲートウェイを経由して、またトラフィックがクラウド側に戻ってくるという所謂トロンボーントラフィックですとかヘアピントラフィックが発生します。これによりレイテンシー、帯域の圧迫が懸念となる場合があります。

<a id="#mobility-optimized-networking"></a>
# Mobility Optimized Networking
これを解消するのが Mobility Optimized Networking (MON) です。延伸されたネットワーク上に接続した仮想マシンはDefault Gateway がオンプレミス側に存在していても、仮想マシン間の通信についてはDefault Gateway に戻ることなく通信できるようになります。これによってトロンボーン現象は回避され、非効率なトラフィックが削減できます

<a id="#monを使ってみる"></a>
# MONを使ってみる
今回はVMware Cloud on AWSを利用してMONを有効化してみます。
HCXからネットワークを延伸する時にMobility Optimized Networkingのチェックボックスにチェックを入れるだけでそのネットワークのMONは有効化されます。
MONが有効になると添付のスクリーンショットのように各ネットワークごとに"MON"という表示がつきます。
![NE_MON.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/dd3e8fa5-9cca-2e0d-1255-bbc572b21ac1.png)

既に延伸済みのネットワークもMON有効化・無効化の変更ができます。


レイテンシーがどう変化されるかを確認する為にVMware Cloud on AWS上のL2延伸をしていないセグメント（192.168.1.0/24）に接続しているVMから延伸しているネットワークに接続しているVM（192.168.150.35）にpingを打ち、レイテンシーの変化を確認します。
![Overview.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/cbba65dd-4c7c-9734-1c8a-13884f3023f6.png)



スクリーンショットを撮り忘れましたが、オンプレミスに仮想マシンがある状態（移行前）のレイテンシーは23 msほどでした。

仮想マシンをHCX vMotionでSDDCに移行します。
移行後レイテンシーが約2倍の45 msになってしまいました。
![ping0.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/0ccd30e1-9e8a-ca74-153e-af847ae39ff7.png)

これはL2延伸時の般的な考慮点で述べたトロンボーントラフィックが発生してしまっている為です。
![Trombone traffic.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/6b154a27-6705-34a8-fda6-5f42ff66145b.png)


MONを有効化したのに何故でしょう・・？

実は仮想マシン毎にルーターのロケーションが定義されており、移行後にそのロケーションを明示的に移行先であるVMware Cloud on AWSを指定してあげる必要があります。
![MON1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/d68d8fa1-6b6a-3b49-bf4a-597cb6dc734a.png)
![MON2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/58f0e492-7398-fb36-be5e-f067391090f2.png)
![MON3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/d6e323b4-e4ca-146c-0e7d-03ee7be3b998.png)


設定を変更が完了すると以下のようにルーターロケーションの所に"MON"という表示がつきます。
![MON4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/3b735fe2-17dc-97d2-c7a4-76019ba7b243.png)

pingの状態を見るとレイテンシーが45 msだったのが0.3 msに改善しています！
![ping1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/c96b2e68-55c9-cf96-d98f-9374e226f05d.png)



<a id="#まとめ"></a>
# まとめ
HCXのEnterpriseエディションに含まれるMONを利用する事によりL2延伸利用時の仮想マシン間の通信のトロンボーントラフィックを防ぐ事ができ、レイテンシー、帯域の圧迫を解消する事ができます。
そしてVMware Cloud on AWSの場合、[追加の費用発生する事なくこの機能が使えます](https://blogs.vmware.com/vmware-japan/2020/11/vmware-cloud-on-aws-hcx-all-functions.html)！
是非有効活用してみてください。


<a id="#参考文献"></a>
# 参考文献
- [VMware HCX Documentation](https://docs.vmware.com/en/VMware-HCX/index.html)