Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2020年1月

月別アーカイブ: 2020年1月

vROps 8.0 はオンプレミスからクラウドまで Part4

Part4:スーパーメトリックもウィザードを強化

日本ヒューレット・パッカード株式会社の中川明美です。
今回は、Part4の「スーパーメトリックもウィザードを強化」です。
vRealize Operationsでは「メトリック」を構成(作成)する方法が複数あります。今回は「メトリック構成」と「スーパーメトリック」をご紹介します。どちらも「管理」メニューの「構成」から始めます。vROps 7.5から、スーパーメトリックはウィザード(アシスト)機能が強化されています。
「メトリック構成」のメトリックはダッシュボードのウィジェットを使用し、「スーパーメトリック」は「環境」メニュー内でデータ表示します。

ー Back Number ー
#1:vROps バージョン 8.0でできること①
#2:vROps バージョン 8.0でできること②
#3:ユーザーインターフェースの変更いろいろ
#4:スーパーメトリックもウィザードを強化
#5:アプリケーションの管理①
#6:アプリケーションの管理②
#7:Workbenchによるトラブルシューティング
#8:8.0のvSANダッシュボード/SDDCコンプライアンス

「メトリック構成」からご紹介します。

◆メトリック構成◆

「メトリック構成」は、「管理」メニューから、メトリック用の新規XMLファイルを作成することもできますし、既存のメトリックを活用することもできます。既存のメトリックを活用することから始め、メトリック構成(作成)に慣れるのもお勧めです。

▼既存メトリックの使用事例

下図は、「VMのトラブルシューティング」ダッシュボードの編集画面です。
組み込みの「VMのトラブルシューティング」ダッシュボードでは、既存の「Dash-VM-Troubleshooting-Utilization」が使用されています。

▼Dash-VM-Troubleshooting-Utilizationの内容確認

メトリックのXMLファイルの内容から、CPUのしきい値を確認できます。黄色は「警告レベル」、オレンジ色は「緊急レベル」、赤色は「クリティカルレベル」を示します。

ダッシュボードを確認すると、CPUは指定された%(しきい値)に線が引かれています。
メモリのしきい値はメトリックの構成で指定していませんが、おそらく、「アラート」メニューの「アラート設定」-「シンプトンの定義」の仮想マシンのメモリワークロードの値が反映されているように思われます。仮想ディスクとネットワークは、ワークロードのシンプトンがありませんから、しきい値の線は表示されていないようです。しきい値に関してはドキュメントに明示的な記述がありませんからこれらは推測です。
メモリや仮想ディスク等のしきい値を設定したいのであれば、「管理」メニューの「構成」-「メトリック構成」で、「Dash-VM-Troubleshooting-Utilization」メトリックの内容をコピー元にして、カスタムメトリックを作成してみてください。

次に、「スパーメトリック」をご紹介します。

◆スーパーメトリック◆

スーパーメトリックは、1 つ以上のメトリックを含む数式であり、ユーザー自身が設計するメトリックです。メトリックの組み合わせを単一のオブジェクトまたは複数のオブジェクトから追跡する必要がある場合に使用します。1 つのメトリックで監視できない場合、スーパー メトリックで定義します。
こちらは、後でご紹介するサンプルのスーパーメトリック「Put Host System child and parent ResourceKinds in alert blackout when host is in Maintenance Mode」です。メトリックの説明文を読むと、ResourceKindから発生する、vROps内のアラートを自動的に制御するメトリックだそうです。メンテナンス時のアラート表示を制御しています。
「depth」は階層を表します。例えばこのスーパーメトリックをESXiホストに適用した場合、depth=0ならESXiホストを対象とします。1なら仮想マシン、-1ならクラスタ、-2ならデータセンターです。負の値は子オブジェクトの親を対象とする場合に使用します。スーパーメトリックでは、このサンプルのように複数のオブジェクトを定義することができます。

※このメトリックをvROps 8.0で使用するには、式の編集が必要です。

ここからは、アシスト機能を使用して、1台のホスト上の全Guest OSのメモリデマンドの平均値を表示するスーパーメトリックを作成します。

▼新規スーパーメトリックの作成

「管理」メニューの「構成」-「スーパーメトリック」で、「新規スーパーメトリックの作成(緑の十字のアイコン)」をクリックします。

「基本情報」で名前や説明を入力し、次の「数式の作成」でメトリックの数式を構成します。「関数」のリストから「avg」を選択します。

「avg()」の()内にマウスカーソルを移動し、「Ctrl + スペース」を押します。「アダプタタイプ」→「vCenter Server アダプタ」→「仮想マシン」の順に選択します。()内で「仮想」と入力後、「Ctrl + スペース」を押し、「仮想マシン」を表示することも可能です。

(仮想マシン: )のセミコロンの右にマウスカーソルを移動し、「Ctrl + スペース」を押します。リストから、「メトリック」→「メモリ|ゲストデマンド(KB)」の順に選択します。

「プレビュー」で、任意のホストを選択し、内容を確認します。

「オブジェクトタイプへの割り当て」で、どのオブジェクトを選択したら、作成したスーパーメトリックが表示されるかを選択します。ここでは vCenter Server アダプタ の ホストシステム を選択しました。

最後にこのスーパーメトリックをポリシーで有効にします。ここではデフォルトのポリシーで有効にしました。

▼スーパーメトリックの表示

「環境」メニューでESXiホストの「メトリック」を選択します。「プレビュー可能なスーパーメトリックの表示」アイコンをクリックします。

作成したスーパーメトリックを右下の画面に表示(ダブルクリックまたはドラッグ)します。
画面上のオブジェクトで「仮想マシン」をダブルクリックすると、選択したESXiホスト上の仮想マシン名を確認することもできます。



▼スーパーメトリックを拡張する

今回作成したスーパーメトリックはシンプルなものですが、where句を追加して同じオブジェクトの異なるメトリックを参照することもできます。where句の例はドキュメントの「スーパーメトリックを拡張する」で確認できます。

https://docs.vmware.com/jp/vRealize-Operations-Manager/6.7/com.vmware.vcom.config.doc/GUID-2290A3B5-3C4B-4EA8-BB52-B0C7DFE7458B.html

◆vRealize Operations Sample Exchange◆

最後に「vRealize Operations Sample Exchange」をご紹介します。

https://vrealize.vmware.com/sample-exchange/

このサイトから、カスタムダッシュボードやスーパーメトリックのサンプルをダウンロードできます。サードベンダーのサンプルもあります。ダウンロードしたサンプルをインポートして、活用するのもよさそうですね。

◆まとめ◆

今回はメトリックを中心にご紹介しました。既存のメトリックを活用したり、新規のメトリックを作成したり、複数の方法でカスタムメトリックを構成できます。ダッシュボード作成時にメトリックを作成することもできます。
運用をメインにされているエンジニアの方には、Logと同様にメトリックは、「いつ」「何が起きた/起きている」は重要な情報ですよね。メトリックの画面から、各オブジェクトの関係性も確認できますから、関係するオブジェクトに問題が起きているのでは?とあたりをつける場合にも活用できます。次は「アプリケーションの管理」です。前提条件の確認が必須です!!

vROps 8.0 はオンプレミスからクラウドまで Part3

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をより活用できると思います。
次回はスーパーメトリックの作成方法をご紹介します。スーパーメトリックの作成も簡単になりましたよ。