【6】VMware環境における性能分析事例

【6】VMware環境における性能分析事例

VMware環境において、負荷の高いESXホストとVMを発見
vCPUの割当の見直しと、VMotionを実施
 


きっかけ:VMwareで集約したシステムの稼働状況を把握したい

  • VMwareを使用し、様々なシステムを集約
  • 今後も集約を進める予定であり、継続的に仮想環境の稼働状況を把握する必要性を感じている
  • VMwareを導入後、全く稼働状況を確認していない

システム部門の対応

  • 現状を確認するため、IIMへ現状評価を依頼
  • ES/1 CSシリーズとコンサルタントにより現状評価実施

システム構成

ESXホスト ESX Version CPUコア  メモリ(MB) VM数 クラスタ
HostA 4.0.0 8CPUs x 2.933GHz 73718.18 13 VSC01
HostB 4.0.0 8CPUs x 2.933GHz 73718.18 15 VSC01
HostC 4.0.0 8CPUs x 2.933GHz 73718.18 18 VSC02
HostD 4.0.0 8CPUs x 2.933GHz 73718.18 11 VSC02

STEP1:チューニングヒントによる問題点の特定

下記二点の問題点をチューニングヒントにより発見

  • 物理CPUの枯渇
    ESXホスト(HostC)のCPU使用率が高い
    →90%を超えている

  • vCPUの枯渇
    仮想マシン(clubmember02、clubmember01)のvCPU使用率が高い
    →90%を超えている


STEP2-1:現状確認 物理CPUの枯渇

  • チューニングヒントで指摘されたESXホストのCPU使用状況をグラフで確認
    他のホストに比べ、HostCの1:15前後のCPU使用率が高いことを発見


STEP2-2:現状確認 CPUReadyの発生状況の確認

  • HostCのCPUReadyの発生状況を確認 
    CPU使用率の高い、1:15前後に10~15%のCPUReadyが発生していることを発見




STEP2-3:現状確認 vCPUの枯渇状況の確認

  • VM毎のvCPU使用率を確認
    vCPU使用率の高いVMを発見


STEP2-4:現状確認 vCPUの余剰状況の確認

  • VM毎のvCPU使用率を確認
    余剰vCPUが多いVMを発見


システム部門の反応

  • CPUReadyが発生している時間が業務時間外(1:15前後)のため、発見できずにいた
  • HostC内には、海外からも頻繁にアクセスされるホームページサーバが含まれているため、夜間であっても遅延は許されないので改善をしたい

STEP3-1:対応策の提案

  • VMotionの実施
    物理CPUが枯渇しているESXホストから、余裕のあるESXホストへのVMotionを提案
  • vCPU割当の追加
    vCPUが枯渇しているVMについて、vCPUの追加を提案
  • vCPU割当の削減
    vCPUが余っているVMについて、vCPUの削減を提案


STEP3-2:対象の決定

グラフより下記を決定
  • VMotionすべきVMの決定(図5)
    top1、top2
    移行元のピーク時間(1:15前後)に使用量が多く、移行先ESXホストのピーク時間(2:15)に使用量が少ないVMが候補となります。移行先候補は、同じクラスタに所属するESXホスト
  • VMotion先のESXホストの決定(図1、図6)
    HostD
    稼働VMの数が少なく、1:15前後に使用量が少ないESXホストが候補となります
    HostDで稼働するVM毎のCPU使用量を確認
    VM追加によってCPU使用量が増えても問題ないことを確認
  • vCPUの割当を追加すべきVMの決定(図3)
    clubmember01、clubmember02、yakuin、send
    仮想CPU使用率が90%を超えたインターバルがあるVM
  • vCPUが余剰しているCPUの特定(図4)
    glass1、glass2、top1、taga2、taga1、doshida3、seki3、seki2、seki1、kita2、kita3、hikawa1、doshida1、hikawa2、hikawa3、eko2
    最小余剰vCPUが1.5個以上のVM

まとめ

  • 今回の評価により、これまで把握していなかった性能劣化と、負荷の偏りを発見することができました
  • 構成変更の多いVMware環境では、継続的な稼働状況の把握と、稼働状況に基づいた、VM追加、リソースの割当の判断が求められます
  • 本事例のお客様も上記を強く認識され、ES/1 NEO CSシリーズを使用して継続的な稼働管理を実施されることになりました