NSX Multi-TEP HA機能を試す

NSX 4.1から追加されたMulti-TEP HAの機能を試してみました。
BFDでTEP間の疎通性を追跡し、リンクアップはしているが何等かの理由でTEP間の疎通が取れなくなった場合などにMulti TEPと本機能を有効にしておくと、障害が発生していないほうのTEPにVMのvNICを割り当てなおしてくれます。
# 準備した環境
ネストESXiを2ホスト分用意し、NSXをMulti TEPでインストールします。それぞれのvmnicはVLAN TrunkのNSXセグメントを用意して使用しています。

このネストESXiのvmnicが接続されているセグメントのVLAN Trunk設定を消すことで、リンクアップはしているがGeneveカプセル化されたパケットがセグメントを通過できなくなる、という状況を作れますので、その際の動作を確認していきます。

NSXのバージョンは下記になります。
NSX: 4.1.2

![画像1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/4f2c7969-34bb-5cff-34e4-826620adc8fb.png)

# 動作の確認
いまのところMulti‐TEP HA機能についてはGUIが用意されておらず、設定や設定の確認はAPIで行う必要があるようです。

[Multi-TEP High Availability](https://docs.vmware.com/en/VMware-NSX/4.1/administration/GUID-72C2F2B2-7DC6-49A2-AD74-2FBAC93E3FAC.html "Multi-TEP High Availability")

まずはTEP HAのプロファイルを作成する必要があるため、下記のリクエストURLとボディを使います。
ID（プロファイル名）もvtephaprofile1と上記リンク先のマニュアルそのままにしました。
```
PUT https://<nsx-policy-manager>/policy/api/v1/infra/host-switch-profiles/vtephaprofile1
```

```
{
"enabled": "true",
"failover_timeout":"5",
"auto_recovery" : "true",
"auto_recovery_initial_wait" : "300",
"auto_recovery_max_backoff" : "86400",
"resource_type": "PolicyVtepHAHostSwitchProfile",
"display_name": "VtepHAProfile1"
}
```
リクエストボディもマニュアルそのままです。（それぞれの項目の意味もマニュアル参照）

TEP HA プロファイルを作成した後は、これをトランスポートノードプロファイルに紐づけてやる必要があります。
今回の環境では、NSXインストール時に既にトランスポートノードプロファイルを作成済みでしたので、既存のトランスポートノードプロファイルにTEP HA プロファイルを紐づけました。

手順としては現在利用中のトランスポートノードプロファイルをGETし、`"host_switch_profile_ids"`の箇所に下記のブロックを追記してPUTする形になります。
```
                    {
                        "key": "VtepHAHostSwitchProfile",
                        "value": "/infra/host-switch-profiles/vtephaprofile1"
                    }
```
![SnapCrab_NoName_2024-6-10_15-16-28_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/d9e9789e-a3f0-1a89-16e2-48cba8f4b324.png)

ここまでの準備が整ったら、Overlayセグメントを1つ作成し、別々のホストに存在する2つの仮想マシンを接続します。その後Pingで通信させ、ホストのTEP間でGeneveトンネルを確立したかを確認します。
![SnapCrab_NoName_2024-6-10_15-27-9_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/b1015b29-5569-f8a6-bc82-5382f8ccc0d9.png)
Geneveトンネルが確立され、カプセル化インターフェースとしてvmk11を使用しています。
vmk11が使用するvmnicをesxtopで確認してみます。
![SnapCrab_NoName_2024-6-10_15-28-7_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/cc1a510e-7590-5c36-0446-a7c387dcebea.png)
その後、vmnic2が接続されている箇所のVLAN Trunk設定を消します。

結果としてはMulti-TEP HA機能によって、TEP通信はvmk10側に割り当て直され、通信を復旧させることができました。
通信断は約10秒程度（1秒間隔のPingが9パケットほどロス）となりました。
![SnapCrab_NoName_2024-6-10_15-35-13_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/1a7fac0d-2db7-4b0b-55c0-e8e2d2d4c482.png)

![SnapCrab_NoName_2024-6-10_15-39-4_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/e4ee8fb6-17d7-ec3e-6c98-0522b4fee507.png)

また、TEP HA プロファイル内では`auto_recovery`の設定があり、こちらがtrueになっていると障害が発生したTEPの疎通が回復すると、元のTEPに切り戻る動作となります。
こちらもVLAN Trunk設定を元に戻し確認してみたところ、正確な時間は計測できておりませんが、元のvmkを使用するようにトンネルのステータスが更新されました。
![SnapCrab_NoName_2024-6-10_15-45-45_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/6484d7e2-f3b6-0b09-c5bb-0f66e804999b.png)
![SnapCrab_NoName_2024-6-10_15-46-41_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/463214ba-98a6-88af-f647-1973dd1cad05.png)
パケットロスは特になしでした。


もう1つのテストとして、TEP HA プロファイルの`failover_timeout`設定（障害検出から代替TEPへVMを移動するまでの時間）を5から1にしてPUTし直してみたところ、通信断時間は約5秒程となりましたので、期待どおりの動作となりました。
![SnapCrab_NoName_2024-6-12_13-56-16_No-00.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3657075/36b6fc10-6ad6-58fb-7974-0a3824c6a6dd.png)