はじめに
以前、Amazon EVS が VCF 9 に対応した際に「デプロイ方式がセルフデプロイモードだけになった」という話を書きました。
VCF 5.2 では EVS が VCF スタックの構築まで全部やっていましたが、現状 VCF 9 からは AWS が用意するのは VLAN サブネットとベアメタルホストまで。VCF 本体のインストールと設定は自分でやる必要があります。
「AWS が公開した自動化ツールキットを使えば3つの CLI コマンドで進められる」と記事では軽く触れただけだったので、今回はその中身、つまり ゼロから稼働する VCF 9.1 環境まで、全体としてどういう流れで構築されるのか を整理してみます。
手を動かす前に「全体像を把握しておきたい」という人向けの記事です。各フェーズの細かい手順や（あまりありませんが）ハマりどころは、別記事で順に書いていく予定です。
参考にしたのは AWS 公式ブログとツールキットのリポジトリです。
GitHub:
自動化ツールキットとは
aws/solutions-for-amazon-evs リポジトリの Deploy/VCF9-Phased-Deployment にある、Amazon EVS 上で VCF 9.1 をデプロイするための IaC + スクリプト一式です。手動でやると数十ステップになる VCF のインストールを、大きく3つのフェーズに分けて自動化しています。
セルフデプロイモードになったことで作業が増えたように見えますが、このツールキットのおかげで実際に手を動かすのは実質3コマンド。むしろすべての構成がコードに残るので、リージョンやアカウントをまたいで同じ環境を再現できたり、設定判断が全部バージョン管理されたりと、手動デプロイにはないメリットがあります。
全体アーキテクチャ（デプロイ完了後）
デプロイ完了後のアーキテクチャは以下の通りとなります。現時点でデプロイツールを使うと3ホスト構成（Simple Deployment）にてデプロイされます。
全体の流れ：3フェーズ ＋ 1つの手動ステップ
まず全体像から。ゼロから完成まで、時系列で並べるとこうなります。
| ステップ | ツール | 実行場所 | 所要時間 | やること |
|---|---|---|---|---|
| Phase 1 | Terraform | ローカル | 5〜10分 | AWS 基盤（VPC・サブネット・DNS・Route Server など） |
| Phase 2 | Python (boto3) | ローカル | 30〜45分 | EVS 環境・3ホスト・VLAN サブネット・EBS |
| 手動ステップ | ESXi UI | jumpbox 経由 | 約30分 | データストア作成・VLAN タグ付け・OVA デプロイ |
| Phase 3 | Python (VCF SDK) | jumpbox | 3〜4.5時間 | VCF bringup・NSX Edge クラスター・BGP |
合計すると、空っぽの状態から完全に稼働する VCF 9.1 環境まで おおよそ3.5〜6時間。このうち手で操作するのは真ん中の手動ステップの約30分だけで、あとの3フェーズはコマンドを叩いたら基本は待つだけです。
Phase 3 が3〜4.5時間と長く見えますが、これは大半が VCF bringup（各管理コンポーネントのバイナリをダウンロードしてデプロイ・構成する処理）の待ち時間です。ここは VCF を手動でインストールしても同じくらいかかる部分なので、自動化で短縮されているのは「人が張り付いて操作する時間」の方だと考えるとしっくりきます。
以下、各フェーズで何が起きているのかを順に見ていきます。
Phase 1：AWS 基盤を Terraform で作る
最初のフェーズは、VCF を載せるための AWS 側のネットワーク基盤づくりです。terraform.tfvars にリージョンや AZ、VPC の CIDR、ホスト名などを書いて terraform apply を実行すると、次のようなリソースが一気に作られます。
- VPC（/16）と VLAN サブネット群
- Route 53 のホストゾーンと DNS レコード（正引き・逆引き）
- VPC Route Server（BGP 用、エンドポイント2つ）
- NAT Gateway / Internet Gateway / DHCP オプションセット
- EC2 キーペア
create_tgw や create_jumpbox といったフラグで、Transit Gateway や踏み台サーバー（jumpbox）を作るかどうかも切り替えられます。Phase 3 はこの jumpbox 上で実行することになるので、多くの場合は jumpbox も一緒に作っておくことになります。
CIDR の切り方が地味に便利で、cidr_prefix に先頭2オクテット（例: "10.0."）を渡すと、第3オクテットを固定して VLAN ごとに /24 サブネットへ自動分割してくれます。vMotion は .20、vSAN は .30、といった具合に予測可能で重複しないサブネットが割り当てられるので、手作業での割り当てミスが起きません。
Phase 2：EVS 環境とホストをプロビジョニングする
次のフェーズは、EVS の環境本体とベアメタルホストを立ち上げるところです。コマンドはこれ1つ。
$ python -m src.main deploy-environment
Phase 2 は Phase 1 が出力した terraform.tfstate を自動で読み込んでくれます。VPC ID やサブネット ID、Route 53 のホストゾーンといった値を、フェーズ間で手でコピー＆ペーストする必要がありません。作業者が用意するのは config.json（環境名や VCF Installer のバージョンなど）だけです。
このコマンドで作られるのは主に次のものです。
- EVS 環境と3台のベアメタルホスト（ESXi 9.1、i4i.metal または i7i.metal-24xl）
- VCF ネットワーク用の10個の VLAN サブネット
- VCF Installer 用の 256 GB gp3 EBS ボリューム
パスワードの扱いもよく考えられています。vCenter や NSX、SDDC Manager などの各種パスワードは自動生成され、AWS Secrets Manager に保存されます。平文のパスワードがディスクに書き出されることはなく、後続の Phase 3 が実行時に Secrets Manager から読み出して使う仕組みです。
なお、このツールキットのデフォルトは3ホストの Simple モデル構成です。ホスト数や冗長構成の考え方は以前書いた記事で掘り下げているので、そちらもどうぞ。
手動ステップ（30分程度）
Phase 2 と Phase 3 の間に、1か所だけ手作業が入ります。ここが自動化されていない唯一の区間で、所要時間はおよそ30分。jumpbox から ESXi ホストの Web UI にアクセスして、次の3つを行います。
- VMFS データストアの作成 — 256 GB の EBS NVMe ボリューム上に VMFS データストアを作る
- VM Network の VLAN タグ付け — VM Network ポートグループの VLAN ID を 20 に設定する
- VCF Installer OVA のデプロイ — さきほどのデータストアに VCF Installer の OVA をデプロイして起動する
VCF Installer を動かすための土台を手で用意するイメージです。OVA デプロイ時に設定した admin@local のパスワードは Phase 3 で使うので、控えておきます。
このステップは今のところ手動ですが、手順自体はシンプルなので、実際のスクリーンショット付きの手順は別記事で早めにまとめようと思っています。
Phase 3：VCF bringup と NSX Edge クラスター
最後のフェーズが本丸で、VCF スタック全体を組み上げます。jumpbox 上で実行するコマンドはこれです。
$ python -m src.main deploy-vcf-and-edge
実行前に、手動ステップで設定した OVA の admin@local パスワードと、Broadcom のデポトークンの2つを環境変数で渡します。それ以外の vCenter / NSX / SDDC Manager のパスワードは、Phase 2 で Secrets Manager に入った値を自動で解決してくれるので、手入力は最小限です。
デポトークンは VCF Installer がバイナリをダウンロードするために必要なもので、取得でつまずきやすいポイントでもあります。取り方は別記事で扱っているので、ここが初めての方はあわせて確認してみてください。
このコマンドの中では、大きく次のことが順に進みます。
- VCF bringup — vCenter、SDDC Manager、NSX Manager、VCF Operations、Cloud Proxy をデプロイ・構成（ここが約2〜3時間で一番長い）
- 一時リソースのクリーンアップ — OVA 配置に使った VMFS データストアと EBS ボリュームを削除
- NSX Edge クラスターの構築 — 2台の Edge ノードをデプロイし、Tier-0 / Tier-1 ゲートウェイと BGP を構成
- Ops Manager Connector の作成 — EVS の Ops Manager コネクターを登録
BGP まわりが個人的におもしろいところで、NSX 側（ASN 65000）と Phase 1 で作っておいた VPC Route Server 側（ASN 65022）でピアリングが確立します。これにより、NSX のオーバーレイセグメント上のルートが VPC のルートテーブルへ自動的に伝播されるようになります。手動でルートを設定しなくても、オーバーレイとアンダーレイがつながるわけです。
Phase 1 と Phase 3 はべき等に作られているので、途中で失敗しても副作用なく再実行できるのも安心なポイントです。
デプロイ後の環境
以下が実際にデプロイをしvSphere Clientでアクセスした状態です。
3ホスト構成（Simple Deployment）にてデプロイされています。NSX Edgeもデプロイ・構成されています。
デプロイ後の確認
一通り終わったら、ちゃんとつながっているかを確認します。ブログでは主に次の3つが挙げられています。
-
AWS コンソールで Route Server の BGP ピアが両方とも Established になっているか
-
NSX 側でテスト用のオーバーレイセグメント（例:
172.16.1.0/24）を作り、そのルートが VPC ルートテーブルに伝播されるか -
テストセグメント上の VM と jumpbox の間で双方向に ping が通るか
- ssh で疎通を確認
ここまで確認できれば、オーバーレイとアンダーレイをまたいだエンドツーエンドの疎通が取れている、ということになります。
まとめ
Amazon EVS 上の VCF 9.1 エンドツーエンド自動デプロイの全体像を、時系列で追ってみました。
- Phase 1（Terraform） で AWS 基盤を作り
- Phase 2（Python） で EVS 環境とホストを立ち上げ
- 手動30分 で VCF Installer の土台を整え
- Phase 3（Python） で VCF スタックと NSX Edge を組み上げる
次回以降は、まず手動ステップの実際の手順あたりから、各フェーズを順に掘り下げていく予定です。