この投稿は、vExperts Advent Calendar 2022 の 21日目です。
今回は HCX 4.4 バージョンにて GA となった “Network Extension High Availability” 機能をメインとした HCX Network Extension (以降、NE) の動作について共有したいと思います。
イメージ図
注意事項
・本記事では、下記環境のバージョンにて動作を確認しています。ご利用の環境状況及びバージョンの差によって、本記事の内容と異なる動作になる可能性があります。
コンポーネント | バージョン | 備考 |
SDDC | 1.20 | |
HCX | 4.5.2 | 現時点の最新バージョン |
・本記事では、下記の通り “CJ-SM” という Service Mesh が作成されており、NE 3 台がデプロイされている前提となります。
・本記事では、オンプレミスと VMConAWS 間の接続を Internet 経由としてあります。
挙動の確認内容
- L2 延伸
- HA 作成
- Failover テスト
- NE 削除 (2 台削除)
- NE 削除 (1 台削除)
- NE 名及び HA グループ名の変更
1. L2 延伸
本記事では、先に NE-l1 にて L2 延伸にて正常にオンプレミスと VMConAWS 間で疎通可能なことを確認します。まずは、下記箇所より L2 延伸作成を開始します。
オンプレミスの “sg-172-016-001″ ネットワークを指定しています。後ほど HA 作成後は、”sg-172-016-002” ネットワークも L2 延伸する予定です。
Gateway IP Address 箇所には、オンプレミス側の Gateway 情報 (例. 192.168.0.1/24) を入力します。また、Extension Appliance 箇所では、対象の NE (NE-l1) を指定します。
下記の通り L2 延伸ができていることが確認可能です。
また、オンプレミスと VMConAWS 間でも正常に疎通可能なことが確認できます。
2. HA 作成
上記イメージ図の通り、NE-l2 と NE-l3 の 2 台にて HA 構成を行います。
① : HA 構成対象の NE を 1 台選択します。(本記事では、NE-l2 を選択しています。)
② : “ACTIVATE HIGH AVAILABILITY” を選択します。上記 ① 手順にて、NE を 2 台選択した場合は、この HA 有効化ボタンがグレーアウトされる動作となります。
③ : “ACTIVATE HA” をクリックし、HA 有効化を実施します。ポップアップ画面の通り、HA のペアとなる NE は自動的に選定され、ユーザー側で任意の NE を指定することはできない動作となります。
HA 有効化タスクが実行された後、下記の通り正常に HA 構成ができたことが UI 上から確認可能です。
HA 構成完了後、上記手順 1 の残り “sg-172-016-002” ネットワークも L2 延伸します。(割愛)
3. Failover テスト
オンプレミスと VMConAWS の仮想マシン間で、PING を実施しておきます。
その後、”MANUAL FAILOVER” メニューより、手動にて Failover を実施します。
・現在 ACTIVE NE : CJ-SM-NE-l3
“VIEW HA ACTIVITY TIMELINE” メニューより、切り替えの詳細が確認可能です。
また下記の UI からも、 ACTIVE / STANDBY が切り替わっていることが確認できます。
・現在 ACTIVE NE : CJ-SM-NE-l2
Failover 時においても、仮想マシン間での PING 疎通は可能なことが確認できます。
補足情報として、NE を Power-OFF にして停止した場合も、HA は正常に動作し、ACTIVE / STANDBY が切り替わる動作となります。(NE が Power-ON してから約 4 分で STANDBY ステータスとなります。)
4. NE 削除 (2 台削除)
本記事では割愛しますが、NE を削除する前に、L2 延伸を除外する必要があります。L2 延伸を利用中に NE を削除しようとすると、エラーメッセージが出力され、NE が削除できない動作となります。
NE の削除は、Service Mesh の編集画面より、数を減らすことで削除可能です。今回は 3 台から 1 台へと数を減らすことで、NE 2 台を削除することとしてあります。これは、HA 構成が作成されている状態で、NE の削除イベントが発生した際の挙動を確認するためです。
Service Mesh 編集画面より、NE の台数を減らし、最後のステップまで進んでいくと、最後に下記の通り HA 構成状態では NE の削除ができないとのエラーメッセージが出力されることが確認できます。
previewServiceMesh Failed. Reason: Could not reduce/remove the network extension appliance count since the Network Extension appliances cannot be removed for switch pair nsx-overlay-transportzone (/infra/sites/default/enforcement-points/default/transport-zones/1b3a2f36-bfd1-443e-a0f6-4de01abc963e-nsxt-internal). To remove a network extension appliance, there should not be any networks stretched via that appliance and the appliances should not be part of an HA group. Please remove all the extended networks from the appliances that you want to remove and try again.
5. NE 削除 (1 台削除)
次は、NE 1 台のみを減らす設定にします。すると、削除対象として HA 構成外の NE-l1 が自動で選定されることが確認できます。次へ進むと、NE-l1 (VMConAWS の Peer 込) が削除される動作となります。
6. NE 名及び HA グループ名の変更
基本 NE の命名規則は下記のようですが、ご自身の運用ポリシーによっては NE 名を変更したいこともあると思います。
・オンプレミス側 : [Service Mesh 名]-NE-l 数字 (今回の例. CJ-SM-NE-l1 / CJ-SM-NE-l2 / CJ-SM-NE-l3)
・クラウド (Peer) 側 : [Service Mesh 名]-NE-R 数字 (今回の例. CJ-SM-NE-R1 / CJ-SM-NE-R2 / CJ-SM-NE-R3)
その際は、下記の通り対象の NE を選択した後、”RENAME APPLIANCE” メニューより変更可能です。(今回の例. CJ-SM-NE-l1 を CJ-SM2-NE-l1 と変更)
変更すると、Service Mesh 画面上でも変更されたことが確認できますし、vSphere Client のインベントリからも NE 名が変更されていることが確認可能です。
ちなみに、NE 名を変更する際にも PING 疎通は可能なことが確認できます。
最後に、現時点で HA グループ名 (今回の例. CJ-SM-HAGrp-1) は自動で設定されて、ユーザー側で変更することができないデザインとなっています。
以上、HCX NE の HA 構成から削除までの動作の紹介でした。本記事が、HCX の動作をご理解いただく上で、少しでもお役に立てれば嬉しいです。
明日の Advent Calendar は、Kunihiro さんです。
[参考情報]
コメントを残す