1. はじめに
「VMware Cloud on AWS」の簡易サイジングであればどなたでも無料でお手軽にできますよというご紹介をします。Tipsも合わせてご紹介します。
高度なサイジング用のWebツールおよび手法についてはVMware社のブログが分かりやすいのでご参考ください。
VMware Japan Blog: 「VMware Cloud on AWS のサイジング（高度 Sizer によるサイジング）」
2. VMware Cloud on AWSのサイジングは必要？
オンプレミス環境に限らずクラウドサービスを利用する際もサイジング、つまりどの程度の性能の物理サーバーやストレージが何台(あるいはコンピュートリソースがどれぐらい)が必要かというのは事前に検討するかと思います。
いやいや今時クラウドサービスだし従量課金だしそんな計算不要でしょ、というか今どきサーバーレスだしそんなこと生まれてから一度も考えたこともないぜ、、なんて方もいるかもしれません。その場合でもIT予算は無限ではないので、利用料あるいはコスト感についてざっくりと把握はするのではないでしょうか。
前置きが長くなりましたが、クラウドサービスでかつ「リソース利用状況に応じて自動でホスト数増減が設定可能 (Elastic DRS)」であるVMware Cloud on AWSでも、本番での利用開始前にはなんらかのサイジングを実施するかと思います。
3. サイジングが必要なのは分かった。ではどうすれば出来るの？ (やっぱり専門家じゃないと難しい..?)
「VMware Cloud Sizer」で簡単に出来ます！
無料のVMware社Webツール「VMware Cloud Sizer」を利用して実はどなたでも簡単に出来ます、というのが本稿の趣旨です。事前に必要なのは、オンプレミス環境でどれぐらいのコンピュートリソースを使っているか、もしくは今後VMware Cloud on AWSでどれぐらいのコンピュートリソースを利用したいかという情報です。
オンプレミスVMware仮想環境のイメージ図
必要な情報
- a. オンプレミスで稼働している仮想マシン台数
- b. CPUオーバーコミット率
- c. 平均的な仮想マシン１台あたりのvCPU
- d. 平均的な仮想マシン１台あたりのRAM
- e. 平均的な仮想マシン１台あたりのストレージ
4. 試しにサイジングしてみる
オンプレミスでVMware仮想環境を利用していると仮定します。
まずはインプット情報の準備
- a. オンプレミスで稼働している仮想マシン台数 => 100台 (Windows, Cent, etc..)
- b. CPUオーバーコミット率 => 4 (特別な要件がない想定でデフォルト値のままで設定)
- c. 平均的な仮想マシン１台あたりのvCPU => 2 ※1
- d. 平均的な仮想マシン１台あたりのRAM => 8 (GiB) ※1 ※2
- e. 平均的な仮想マシン１台あたりのストレージ => 200 (GiB) ※1 ※2
注記
※1. c,d,eの値はvCenterにログイン後、仮想マシンの「設定」からも確認できます。(下図)
※2. VMware Cloud Sizerではd,eの値はGiBで入力します。今回は精緻なサイジングを想定していないため、便宜的にGBをGiBに単位換算しないままとします。ちなみに100GB(ギガバイト) ≒ 93.1GiB(ギビバイト)なので約7%の誤差があります。
サイジング結果
下図が上記を元にインプットした際の結果です。今回の場合はオンプレミスで稼働している仮想マシンをそのままVMware Cloud on AWSで稼働させる場合に必要なリソースの概算が確認できます。
ESXi Hosts: 必要なホスト数
Host Type (AWS): インスタンスタイプ (i3.metalとi3en.metalから選定されます)
VMware社無料Webツール：「VMware Cloud Sizer」 (VMC Sizerとよく略称されます。)
利用料について
「Pricing Calculator」というツールで簡単に見積もり可能です。こちらは次回記事にてご紹介します。
5. サイジングのTips (どうやってコスト削減ができるのか)
再度サイジング結果を確認してみましょう。"Driven By Storage"と表示されている赤枠の部分に注目ください。
こちらはサイジング結果でどのパラメーターが最も効いているか、サイジング結果に最も影響を与えているリソースを意味しています。この場合は"Storage"のサイズを削ることが出来れば、必要なホスト台数を減らす (つまりコスト削減できる)可能性があることを示しています。
例えばインプットの「e. 平均的な仮想マシン１台あたりのストレージ」を150(GiB)から200(GiB)にダウンサイズした結果が下図です。ホスト数が以前の4ホストから削減され、3ホストになったことが分かります。
今回仮想マシンは100台の想定ですので、合計5,000(GiB, 約5TiB)分のストレージを削ったことになります。
どうやってストレージを削るのか？
これにはいくつかの推奨シナリオがありますが、代表的なものとして次の２パターンが挙げられます。
パターン#1. AWSネイティブサービスにオフロード
パターン#2. プロビジョニングサイズではなく実際のリソース使用量に基づいてサイジング実施
パターン#1について例えば、オンプレミス仮想マシンの中にファイルサーバーが存在する場合などはAWSストレージサービスの「Amazon FSx」および「Amazon S3」にオフロードするというケースが考えられます。
上図はVMware Japan Blog: 「VMware Cloud on AWS と AWS の連携）」から抜粋しています。
パターン#2は実際にはパターン#1と同時に実施することがほとんどで、より高度なサイジングが必要になってきます。
さいごに
本記事ではあくまで簡単にサイジングすることを目的としているため、さらに精緻なサイジングが必要な場合は前述のVMware社ブログをご参考いただき、VMware社あるいはAWSもしくは各社のパートナーにご相談いただければと思います。まずはVMware Cloud on AWSにご興味を持っていただくキッカケとなれば幸いです！
VMware社公式サイトでも「VMware Cloud Sizer」についてご確認いただけます。
VMware Docs: VMware Cloud Sizer ユーザーガイド
4. 関連記事