Part3：ユーザーインターフェースの変更いろいろ
日本ヒューレット・パッカード株式会社の中川明美です。
今回は、Part3の「ユーザーインターフェースの変更いろいろ」です。
vRealize Operations7.5から、カスタムダッシュボードの作成方法がアップデートされています。ウィジェット間の関係を指定する方法が容易になりました。ドラッグ操作で視覚的に設定できます。
このPartでは、復活した「ワークロード」タブ、メトリックを使用したカスタムダッシュボードの作成を例に進めます。
-Back Number-
#1：vROps バージョン 8.0 でできること①
#2：vROps バージョン 8.0 でできること②
#3：ユーザーインターフェースの変更いろいろ
#4：スーパーメトリックもウィザードを強化
#5：アプリケーションの管理①
#6：アプリケーションの管理②
#7：Workbench によるトラブルシューティング
#8：vROps 8.0 の vSAN ダッシュボード/ SDDC コンプライアンス
◆ワークロード◆
「ワークロード」タブが復活しました！！！
「CPU」と「メモリ」の構成サイズ(キャパシティ)が妥当であるかを分析する最初のステップとして使用していたため、うれしい限りです！
メモリのワークロードの内訳の数値は、「消費」から「デマンド」へ変更されています。
上図は「クラスタ」オブジェクトを選択したワークロード画面です。
クラスタのデマンドは80%を超え、赤色の警告表示になっています。しかしすべての仮想マシンのデマンドが高い値を示しているわけではありません。仮想マシンのメモリ構成サイズが適正サイズより大きい場合、このような結果になることがあります。エンドユーザー様の環境でもよく見かけるメモリ状況です。
仮想マシンのメモリサイズを最適な値に変更すれば、クラスタのデマンド値や使用量を下げることができます。
低パフォーマンスの仮想マシンの誤ったチューニング例をご紹介します。
クラスタやホストのメモリ使用量から、低パフォーマンスの原因をメモリと判断し、「ホストのメモリ増設」＆「仮想マシンのメモリ割り当て追加」があげられます。しかし、仮想マシンやゲストOSまで視点を広げると、仮想マシンのメモリサイズは十分であり、CPU数が原因だったということもあります。
今回の例のように、クラスタのデマンドは高い状態であっても、デマンドが高くない仮想マシンが存在する場合は、それらの仮想マシンを最適なメモリサイズへ変更することを検討ください。
仮想マシンを最適なメモリサイズに変更してホストのメモリ使用量が下がれば、パフォーマンスに影響を与えることなく、メモリリソースの最適化が可能です。
ここからは、1つの仮想マシンをフォーカスし、詳細に分析してみます。下図(赤色点線枠)から、「キャパシティ(メモリ構成サイズ)」「デマンド」「使用量」を比較します。この仮想マシンは「4GB」でメモリを構成しています。デマンド値は「3.49GB」です。過去6週間の平均使用量は「774.68MB」です。
仮想マシンはデフォルトでは実際の物理メモリ使用量に関わらず、構成(最大)サイズまで要求することが可能です。仮想マシンのデマンドに応じて、物理メモリが割り当てられるため、クラスタ(またはホスト)の使用率が高くなる傾向があります。
次に、「ゲスト使用量」「ゲストデマンド」「mem.standby.normal_latest」のメトリックを使用して、仮想マシンのメモリサイズが適正であるかを比較検討してみます。ゲストOSは、一般的なOSとアプリケーションの関係とは異なり、割り当てられた物理メモリを解放せず、最近使用していないメモリをフリーリストに移動します。物理メモリ不足時には、バルーニングによって、GuestOS未使用のメモリは再利用されます。
仮想マシンの「ワークロードのメモリ使用量」と「ゲスト使用量」の値は次の通りです。収集期間や計算方法は異なりますが、仮想マシンのワークロードのメモリ使用量 (約775MB) と、ゲスト使用量(最高値と最低値の平均値 は約754MB) は近い値です。仮想マシンが使用している物理メモリが、ゲストOSに割り当てられていることがわかります。
・仮想マシンのワークロードのメモリ使用量：774.68MB ※過去6週間の平均値
・ゲスト使用量： 809, 052.81KB (約790MB) ※過去7日間の最高値
「ゲスト使用量」と「ゲストデマンド(要求値)」を比較すると、ゲストデマンドはゲスト使用量の半分未満です。これらの値から、ゲストOSは割り当てられた物理メモリの半分も要求していないことがわかります。
・ゲストデマンド：322,784KB (約315MB) ※過去7日間の最高値
mem.standby.normal_latestの値を確認します。「ゲスト使用量」の半分近くあります。この値から、割り当てられた物理メモリの半分ほどが最近未使用であることがわかります。
・standby.normal_latest：415,732.28 (約406MB) ※過去7日間の最高値
これらの状況から、4GBのメモリの構成サイズを減らせるのではないかと検討できます。
継続的な監視を前提に、仮想マシンやゲストOSのメトリックから判断すると、たとえば1GBまで減らせるのではないでしょうか。仮想マシンの構成サイズを4GBから1GBへ変更すると、仮想マシンのデマンド(3.49GB)も減りますから、ホストの使用量を抑えられそうですね。
話は変わりますが、メトリックの画面上部にオブジェクトの関係性が表示されるようになりました。
また、以前は最近未使用のフリーリストの値を監視するために、「空きメモリ(上図の赤点線枠)」を使用していましたが、vRealize Application Remote Collectorによって収集される「standby.normal_latest」の方がより正確な値が得られそうですから、こちらを使用しました。
◆カスタムダッシュボード◆
「ダッシュボードの作成」では、最初にダッシュボードを構成するパーツをドラッグします。
画面右下から「ウィジェット」または「ビュー」に切り替え、パーツを追加することができます。
ここから、適正サイズを分析するためのダッシュボードを作成してみようと思います。
「オブジェクトリスト」で選択した仮想マシンの「メモリ」と「CPU」のメトリックを表示します。
ダッシュボード作成時には、メトリックの単位を変更することができます。
メモリは「KB」から「GB」へ、CPUは「KHz」から「GHz」へ変更しました。残念ながら、「standby.normal_latest」メトリックは変更することができませんでした。
▼相互作用
相互作用は、矢が付いているアイコンから、連携したいウィジェットにドラッグします。この設定により、リストで選択したオブジェクトに関するメトリックが表示されます。
できない操作は、ドラッグ後の線が表示されませんから、設定ミスを防ぐこともできます。オブジェクトリストの矢が付いていないアイコンからドラッグしても、線は表示されません。
▼「仮想マシンキャパシティ」の確認
「仮想マシンリスト」で選択した仮想マシンの「CPU」および「メモリ」のメトリックが表示されるカスタムダッシュボードが作成できました。
適正な構成サイズ(キャパシティ)は、デマンド値を参考に比較検討します。
【メモリ】
表示された期間の使用量のMAX値は約2.5GB、デマンドは0.5GB程度です。使用量よりデマンド値は低く、フリーリストにもメモリがある状況です。デマンド値を参考に1GBまで減らしたとしてもゲストOSの要求は十分に満たせそうです。構成サイズを減らす変更が心配なら、仮想マシンの設定の編集で「制限」を利用し、しばらく監視するのもよいかもしれません。
「構成サイズ」より「デマンド」が高い場合はメモリの追加を検討します。「デマンド」より「使用量」が低い場合は競合の発生を疑います。
【CPU】
CPUはデマンドおよび使用量も、物理コアの性能(2.2GHz)を上回っていませんから、現在の1vCPUで問題なさそうです。「デマンド」が性能を上回る場合は、vCPUの追加を検討します。
◆まとめ◆
vROpsは、Advanced以上のライセンスがあればダッシュボードのカスタマイズできますから必要な情報を限定して表示することができますね。また、vRealize Application Remote Collectorで収集されるゲストOSのメトリックを使用すれば、仮想マシンとゲストOSのデータを比較することも可能です。より確かな分析ができますね。
カスタム作成は以前のバージョンと比べ容易になってきましたから、ご自身の環境に合わせ準備頂けると、vROpsをより活用できると思います。
次回はスーパーメトリックの作成方法をご紹介します。スーパーメトリックの作成も簡単になりましたよ。
