今回は、 VMware Cloud on AWS で Software Defined Data Center (SDDC) を構成するソフトウエアとリソースの考え方について解説します。サービスを構成する管理コンポーネントやリソース配分の仕様、およびクラスタとリソースの関係などに注目してみます。

　　　

SDDC のソフトウエアコンポーネントとは？

はじめに VMware Cloud on AWS の中で SDDC を構成するソフトウエアについて見ていきましょう。SDDC は、VMware ESXi、VMware vCenter Server、VMware vSAN、VMware NSX で構成されます。ユーザーが最初に SDDC を作成する時、同時にこれらの基本コンポーネントがインストールされたクラスタが展開されます。

さらに、VMware Cloud on AWS では二つのアドオンサービスが利用できます。一つは VMware HCX が機能するクラウド移行のサービスです。もう一つは VMware Site Recovery が機能する災害対策のサービスです。これらはオプションサービスであるため、利用する時だけ関連ソフトウェアが自動的にインストールされます。これらの基本コンポーネントとアドオンサービスのコンポーネントをあわせて「管理コンポーネント」と呼びます（図1）。

図1　SDDC のソフトウエアと管理コンポーネント

　　　

VMware Cloud on AWS は、占有ホストを含め SDDC をそのままクラウドサービスとしてユーザーに提供します。したがって、管理コンポーネントもユーザーが利用する SDDC の中に配備され、vCenter をユーザーに解放する仕様になっています。

　　　

ユーザーリソースと管理リソースは分離されている

SDDC を構成するクラスタは、管理コンポーネントが使用するリソースとユーザーが使用するリソースを分離しています（図２）。分離している理由は、サービスの健全性を維持するために管理コンポーネントが使用できるリソースを確保すること、およびユーザー領域とのリソース競合を避けるためです。

なお、管理コンポーネントを含む SDDC 環境は、すべて VMware が管理・運用するので、ユーザーは仮想マシンと利用環境の管理（ユーザーのネットワークや Firewall ルールの管理など）に集中できます。

図2　リソースの分離

　　　

リソース分離の仕組みに目を向けてみましょう。CPUとメモリリソースは予め定義されたリソースプールが構成され、そこで分離されます（図3）。管理コンポーネントの中で vCenter Server や NSX Manager など仮想アプライアンスとして展開されるものは「Mgmt-ResourcePool」と呼ばれるリソースプールに配置されます（図4）。一方、ユーザーが作成する仮想マシンは「Compute-ResourcePool」に配置します。ユーザーは Compute-ResourcePool の配下で自由にリソースプールを構成できます（図5）。

図3　事前に定義されている Compute-ResourcePool と Mgmt-ResourcePool

　　　

図4　管理コンポーネントの配置（アドオンサービスを含めすべてのコンポーネントが配置された状態。初期構成時は vCenter と NSX のみが展開される）

　　　

図5　ユーザーが作成するリソースプールの例

　　　

データストアもストレージリソースの分離のために Namespace で分割された二つのデータストア（vsanDatastore、WorkloadDatastore）が構成されます。管理コンポーネントは「vsanDatastore」データストアに配置され（図2）、ユーザーの仮想マシンは「WorkloadDatastore」データストアに配置します。

仮想マシンを作成する操作は、リソースプールとデータストアの選択以外はオンプレミスの vSphere 環境と同じです（図6）。

図6　オンプレミスでの操作と変わらない仮想マシン作成ウィザード

　　　　

リソースを考慮してクラスタをうまく使い分けたい

管理コンポーネントは SDDC の中で最初に作成されたクラスタ上に展開されます。二つ目以降に作成するクラスタには、管理コンポーネントは展開されません（図7）。

図7　クラスタと管理コンポーネントの配置

　　　

また、SDDC の中でホストの種類が異なるクラスタが混在できるので、要件と設計次第でユーザーリソースを効率的かつ柔軟に活用することができます。ホストの種類については過去のブログをご覧ください。

二種類のホストのうち、「i3.metal」は標準的な仮想マシンをより多く配置できるようにバランス良くハードウエアリソースを搭載しているホストです。一方、「i3en.metal」は、 i3.metal よりもストレージ容量の比率が大きいので、より大容量なストレージが必要な仮想マシンの配置に適しています。

例えば、比較的大きめなストレージを必要とする仮想マシンが多数存在する場合、i3.metal だけでクラスタを構成してしまうと、ストレージ容量を満たすために準備すべきホスト台数が多くなり、CPU とメモリリソースが大幅に余ってしまう可能性があります。このようなケースでは i3en.metal を選択するか、または i3.metalとi3en.metal のクラスタを併用することで、全体として効率よく配分できる可能性があります（図8）。

図8　二つのクラスタと物理リソース容量の例

　　　

まとめ

VMware Cloud on AWS は SDDC をそのまま提供するサービスであり、リソース管理面でも安心して利用できる仕組みが備わっています。また、管理コンポーネントは すべて VMware が管理・運用するため、ユーザーは仮想マシンの管理に集中できます。その結果、オンプレミスと比べて大幅な運用コストの削減が期待できます。VMware が管理するメリットについては、また別な機会で詳しくご紹介します。

　　　

関連情報

• VMware Japan Blog – VMware Cloud on AWS サイト
• ブログ「VMware Cloud on AWS のホスト構成」
• ブログ「VMware Cloud on AWS のホスト構成パターン」