VMware Cloud on AWSの構造とハイブリッド管理（2）：詳説VMware Cloud on AWS（3）（1/3 ページ）

VMware Cloud on AWSを解説する本連載。今回はいよいよ、AWSのベアメタルインスタンスをどう活用しているのかを詳細に説明する。合わせて、オンプレミスのVMware vSphereとVMware Cloud on AWSのハイブリッド管理についても紹介する。

[大久光崇，ヴイエムウェア株式会社]

　前回は、「VMware Cloud on AWS」の基本的な構成について解説した。今回はその続編として、AWSのベアメタルインスタンスとVMware Cloud on AWSの関係を詳細に説明する。併せて、オンプレミスの「VMware vSphere」とVMware Cloud on AWSのハイブリッド管理についても紹介する。

EC2ベアメタルインスタンスの利用

　VMware Cloud on AWSの物理ホストとして利用されているのはAmazon EC2ベアメタルインスタンスである。EC2ベアメタルインスタンスは、仮想マシンタイプのEC2インスタンスのようにハイパーバイザー上の仮想マシンではなく、物理ハードウェアへの直接のアクセスが可能である。ハイパーバイザーである「VMware ESXi」はベアメタルインスタンス上で直接起動し、運用管理は、ユーザーに代わってVMwareにより行われる。ユーザーはこのESXiの設定を参照することができるものの、変更を行うことは一切できない。

2019年6月時点では、2種類のベアメタルインスタンスが利用できる

　AWSが提供するベアメタルインスタンスは徐々に増えているが、VMware Cloud on AWSで利用できるのは現時点で「i3.metalインスタンス」と「r5.metalインスタンス」のみとなっている。i3.metalインスタンスは全てのVMware Cloud on AWSリージョンで利用可能である。r5.metalインスタンスは2019年5月にGA（一般提供開始）を迎えたインスタンスで、利用できるリージョンが米国のオレゴン、オハイオ、バージニア北部、ドイツのフランクフルトのみに限定されている。東京で利用できるインスタンスタイプを増やすためには、4つの段階が必要となる。

1. AWSが、あるベアメタルインスタンスタイプをリリースする
2. VMware Cloud on AWSが、そのタイプをリリースする
3. AWSが、そのタイプを東京リージョンでリリースする
4. VMware Cloud on AWSが、そのタイプを東京リージョンでリリースする

　r5.metalインスタンスは、執筆時点でVMware Cloud on AWSとしてはGAしたものの、2の状態であるため、東京リージョンで利用できるようになるまでもう少しかかる。インスタンスタイプの追加やリージョンの展開は、需要を見て決められるため、r5.metalインスタンスの東京リージョンでの利用や、他のインスタンスタイプの利用を希望する場合には、ヴイエムウェアの営業・パートナーにフィードバックをお願いしたい。

　次に、i3.metalインスタンスとr5.metalインスタンスの詳細を見ていく。

i3.metal

　i3.metalインスタンスは、高トランザクションで低レイテンシのワークロード向けにストレージを最適化したi3インスタンスにおけるベアメタルインスタンスである。最大の特徴はインスタンスに内蔵した8台の高速なNVMe SSDデバイスで、VMware Cloud on AWSにおいても仮想ストレージであるvSANのパフォーマンス向上に寄与している。

CPU

　「Intel Xeon E5-2686 v4 2.3GHz」を2基搭載し、合計物理コア数は36コアである。最新のCascade Lake世代からは2世代前のBroadwell世代ではあるが、汎用的なワークロードでは、その潤沢なコア数もあり十分な性能となっている。

　仮想マシン上で稼働するアプリケーションのソフトウェアラインセスが物理コア数を元に計算される場合、この潤沢なコア数がソフトウェアライセンスコストの上昇を招くことがある。この場合、「カスタムCPUコア」の機能を用い、物理ホストの物理CPUコア数を8コア、16コア、36コアと構成変更し、ソフトウェアライセンスコストを抑えることができる。カスタムCPUコアは、SDDCの2つ目以降のクラスタの作成時に指定し、そのクラスタ内の全ての物理ホストに適用される。

メモリ

　搭載メモリは512GBと、比較的大容量に見えるかもしれない。しかし、オンプレミスのプライベートクラウド環境においても、昨今では512GB超えのメモリ容量を備えた物理ホストをそろえる顧客も少なくない。実際に仮想マシンの集約を進めると、CPUよりもメモリの容量不足が顕著になりがちである。これは仮想化環境の宿命ともいえる。CPUよりもメモリの方が、仮想マシン間でのリソースの受け渡しの手順が複雑になることと、クリティカルなアプリケーションほどメモリ領域を確保したままで動作する設計が好まれるためである。

　CPUリソースは、ある仮想マシンがスケジューリングから外れれば、コンテキストスイッチなどを経て別の仮想マシンがすぐに利用できる。これに対し、メモリリソースでは、ある仮想マシン上のアプリケーションがメモリ領域を解放し、さらにその領域をハイパーバイザーが仮想マシンから回収することで、初めて別の仮想マシンにメモリリソースを与えることができる。あるいはハイパーバイザーが仮想マシンのメモリリソースを圧縮、または、ディスクにスワップすることで、別の仮想マシンに与えるメモリリソースを捻出する。しかし、圧縮からの復帰時、特にスワップからの復帰時のメモリアクセスパフォーマンスの劣化が発生する。このパフォーマンス劣化を避けるため、昨今の仮想基盤の物理ホストはメモリを大容量とする傾向があり、i3.metalインスタンスの512GBも、大き過ぎることはない。

NIC

　AWSのNitro世代のインスタンスは、「Elastic Network Adapter（ENA）」を搭載している。i3.metalインスタンスも同様に25GbpsのENAを搭載し、ESXiは1基のNICを認識している。ドライバはAWSによって開発され、ハイパーバイザーのカーネルAPIを直接コールするネイティブドライバが採用されている。

　顧客からよくある質問の一つに、「NICの冗長化はどうなっているのか」というものがある。これは直接回答するのが難しい質問で、「SLA（サービスレベル契約）に定義された稼働率を満たすように実装されている」というのが回答である。インフラに長く携わるエンジニアが、ここを気にするのは十分理解できるが、実際には枝葉にすぎない。本当に重視すべきはシステムとしての稼働率であり、その稼働率を導出するための一要素であるNIC冗長化の実装方式ではない。一方、「どのように実装されているのか」という点については、VMworld、AWS re:Inventなどのイベント会場における開発者との話題としていただければと思う。

ストレージ

　i3.metalのストレージは2種類に分けてみていきたい。ブートデバイスとvSANのキャッシュ／キャパシティーデバイスである。

　ブートデバイスは、AWSによって暗号化された12GBのEBSボリュームである。ESXiはこのEBSボリュームをローカル接続のNVMe SSDデバイスとして認識する。ネットワーク接続のEBSボリュームにもかかわらずローカル接続とはどういうことであろうか。これは物理ホストのファームウェアによって実現している。まずファームウェアがEBSイニシエータを持ち、EBSのボリュームのターゲットを参照する。次にファームウェアはそのEBSボリュームをバックエンドとしたNVMeターゲットを作成し、ESXiにNVMeターゲットとしてエクスポーズ（提供）する。これによってESXiからは、ローカル接続されたNVMe SSDデバイスとして参照される。ESXiに新しいストレージスタックとしてEBSのイニシエーターを実装する場合と比較し、合理的な実装となっている。

　vSANのキャッシュ／キャパシティーデバイスには、i3.metalインスタンスに内蔵されたNVMe SSDが利用される。これらのデバイスもブートデバイスと同じくAWSによって暗号化されている。全てのNVMe SSDデバイスがESXiにコントローラーをエクスポーズしており、標準のNVMeドライバで動作する。これらの内蔵NVMe SSDデバイスはインスタンスストアとして扱われるため、インスタンス削除のタイミングでデバイス上のデータも削除される。

r5.metal

　r5.metalインスタンスは、AWSではメモリ最適化インスタンスと位置づけられているが、VMware Cloud on AWSにおいては、大容量ストレージ環境向けのインスタンスとして扱われる。i3.metalインスタンスとの違いとして、CPU／メモリが強化されている他、大きな違いとしてvSANのキャッシュ／キャパシティーデバイスにAmazon EBSを使っている。

CPU

　2.5GHzのIntel Xeon Platinum 8000シリーズを2基搭載し、合計物理コア数は48コアである。i3.metalインスタンスよりも登場時期が最近であることから、より新しい世代のSkylakeアーキテクチャであり、コア数も強化されている。

　r5.metalインスタンスでも、i3.metalインスタンス同様にカスタムCPUコアの機能を利用できる。クラスタを追加する際に、物理ホストのコア数を8コア、16コア、48コアから選択できる。

メモリ

　CPUと同じく、メモリもi3.metalインスタンスに対して強化され、1.5倍の768GBを搭載する。

NIC

　r5.metalインスタンスはNitroプラットフォームのため、i3.metalと同様に25GbpsのENAを1基備える。

ストレージ

　ストレージは、r5.metalを特徴付ける要素である。ブートデバイスだけでなく、vSANのキャッシュ／キャパシティーデバイスにもEBSボリュームが使われている。

　ブートデバイスはi3.metalと同じく12GBの暗号化されたEBSボリュームが利用されている。

　vSANのキャッシュ／キャパシティーデバイスにも暗号化されたEBSボリュームが利用されている。このEBSボリュームもブートデバイスと同様に、ESXiからはローカル接続されたNVMe SSDデバイスとして見える。キャッシュデバイスには3.3TBのEBSボリュームが1ホスト当たり3ボリュームアタッチされている。キャパシティーデバイスは1.66TBのボリュームを9本から21本まで可変でアタッチできる。残念ながら現時点では、ホットアド／ホットリムーブすることはできない。vSANのディスク構成については、後続のストレージの回で詳細に説明する。