近年、VMwareを稼働させている基盤（特にオンプレミス上で稼働している）をパブリック・クラウドに移行するという案件が増えつつあります。
理由は様々ありますが、「自社で運用しているデータセンターを廃止してパブリック・クラウドに移行する」というお客様が多いなと感じています。
そこで今回は、現在オンプレミスで動いているVMware環境をパブリック・クラウドに移行する際に必要なサイジングの方法を、弊社のOCVS(Oracle Cloud VMware Solutions)を例に記載していきたいと思います。
①移行元のVMware環境のスペックを確認する
まずはじめに、移行元となるVMware環境のスペックを確認します。
具体的には、以下のスペックを確認します。
-CPUのモデル、クロック周波数
-CPUの物理コア数
<メモリ関連>
-物理メモリの容量
<ストレージ関連>
-物理ストレージの容量
例を示すと、以下のようになります。
-CPUのモデル、クロック周波数
Intel(R) Xeon(R) CPU E5-2697 v4 @ 2.30GHz
-CPUの物理コア数
16コア、2ソケット（合計32コア）
<メモリ関連>
-物理メモリの容量
512(GB)
<ストレージ関連>
-物理ストレージの容量
1000(GB)
②CPUのスペック差異を計算する
CPUは新しくなればなるほど性能が進化しており、既存のオンプレミス基盤よりも移行先のパブリック・クラウドが新しいモデルを採用しているためより性能が良いということがよくあります。
そこで既存環境と移行先の環境のCPUの性能差異を計算し、移行後に性能の余剰がないようにしておきます。
具体的にはCPUのベンチマーク数値を利用して性能差を計算するのですが、ベンチマークは様々なサイトで公表されているので、ここで特定のサイトを紹介することは差し控えます。
（もちろん、具体的な案件のご相談の際には、最適なベンチマークを利用して性能差を計算いたしますのでご安心ください）
③移行する仮想マシンの全体のスペックを算出する
移行する仮想マシンのスペックをここで計算します。
具体的には以下の数値を確認します。
-移行対象となる仮想マシン数
-移行対象となる仮想マシンの論理コアの合計数
-移行対象となる仮想マシンのメモリの合計数
-移行対象となる仮想マシンのストレージ容量の合計数
既存のVMware環境を移行するにあたり、バージョンの古さや業務調整により必要のなくなった仮想マシンを整理される場合も多くあると思います。
必要のないマシン等があれば、ここで整理してしまいましょう。
④オーバーコミットを考える
VMwareの世界では、オーバーコミットという考え方が存在します。
言葉の定義としては「仮想マシンに対してリソースを割り当てる際、基盤となる物理マシンの上限を超えた割り当てを行う」ことです。
例えば、100個の仮想マシンがあり、それぞれに4CPUずつ割り当てるとします。
この場合、全部で400CPUが必要となりますが、仮想マシンの性質によっては「常に4CPU必要」とはならないものがあると思います。
夜間バッチを稼働させる場合であったり、開発/検証環境など必要なときだけ起動させる場合であったりと、理由は様々ですが
こうした常に必要でないリソースを鑑みてオーバーコミットを決定します。
上記100個の仮想マシンがあり、それぞれに4CPUずつ割り当てる場合であれば、
オーバーコミット率100% 400CPU
オーバーコミット率200% 200CPU
オーバーコミット率300% 134CPU(端数切り上げ)
オーバーコミット率400% 100CPU
と、オーバーコミット率を高めれば高めるほど必要なCPU数が減るため、コストも削減することができます。
一方、ミッションクリティカルなシステム等、常ににリソースを必要とする場合はオーバーコミット率を低く設定しなければ
必要な時にリソースが枯渇してしまうといったことも起こりえます。
VMware社の方から聞いた話であれば一般的に200%程度が目安であると伺いましたが、
OCVSのお客様の事例では600％まで許容されるお客様もいらっしゃいます。
もちろん、パブリック・クラウドはリソースの追加が柔軟にできるため、後から必要なリソースだけ追加/削除するといったことも可能であり、
時間もOCVSであれば3～4時間以内で対応ができます。
こうしたことを考慮し、なるべく余剰なリソースがないようにオーバーコミット率を考えましょう。
⑤メモリ使用率の上限を考える
ここまでくればサイジングは終盤です。
③で計算した仮想マシンのメモリの容量や、普段の仮想マシンのメモリ使用率を前提に、メモリの使用率の上限を検討します。
一番わかりやすいのは、普段の仮想マシンのメモリ使用率の最大値（繁忙期など、リソースを必要とする時期）を見てみましょう。
メモリの容量をオーバーコミットするパターンは一般的ではありませんので、どのお客様でも割り当て容量の80%を目安とされる場合が多くなります。
⑥必要なホスト台数を計算する。
ここまで準備ができれば、ようやくホストの台数を計算します。
以下のような例の場合を考えてみましょう。
-移行対象となる仮想マシン数
600VM
-移行対象となる仮想マシンの論理コアの合計数
2,900(コア)
-移行対象となる仮想マシンのメモリの合計数
9,000(GB)
-移行対象となる仮想マシンのストレージ容量の合計数
240(TB)
オーバーコミット率
500%
メモリ使用率
80％まで許容
[2900(論理コア合計)+45(OCVSの基盤に必要なコア数)]×1/5(オーバーコミット500%許容)
=589(vCPU)が必要な論理コア数
これをOCPU(1 OCPU=2vcpu)に直すと
589×1/2
=295 OCPUが必要なコアになります。
必要な295 OCPUをOCVSのシェイプに当てはめるために割り算をすると、
DenseIO_IntelX7：6台
DenseIO_AMDE4：32コアで10台、64コアで5台、128コアで3台
Standard_IntelX7：6台
Standard_IntelX9：16コアで19台、32コアで10台、64コアで5台
Standard_AMDE4：32コアで10台、64コアで5台、128コアで3台
となります。
以下のメモリの必要量と合わせて必要台数を見積もるので、ここではこのまま進みます。
<メモリの計算>
9,000GB（仮想マシン全体のメモリの容量）×0.8(許容する最大メモリ使用率)
=7,200GB（必要なメモリの容量）
これを各シェイプに当てはめるために割り算をすると
DenseIO_IntelX7(768GB/ホスト)：10台
DenseIO_AMDE4(2,000GB/ホスト)：4台
Standard_IntelX7(768GB/ホスト)：10台
Standard_IntelX9(1,000GB/ホスト)：8台
Standard_AMDE4(2,000GB/ホスト)：4台
となります。
<ストレージの計算>
必要なストレージは240(TB)でありますが、
OCVSの実行領域（VMware ESXi等の稼働分を各ホストから除く）を考えなくてはなりません。
1台あたり6TB程度をESXi等が利用しますので、
DenseIO_IntelX7（51TB）：1台あたり45TB
DenseIO_AMDE4(54.4TB)：1台あたり48.4TB
となり、必要ホスト台数は
DenseIO_IntelX7（51TB）：6台
DenseIO_AMDE4(54.4TB)：5台
となります。
なお、Standardシェイプは必要に応じてBlock Volumeを利用する形態となるため
各ホストにストレージの領域はありません。
また、DenseIOシェイプでも昨年より必要に応じてBlock Volumeをホストに追加することができるようになりました。
よって、CPUとメモリから計算すると、
DenseIO_IntelX7：10台
DenseIO_AMDE4：64コアで5台、128コアで4台
Standard_IntelX7：10台
Standard_IntelX9：64コアで8台もしくは32コアで10台
Standard_AMDE4：64コアで5台もしくは128コアで4台
が必要な台数となります。
最後の必要ホスト台数は、より低いコストとなるように
オーバーコミット率をすこし上げたり、メモリの使用率の上限を上げたりすることで
より効率的なホスト台数にすることができます。