VMConAWS

VMware Cloud on AWS 事始め

はじめに

少しずつ時間も取れ始めたので、VMware Cloud on AWS について書き記していきたいと思います。

2016 年、AWS と VMware が協業を発表しました。そして、それから僅か 1 年で実サービスの提供まで辿り着きました。

VMware Cloud on AWS を 3 行で説明してみると以下のようになります。

VMware の SDDC スタックが AWS のデータセンターの中で動作し、
ハイパーバイザー および 管理モジュールは VMware が運用し、
これを時間単位のオンデマンド、1年単位、3年単位で提供するサービス

ユースケース

どのようなケースに利用できるでしょうか。例えば以下のようなユースケースです。

  • データセンターの移行
  • データセンターの統合
  • 海外や地域毎のデータセンターの配備
  • 災害対策サイト
  • 一時的なデータセンターの利用

もちろん、もっとド直球に響くユースケースもあるかもしれません。

今となっては「どインフラ」な人となっている私としては、

  • API で直ぐにも利用可能になるベアメタル i3.metal/i3p.16xlarge EC2 インスタンス
  • AWS のネットワーク サービス – VPC/ENA/ENI/Direct Connect
  • VMware SDDC を構成する vCenter/ESXi/NSX/vSAN
  • ハイパーバイザー レベルでのレプリケーションを実現する vSphere Replication

の組み合わせで、事情に合わせて夢が無限に広がってくるのです。

お気に入り

VMware Cloud on AWS は、その動作環境と運用形態から、オンプレミスの VMware SDDC 環境とはまたひと味違った特徴があります。私が特に気に入っているのは以下の 3 点です。

  • AWS のデータセンター内で動作する環境
  • VMware が運用
  • 好きなネットワークセグメントを選びたい放題

AWS のデータセンター内で動作する環境

VMware Cloud on AWS は AWS のデータセンター内で動作するサービスです。このため、オンプレから AWS の各種サービスにアクセスするのに比較して、遙かに低レイテンシ、高バンド幅のアクセスが可能になります。

VMware Cloud on AWS と AWS サービスの組み合わせに、バックアップデータの保管先を S3 にするというものがあります。オンプレでもバックアップと S3 の組み合わせは可能ではありますが、次のような問題があります。

  • 大量のバックアップデータを S3 に送らなければならないため、DC のネットワーク帯域を圧迫する
  • リストア時に S3 からバックアップデータをダウンロードするため、リストア時間が掛かってしまう
  • リストア時に S3 からバックアップデータをダウンロードするため、Egress のネットワーク料金が発生してしまう

これらが、S3 と同じ AWS のリソースとして動作する VMware Cloud on AWS の場合は、全て解決されます。S3 とは至近にあるので、低レイテンシ、高バンド幅となり、同じ AWS のリソースであるため S3 のダウンロードトラフィックはネットワーク課金されません。

対応するバックアップソフトウェアは こちら

その他、Elastic File System も至近で利用できますね (VMware Cloud on AWS 同様、東京リージョンはまだですが、要望は多いようで…)。

VMware が運用

VMware Cloud on AWS は一定の間隔で機能追加がなされますが、この vSphere (vSAN)/vCenter/NSX のパッチ当て、アップグレードは VMware が行います。これにより、バージョンアップの検証作業やトラブルに費やされていた時間を別のことに利用できるようになります。検証は VMware が事前に行い、全てのユーザーが同一構成なので揺らぎがなく、パッチ適用/アップグレード時のリスクが限りなく最小化されています。

機能追加のペースについては VMware Cloud on AWS のリリース ノート を参照してください。

もっとも、「塩漬けにしたい」という要望もあるかとは思いますが、残念ながら その要望とは相容れないポリシーとなります。

好きなネットワーク セグメントを選びたい放題

VPC のネットワーク的な制限として、Subnet のネットワーク アドレスは VPC のネットワーク アドレスに依存していしまうことがあげられます。これは VPC の制約というよりも仕様なので受け入れるしかないのですが、自由にネットワーク アドレスを選べないというのは、オンプレの環境を AWS に移行する際はかなりの負担となります。真なる Lift-and-Shift を実現するには、任意のネットワーク アドレス、L2 延伸、同一ハイパーバイザーというのは外せない要素となるのです。

これが VMware Cloud on AWS では、VPC とは関係ない NSX の論理スイッチ機能により、任意のネットワーク アドレスを利用することが可能になります。また、NSX Edge Gateway の機能で L2 延伸も可能になります。そしてなによりも、オンプレと同じ vSphere であれば、VMware Cloud on AWS も vSphere なので、ブート仮想ディスクやデータ仮想ディスクのコンバート作業なども発生しません。

VPC の中なのに、全く異なるネットワークを作成できる機能は、AWS への移行まったなしとなっているユーザーに福音になるかと思います。
例) 10.1.1.0/24、172.16.10.0/25、192.168.3.0/26 の混在

おわりに

日本リージョンでの利用はまだ先ですが、できるだけ無理のない範囲でトピックを書き記していければと思います。

関連記事

  1. VMConAWS

    ワークロードの容易な移動

    はじめにVMware Cloud on AWS では…

  2. VMConAWS

    VMware Cloud on AWS 概要

    はじめにVMware Cloud on AWS は 2016 年に…

  3. VMConAWS

    VMware Cloud on AWS – SDDC Version 1.4

    What's new in SDDC 1.4AWS Summit …

  4. VMConAWS

    ベアメタル インスタンスにインストールされた vSphere ESXi

    はじめにVMware Cloud on AWS で用いられるハイパ…

  5. VMConAWS

    柔軟なキャパシティと回復

    はじめにVMware Cloud on AWS で用…

コメント

  1. この記事へのコメントはありません。

  1. この記事へのトラックバックはありません。










  1. install

    QUADstor – (1) Installation
  2. vsphere client

    vSphere Client (C#) 5.5 update 2 へのアップグレ…
  3. fusion

    VMware Fusion に vCenter Server Appliance…
  4. powershell

    PowerCLI – ダブルクォート内での配列型の変数の展開
  5. virtual san

    Virtual SAN 6.2
PAGE TOP
Translate »