VMware Cloud Foundation (VCF) 入門①：vSphere 単体利用との違いから理解する

## はじめに

Broadcom による VMware の買収完了後、VMware 製品ポートフォリオは大きく再編されました。
2025年3月9日時点で VMware vSphere は以下の 4つのエディションに集約されています：

1. **VMware vSphere Standard** - 標準的な仮想化環境向け
1. **VMware vSphere Enterprise Plus** - 高度な機能を含む上位エディション
1. **VMware vSphere Foundation (VVF)** - vSphere と vSAN を統合した大規模環境向けエディション
1. **VMware Cloud Foundation (VCF)** - 統合クラウド基盤として最上位のソリューション

この製品再編において、Broadcom は VCF を戦略的製品として位置づけ、統合クラウド基盤としての機能強化に注力しています。VCF は単なる vSphere の拡張ではなく、完全な統合プラットフォームとして、ハイブリッドクラウド環境の構築・運用を簡素化することを目指しているとの事です。

> *First, we remain steadfast in our decision to focus our resources on R&D, and continuing to develop a true, seamless private cloud experience for customers through VCF – one that is competitive with the public cloud.*
> *Second, we're making changes to deliver consistent customer experiences.*
>
> [Broadcom B-Connected Blog - A changing market landscape requires constant evolution: our mission for VMware customers](https://jp.broadcom.com/blog/a-changing-market-landscape-requires-constant-evolution-our-mission-for-vmware-customers) からの抜粋

先日ブログを公開した Amazon Elastic VMware Service（プレビュー）も VCF を Amazon VPC 内で実行する、AWS のネイティブサービスです。

https://qiita.com/mtoyoda/items/0295c2d3248df07ae5d8

本記事では、vSphere ユーザーが VCF を理解するための基本的な情報をまとめてみます。

:::note warn
本記事は、個人の理解のために 2025年3月9日時点の情報をまとめたものになります。公式文書から確認を行なっていますが間違っている箇所があるかもしれません。
:::

## VMware Cloud Foundation とは？

VMware Cloud Foundation（VCF）は、VMwareのコンピュート、ストレージ、ネットワーク仮想化技術を統合した、モダンなハイブリッドクラウド向けの統合プラットフォームです。簡単に言えば、「vSphere + vSAN + NSX + 管理機能」をひとつのパッケージにまとめ、クラウドのような使い勝手を提供するソリューションといえます。


VCF の最大の特徴は、これらのコンポーネントが個別に存在するのではなく、統合された形で提供され、一元管理できることにあります。


## vSphere 単体と VCF の違い

### 1. 構成要素の違い

**vSphere 単体の場合：**
- ESXi ハイパーバイザー
- vCenter Server（管理サーバー）
- 必要に応じて個別に追加するコンポーネント（vSAN、NSXなど）

**VCF の場合：**
- SDDC Manager（構成・プロビジョニングからアップグレード・パッチ適用まで、システム全体のライフサイクルを自動化）
- vSphere（ESXi + vCenter Server）
- vSAN（ストレージ仮想化）
- NSX（ネットワーク仮想化）
- vSphere with Tanzu（Kubernetesワークロードを実行できるプラットフォームに変換し、コンテナベースのアプリケーション開発・運用を可能にする）
- VMware Aria Suite（プライベートクラウドマネジメント。Aria Operations for Logs、
 Aria Automation など）

![image.png](https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2/_jcr_content/assetversioncopies/9e67a7a0-7503-45e7-9a15-6f67d5300add.original.png)
_（図は [Broadcom TechDocs - VMware Cloud Foundation 5.2](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2/getting-started-with-vcf-5-2/natively-integrated-stack.html)からの抜粋）_

VCF では、これらのコンポーネントがあらかじめ統合されており、SDDC Manager（Software-Defined Data Center Manager）を通じて一元管理できます。

### 2. 管理方法の違い

**vSphere 単体の場合：**
- vCenter Server を使って仮想マシンやホストを管理
- 他のコンポーネント（vSAN、NSXなど）が必要な場合は、それぞれ個別に導入- アップデートやパッチ適用も個別に行う必要がある

**VCF の場合：**
- SDDC Manager を通じて全コンポーネントを一元管理が可能
- ライフサイクル管理（アップデート、パッチ適用）が統合されている
- 証明書管理やパスワード管理も統合インターフェースから実行可能

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/441095/b4b8bd92-c03c-4339-b2f9-0d90b96cff0e.png)
SDDC Manager の管理画面

### 3. デプロイメントモデルの違い

**vSphere 単体の場合：**
- 必要に応じて個別にコンポーネントをインストール・設定
- 構成の自由度は高いが、ベストプラクティスの適用は管理者の知識に依存

**VCF の場合：**
- ワークロードドメインという概念でリソースを論理的に分離
- VMware のベストプラクティスに基づいた自動デプロイ
- 管理ドメインとワークロードドメインの分離による安全性の向上
- vSphere のみでなく、vSAN、NSX など幅広い理解が求められる

## VCFの主要概念：ワークロードドメイン

VCF では「ワークロードドメイン」という概念が重要です。ワークロードドメインは、VMware のベストプラクティスに従って特定の特性を持つ vCenter Server インスタンスによって管理される ESXi ホストをグループ化します。SDDC Manager によってプロビジョニングされる1つ以上の vSphere クラスタで構成されます。

VCFには大きく分けて 4 種類のワークロードドメインがあります。

### ワークロードドメインの種類

| ワークロードドメインタイプ | 説明 | メリット | デメリット |
|----------------------|-------------|----------|-----------|
| **管理ドメイン** | 最初に展開されるドメイン。すべてのワークロードドメイン用の管理アプライアンス（vCenter、vSAN、NSX Manager、SDDC Manager、オプションのAriaスイートコンポーネントなど）を含む。専用のESXiホストを持ち、最初にアップグレードされるドメイン。<br> **管理ドメインでは vSAN Ready Node での構成が必須となる。 -> 最低 4 ホスト必要** | 管理コンポーネントに十分なリソースを保証。管理コンポーネントのニーズのみを満たす特定のハードウェアの使用が可能。追加のワークロードとは別に専用の物理コンピュート、ネットワーク、ストレージの使用が可能。管理コンポーネントとユーザーワークロードコンポーネントのライフサイクル管理（パッチ適用、アップグレード）を異なるスケジュールで実行可能 | 管理コンポーネント専用の ESXi を準備する形になるため、リソースが有効活用できないケースがある。初期で必要となる ESXi ホスト数が多くなる。（管理ドメイン 4 ホスト + VI ワークロードドメイン 3 ホスト）|
| **Virtual Infrastracture (VI) ワークロードドメイン** | ユーザーのワークロードを実行するための追加のワークロードドメイン。管理ドメインと vCenter SSO ドメイン / ID プロバイダ構成を共有。専用のESXiホストを用意。他の VI ワークロードドメインと NSX Manager インスタンスを共有可能。 | すべてのワークロードドメインを単一の管理画面で管理可能。管理コンポーネントとユーザーワークロードコンポーネントのライフサイクル管理（パッチ適用、アップグレード）を異なるスケジュールで実行可能 | ワークロード専用の ESXi を準備する形になるため、管理ドメインに空きリソースがあっても利用できない（有効活用できない）<br> 初期で必要となる ESXi ホスト数が多くなる（管理ドメイン 4 ホスト + VI ワークロードドメイン 3 ホスト） |
| **分離 VI ワークロードドメイン** | ユーザーワークロードを実行するための追加のワークロードドメイン。個別のvCenter SSO ドメインおよび個別のIDプロバイダ構成を持つ。専用のESXiホストを用意。 | ユーザーワークロード用の個別の vCenter SSO ドメインを提供可能。VCF インスタンスごとに最大 24 の VI ワークロードドメインまで拡張可能。独立したライフサイクル管理が可能。 | ワークロードドメインの vCenter Server インスタンスは異なる管理画面で管理される。VCF の管理者には追加のパスワード管理オーバーヘッドが存在する。 |
| **統合ドメイン** | 一つのドメインにて 管理ドメイン + VI ワークロードドメインを実行。| ハードウェアリソースを最大限有効活用が可能。<br> 初期で必要となる ESXi ホスト数が少なくて済む。<br> 標準アーキテクチャモデルに拡張可能。 | 管理コンポーネントとユーザーワークロードが分離されていない。管理コンポーネントに十分なリソースを確保するために監視が必要。 |


### ワークロードドメインの選択フロー
どのワークロードドメインを選択すべきか？は Broadcom TechDocs 内の選択フローがわかりやすいです。

![image.png](https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2/_jcr_content/assetversioncopies/5422ec3b-85ce-400b-8f97-a77f4c698591.original.png)

![image.png](https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2/_jcr_content/assetversioncopies/716b7ad6-73d9-4cce-b69e-a8568e58263b.original.png)
_（図は [Broadcom TechDocs - VMware Cloud Foundation 5.2](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2/vcf-design-5-2/vmware-cloud-foundation-concepts/vmware-cloud-foundation-architecture-models.html)からの抜粋）_

尚、現時点で **Amazon EVS では統合ドメインのみ**がサポートされます（Preview 期間中）。


## まとめ

本記事では、vSphere ユーザーが VCF を理解するための基本的な情報をまとめてみました。
（需要があれば）次回以降に Bring Up についてもまとめてみようと思います。

## 参考文献

- [Broadcom TechDocs - VMware Cloud Foundation 5.2](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-5-2-and-earlier/5-2.html)
- [Broadcom B-Connected Blog - A changing market landscape requires constant evolution: our mission for VMware customers](https://jp.broadcom.com/blog/a-changing-market-landscape-requires-constant-evolution-our-mission-for-vmware-customers)