[クラスタ キャパシティ] ダッシュボードでは、カスタマイズの選択肢を提供することで、さまざまな形での情報の可視化を実現します。このダッシュボードを使用して、注意が必要なクラスタを明らかにできます。[クラスタ キャパシティ] ダッシュボードはキャパシティ チーム向けに設計されており、オペレーション チーム向けではありません。長期およびトップダウンのビューが用意されており、キャパシティ チームは今後の拡張や、旧式のハードウェア テクノロジーの更新を計画できます。

設計上の考慮事項

キャパシティ管理のすべてのダッシュボードに共通した一般的な設計上の考慮事項については、 [キャパシティ] ダッシュボード を参照してください。 [クラスタ キャパシティ] ダッシュボードは、キャパシティに影響を与える次の要因を考慮します。
  • 競合
  • 使用率
  • 割り当て
  • 再利用

競合は、パフォーマンスを直接測定するので、含まれています。クラスタで既存のワークロードを処理できない場合は、新しいワークロードを追加しないでください。定義上、クラスタに新しいワークロード用の領域がない場合、そのキャパシティはいっぱいです。理想的なシナリオとしては、クラスタを 100% の使用率で、競合を 0% として実行する必要があります。この場合、クラスタの生産性が向上し、投資が適切に使用されます。

使用率は、リソースの実際の生の使用量を反映しているので、キャパシティの主要カウンタになります。使用率が高い場合、クラスタがいっぱいであるためにオーバーコミット率が目標よりはるかに低いかどうかは関係ありません。また、使用率は非常に低くなってはなりません。

割り当ては、すべてのワークロードが本物とは限らないので、使用率を補完します。次のような需要が突然発生する場合があります。
  • 新たにプロビジョニングされた仮想マシン
  • 災害復旧
  • サイズ不足の仮想マシン
  • 自動スケール仮想マシン (ロード バランサの背後にある Web サーバ グループ)

再利用は、決定に影響を与える可能性があり、浪費が一般的である可能性があるために含まれます。キャパシティは低くなる場合がありますが、大量のまとまった浪費を再利用できる場合、ハードウェアの購入を延期できます。

浪費は新しい色で表示されます。濃い灰色は、キャパシティが使用されていないときの浪費を示します。低使用率によるパフォーマンスの問題は、ほかの箇所のボトルネックによって発生する可能性があります。

ダッシュボードの使用方法

[クラスタ キャパシティ] ダッシュボードは階層化されており、ダッシュボードで上から下に進むにつれ徐々に詳細が示されます。

最初のレイヤーには 2 つの分布チャートが表示されます。
  • [残りキャパシティによるクラスタ][残り時間 (日数) によるクラスタ] の横棒グラフは、残りキャパシティと残り時間に基づいて、クラスタの概要を示します。キャパシティが不足しているという理由だけで、時間が切れているわけではありません。
  • 2 つの横棒グラフを合わせて使用します。残りキャパシティが少なく、残り時間が長い状況が理想的です。これは、リソースが費用対効果に優れており、期待どおりに機能していることを意味します。
2 番目のレイヤーにはヒートマップが表示されます。
  • 3 つのヒートマップは、[残り時間][残りキャパシティ][残り仮想マシン] です。
  • 使いやすくするために、クラスタ サイズは一定の値にされます。クラスタ サイズが標準化されていない場合は、ESXi ホストの数を使用してサイズの違いを表示することを検討してください。
3 番目のレイヤーにはテーブルが表示され、選択されたクラスタの詳細を表示したその他のウィジェットが伴います。
  • [クラスタ キャパシティ リスト] ウィジェット。注意が必要なクラスタがある場合は、クラスタを選択して、関連する詳細を表示します。
  • 使用率は 1 週間ではなく 3 か月で表示されます。表示されている平均値は 1 日あたりのもので、1 時間あたりではありません。また、有効な RAM ではなく使用済みの RAM に焦点を当てて表示されています。
  • 予約は、クラスタの効率に影響を与える可能性があります。クラスタ サイズが異なる場合、相対値を表示することで予約数を補完します。
  • 新たにプロビジョニングされた仮想マシンがまだアクティブでない可能性があるため、仮想マシンの数が表示されます。このような仮想マシンは、数か月間未使用のままの場合があるため、アイドル状態に間違えられることがよくあります。仮想マシンが増加しているにもかかわらず、残りの需要が低い場合は、今後需要が発生する可能性を示す兆候となります。
  • ワークロードは低くできますが、オーバーコミット率は高くならないのでしょうか? 新たにプロビジョニングされた仮想マシンは、数週間でアイドル状態になり、突然増加する傾向があります。[仮想マシン数] ウィジェットを使用して、最近の成長があったかどうかを確認します。
  • キャパシティが低い理由を確認できます。その理由は実際のワークロードにありますか、それとも単に予約にありますか?

注意点

  • [ESXi キャパシティ] ダッシュボードへのドリルダウンを追加します。このドリルダウンを開始するための論理的な場所は、[クラスタ キャパシティ リスト] ウィジェットにあります。このウィジェットをターゲット ダッシュボードの ESXi ホストの表にリンクします。
  • 画面の領域に余裕がある場合は、クラスタ サイズの情報を追加します。クラスタ サイズを追加します。規模が小さいクラスタはオーバーヘッドが高く、大規模な仮想マシンをサポートできないため、キャパシティの観点からは効率が悪くなります。
  • ピークは、ESXi ホストのうち最も高いものとして定義されます。ピーク値がクラスタ全体の平均よりも大きい場合は、不均衡につながり、キャパシティの最適化が不十分である一般的な理由となります。ピーク値を追加して、平均使用率を補完できます。不均衡の原因を特定して、最適化します。
  • ピークを追加して平均使用率を補完します。これにより、最適とはいえないキャパシティの一般的な理由である不均衡に焦点を当てられます。不均衡の原因を見つけます。これが最適化の機会になる可能性があります。
  • このダッシュボードは、独自のキャパシティ モデルを必要とするため、ストレッチ クラスタ向けには設計されていません。