本記事では、VMware Cloud Foundation（VCF）のコンポーネントである「SDDC Manager」と、それによって構成されるSoftware-Defined Data Center（SDDC）を理解するうえで重要な、SDDCやワークロード ドメインなどについてご紹介します。

VMware by Broadcomは、2024年2月にvSphereを中心とする仮想化インフラ製品群のライセンス提供形態を整理し、最上位のエディションを「VMware Cloud Foundation（VCF）」としました。VCFは、VMware製品群を利用してSDDCを構築するソリューションとして提供されていたものでもあり、SDDC Managerという独自の管理サーバーを利用できます。

　

1. VMware Cloud Foundationの概要

VCFではVMwareのソフトウェアによってSDDCを構成する製品で、主に以下のソフトウェア コンポーネントが含まれています。

• VMware vSphere（ESXiとvCenter Serverによる仮想化）
• VMware vSAN（分散ストレージ/HCI）
• VMware NSX（ネットワーク）

さらに、vSphere with Tanzu、Aria Suiteなども利用可能です。

これらのソフトウェアは、VCFのバージョンごとに、Bill-of-Materials（BOM）により各コンポーネントのバージョンが定められています。執筆時点の2024年3月28日時点ではVCF 5.1.1がリリースされており、以下のようなBOMが提示されています。

BOMに記載されているとおり、「vSphereを中心とする仮想化インフラ製品群のエディション」としてVCFを採用した場合にはSDDC Managerが利用可能になります。しかし、「SDDC Managerが必須である」ということではありません。つまり、エンジニア自身がvCenter Server、ESXi、vSAN、NSXといった製品群を組みあわせて、自動化せずに従来どおりの仮想化インフラを構築することもできます。

しかし、VCFの導入による仮想化インフラの「標準化」や「自動化」といったメリットは、SDDC Managerによって提供されるものです。そこで、ここからはSDDC Managerを導入することによって構成されるSDDCについてご紹介します。

　

2. VMware Cloud FoundationによるSDDCとは

ここでは、VCFによるSDDCを理解するうえでポイントとなる2つの用語をご紹介します。

　

用語1： ワークロード ドメイン

VCFによって展開されるSDDCは、「ワークロード ドメイン」と呼ばれる単位で管理されます。

具体的には、ワークロード ドメインはvCenter SeverやESXiで構成される「vSphere環境」のことを指します。なお、「ドメイン」という単語が用いられていますが、DNSのドメインとは無関係です。

ワークロード ドメインには、次の2種類が存在します。

• 管理ドメイン
• 仮想インフラストラクチャ― ドメイン（VIドメイン）

管理ドメインは、SDDCを展開すると最初に構成されるvSphere環境であり、vCenter ServerやNSX ManagerといったSDDCを管理するコンポーネントが展開されます。管理ドメインを構成するvSphereのvCenter ServerやNSX Managerなどが稼働し、さらにVIドメインを構成するvSphereのvCenter ServerやNSX Managerも、管理ドメインに配置されます。
管理ドメインは、SDDC Managerあたり1つだけ構築されます。

VIドメインには、SDDCの管理コンポーネント以外の仮想マシンが配置されます。つまり、ユーザーのワークロード（たとえば業務アプリケーションが稼働するサーバーやVDIなど）の仮想マシンを配置するためのvSphere環境です。慣例的に、「ワークロード ドメイン」がVIドメインを指す言葉として用いられることもあります。
VIドメインは、管理ドメインあたりに複数作成できます。

　

用語2： SDDC Manager

SDDC Managerは、VCF独自の管理コンポーネントであり、おもにVCFによって構成されるSDDCのライフサイクル管理を担います。

サービス プロバイダや、大規模な企業でなくとも、ひとつの企業内には多くのITシステムが構築され、複数の仮想化インフラが構築されることは一般的です。SDDC Managerの導入により、次のようなメリットが得られます。

• 自動化： たとえば、ハードウェア（ESXiホスト）のプロビジョニングや、vCenter Serverのデプロイ、vSANによる分散ストレージの構成、NSXによるネットワーク構成といった、仮想化インフラ（つまりはSDDC）の構築を自動化します。また自動化の対象には、ESXiホストの増設や、ソフトウェア コンポーネントのバージョンアップなども含まれます。
• 標準化： SDDCの構築の際に、VMwareによるベスト プラクティスにもとづいた設計を適用します。これは、SDDC Managerを介した構築作業をすることで、可用性や拡張性が考慮された設計を強制する、製品の一部としてExcelベースのパラメータ シート（自動構築のインプットとしてSDDCに読み込ませる）を提供する、といったように、仕組みとして設計が強制されるように実装されます。

 

SDDC Managerは、下記のようにWebベースでの管理画面で利用できます。

　

3. VMware Cloud FoundationでのSDDC構築の流れ

VCFでのSDDC管理にはSDDC Managerが利用されます。ただし、SDDC Managerを利用可能にするまでの初期構築には、SDDC Managerとは別にCloud Builderという仮想アプライアンスを使用する独自の仕組みが用意されています。

ここからは、SDDCにVIドメインを構成するまでの手順について、3段階にわけて概要を説明します。

1. Cloud BuilderのOVAをデプロイする
2. Cloud BuilderからSDDC（の管理ドメイン）をデプロイする
3. SDDC ManagerからVIドメインをデプロイする

手順1. Cloud BuilderのOVAをデプロイする

Cloud Builderは、VCFによるSDDCの初期構築を実行するための仮想アプライアンスです。OVAファイルとして提供されており、一般的なOVFテンプレートのデプロイ手順で（これからSDDCを展開するvSphereとは別の）vSphere環境に展開します。

ちなみにこの仮想アプライアンスには、vCenter ServerとNSX ManagerのOVAファイル、そしてESXiインストーラーのISOファイルなどが内蔵されているため、容量は30GBほどあります。

　

手順2. Cloud BuilderからSDDCをデプロイする

Cloud Builderでは、Excel形式のパラメーター ワークブックをアップロードしてSDDCをデプロイします。このVCFならではの初期デプロイ手順は、「ブリング アップ（Bring-up）」と呼ばれています。

このときに、ソフトウェアのインストール先（つまり管理ドメインの展開先）となる物理マシンには、事前にESXiのインストールと基本的なネットワーク設定のみを実施しておきます。VCFならではのベスト プラクティスに沿った設計に基づく設定については、Cloud BuilderやSDDC Managerによる自動化の中で実施されることになります。

VCFによるSDDCのデプロイ処理が完了すると、管理ドメインにあたる仮想化インフラを構成するvCenter Server・vSAN・NSXが自動構築され、さらにその上にSDDC Managerの仮想アプライアンスが自動デプロイされた状態になります。この時点で、管理ドメインを構成するESXiホストでは、vSANデータストアが利用でき、NSXがインストールされた状態になっています。そして、SDDC Manager、vSphere Client、NSX Managerといった管理ツールがWebブラウザから利用できるようになっています。

なお、Cloud Builderはこれ以降の運用では使用されません。

　

手順3. SDDC ManagerからVIドメインをデプロイする

管理ドメインのデプロイが完了したら、次にVIドメインをデプロイします。この段階からは、Cloud BuilderからではなくSDDC Managerによって自動構築処理が実行されます。

VIドメインをデプロイする場合も、SDDCのデプロイ（つまり管理ドメインのデプロイ）前と同様に、ESXiホストの準備が必要です。ただし管理ドメインのデプロイ時点とは異なり、SDDC Managerでは「コミッショニング」と呼ばれる処理が用意されており、これによりESXiホストがSDDC Managerでプロビジョニング可能な対象として登録されます。

デプロイが完了したVIドメインでは、管理ドメインと同様に、vSANデータストアが利用でき、NSXインストールされた状態になっています。そして、vSphere ClientとNSX Managerも利用可能になっています。

　

4. SDDC Managerと他管理ツールとの役割分担

vSphereとvSANの管理ツールとしてvCenter ServerのvSphere Clientが提供されており、NSXにはNSX Managerが管理ツールとして提供されています。しかしVCFでは、SDDCの構築だけでなく、運用においてもSDDC Managerを利用します。 

そこで、ここではSDDC Manager、vSphere Client、NSX Manager、そしてCloud Builderの役割分担のイメージをご紹介します。

まずは、下記のように基本的な役割分担のイメージを持つとよいと思います。ただし実際には、作業ごとに複数のツールが利用でき、ここで紹介していないCLIを利用するケースもあります。

ポイントとしては、次の点が挙げられます。

• Cloud Builderは、初期構築のみで利用されます。
• VCFによるSDDCの全体的な管理は、まずSDDC Managerから実施します。VCFのBOMに含まれるソフトウェア コンポーネントのアップデートや、ワークロード ドメインへのESXiホストの増設、VIドメインの追加などがSDDC Managerの担当範囲となります。ほかにもパスワードや証明書の更新などもカバー範囲なっています。
• 仮想マシン単位の管理では、従来どおりvSphere Clientを利用します。そのため、仮想マシンの追加や削除、コンソール アクセスなど、仮想マシンの利用者の視点では、これまで通りの運用となるはずです。
• NSXについては、じつはSDDC ManagerでもNSX Edgeクラスタ作成やTier-0 / Tier-1ゲートウェイ作成などが実施可能ですが、運用においては従来のようにNSX Managerでの操作も必要となります。

 

実際のところ、各ソフトウェア コンポーネントの操作や設定変更には、自動化や標準化を実現するために必要なVCFのSDDC独自の制約も存在します。また、VCFのバージョンによってSDDC Managerの機能追加もあるため、PoCや本番稼働前の運用試験では、実際に想定している運用方式や手順が実施できるか確認することが重要となります。

　

最後に

VCFでは、SDDC Managerを導入することで、仮想化インフラの設計や運用にベスト プラクティスを適用できます。一方で、エディションとしてVCFを利用しても、SDDC Managerを利用せずワークロード ドメインも構成しない、「従来設計の踏襲」をする選択肢もあります。

しかしながら、検証実績やメーカー保証のある基盤設計、手厚いサポートが要求される、セキュリティ対策などにより積極的なソフトウェア アップデートが必要、といった環境においては、SDDC Managerの導入を検討する価値があると考えられます。

また、エンタープライズ向けのソリューションにはVCFを前提とするものも発表されており、「VMware Private AI Foundation with NVIDIA」もそのひとつです。

そして当然のことながら、メーカーとしてのベスト プラクティスも「SDDC Managerを導入する」という構成を推奨しています。今後も、検証環境の構築や機能紹介やユースケースの紹介など、VCFおよびSDDC Managerをより活用できる情報を発信できればと思います。