HCXに関して、サイトAとサイトBにそれぞれvCenterが存在し、サイト毎にHCX ManagerをデプロイしてvCenterと連携させる構成がオンプレミス間で移行させる際の基本的な構成となります。そのため、１つのvCenterでサイトA、B両方を管理しているような環境では、HCXが構成できないと思っていたのですが、Version 4.5からシングルvCenter構成でのBulk Migrationがサポートされた旨の記載があったようです。
HCX Bulk Migration for Single vCenter Server Topologies
In HCX 4.5, HCX can be deployed within a single vCenter Server to enable the Bulk migration. This is useful for cluster-to-cluster migrations in environments where the vendor compatibility or other requirements for cluster-to-cluster vMotion cannot be satisfied.
こちらの方のBlogでも本構成が紹介されており、参考にさせていただきました。
https://chrisdooks.com/2023/02/20/hcx-bulk-migration-for-single-vcenter-server-topologies/
サイト毎にvCenterが存在する構成のデプロイしか経験したことがないので、このシングルvCenterでの構成イメージを掴むために実際にデプロイしてBulk Migrationができるところまで試してみました。Versionは4.10です。
HCX Cloudのデプロイ
BroadcomダウンロードサイトからHCX CloudのOVAファイルをダウンロードし、移行先となるクラスタ上にデプロイします。
1枚1枚画面キャプチャを貼るのは省略しますが、おおまかな手順としては、OVAファイルからデプロイ時に指定したIPアドレス（or FQDN）の9443ポート宛にブラウザでアクセスし、初期設定を進めます。下記画像の入力項目＋ライセンスのアクティベーションを実施する必要があります。
HCX Cloudは本番環境ではNSX Managerとの連携も必要となります。
Network ProfileとCompute Profileを作成する
HCX Cloudの初期設定でvCenterと連携したことでHCXのvCenterプラグインが追加されます。vSphere ClientからHCXの設定が実施できるようになります。
HCX Manager（HCX CloudやHCX Connector）以外のHCXコンポーネントはNetwork ProfileとCompute Profileに従って、この後のService Mesh作成時に自動的にデプロイされます。
今回は管理用のネットワークとアップリンク用のネットワークを2つのクラスタ間で共通のものを用意しておりますので、下記のような形でアップリンク用とそれ以外としてNetwork Profileを2つ用意しました。
Compute Profileのほうでは、使用するサービス（今回はBulk Migration）やHCXコンポーネントをデプロイするクラスタやデータストア、使用するNetwork Profileの指定等を行います。
Bulk MigrationとWAN Optimization（VM移行トラフィックの最適化）をサービスとして指定
選択したサービスに必要なコンポーネントをデプロイするクラスタとデータストアを指定
使用するNetwork Profileの指定
Compute Profileの作成が完了
これでHCX Cloud側（移行先側）での準備は完了です。
HCX Connectorのデプロイ
HCX Connectorのデプロイに関してはHCX Cloudとほぼ同様です。ダウンロードサイトからOVAファイルをダウンロードし、移行元クラスタの方にデプロイします。ブラウザアクセス後の初期設定も下記画像の通り、ほぼ同様です。
HCX ConnectorについてはNSX Managerとの連携はオプションとなります。
Network ProfileとCompute Profileを作成する
こちらも手順としてはHCX Cloud側と同様です。vSphere ClientのHCXプラグインがどうなるのかと思いましたが、HCX ConnectorをデプロイしvCenterと連携した時点でHCX Connector側のプラグインで上書きされ、vSphere ClientからはHCX Connector側の設定のみが行える状態になるようです。そのため、HCX Cloud側の設定を後から変更したい場合は、vSphere Clientからではなく、HCX Cloud自体にブラウザでアクセスしGUIから設定変更する形となります。
Site PairとService Meshを作成する
ここまででHCX CloudとHCX Connectorの個別の準備が完了しましたら、Site Pairを作成し、その後Service Meshを作成することで、すべての準備が完了します。
設定自体はこのままHCX Connector側のGUIを利用するため、vSphere Clientのプラグインから行えます。
Site Pairに関してはHCX Cloudの初期設定で入力したPublic Access URL宛にvCenterのクレデンシャルを入力して正しく認証されればペアリング完了となります。
最後にService Meshを作成します。
Service Mesh作成ではお互いのサイトで使用するCompute Profileを選択します。それぞれのサイトでCompute Profile作成時に選択したNetwork Profileを自動的に選んでくれます。その他WAN Optimizationアプライアンスのアップリンク帯域幅の設定などがあります。
Service Mesh作成が開始されるとお互いのサイト（今回の場合はクラスタ）でHCXコンポーネントのデプロイが開始されます。HCXのGUIからは下図のTasksタブで進行状況が確認できます。（なんらかのエラーで作成が失敗した場合などはこのTasksの画面からどこで失敗したのかが確認できます）
Service Meshが作成完了した後、上図のようにAppliancesタブからデプロイされたアプライアンスの状況を確認し、Tunnel StatusがUPになっていれば、正しくアプライアンス同士が疎通しており、仮想マシン移行ができる状態となります。
下図のように2つのクラスタそれぞれでHCXアプライアンスをデプロイすることができました。
（interconnect.. という名前の仮想マシンが自動デプロイされたものです。IXが仮想マシン移行用、WOはWAN Optimization用のアプライアンスとなります）
仮想マシンを移行してみる
それでは実際に仮想マシンをBulk Migrationで移行してみます。テスト用の仮想マシンを選択し、仮想マシンの切り替えスケジュールは即時とします。
今回参考にさせていただいた冒頭のBlogにも情報があったのですが、移行の際に移行先のクラスタやデータストア、仮想マシンフォルダを指定する際に、フォルダが移行元の仮想マシンが存在するフォルダと同一ですと、エラーとなり移行ができません。
ここはvCenterが別れている環境であれば気にしなくても良いポイントでしたので、注意が必要です。
その後、特に問題なく移行完了できました。
おわりに
シングルvCenter環境のHCXデプロイ試してみましたが、普段の2サイトでvCenterが個別にある場合とほぼかわらなかったですね、、（そりゃそうか）
いつもの環境との差異というとvSphere Clientのプラグインが書き換わり、HCX Cloud側を後から設定変更する場合は直接HCX Cloudにブラウザでログインする、というのと仮想マシン移行の際のフォルダぐらいでしょうか。