CPUリソースを割り当てたり、リソース量を制限したりする方法の1つに、「シェアの割り当て」があります。VMに与えたシェア数の比率に応じてプロセッサ・スケジュールを組むことで、CPUリソースの割り当て量を制御します。
この方法では、各VMに特定のシェア数を与えます。VMが実際に獲得するCPU時間は、利用できる全シェア数のうち、与えられたシェアの割合と、現在のESX ServerホストにおけるCPUリソースの利用状況によって決まります。
シェアとは、本質的にサービスの保証になります。2つのVMを稼動させ、一方のVMに2倍のCPUシェアを与えれば、そのVMに2倍のCPUサイクルが割り当てられますが、両方のVMともアクティブにすることができます。
デフォルトでは、いずれのシングル・プロセッサVMにも1,000シェアが割り当てられ、リソースへのアクセス能力に差はありません。
例えば、テスト中、VM IDが151であるVM0のステータスは、次のようになりました。
%less -S /proc/vmware/vm/151/cpu/status
vcpu vm type name uptime status costatus usedsec syssec wait
151 151 V vmm0:Exchang 1364647.127 WAITB NONE 74991.611 419.716 IDLE
waitsec idlesec readysec cpu affinity htsharing min max shares
1275933.220 1270388.050 3928.922 2 0,1,2,3 any 0 100 1000
- VCPU
- 仮想CPUのID（識別子）
- VM
- 仮想マシンのID
- Type
- VCPUの種類:「V」は、仮想マシンを示す
- Name
- VMに付けられた表示名
- Uptime
- VMをパワーオンしてからの経過時間
- Status
- 現在のVCPUの実行状況: 実行（RUN）、実行可能（READY）、イベント待機(WAITまたはWAITB)、終了（ZOMBIE）
- Cosststus
- 現在のSMP VMに対する協調スケジュールの状態: ユニプロセッサVMの場合「NONE」
- usedsec
- vcpuが使用したプロセッサ時間の累計
- syssec
- vcpuが使用したシステム時間の累計
- wait
- 現在vcpuが待機しているイベントの種類
- waitsec
- vcpuの待機時間の累計
- cpu
- 現在のvcpuプロセッサの割り当て
- htsharing
- ハイパースレッディングのシェア設定
- Min
- VM用に最小限確保されるプロセッサの割合（%）
- Min
- VM用に確保されるプロセッサの上限（%）
- Shares
- VMに割り当てられたCPUシェア数
表1：この出力結果の説明
VM0には、前述のとおりデフォルトの1,000シェアが割り当てられており、このVMのステータスは、イベント待ちとなっています。VMに割り当てたCPUシェア数を変えるとどのような影響が出るのか調べるため、次のコマンドを実行し、シェア数を2,000に増やしました。
# proc 2000 > /proc/vmware/vm/151/cpu/shares
次に、第13回で説明したシナリオ2と同じテストを実行しました。シナリオ2では、VM0の方がVM1より頻繁にCPUリソースにアクセスしていましたが、このテストでは、VM1の方が高いVCPU 利用率を示しました。VM1のVCPU利用率の方が高くなった理由は、VM0の利用できるリソース量が与えられたプロセッサ・シェア数に応じて増え、余裕ができたからです。
図1：VMに割り当てたCPUシェア数とCPU利用率の関係
図1のグラフを見ると、VM0とVM1は同じ処理量を実行しているにも関わらず、VM0のVCPU利用率はVM1より低いことがわかります。このようにシェアを動的に割り当てられる能力は、1台のESX Serverホスト上で優先度の高いVMと低いVMを混在させるときに便利です。今回のテストで実証されたように、優先度の高いVMのシェア数を増やすか、優先度の低いVMのシェア数を減らすことで、リソース要件を満たすことができます。
|
