1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

VMware Cloud Foundation 入門③:VCF 9 の2ホスト・3ホスト構成 - Simple モデルの制約と使いどころ

1
Last updated at Posted at 2026-07-17

本記事の内容はあくまでも私個人の理解をまとめたものです。正確な情報は Broadcom 社の公式ドキュメントを参照してください。

前回の記事(Amazon EVS で VCF 9 のサポートが開始!)で「VCF 9 から2〜3ホスト構成が可能になった」と紹介しましたが、「では実際どういう制約があるの?」という部分を今回まとめます。

VCF 9 で4ホスト最小要件が撤廃されたのは嬉しいニュースですが、ホスト数を減らせばその分トレードオフが生まれます。この記事では Simple モデルと High Availability モデルの違いを整理した上で、2ホスト・3ホスト構成がどういう場面に向いているのかを掘り下げます。

先に全体像を1枚にまとめるとこうなります。それぞれの項目をこの後のセクションで説明していきます。

2ホスト・3ホスト構成 — 制約と影響の詳細

VCF 9 のデプロイモデル: Simple vs High Availability

VCF 9 では管理スタックの構成方法が2つのモデルに分かれました。

Simple モデル

  • 各管理コンポーネントが1ノード構成(単一障害点あり)
  • 最小7アプライアンスで展開可能
  • 2ホストから構成できる

High Availability モデル

  • NSX / Operations / Automation が3ノードクラスタ構成
  • 最小13アプライアンス
  • 最低4ホストが必要
  • 管理プレーンが冗長化される

つまり、2〜3ホストで構成する場合は必然的に Simple モデルを選ぶことになります。4ホスト以上であれば HA モデルを選択して管理プレーンを冗長化できます。

管理アプライアンスの構成差異

Simple モデルと HA モデルで具体的に何が変わるのか、コンポーネント単位で見てみます。

コンポーネント Simple High Availability Simple で障害が起きると
vCenter Server 1台 1台(+vCenter HA 別途) VM 管理操作不可
SDDC Manager 1台 1台 Fleet 管理操作不可
NSX Manager 1台 3台クラスタ NW ポリシー変更不可(データプレーンは維持)
VCF Operations 1台 3台(master+replica+data) 監視・アラート停止、LCM 操作不可
VCF Automation 1台 複数ノード(IP Pool) セルフサービス停止
VCFMS 1 CP + 3 Worker 3 CP + 3 Worker LCM 操作不可

この表は Broadcom TechDocs の Single-Rack vSphere Cluster Model の情報を基にしています。

押さえておきたいのは、Simple モデルでもデータプレーン(実際のワークロード VM のネットワーク通信やストレージ I/O)は維持されることです。止まるのはあくまで「管理操作」であり、ホスト障害が起きても動いている VM がいきなり全部落ちるわけではありません。vSphere HA が管理 VM を別ホストで再起動してくれるので、数分〜十数分で管理操作も復旧します。

ホスト数別の構成比較

ホスト数ごとにストレージ、HA 予約率、障害耐性がどう変わるかを整理しました。

2ホスト構成

項目 内容
ストレージ NFS または FC(外部ストレージ必須、vSAN は使えない
デプロイモデル Simple のみ
HA 予約率 50%(実質1ホスト分しかワークロードに使えない)
アプライアンス HA なし

VCF 9 の大きなアップデートの一つとして、管理ドメインで vSAN が必須ではなくなりました。従来は管理ドメイン = vSAN 一択だったので、NFS や FC の外部ストレージを principal storage として使えるようになったのは設計の自由度を大きく広げる変更です。この緩和があるからこそ、vSAN の最小要件(3ホスト)を下回る2ホスト構成が成立します。

一方で2ホストでは vSAN が使えないため、外部ストレージ(NFS or FC)が前提になります。1ホスト障害で全 VM が残り1台に集約されるので、リソース圧迫リスクはかなり大きいです。外部ストレージ自体の冗長設計も別途必要になる点は忘れないでください。

3ホスト構成

項目 内容
ストレージ vSAN(FTT=1 で1台障害に対応)、NFS / FC も可
デプロイモデル Simple のみ
HA 予約率 33%(実質2ホスト分を利用可能)
アプライアンス HA なし

3ホストになると vSAN が使えるようになります。FTT=1(Failures To Tolerate = 1)で1台分の障害には耐えられますが、修復が完了する前に2台目が障害を起こすとデータ消失リスクがある点には留意が必要です。

4ホスト以上

項目 内容
ストレージ vSAN / NFS / FC すべて選択可
デプロイモデル HA モデル選択可
HA 予約率 〜25%(ホスト数が増えるほど下がる。実質75%以上を利用可能)
アプライアンス HA あり(管理プレーン冗長化)

4ホスト以上であれば HA モデルを選んで管理プレーンを完全に冗長化できます。ホスト障害時も管理操作の停止が発生しにくくなります。HA 予約率は「1ホスト分の障害に耐える割合」なので、4ホストで25%、5ホストなら20%と、ホスト数が増えるほど予約のオーバーヘッドは小さくなっていきます。

障害時の動き

Simple モデル(2〜3ホスト構成)で ESXi ホスト障害が発生した場合のフローは以下の通りです。

  1. 障害発生: ESXi ホストがダウン → そのホスト上の管理 VM が停止
  2. 影響: 管理操作が停止(数分〜十数分)。ただしデータプレーンは維持される
  3. 復旧: vSphere HA が管理 VM を別ホストで自動再起動

ここで重要なのは「データプレーンは維持される」という点です。NSX Manager が1台しかいない Simple モデルでも、既に設定済みのネットワークポリシーで動いているトラフィックはそのまま流れ続けます。影響を受けるのはポリシーの新規変更や vCenter からの VM 操作など、管理操作に限定されます。

どこで使うべきか

2〜3ホスト構成が向いている場面:

  • PoC / 検証環境
  • 管理操作の一時停止が許容される非本番環境
  • 小規模リモート拠点(Branch Office)

4ホスト以上を選ぶべき場面:

  • 本番環境
  • 管理プレーンの可用性が要求される環境

「本番環境は4ホスト以上」というのが Broadcom の推奨です。逆に言えば、PoC や検証環境であれば2〜3ホストで気軽に始められるようになったのは大きな進歩です。

スケールアップパス

2〜3ホストの Simple モデルで始めても、後からホストを追加して HA モデルにスケールアップできます。最初は小さく始めて、本番利用が決まった段階で拡張するフローが取れるわけです。

また、「全部 Simple」か「全部 HA」かの二択でもありません。VCF Installer の UI 上は2択ですが、デプロイ用の JSON を編集すれば NSX Manager / VCF Operations / VCF Automation をコンポーネント単位で Simple / HA を選択でき、合計8通りの組み合わせが可能です。詳細は William Lam 氏の記事で解説されています。

さらに VCF 9.1 では、Small サイズの VCFMS でも API 経由で HA を有効化できることが確認されています(UI からの操作は将来の VCF 9.1.x リリースでサポート予定とのこと)。

「全部まとめて HA 化」だけでなく、段階的に冗長性を上げていけるのは運用の現実に沿った良い設計だと感じます。

Amazon EVS との組み合わせで気になる点

前回の記事でも触れましたが、この最小ホスト数の緩和は Amazon EVS の i7i.metal-24xl(48 物理コア)と組み合わせると面白い構成が考えられます。

VCF のライセンスは物理コア数ベースで課金されるので、物理コア数で比較します。

  • 従来: i4i.metal(64コア)× 4ホスト = 256コア分のライセンス
  • 新構成例: i7i.metal-24xl(48コア)× 2ホスト = 96コア分のライセンス

最小構成同士の比較で、必要なライセンスは半分以下になります。もちろん2ホスト構成の制約(HA 予約50%、外部ストレージ必須、管理プレーン非冗長)を許容できる用途に限られますが、PoC 環境やコスト優先の検証環境なら十分選択肢になりそうです。こちらは実際に構成を組んで検証する機会があれば、また記事にしたいと思います。

まとめ

VCF 9 で導入された2ホスト・3ホスト構成のポイントを整理すると:

  • 2〜3ホストで構成する場合は Simple モデル(管理コンポーネント非冗長)になる
  • 2ホストは外部ストレージ必須(vSAN 不可)、HA 予約50%で実質半分しか使えない
  • 3ホストは vSAN が使え、HA 予約33%で効率が上がる
  • 障害時に止まるのは管理操作のみ。データプレーンは維持される
  • 本番環境には4ホスト以上 + HA モデルが推奨
  • Simple → HA へのスケールアップは後から可能

2ホスト・3ホスト構成 — 制約と影響の詳細

4ホスト最小要件の撤廃は「小さく試して、大きく育てる」を可能にした変更です。個人的には、評価モード(ライセンス不要)とこの2ホスト構成の組み合わせで VCF の PoC を始めるハードルが一気に下がったと感じています。まずは小さく触ってみて、制約が気になったらホストを足す。そういう始め方ができるようになりました。

参考リンク

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?