[クラスタの競合] ダッシュボードは、vSphere クラスタのパフォーマンスに関するプライマリ ダッシュボードです。VMware 管理者やアーキテクト向けに設計されています。これは、監視とトラブルシューティングに使用できます。パフォーマンスの問題が発生していると判断したら、[クラスタ使用率] ダッシュボードを使用して、使用率が高いために競合が発生しているかどうかを調べます。
設計上の考慮事項
このダッシュボードは、標準作業指示書 (SOP) の一部として使用されます。これは日次使用用に設計されているため、画面は過去 24 時間のデータを表示するように設定されています。ダッシュボードには、選択したデータセンター内の仮想マシンのパフォーマンス メトリックが表示されます。
クラスタの使用率は [クラスタの競合] ダッシュボードには表示されません。使用率と競合の 2 つの概念を分ける必要があります。パフォーマンスとキャパシティは、2 つの独立したチームによって管理される別々の概念です。CPU とメモリも、個別に表示されます。一方に問題が発生しても、もう一方には問題が発生しない場合もあります。メモリのオーバーコミット率は低くなる傾向があるため、CPU のほうに問題がよく起こります。
すべてのパフォーマンス管理ダッシュボードに共通の一般的な設計上の考慮事項を表示するには、パフォーマンス ダッシュボード を参照してください。
ダッシュボードの使用方法
- 平均クラスタ パフォーマンス (%)。
- これは、IaaS 全体のプライマリ KPI です。IaaS が 5 分ごとにどのように実行されているかが表され、全体的なパフォーマンスの傾向がわかります。
- メトリック自体は、単にクラスタ KPI/パフォーマンス (%) メトリックの平均です。このパフォーマンス メトリックが今度は、クラスタ内で実行されているすべての仮想マシンから、仮想マシンのパフォーマンス/KPI 違反数のメトリックを平均します。したがって、100% の値は、クラスタ内で実行されているすべての仮想マシンが適切に処理されることを示しています。
- この KPI は環境内で実行されているすべての仮想マシンを考慮しているため、この数値は常に一定である必要があります。実生活では、株式市場指数がこれに類似しています。個々の株式は変動しやすいですが、指数全体は 5 分ごとで比較的一定しているはずです。
- メトリックの相対的な変動は、メトリックの絶対的な値と同じくらい重要です。絶対的な数値は希望するほど高くない可能性がありますが、長期間不満がない場合は、これを改善することに緊急のビジネス上の理由はありません。
- クラスタのパフォーマンス。
- すべてのクラスタが、過去 1 週間でパフォーマンスが低いクラスタ順に並べ替えられて一覧表示されます。この期間は変更できます。
- 最悪のパフォーマンスは、期間内で最低の数値になります。vRealize Operations は 5 分ごとにデータを収集するので、1 週間では 12 x 24 x 7 = 2016 のデータ ポイントとなります。この列には、これらの 2016 のデータ ポイントのうち最悪のポイントが表示されます。
- 2016 のデータ ポイントのうち 1 つの数値は外れ値になることがあり、これは別の数値で補完する必要がある場合があります。論理的には、これらの数値の平均が選ばれます。平均的なパフォーマンスを低下させるには、多くの条件も低くなる必要があります。平均を待機していると運用上の遅延が発生し、不満が高まります。パフォーマンスの監視にとっては、95 パーセンタイルが平均よりも優れたサマリになります。
- クラスタは 100% で動作し、計画どおりに機能を実行する必要があります。
- 表からクラスタを選択します。
- すべての健全性チャートには、選択したクラスタの KPI が表示されます。
- パフォーマンスにとっては、パフォーマンスの問題の深さと幅の両方を示すことが重要です。1 台または 2 台の仮想マシンに影響する問題は、クラスタ内のすべての仮想マシンに影響する問題とは異なるトラブルシューティングを必要とします。
- 深さは、仮想マシン数のうち最悪のものを報告することによって示されます。したがって、実行中のすべての仮想マシンの中で、[仮想マシン CPU Ready]、[仮想マシン メモリ競合]、[仮想マシン ディスク遅延] の最高値が表示されます。最悪の数値が良ければ、残りの仮想マシンを確認する必要はありません。
- 数千台の仮想マシンを含む大規模なクラスタでは、1 台の仮想マシンでパフォーマンスが低下することもありますが、仮想マシンのポピュレーションの 99.9% は問題ありません。この深度カウンタは、ほとんどの仮想マシンが正常であることを報告しない場合があります。状態が最悪な仮想マシンのみを報告します。ここで幅カウンタが必要になってきます。
- 幅カウンタは、パフォーマンスの問題が発生している仮想マシンのポピュレーションの割合を報告します。このしきい値は、早期警告を提供し、プロアクティブな運用を実現することを目的としているため、厳格に設定されています。
注意点
クラスタ使用率が低い場合でも、クラスタ内の仮想マシンのパフォーマンスが望ましくないこともあります。主な理由の 1 つとして、クラスタ使用率がプロバイダ レイヤー (ESXi) を見ているのに対し、パフォーマンスが個々の利用者 (仮想マシン) を見ていることが挙げられます。次の表には、考えられるさまざまな理由が示されています。
パフォーマンス管理の観点から見ると、vSphere クラスタは、リソースの最小論理構成要素となります。リソース プールと仮想マシン ホスト間のアフィニティは、より小さなスライスを提供できますが、運用上複雑なため IaaS サービスの確実な品質をもたらすことはできません。リソース プールでは、サービス クラスをはっきりと区別して提供できません。たとえば、ゴールドの料金はシルバーの 2 倍なので、2 倍の速度が提供されると SLA で規定しているとします。この場合、リソース プールでゴールドに 2 倍のシェアを割り当てる事ができます。ただし、シェアの割り当てを増やせば、CPU 準備中の時間を半分にできるかどうかを前もって判断することはできません。
DRS 自動化レベルなどの特定の設定と、多くのリソース プールの存在は、パフォーマンスに影響を与える可能性があります。選択したクラスタの関連プロパティを表示するプロパティ ウィジェットと、リソース プールを表示する関係ウィジェットを追加することを検討してください。
多数のクラスタが存在する大規模環境では、グループ分けを追加して、リストをより管理しやすくします。重要なクラスタに集中できるように、サービス クラスごとにグループ化します。
