こんにちは。
システムセンターサポート担当の住です。

これまでにSCVMM の管理者が遭遇しやすい障害状況などを 「SCVMM の落とし穴」 としてご紹介してきましたが、今回がシリーズ最終回となります。

過去の投稿についてはこちらをご覧ください。

• SCVMM の落とし穴 その１ - 仮想マシンの自動起動（ホストクラスター）
• SCVMM の落とし穴 その２ - 複数ドメインの管理
• SCVMM の落とし穴 その３ - 仮想ネットワークの管理
• SCVMM の落とし穴 その４ - XP クライアントからVMへ接続出来ない!?
• SCVMM の落とし穴 その５ - ある日突然、管理コンソールが開けない!?
• SCVMM の落とし穴 その６ - 仮想マシンが「不足」する!?

最終回は、「過剰コミット」についてです。

前回同様、これまでにも技術情報やブログ等で紹介されていますが、非常に理解しづらいものの、管理者の方にとって重要な問題となる「過剰コミット」について、詳しく見ていきます。

序章

まずは、「過剰コミット」とは何かを見てみます。
管理コンソールのホスト ワークスペースから、ホスト クラスター のプロパティを開いてみてください。「全般」タブをみると、「クラスター予約状態」の欄が以下の様に「過剰コミット」と表示される場合があります。
「クラスター予約」とは、クラスターとして確保しておきたいリソース（特にメモリ）を指します。このクラスターとして確保しておきたいリソースが、一定値以下であると判断された場合に、クラスター予約の状態が「過剰コミット」状態となり、管理コンソールから新規の仮想マシン作成や仮想マシンのノード間の移動などが制限されます。

続いて「クラスター予約状態」が「過剰コミット」となった場合の具体的な症状を見てみましょう。
過剰コミット状態では、管理コンソールからクラスター内に新たに仮想マシンを作成したり、配置したりする事ができなくなります。

大きなメモリを割り当てた仮想マシンの場合、ノードによってはこのように明示的に配置出来ない理由が記述されますが、

別のノードでは、単に「過剰コミット」としか表示されません。

ただし「過剰コミット状態」とは、あくまでも SCVMM がホスト クラスターを管理する場合の概念であり、実際の Hyper-V やフェールオーバー クラスタ ー機能には、このような概念がありません。つまり、SCVMM （＝管理コンソール）上でHAVM の移動や新規作成がエラーとなっても、Hyper-V マネージャや、フェールオーバー クラスター マネージャ上からは、問題なく仮想マシンの作成や配置ができます。

そもそも、クラスター予約の状態はどのようにして「過剰コミット」となるのでしょう。
それを知るにはまず、「クラスター予約（ノード数）」について考える必要があります。

このダイアログ上にある「クラスター予約（ノード数）」は、設定されたノード数が処理不能状態に陥った場合でも、クラスター内の仮想マシンが全て正常に稼動できるノードの数となります。つまり、「1」が設定された場合には、1台のホスト ノードが障害となった場合でも、残りの仮想マシンホストによって全ての仮想アプリケーションが実行可能である事を期待しています。
「0」を設定した場合には、「0台までの障害に耐えられる」ことになります。
これは、このクラスターでは（意図的なシャットダウンも含めて）障害となるノードを想定していない、という意味になります。
過剰コミットとは、こうして規定されたクラスター予約を基準に "残りのノードでは全ての仮想マシンが実行出来ない" と判定される状態を指します。
それでは、どのような計算によって、SCVMM が「過剰コミット」状態と判断するのでしょうか。

続いては、この点を見ていきましょう。

スロットの考え方

SCVMM がクラスターとして全仮想マシンを稼動可能かどうかの判断の基準となる尺度として、「スロット」というものさしがあります。
この「スロット」は、過剰コミットの計算の時にだけ使われる尺度ですので、他のオペレーションでは、まず出てきません。それだけに、理解しづらい概念の一つです。
スロットは、クラスター リソースとしての高可用性仮想マシン（以下 HAVM）に割り当てられた、最も大きなメモリ サイズになります。この際、HAVM が起動しているかどうかは問われません。SCVMM は、このスロットのサイズを基準にして、クラスター全体が全ての HAVM を稼動させることが可能かどうかを判断します。

それでは、具体的な例を基にして、どのようにして SCVMM が 「過剰コミット」と判断するのか見てみましょう。

「過剰コミット」の計算式

過剰コミットの計算式については、一部間違いがございました。正しい計算式につきましては、以下からご確認ください。 (2014. 06. 17 追記)

 [ 改訂版 ]SCVMM の落とし穴 その7 – 「過剰コミット」について

過剰コミットの計算は以下の様に行われます。

1. クラスター内の全ての HAVM の中で最大のメモリサイズが割り当てられた仮想マシンを見つけ、そのメモリ割り当てサイズを「スロット」のサイズとします。
2. 全てのホスト ノードでそれぞれ使用中のスロット数を数えます。全てのホスト ノードでそれぞれ未使用のスロット数を数えます。
   1. 各ノード毎に、HAVM をグループ化していきます。
   2. 一つのグループには、最低一つの HAVM が割り当てられます。
   3. 次の HAVM に割り当てられたメモリ サイズと、既にグループ化された　HAVM のメモリ サイズの合計が、1. で決定したサイズを超えない限り、
      同じグループとします。
   4. HAVM がなくなるまでグループ化を続けます。
   5. 最終的に出来たグループの数が このノードの使用中スロットの数になります。

3. 
   各ノード毎に、以下の式に照らして、未使用のスロット数を決定します。

   （物理メモリ量 – ホスト予約（メモリ） - ホスト ノード上の全HAVM に割り当てられたメモリ量の合計） / 1. で決定したスロット サイズ

4. それぞれのノード毎に、使用中、未使用のスロット数を合計し、最大値を見つけます。
   これが、このクラスターで確保しなければいけないスロット数となります。
   ここで注意すべき点としては、使用中、未使用のスロット数を別々に計算するため、その合計スロット数 x スロット サイズが必ずしも物理メモリ量の範囲には収まらない事がある点です。ですので、単純に物理メモリ量をスロット サイズで割ることでは、確保すべきスロット数が算出できません。
5. 3. で数えた未使用のスロット数を全ノード数からクラスター予約（ノード数）を引いた残りのノードで合計した最大値が、4. で数えた確保しなければいけないスロット数と同じか、少ない場合に、このクラスターは「過剰コミット」となります。

例として、以下の様な構成の4 ノードのクラスターを考えてみましょう。

クラスター予約（ノード数）は1です。
各ホストに設定されたホスト予約（メモリ）は、 既定値（512MB）とします。

1. このクラスターの HAVM の中で最も大きなサイズの HAVM は VM1と VM5 でサイズはどちらも 8GB ですので、「スロット サイズ」は 8GB に決定されます。
2. 各ノードで、このスロット単位に HAVM を割り当てていき、使用中のスロット数を数えます。
   VM1 が最初のスロットに割り当てられます。VM2 は、最初のスロットが VM1 の 8GB で既にいっぱいですので、次のスロットに割り当てられます。
   VM3 は4GB なので、VM2 とは同じスロットには入りません。次のスロットに割り当てられます。VM4 は2GB ですので、このスロットに割り当てられます。つまり、ノード 1 では、使用中スロットとして、 3 スロットであると決定されます。同様に以降のノードでは 3, 2, 1 スロットが決定されます。
3. 各ノードで前述の式に当てはめて、未使用のスロット数を数えます。
   N1: (32GB – 512MB – 20GB) / 8GB = 1
   N2: (32GB – 512MB – 18GB) / 8GB = 1
   N3: (32GB – 512MB – 10GB) / 8GB = 2
   N4: (32GB – 512MB – 8GB) / 8GB = 2
   ここで計算結果に小数以下が出た場合は切り捨てられる事に注意してください。
4. 使用中スロット数と未使用スロット数をそれぞれ合計した合計スロット数から、確保すべきスロット数を割り出します。
   N1: 使用中スロット 3 + 未使用スロット 1 = 4
   N2: 使用中スロット 3 + 未使用スロット 1 = 4
   N3: 使用中スロット 2 + 未使用スロット 2 = 4
   N4: 使用中スロット 1 + 未使用スロット 2 = 3
   クラスター予約（ノード数）は 1 ですので、最も必要スロット数の多い、N1, N2, N3 の中から1つを選択した、4 （スロット数）が 確保すべきスロット数となります。
5. 全ノード数 4 からクラスター予約（ノード数）1 を引いた、3 つのノードの組み合わせの中で、未使用スロットの数の合計が最大となる時の未使用スロットの合計 (1+2+2=) 5 が、確保すべきスロット数 4 よりも大きい為、このクラスターは、「過剰コミット」にはなりません。

ここで大事なのは、スロット サイズの計算やスロットの数の計算で、HAVM がオンラインであるか、オフラインであるかは問題ではない点です。
つまり、停止中の HAVM であっても、稼働中の HAVM であっても、同じように計算されます。

また、ディスク サイズについては一切考慮されません。これは HAVM では基本的にクラスター ボリュームに配置されるためです。

この「スロット」サイズに基づく、考え方は一見すると複雑に見えますが、要は最もリソースを消費するノードが障害となった場合に、他のノードが障害となったノードが抱えるリソースを全てランダムに割り当てられたとしても耐え得る事を保証します。

まとめ

もしホスト クラスターが「過剰コミット」となって仮想マシンの移動が行えなくなった場合には、一旦クラスター予約（ノード数）を０にして、仮想マシンに割り当てられたメモリを変更したり、仮想マシンの配置を変更したりしてみてください。
前述の様に、クラスター予約数は、障害が許容されるノード数ですので、「０」を設定すると、全てのノードがリソースとして利用できるようになり、過剰コミット状態は解消されます。しかしこれは、仮想マシンの移動や作成を一時的に実行するために使用して、クラスター予約を「０」のまま運用する事は避けてください。
また繰り返しになりますが、「クラスター予約」は、SCVMM 独自の管理機能ですので、クラスター予約の状態が「過剰コミット」状態となっていても、Hyper-V やフェールオーバー クラスターには影響しません。Hyper-V マネージャや、フェールオーバー クラスター マネージャ上から、仮想マシンのメモリ設定や再配置を行うことは可能ですので、適切な方法で過剰コミット状態を解消してください。

これまで良くあるお問い合わせをベースに、SCVMM 2008 R2 の管理者が陥りやすい障害事例とその解決方法を「SCVMM の落とし穴」シリーズとしてお伝えしてきましたが、今回で最後となります。今後も、修正プログラム情報など SCVMM 2008 R2 に関する情報は公開していく予定ですので、よろしくお願いします。 

参考情報

ブログ：ホスト クラスタの過剰コミット状態について
http://blogs.technet.com/b/askcorejp/archive/2010/02/12/3312460.aspx

TechNet： 高可用性の計画
http://technet.microsoft.com/ja-jp/library/cc764243.aspx

KB 2463008： How to determine if a cluster is over-committed in System Center Virtual Machine Manager 2008
http://support.microsoft.com/kb/2463008 (英語)

ブログ： How to determine if a cluster is over-committed in System Center Virtual Machine Manager 2008
http://blogs.technet.com/b/scvmm/archive/2010/11/17/how-to-determine-if-a-cluster-is-over-committed-in-system-center-virtual-machine-manager-2008.aspx (英語)

Tomoyuki Sumi