クラウド VMware Cloud on AWS

VMware Cloud on AWS の vSAN 構成

今回は、VMware Cloud on AWS で提供されているホストとストレージ（vSAN）の構成について解説します。ホストによって異なるストレージ構成や容量について少し掘り下げてみます。最後に簡単ながらサイジングツールもご紹介します。

 

 

ホストのスペックとストレージデバイス

VMware Cloud on AWS は、SDDC を構成するホストに「Amazon EC2 ベアメタル インスタンス」を採用しています。現時点で選択可能なインスタンスタイプとして「i3.metal」と「i3en.metal」が提供されています。ユーザーは、これら二種類のインスタンスタイプから一つを選択してクラスタを作成します。

最大の違いはストレージ容量です。ホストに搭載しているストレージデバイスには「NVMe SSD」 が採用されており、デバイスの搭載数はどちらも同じです。しかし、デバイスあたりの容量を見ると、i3en.metal の方が 4.4倍大きいため、ホストあたりのストレージ容量に違いが生じます（図1）。

図1  ホストのスペック比較とストレージデバイス

 

同様に CPU とメモリを比較しても i3en.metal の方が高スペックです。そのため、ディスク容量が大きい仮想マシンが多く存在する環境では、i3en.metal に集約すると i3.metal よりも使用するホスト台数は少なくなります。

 

 

vSAN Disk Group の構成

ストレージの構成に目を向けてみましょう。どちらのホストもブート領域とデータ領域で異なるストレージを使用しています。ブート領域には、Amazon Elastic Block Store の Volume を使用しています。一方、データ領域にはホストに搭載されているデバイスで構成された vSAN を使用しています（図2）。

vSAN の構成を詳しく見てみましょう。まずは i3.metal の構成です。vSAN は2つの Disk Group で構成されています（図2）。その Disk Group に注目すると、Disk Group ごとに4つの NVMe SSD デバイスを割り当ててキャッシュ層とキャパシティ層に分けて構成しています。

図2  i3.metal の Disk Group 構成イメージ

 

次に、i3en.metal を見てみましょう。こちらは4つの Disk Group で構成されています。注目すべきは、NVMe SSD デバイスが複数の論理デバイスに分割された状態で Disk Group に割り当てられている点です（図3）。

図3  i3en.metal の Disk Group 構成イメージ

 

i3en.metal に搭載されている NVMe SSD デバイスは容量が大きいため、i3.metal と同じように物理デバイス単位で Disk Group に割り当てると、Disk Group の仕様によりキャッシュ層で一時的に使用されない領域が生まれてしまいます。そこで採用されたのが、 NVMe の「Namespace」を活用した論理デバイスです。

NVMe の Namespace とは、磁気ハードディスクドライブ（HDD）におけるパーティションに相当するような概念であり、NVMe デバイス内部で論理的に領域を分割して論理デバイスとして外部から認識させることができる仕組みです。この論理デバイスは、それぞれ独立したデバイスとして vSAN から認識されます。

i3en.metal では、NVMe SSD デバイスを4つの論理デバイスに分割し、合計 32個の論理デバイスとして認識します。その後、1つの Disk Group ごとに8個の論理デバイスを割り当てて、キャッシュ層とキャパシティ層に分けて構成します。このアーキテクチャを採用することによってキャッシュ層の領域も効率的に活用できます。

 

 

データストアの論理分割

次に、データストアの構成に目を向けてみましょう。 ブログ「VMware Cloud on AWS のソフトウエア構成とリソース管理」でもご紹介していますが、SDDC のインフラは VMware が管理・運用しているため、一部の設定や構成はユーザーが変更できない仕様になっています。

その一例として、データストアは vCenter や NSX などの管理コンポーネント専用の区画（Management Namespace）とユーザー専用の区画（Compute Namespace）に分割されています（図4）。これは VMware Cloud on AWS 独自の実装であり、サービスの安定運営を目的として管理コンポーネントのリソース領域に対するユーザーのアクセスを制限するために採用された仕組みです。ユーザーは仮想マシンをプロビジョニングする時、データストア名「WorklodadDatastore」を使用します。データストア名「vsanDatastore」は、管理コンポーネントで使用されます。

図4 VMware Cloud on AWS の SDDC リソース分離

 

尚、これらのデータストアは共通の容量プールを使用しています。そのため、消費している容量（Provisioned Space）は、それぞれのデータストアで異なる結果を表示しますが、空き容量（Free Space）は、どちらのデータストアから見ても同じ値を示します（図5）。

図5  二つのデータストアの容量表示画面

 

 

ストレージ容量とサイジング

次に、ストレージ容量 を見てみましょう。下表（図6）は、i3.metal と i3en.metal インスタンスタイプのストレージをそれぞれホスト台数ごとに合算して比較したものです。同じホスト台数で比較すると i3en.metal の方が大きいことが一目で分かります。

図6   物理ストレージ容量の違い

 

ストレージ容量の考え方は、基本的にオンプレミスの vSAN 環境と変わりありません。仮想マシンに適用するvSANストレージポリシー（RAID 構成を決めるFault Tolerance Method 値）によってストレージの使用容量や比率が変わる点も同じです（図7）。

図7  RAID構成によるストレージ使用容量の違い

 

ただし、VMware Cloud on AWS の場合は独自のデフォルトストレージポリシーが採用されています。この点は、オンプレミス環境と異なります（詳しくは、ブログ「VMware Cloud on AWS の vSAN ストレージポリシー」をご覧ください）。

それらを踏まえた上で、オンプレミスのワークロードを VMware Cloud on AWS へ移行する計画を立てることを想像してみましょう。その場合、はじめに移行対象とする全ての仮想マシンが使用しているリソース（CPU やメモリ、ストレージ容量など）を合算します。その後、VMware Cloud on AWS の SDDC に集約するために必要なホスト台数を計算する、という流れで進めるのが一般的です。そこで役立つのがサイジングツール「VMware Cloud Sizer」です。

 

 

サイジングツールの活用

VMware は VMware Cloud on AWS を採用する際のリソース計算に最適なサイジングツール「VMware Cloud Sizer」を提供しています（図8）。このツールには、VMware Cloud on AWS のリソース計算に必要なパラメータが埋め込まれているため、より正確な算出が可能です。

図8  VMware Cloud Sizer の画面サンプル

 

移行対象のワークロード（仮想マシン）の情報を入力すると、最適なホスト台数を算出できます。計算結果には、入力した情報からクラスタを構成する際の最適なホスト台数が表示されます（図9）。画面上でホストの種類（Host Type）を切り替えることで、前提条件を変えた出力結果を比較することもできます。また、ストレージ容量に関しても消費容量や空き容量、RAID 構成など詳細に確認することができます。

図9  VMware Cloud Sizer の計算結果サンプル

 

VMware Cloud on AWS の採用を検討中のお客様は、VMware のパートナー様または VMware の担当営業に依頼していただければ、最適なホスト台数を計算します。ぜひお気軽にご依頼ください。

 

 

まとめ

今回は、VMware Cloud on AWS のストレージ構成について解説しました。vSAN で構成されているストレージサービスは、容量および性能面で最適化されており、安定したサービスを提供します。その他、VMware Cloud on AWS に関する情報（下記リンク）も併せてご覧ください。

 

 

関連情報リンク

 

吉田 尚壮

プリンシパル ソリューション アーキテクト｜ヴイエムウェア にて VMware Cloud Foundation の技術担当として営業支援活動に従事しています。

関連記事