VMware Cloud on AWSについて、現時点で分かっていること：VMworld 2017で提供開始を発表（2/2 ページ）
VMwareは2017年8月28日（米国時間）、同社イベントVMworld 2017で、「VMware Cloud on AWS（以下、VMC on AWS）」を提供開始したと発表した。サービス提供開始の経緯、VMware on AWSのユースケース、これまでVMwareとAmazon Web Services（AWS）が進めてきた作業、現時点での機能制限、今後の可能性など、2社の幹部たちが話したことをまとめた。
Direct Connectは当初使えない
プライベートネットワークサービスでAWSと顧客拠点を結ぶ「Direct Connect」は、当初のVMC on AWSではサポートしない。従って、ユーザー組織がVMC on AWSの自社仮想セグメントにプライベート接続するには、SD-WANの機能に見られるような、IPsecなどによるパブリックネットワーク経由のVPNを使うことになる。
vMotionは当初使えない
VMworld 2017における基調講演のデモでは、企業のデータセンターからVMC on AWSへの、仮想マシンのライブマイグレーション（vSphereでは「vMotion」と呼ばれている機能）を見せた。だが、当初は停止している仮想マシンの移行しかできない。
vMotionが当初サポートされない理由として、ローマイヤー氏はDirect Connectが使えないため安定した帯域を確保できないことおよびAWSのネットワーク機能の問題を挙げている。後者は、vMotionがレイヤー2接続を前提としていることに理由があるようだ。顧客のデータセンターと、その顧客のVMC on AWS仮想セグメントの間での、仮想マシンレベルのレイヤー2接続は、容易に実現できる。だが、管理ネットワークのレイヤー2接続が難しく、回避策を見いだそうとしているところのようだ。
ディザスタリカバリーサービスは当初提供されない
ディザスタリカバリー（Disaster Recovery）は、vCloud Airでは提供されていた。だが、初期のVMC on AWSでは提供されない。
上記の全ての課題については、今後数カ月のうちに対応することを、ローマイヤー氏は示唆している。
VMC on AWSで期待される機能
では、VMC on AWSで期待される機能には何があるだろうか。
Elastic DRS
VMC on AWSでは、これまでになかった機能が実装される。これは「Elastic DRS」と呼ばれるもの。DRS（Distributed Resource Scheduler）は、各物理マシン上の仮想マシンの稼働状況をVMware vSphereが監視し、物理マシンのリソース利用がしきい値を超えた場合に、仮想マシンを他の物理マシンにvMotionで自動的に移動することによって、物理マシンの負荷を平準化する機能。
Elastic DRSでは、DRSの機能を使って、オンデマンドで自動的にDRSクラスタを拡大できるという。つまり、VMware Cloud on AWSで、契約している物理マシン数では賄えないほど総体的な負荷が高まった場合、新たな物理マシンをプロビジョニングして、DRSクラスタに自動で追加、その上で仮想マシンを再配置し、物理マシンの負荷を平準化する。
AWSの各種サービスの利用
速報記事でも触れたが、VMC on AWSの仮想ネットワークセグメントは、AWS側からはAmazon VPCと同一の存在として見える。このため、Amazon VPCから利用できる全てのサービスは、VMC on AWSの仮想ネットワークセグメントから利用できる。
VMC on AWSとAWSの間のデータ連携
VMC on AWSがストレージで利用しているVMware vSANと、AWSストレージサービスのデータ連携が進めば、ユースケースが広がることが考えられる。現状ではVMC on AWSセグメント上のアプリケーションがS3 APIでAmazon S3にアクセスする、あるいはAWS側でファイルサービスの仮想インスタンスを稼働し、これにVMC on AWSからアクセスするといった選択肢しかない。
今後vSANによるS3 APIをサポートするなどは考えていないのか。VMwareのストレージ＆アベイラビリティ事業部門ジェネラルマネージャーでシニアバイスプレジデントのヤンビン・リー氏は、どのようなやり方をするかこそ決めていないものの、連携ができるようにしたいと話している。
管理レイヤーでの連携
VMwareとAWSは、双方向で管理レイヤーでの連携を進めたいと考えているとローマイヤー氏は話す。確定したわけではないが、次のような取り組みに興味を持っているという。
まず、AWSは、Cloud FormationやCloudWatchの適用対象を、VMC on AWSに拡張したいと考えているという。特にCloud FormationのVMC on AWS対応が実現すれば、AWS環境に主軸を置いているユーザーが、VMC on AWSをAWSの「Dedicated Hosts（専有ホスト）」などと同様に扱って、VMC on AWSの特徴を生かしたハイブリッドアプリケーションを構築できるという点で興味深い。
「つまり、AWSはVMC on AWSをAmazon EC2やECS（Elastic Container Service）と同様の位置付けにしたいと望んでいる」（ローマイヤー氏）
一方VMwareは、同社がCross-Cloud Servicesと呼んでいたマルチクラウド管理サービス群をVMworld 2017で発表しており、これらのツールの適用を進めていきたいという。
2社はどんな作業を進めてきたのか
VMwareとAWSは、両社におけるトップレベルのエンジニアが100人単位で、VMC on AWSに関わってきたと話している。だが。「AWSがファシリティとサーバを貸し、VMwareがこれにvSphereを導入してIaaSを提供するというだけなら、作業は比較的シンプルなはずで、多数のエンジニアが関わる必要はないのではないか」という疑問を持つ人はいるだろう。
これについては、AWSが独自のサーバを使っていることに起因する問題が以前より指摘されていた。VMwareはラックスケールのハイパーコンバージドインフラソリューション「VMware Cloud Foundation」で、ベアメタルサーバのプロビジョニング／ライフサイクル管理を自動化する機能を提供しており、VMC on AWSでは、これによって運用を効率化している。だが、AWSのサーバは独自のファームウェアを搭載しているため、対応が難しかったとされる。また、ネットワークアダプターもAWSが独自に開発したものであるため、対応に両社エンジニアの時間と労力を要したようだ。
またVMC on AWSの仮想ネットワークセグメントと、AWSのネットワークとの接続についても、ある程度の苦労があったようだ。
VMwareは、VPCと同等のSDN機能を、AWSの協力を得て開発したという。VMC on AWS環境は、独自の実装でバックエンドのAWSネットワークに接続し、これを内部でNSXによりマルチテナント分割している。この独自実装は、Amazon VPCとの接続制御も行い、VMC on AWS内の仮想マシンからのAmazon VPC内のサービスへのアクセスを実現しているという。
Copyright © ITmedia, Inc. All Rights Reserved.