理系学生日記

おまえはいつまで学生気分なのか

忍者TOOLS

vSphere HA を組み、アドミッションコントロールを行う前提でのESXi サーバ台数を見積り

** vSphere HA

vSphere には vSphere HA という機能がある。 HA というのは、当然ながら High Availability を意味していて、vSphere が提供するクラスタ機能を意味している。ざっくり言うと - ホスト自体にハードウェア障害が発生した場合は、当該ホスト上で稼動していた VM を他のホスト上に移動し起動させる - ゲスト OS の障害によるアプリケーション障害に対しては、VM を監視しておいて、障害が発生したら VM ごと再起動させる という動作を行う。ライブマイグレーションと違って無停止というわけにはいかないが、それでも、通常時の待機系を強く意識することなく運用ができるというメリットは大きい。

** アドミッションコントロール

一方で、vSphere HA の機構によるフェイルオーバーが発生したときに、障害の発生していないホストには VM が満載されてしまっていて 障害ホストから VM が移動できない、というような悲劇が有り得る。このような悲劇が生じては、vSphere HA で得られる安心感は全て幻想だった、ということになりかねない。これを防止するために、vSphere ではアドミッションコントロールという機構が備わっている。 アドミッションコントロールとは、フェイルオーバーを確実に実施できるだけの予備リソースをホストに確保しておくことを強制する機構。強制する機構に対して "Admission" というと直感的ではないが、これは「予備リソースを侵すような操作」を"入口"で制限する、と考えれば名が体を表している。 具体的には以下のような動作が制限される。 - VM の電源 ON - ホスト、クラスタ、リソースプールへの VM の移行 - VM の CPU/メモリ予約の増加

** 計算前提 ようやく今日の主題なのだが、vSphere HA を組み、アドミッションコントロールを行う前提で、導入すべきホスト台数は何台なのか、というところを考えていく。 考える前提は以下の通り。 - 導入するホストは全て同一の構成とする。メモリ、CPU 等はホストによって変化しない - vShere HA 上で動作させる VM は CPU bound ではないものとする。 -- これは単純に、今日はメモリ制約のことだけ考えたいだけで、CPU Bound のものがあるのであれば、下記で記述する流れを CPU についても考えれば良い。 - VM に割り当てるべきメモリの見積もりは全て完了しているものとする - vSphere 5.5 を使用する

以上を前提とし、さらに、以下を定数として表現する - ホストの物理メモリを [tex:M] とする - VM [tex:i] が要求するメモリ容量の見積りを [tex:m_i] とする - 可用性設計上のフェイルオーバーキャパシティを [tex:f] とする - 必要になるホスト台数を [tex:n] とする フェイルオーバーキャパシティというと難しそうな単語なのだが、「VM を全てパワーオンにしたままで、何台までのホスト障害に耐えられるようにするか」を表す値である。

さらに、複数存在するアドミッションコントロールのポリシの中で、「クラスタリソースの割合アドミッション コントロールポリシ」を採用するものとする。これは vSphere の推奨であり、VM 毎のリソース要件のバラツキに対し1て柔軟なポリシになる。

http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.avail.doc/GUID-39731BEC-EB0C-48C9-813B-CAF9DE884FD5.html:title> 予約されたクラスタ リソースの割合アドミッション コントロール ポリシーを選択します。このポリシーは、ホストと仮想マシンのサイズについて最も柔軟です。このポリシーを構成する場合、サポートするホスト障害の回数を反映した CPU とメモリの割合を選択してください。 <<

** 計算をしましょう CPU Bound の処理がないという前提から、ここで検討すべきなのはメモリ制約となる。 ホストの物理メモリのうちの一定量は、VM ではなく、VMware vSphere ESXi (ハイパーバイザ) に割り当てる必要がある。では、ハイパーバイザに割り当てるべきメモリはどれほどなのか。これは ESXi 5.5 のシステム要件から持ってくる。

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2080534:title> 4 GB RAM を搭載している。これは、ESXi 5.5 をインストールするための最低要件です。ESXi の機能を十分に活用し、一般的な本番環境で仮想マシンを実行するために、少なくとも 8GB の RAM を提供します。 << 以上の記述から、8 GB は見ておいた方が良いだろう。結果として、ホスト 1 台あたりが VM に提供できるメモリは [tex:M-8] となる。

次に、個々の VM に対して、仮想化のオーバヘッドがかかってくる。メモリについては、ゲスト OS が要求するメモリにプラスして、オーバヘッドメモリが別に必要。 - [http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.resmgmt.doc/GUID-B42C72C1-F8D5-40DC-93D1-FB31849B1114.html:title] 上記ページで、ある程度の目安が提示されているが、計算が煩雑になるので VM のオーバヘッドメモリは一律 [tex:o] と表現する。

これでだいたい準備が整った。 フェイルオーバキャパシティ [tex:f]、ホスト台数が [tex:n] なので、リソースとして予約しておく必要があるのは [tex:f/n] となる。 次にメモリのフェイルオーバーキャパシティであるが、「クラスタリソースの割合アドミッション コントロールポリシ」を採る場合、以下のように計算される。

http://pubs.vmware.com/vsphere-55/index.jsp#com.vmware.vsphere.avail.doc/GUID-FAFEFEFF-56F7-4CDF-A682-FC3C62A29A95.html:title> 現在の CPU フェイルオーバー キャパシティは、ホスト CPU リソースの合計から、CPU リソース要件の合計を減算し、その結果の値を、ホスト CPU リソースの合計で除算した値になります。 現在のメモリ フェイルオーバー キャパシティも同様に計算されます。 << これに基くと、メモリのフェイルオーバーキャパシティの値は[tex:\frac{Mn-\sum_i{(m_i+o)}}{Mn}] であり、これがリソースとして予約しておくべき [tex:f/n] 以上であれば良い。結果として [tex:\frac{Mn-\sum_i{(m_i+o)}}{Mn} \ge \frac fn] を [tex:n] について解けば良い。 この結果は [tex:n \ge \frac{fM+\sum_i(m_i+o)}{M}] となる。 あとは定数に具体的な値を埋めて計算をすれば答えがでる。