1回目：仮想基盤のパフォーマンスは使用率だけでは図れない

– Back Number –
#1：仮想基盤のパフォーマンスは使用率だけでは図れない
#2：アラートからブレイクダウン
#3：仮想マシンのリストはカスタムビューで
#4：6.7バージョンはメトリックの活用がポイント
#5：vSAN運用管理者にはvROpsは欠かせないツール
日本ヒューレット・パッカード株式会社の中川明美です。
VMware vRealize Operations Manager 6.7が2018年4月にリリースされましたね。
6.7を操作した感想は、「仮想基盤の運用管理に必要なメトリック (カウンタ) にフォーカスしている！」です。フォーカスされていると、覚えるべき項目が少なくなり、初めて仮想基盤の運用に携わる方は助かりますね。
6.7バージョンの一番の変更点は、「分析」タブがなくなったことです。分析タブがなくなったのは残念ですが、初心者に優しいダッシュボードが準備されています。
#1：仮想基盤のパフォーマンスは使用率だけでは図れない
#2：アラートからブレイクダウン
#3：仮想マシンのリストはカスタムビューで
#4：6.7バージョンはメトリックの活用がポイント
ここ数年vROpsに関わるお仕事で、現在も物理マシンと同様の手法で仮想マシンを監視されていらっしゃる方をお見受けします。よくあるのは「使用率」のみを監視する方法です。
仮想基盤は、「キャパシティ」と「パフォーマンス」の2つの視点で監視する必要があります。「使用率」に加え、仮想基盤特有のメトリックと合わせて監視するのがポイントです。
数バージョン前からVMware vRealize Operations Manager (以降はvROps) のワークロードには、CPUは「デマンド」、メモリは「消費 (実際に使用された物理メモリ量) 」を分析結果に表示しています。これらのメトリックを調査するのは仮想マシンのパフォーマンスを最適化する前提となります。標準で提供されるVMのトラブルシューティングダッシュボードでは、使用率と仮想基盤に特化するメトリックが並べて表示されています。

仮想基盤において、なぜ使用率のみでは正しい判断ができないのでしょうか。コンピュータリソースのCPUとメモリを例に検証します。

◆ワークロード◆

下図は、vROps 6.6まで提供されていた、「分析」タブの「ワークロード」画面です。
この画面はデータセンターを選択しています。ESXiホスト2台分で、CPUのキャパシティは16.76GHz、メモリは32GBです。

<CPU>
ESXiホストの使用率は23.2%です。物理マシンの使用率を監視するならば、問題なしと判断されます。しかしこの画面から2台の仮想マシンのワークロードが高い状態であることがわかります。この画面だけでは根本原因はわかりませんが、ホストの「デマンド」が「使用量」より高い状態であることが1つのヒントになります。
参考までに、この画面でオーバーヘッドが高いのは、CPUの省電力機能が原因です。
KB: Virtual machine application runs slower than expected in ESXi (1018206)

<メモリ>
ESXiホストの使用率は82.48%です。物理マシンの使用率を監視するならば、高い使用率から問題ありと判断されるのではないでしょうか。しかし仮想マシンのワークロードは高くありません。この結果から、仮想マシンからのデマンド(要求)により、物理マシンの多くの物理メモリが消費されていることがわかります。
ESXiホストの使用率は90%を超えないように監視するのがポイントです。
仮想マシンからの要求により割り当てられた物理メモリの回収の発生タイミングは、次のBlogにまとめられています。
https://blogs.vmware.com/vsphere/2012/05/memminfreepct-sliding-scale-function.html
ESXiホストに96GBの物理メモリが搭載されていた場合、バルーニングが発生するタイミングは残りメモリが10244.26MBになった時です。このスライディングスケールというアーキテクチャを知ると、90%を超えないように監視するというのも納得できますね。
そして物理マシンの高いメモリ使用率が単純に仮想マシンのパフォーマンスに影響を与えるわけではないこともわかると思います。

CPUの高いワークロードの原因を特定しましょう。

◆仮想マシンのCPU診断リスト◆

下図は、vROps 6.6まで提供されていた、「仮想マシンのCPU診断リスト」ビューの画面です。
高いワークロードの原因は、高い競合値です。仮想CPUに物理CPUが割り当てられず、待ちが発生すると、高い競合値となります。
さらにこのBlogのテーマである使用率を確認します。VM-2を例にします。
VM-2のCPUキャパシティは約2.8MHzです。使用量を確認すると、約1.4MHzですから、使用率は50%です。低い使用量は物理CPUが割り当てられないためと考えられます。

上記から、物理マシンや仮想マシンの使用率のみでは、仮想基盤のパフォーマンスを分析するための判断材料が不足していることはおわかりになるかと思います。
次にデマンドの値も確認しましょう。競合値が特に高い、2つの仮想マシンでは、「キャパシティ」よりも「デマンド」の方が高い値が表示されています。これも物理CPUが割り当てられないために、リソース要求 (デマンド) が高くなっているためです。

◆「VMのトラブルシューティング」ダッシュボード◆

vROps 6.7では、「VMのトラブルシューティング」ダッシュボードが標準で提供されています。
このダッシュボードの内容から、「慣れるまではこのダッシュボートを活用すれば問題ないよ」というメッセージを感じます。私が個人的にお勧めする初心者に優しいダッシュボートです。
左側のリストから仮想マシンを選択すると、仮想マシンの構成情報、アラート、ワークロード、稼働ホスト、格納先データストア、VMware Toolsのバージョンを一覧表示できます。

ダッシュボードをスクロールすると、左側に各リソースの使用量 (CPUはデマンド/メモリはワークロード/ディスクはIOPS総数/ネットワークは使用率)、右側にパフォーマンスに影響を与えるメトリックが表示されています。そのメトリックには、CPUとメモリは競合、ディスクは遅延、ネットワークはドロップパケット数が選択されています。

複数の画面を遷移せずとも、このダッシュボードから、パフォーマンスに影響を与える原因と対応方法のおおよその検討をつけることができます。
CPUを例にします。CPUのデマンドが高くかつ競合が高いのであれば、パフォーマンスに問題があると判断し、他のESXiホストへの移行を検討します。CPUのデマンドが高くかつ競合が低いのであれば、キャパシティに問題があると判断し、その仮想マシンの仮想CPUの追加を検討します。

◆「運用概要」ダッシュボード◆

「運用概要」ダッシュボードで表示される上位15でも、「使用率」ではなく、「CPU競合」「メモリ競合」「ディスク遅延」が選択されています。このダッシュボードも標準で提供されています。
なぜ使用率 (使用量) が選択されていないのかはもうおわかりですよね！

競合の詳細な原因や、ディスク遅延およびネットワークのドロップの発生原因は、「ビュー」または「メトリック」を使用して分析します。こちらについては、以降の回でご紹介します。

◆まとめ◆

仮想基盤のパフォーマンスに影響を与えるメトリックには仮想基盤特有のメトリックがあるにも関わらず、物理基盤と同様の方法で監視されている方がいらっしゃるのが気になっていました。それをご存じないために、物理基盤と同様の方法で監視されるのではないかと推測します。vROpsで仮想基盤に特化したメトリックが表示されていても、活用するには少々ハードルが高いというお話も私の耳には入っていました。
「VMのトラブルシューティング」ダッシュボードを見た時に、「そうそう、このメトリックが必要なの！」とうれしく思いました。仮想基盤の運用に慣れていない方も、VMのトラブルシューティングダッシュボードを活用すれば、一時切り分けが可能です。
vROps 6.7から、初心者が活用することを意識した構成になっていると個人的に感じています。知識習熟度レベルによって、使い分けられたら費用対効果もあります。
次回は、アラート対象のオブジェクトの原因を探る方法をご紹介します。