はじめに
VMware Cloud Foundation（VCF）という、SDDC Manager で SDDC 環境全体をイイ感じに管理できる製品があり、これを（ハンズオンラボでなく）自宅で触りたくなりました。ただの趣味というか興味です。
しかし VCF は、お行儀のよい SDDC 環境をしっかりした規模で作るための製品なので、自前で構築しようと思えば、たとえ最小構成でも、256 GB のメモリと 10 TB 超の SSD と 2 つの 10 GbE の NIC を積んだサーバを 4 台用意しないといけません。また、上位ネットワークとは BGP で会話できないといけないですし、DNS サーバや DHCP サーバなど周辺にもいろいろ必要です。さらにはネットワーク構成の詳細やさまざまなオブジェクトの命名など ワークブック の 400 ちかいパラメータを決定する必要もあります。
要するに、自宅で気軽に触れる程度のものでは到底ないわけです。ネステッドで作ればハードウェア面はある程度ごまかせはするものの、周辺サーバの用意やパラメータの決定は、ちょっと触れればいいとほんのり思っているくらいのモチベーションではしんどいものがあります。
とはいえ、海外のさかんな自宅ラボ事情を考えると、自宅で触りたい勢は世界のどこかには存在しているはずで、そう思っていろいろ調べていると、VCF Lab Constructor（VLC）なるものの存在を知りました。このエントリでは、これを使ってネステッドな VCF を構築するまでの流れを紹介します。
VCF Lab Constructor（VLC）
概要
VCF Lab Constructor（VLC）は、VCF をネステッド環境で簡単に構築できるようにいろいろお膳立てをしてくれるツールです。詳しくは VMware のブログで紹介されています。
- Deep dive into VMware Cloud Foundation – Part 1 Building a Nested Lab
- Deep dive into VMware Cloud Foundation – Part 2 Nested Lab deployment
具体的には、VLC 経由でデプロイすることで、
- 値が全部埋まったサンプルのパラメータ（JSON）が提供されていて、ただ動けばよいレベルであればそのまま使える
- Cloud Builder アプライアンスをパラメータに従って自動でデプロイしてくれる
- デプロイした Cloud Builder アプライアンスの中に、DNS サーバや BGP ルータなど、必須の周辺サーバの機能を無理やり同居させてくれる
- パラメータに従って vSAN の構成要件を満たした ESXi を ESXi 上の仮想マシンとしてデプロイしてくれる
- （指定すれば）Cloud Builder での Bring-Up プロセスも開始してくれる
などのメリットが得られます。これによって、VCF に必要な Cloud Builder と ESXi 環境がサクッと整うため、気軽に VCF を試す環境を得るためのハードルが一気に下がるわけです。
もちろん公式にサポートはされていませんが、開発は VMware のなかのひとであり、また Slack のコミュニティもあって、それなりにワイワイしています。
準備
VLC のダウンロード URL は、次の URL から登録することで得られます。
ここで得られる URL は最新版のダウンロード用ですが、過去のバージョン用の URL は Slack でピン止めされたメッセージでリストされています。
なお、VCF のバイナリ（Cloud Builder の OVA イメージ）と、VCF を構成する各製品（vCenter Server、ESXi、vSAN、NSX-T）のライセンスキーは別途必要です。ぼくは VMUG Advantage なヒトなのでそれで入手しています。
ハードウェア要件
VLC にはインストールガイドも付属しており、それによると、現在のバージョンでは、
- 1 台の ESXi（6.7 以降）
- 128 GB 以上のメモリ
- 800 GB 以上の SSD
が最低要件とされています。本来の VCF のハードウェア要件からは圧倒的に小さいですが、それでもそこそこのモノは必要ですね。
今回の環境
といいつつ、残念ながら上記の要件を満たせるハードウェアが自宅にないので、以下の環境で踏ん張ることにしました。
- 1 台の vCenter Server で管理される 2 台の ESXi 7.0
- 各 32 GB のメモリ（2 台の合計で 64 GB）
- 各 512 GB の SSD（2 台の合計で 1 TB）
- 共有ストレージなし
どうにかして処理を 2 台で分散させることにしてディスク容量を確保し、メモリの不足については、パフォーマンスを犠牲にしてオーバコミットをさせまくる前提にします。
手順
細かい手順や注意事項は付属のガイドや Slack のピン止めされたメッセージで案内されているので、ここでは概略だけ紹介します。
環境の準備
VLC に付属のガイドに従って、環境を整えます。
母艦となる物理 ESXi 側では、vDS で MTU を 9,000 にして、トランクモードのポートグループをひとつ作りました。このポートグループに仮想 ESXi と Cloud Buider が接続され、VCF 関連のすべてのパケットが（VLAN のタグ付きで）流れることになります。ポートグループのセキュリティ設定は、プロミスキャスモードなどもすべて承諾しています。
また、今回は二台の ESXi で無理やり分散させるため、vDS のアップリンクもトランクにして、上位にちょっといいスイッチをつなぐことで、ESXi 間で 9,000 バイトのジャンボフレームも VLAN もそのまま流せるようにしています。
作業端末となる Windows 10（ドキュメントや図で触れられている Jump Host）は、仮想マシンではなく、普段使いの Windows 10 をそのまま使うことにしました。積んでいる Intel の物理 NIC が VLAN を喋れたので、サブインタフェイスを作って VLAN ID や IP アドレスをガイドと同等に構成しています。
パラメータの用意
VCF の最新は 4.0.1 ですが、VMUG Advantage でダウンロードできる VCF が 4.0 だったので、VLC も 4.0 をダウンロードしました。
バンドルされている JSON は二つありますが、今回は NO_AVN を使います。AVN（Application Virtual Network）については こちらのエントリで説明 されています。
AUTOMATED_AVN_VCF_VLAN_10-13_NOLIC_v4.jsonAUTOMATED_NO_AVN_VCF_VLAN_10-13_NOLIC_v4.json
この JSON ファイルは、VLC が Cloud Builder や仮想 ESXi をデプロイするときのパラメータになるだけでなく、Cloud Builder がマネジメントドメインをデプロイするときの Bring-Up プロセスのパラメータとしてもそのまま使えます。
この段階で、JSON ファイル中の以下の箇所に、ライセンスキーを埋め込んで上書きしておきます。
{
...
"esxLicense": "<Insert ESXi License>",
...
"vCenterSpecs": [
{
...
"licenseFile": "<Insert vCenter License>",
...
}
],
"vsanSpecs":[
{
...
"licenseFile": "<Insert vSAN License>",
...
}
],
"nsxtSpec":
{
...
"nsxtLicense": "<Insert NSX License>",
...
},
...
}
VLC の起動と設定
VLCGui.ps1 を PowerShell で実行すると、進捗表示とログ表示用の PowerShell ウィンドウと、操作用の GUI が起動します。
DNS サーバなど、必要な周辺サービス含めて VLC でデプロイする場合は Automated を、自前で用意しているものを使わせる場合は Manual を選択します。今回は全部オマカセしてしまうので、Automated です。
VCF EMS JSON に先に用意した JSON ファイルを、CB OVA Location に Cloud Builder の OVA ファイルをそれぞれ指定します。右側にはデプロイ先の vCenter Server か ESXi の認証情報を入力して、Connect を押下し、目的の構成を選択状態にします。
Bring-Up プロセスまで続けて実行させてしまう場合は Do Bringup? にチェックを、Cloud Builder と仮想 ESXi のデプロイまでで終える（その先は本来の VCF の構築手順に従って自分でやる）場合はチェックを外します。今回は、小細工もしたいのでチェックを外します。Bring-Up プロセスの詳細を知りたいなどお勉強目的の場合も、チェックを外した方があとあとわかりやすいでしょう。
この後、Validate を押下するとバリデーションが走り、問題なければ Construct! が押下できるようになります。
このバリデーションで、データストアの空き容量もチェックされます。選択したデータストアに 800 GB の空きがないと怒られてしまうので、今回は VLCGui.ps1 のバリデーションの条件文をちょろまかして強引に進めました。
Construct! を押下して走り出してしまえば、あとは待つだけです。Do Bringup? にチェックを入れていた場合は、このまま VCF のマネジメントドメインが完成して SDDC Manager が使える状態になるまで、ひたすら放置すれば勝手に進みます。典型的には 3.5 時間とされていますが、遅い環境だと 9 時間程度かかる例もあるようです（数字だけ見ると長いですが、ほんとうに放置するだけなので、手作業で作るよりは比較にならないほど楽ですね……）。
Do Bringup? にチェックを入れていない場合は、Cloud Builder のデプロイと仮想 ESXi の構成だけなので、数十分程度で終わるでしょう。
Cloud Builder と仮想 ESXi の完成
本来は Cloud Builder のデプロイだけでも手作業 ですが、VLC では OVF Tools を使ってパラメータを流し込んでいるようです。画面を眺めていると、そうして Cloud Builder がデプロイされて構成されたあと、GoBGP や MaraDNS などを使って Cloud Builder に周辺サービス群がねじこまれていく様子が見えます。
Cloud Builder 関係の作業が終わると、4 台の仮想 ESXi の作成が始まり、そして終わります。ESXi も、本来であれば VIA などを使って手作り する必要があった作業です。ラクですね。
今回のように Do Bringup? にチェックを入れなかった場合は、VLC の出番はここで終わりです。
デプロイ先の状態を見ると、Cloud Builder の仮想マシンと、仮想 ESXi が並んでいる様子がわかります。
今回は、VLC でデプロイ先をローカルデータストアにした影響で、Cloud Builder も仮想 ESXi も物理的に同じ ESXi に載ってしまっています。物理リソースが潤沢であればそれで全く問題はありませんが、今回はそうではないので、この段階で 4 台のうち 2 台の仮想 ESXi をもう一方の物理 ESXi に移行して、コンピュートとストレージの負荷分散をはかりました。
VCF の Bring-Up プロセスの実行
VCF の初期構築作業の肝（とぼくが勝手に思っている部分）が、この Bring-Up プロセス です。構成さえ事前に決めれば、vCenter Server も vSAN も NSX-T も SDDC Manager も全自動で仕上げてくれる、VCF によるライフサイクル管理のメリットの一端が垣間見える部分です。
付属の JSON を使った場合は、この段階でホスト名 CB-01a.vcf.sddc.lab で Cloud Builder にアクセスできるようになっているはずです。ログインして、EULA を確認して進めます。
VxRail ではないのでそのまま次へ。
環境要件が表示されます。いろいろありますが、事前準備と VLC によって充足されているか、充足できていなくても無視できる程度にはなっているはずです。
続行するとパラメータを設定するパートに入ります。本来は、ここか VMware の Web サイトからワークブックをダウンロードして、値を埋め、再度ここにアップロードして進めるものですが、VLC の実行時に利用した JSON がここでそのまま使えます。
つまり、今回は、ワークブックを埋めなくてもよく、JSON をアップロードすれば進めます。
バリデーションが開始されます。いくつか警告が出ますが、警告であれば確認の上で Acknowledge で了承して進められます。
続行すると、楽しい構築の始まりです。
あとは、表示されている大量のタスク（スクロールバー参照）が全自動でごりごり進んでいくのを眺めているだけで終わりです。壮観ですね。
VLC で Do Bringup? にチェックを入れていた場合は、VLC が Cloud Builder の API 経由でこの Bring-Up プロセスをキックすることになり、その結果、最初から最後まで VLC だけで透過的に全自動、な見え方になります。
Bring-Up プロセスは、早くて数時間、遅いと半日程度はかかると思います。放置してもよいですが、タスクの中身を見たりデプロイ先の各管理画面に直接入って過程を観察したりするとたいへんおもしろく、かつお勉強になり、これを手でやれといわれたら死んでしまう感じです。
すべてのタスクが Success になって走り切ったら、完成です。
トラブルシュート
Bring-Up プロセスのどこかでエラーが起きたときは、エラーメッセージに加えて、それぞれの管理画面やログファイルを直接のぞくと調べやすくなります。付属の JSON を使った場合は、
- Cloud Builder：
CB-01a.vcf.sddc.lab - ESXi：
esxi-[1-4].vcf.sddc.lab - vCenter Server：
vcenter-mgmt.vcf.sddc.lab - NSX-T Manager：
nsx-mgmt.vcf.sddc.lab - SDDC Manager：
sddc-manager.vcf.sddc.lab
あたりです。認証情報は JSON に含まれています。
なお、今回のように物理リソースが貧弱な場合は、たまに単なる高負荷で失敗することもあるようです。ネステッド環境内で DRS による vMotion がキックされることもあり、それが負荷に拍車をかけている場合もあります。
このようなとき、単純なリトライで成功する場合もありますが、状況によってはネステッド環境内の DRS のモードを変更したり、リトライ前に手動で vMotion するなどして（物理ホストレイヤでの）負荷の平準化をはかるとよさそうです。VCF 的には DRS はもりもり動かすべきですが、リソースに余裕はないので仕方なしです……。
このほか、VLC のガイド内にもヒントがいろいろありますし、Slack にも情報がたまっています。
VCF の管理と拡張
Bring-Up プロセスが無事に完了したら、SDDC Manager が利用できるようになっているはずです。付属の JSON では、sddc-manager.vcf.sddc.lab です。
ネステッド環境の vCenter Server に入れば、マネジメントドメインの構成も探索できます。
NSX-T の管理画面も触れますね。
現時点でできているのはマネジメントドメインだけなので、本来はここからさらにワークロードドメインを追加構築したり、vRealize Suite をデプロイしたり、VCF 4.0 であれば vSphere with Kubernetes を使ったワークロード管理機能を有効化したり、ネットワークをうにゃうにゃしたり、それっぽいことをいろいろやっていくわけです。
なお、ネステッド環境を拡張したい場合は、VLC の Extension Pack! から、空の ESXi を追加構築できます。追加に必要な JSON も付属しています。
まとめ
VCF Lab Constructor を使って、自宅のラボ環境に、ネステッドな VMware Cloud Foundation 4.0（VCF 4.0）を構築し、その過程を体験・観察しました。
あたかもサクサク成功させたかのように書いていますが、実際は何度かの失敗のあとにたどりついています。
- 単一の ESXi（32 GB のメモリ、512 GB の SSD）のみを使ってデプロイしようとしたら、データストアがあふれて失敗
- 単一の ESXi（32 GB のメモリ）と外付けの NFS データストア（2 TB の HDD）を使ってデプロイしようとしたら、処理が遅すぎて NSX-T Manager のデプロイから進めず失敗
- 二台の ESXi（各 32 GB のメモリ）と外付けの共有 NFS データストア（2 TB の HDD）を使ってデプロイしようとしても、NSX-T Manager のデプロイから進めず失敗
要するに、潤沢なリソースはとにかく正義です。富豪的解決はだいじです。動けばいいや、と割り切るにも限度はあり、こういう無茶をしてもまともに動く環境は得られません。
最終的には本エントリで紹介したように 2 台にうまく分散させることで Bring-Up までは成功しましたが、重すぎてほぼ使い物にならないのが正直な現実でした。
とはいえ、構築プロセス（の一部）を体験できるという意味で、知的好奇心の充足には非常に有効であり、いろいろ見えておもしろかったです。満足しました。
もちろん、構築そのものが高度に自動化されているからといって、設計も同じ程度に楽かといえば当然そんなことはまったくないでしょうし、それどころかむしろ設計、とくに周辺サービス群とのインタラクションとパラメータの具体化、そして長期的な運用プロセスの定義こそがキモな気もするわけで、過度な期待はせずに、できるだけ誠実に向き合っていきたいものですね。
