前回、「VCF-CLD-FND」という最強のライセンスキーを手に入れました。
これでソフトウェア的には、エンタープライズ企業がデータセンターで動かしているVMware Cloud Foundation (VCF) と同等の機能が使い放題になります。
しかし、自宅のラック(という名のメタルラック)を眺めてみると、そこに鎮座するのは、エンタープライズサーバーではなく、ファンの音を気にしながら稼働するコンシューマー向けのPCたちです。
VCFの推奨構成は、最小4ノード、全ノード10GbE以上、オールフラッシュ...。
これを物理でそのまま再現しようとしたら、家庭の平和と電気代が崩壊します。
というわけで、今回は物理的な制約をソフトウェアの力でねじ伏せる、「Nested VCF ホロデック」の設計回です。
物理層の悲哀とNested環境という救い
VCFを学ぶ上で最大の壁は、その重厚長大さ。
管理コンポーネント(SDDC Manager, vCenter, NSX Manager...)だけで、メモリを湯水のように消費します。
物理マシン数台でこれをまともに組むのは現実的ではありません。
そこで採用するのが、物理ESXiの上にさらに仮想ESXiを建てる「Nested ESXi」構成です。
VMware公式でも「VCF Holodeck」というツールキットが出ているくらいなので、学習用としてはむしろ王道と言えるでしょう。
今回、ホームラボの再構築に伴い、多少増強しているので、NestedでSDDC環境を構築していこうと思います。
まずは、Nested ESXiを構築する土台の環境がこちらです。
この上に、論理的なVCF環境を構築します。
ネットワーク構成図

ハードウェア構成
| ホスト名 | 機器 | CPU | メモリ | ストレージ |
|---|---|---|---|---|
| esx11 | HP ProDesk 600 G6 SFF | Intel Core i7-10700 | 128GB | 1TB |
| esx12 | HP ProDesk 600 G6 SFF | Intel Core i7-10700 | 128GB | 1TB |
| esx13 | HP ProDesk 600 G6 SFF | Intel Core i5-10500 | 128GB | 1TB |
| esx14 | HP ProDesk 600 G5 SFF | Intel Core i7-9700 | 64GB | 1TB |
ソフトウェア構成(vExpertライセンス)
VMware vDefend Firewall with Advanced Threat Prevention
VMware vDefend Gateway Firewall with Advanced Threat Prevention
VMware vDefend Distributed Firewall with Advanced Threat Prevention
VMware Avi Load Balancer (Enterprise)
VMware VCF Operations
VMware NSX Networking
VMware vSphere Enterprise Plus for VCF
VMware vCenter Server Standard
VMware vSAN
vSAN 8:ESAの夢とOSAの現実
今回の構成の肝となるのが、ストレージです。
VCF環境では、シェアードストレージとしてvSANがほぼ必須要件になります。
vSphere 8からは、**vSAN ESA (Express Storage Architecture)** という、NVMeに最適化された超高性能な新アーキテクチャが登場しました。
当然こちらの検証をしたいのですが、ESAの要件を見て断念しました。。。
- 全ドライブ NVMe 必須
- 25GbE ネットワーク推奨(最低10GbE)
- vSAN ReadyNode 認定ハードウェア...
私の自宅ラボは、SATA SSDと、かろうじて10GbEが数本ある程度の「庶民派」ラボ。
ESAを有効化しようとした瞬間に、インストーラに怒られる未来が見えます。
というわけで、今回は潔く vSAN OSA (Original Storage Architecture) を採用します。
いわゆる従来の「キャッシュ層 + キャパシティ層」の2層構造モデルです。
「なんだ、旧世代か」と侮るなかれ。
OSAもvSphere 8で着実に進化していますし、何より枯れた技術ゆえの安定感があります。
限られたリソースの中で「VCFとしての動作」を検証するには、足回りの安定性は重要です。
ネットワーク設計:NSXを見据えて
ストレージが決まったら、次はネットワークです。
ここもVCF/NSXを見据えた設計にしておく必要があります。
通常のvSphere環境なら標準スイッチ(VSS)で十分ですが、今回は**分散スイッチ(VDS)**一択です。
NSXを導入する際、ホストのネットワークはVDSで管理されている方がスムーズですし、何より構成が美しいですね。
Nested ESXi側には、以下のようなネットワークポートグループを通す予定です。
1. Management: 管理用。vCenterやESXiの管理IP。
2. vMotion: 文字通り。
3. vSAN: ストレージトラフィック用。ここは10Gネットワークで、ジャンボフレーム(MTU 9000)にしたいところ。
4. Overlay (Geneve): NSX用。ここが後々の主戦場になります。
5. Uplink: 外部との通信用。
物理スイッチ側のVLAN設定も必要ですが、面倒なので物理ESXiのポートグループを「VLAN ID: 4095(トランク)」にして、タグ付けは全部Nested ESXi側でやる暴挙に出ようと思います。
これが許されるのも自宅ラボならではですね。
設計完了、そして構築へ
コーヒーを飲みながら構成図を引いているこの時間が、一番楽しいのかもしれません。
それでは、さっそく構築していきます。
すでに過去の記事で、ひと取り紹介していますがのでリンクを貼っておきます。
hironw.hatenablog.com
とはいえ、久しぶりの再構築で何度かやり直した部分をメモっておきます。
- マネージメントVLANの設定は、ESXで行い、スイッチはTrunkポートで設定する。
- vCenterのインストールでは、DNSサーバーを先に構築しておく。
- vCenterでクラスタを作成するときに、クラスタの管理方法を指定するが、USBメモリ起動していると、ストレージがないので失敗する。ここはスキップする。

- クラスタ構築後、すぐにEVCの設定をしておく。後から設定すると互換性を取るのが面倒。

- クラスタにホスト追加するときにvCenterが稼働しているホスト以外をまずは参加させて、いったんvCenterはシャットダウン後、クラスタ参加したホストで、仮想マシンの再登録をしてvCenterをクラスタ内に参加させる。私の環境では、vCenterを2回再起動したらうまくホストが認識されました。
- ホストのNICを後から追加する場合は、いったんホストでVSSとして登録してからVDSに移行する。
これで、土台の環境が構築完了です。
続きは次回を紹介します。

