MetroCluster構成のクラスタの動的なパフォーマンス イベントの分析

Unified Managerを使用して、パフォーマンス イベントが検出されたMetroCluster構成のクラスタについて分析することができます。クラスタの名前、イベントの検出時刻、および関連するBullyとVictimのワークロードを特定できます。

1. [イベントの詳細]ページを表示してイベントに関する情報を確認します。
2. イベントの説明を参照して、関連するワークロードの名前と数を確認します。
   例

   この例では、[MetroCluster リソース]アイコンが赤色で表示されており、MetroClusterのリソースが競合状態にあることがわかります。アイコンにカーソルを合わせると、アイコンの説明が表示されます。ページの上部に表示されたイベントIDに含まれているクラスタ名から、イベントが検出されたクラスタの名前を特定できます。

   
   

   

   
   
3. クラスタの名前とイベントの検出時刻を書き留めます。この情報は、パートナー クラスタのパフォーマンス イベントを分析するときに使用します。
4. グラフで、Victimワークロードの応答時間がパフォーマンスしきい値を超えていることを確認します。
   例

   この例では、マウスオーバーで表示される情報にVictimワークロードが表示されています。レイテンシグラフを確認すると、関連するVictimワークロードの全体的なレイテンシのパターンは一貫していることがわかります。Victimワークロードの異常なレイテンシによってイベントがトリガーされた場合でも、レイテンシのパターンが一貫していれば、ワークロードのパフォーマンスは想定範囲内に収まっており、I/Oの一時的な上昇によってレイテンシが増加したことでイベントがトリガーされた可能性が考えられます。

   
   

   

   
   

   これらのボリュームのワークロードにアクセスするアプリケーションでクライアントに最近インストールしたものがある場合は、そのアプリケーションから大量のI/Oが送信されたことが原因でレイテンシが増加した可能性があります。ワークロードのレイテンシが想定範囲内に戻ってイベントの状態が廃止に変わり、その状態が30分以上続くようであれば、このイベントは無視しても問題がないと考えられます。イベントが新規の状態のまま継続する場合は、イベントの原因となった問題が他にないかどうかをさらに詳しく調べます。

5. [ワークロード スループット]グラフで、[Bully ワークロード]を選択してBullyワークロードを表示します。
   Bullyワークロードがある場合は、ローカル クラスタの1つ以上のワークロードがMetroClusterのリソースを過剰に消費しているためにイベントが発生した可能性が考えられます。Bullyワークロードでは書き込みスループット（MBps）が突出します。

   このグラフには、ワークロードの書き込みスループット（MBps）のおおまかなパターンが表示されます。書き込みMBpsのパターンから異常なスループットを特定できた場合、そのワークロードがMetroClusterのリソースを過剰に使用している可能性があります。

   イベントに関連するBullyワークロードがない場合は、クラスタ間のリンクの健全性の問題やパートナー クラスタのパフォーマンスの問題がイベントの原因として考えられます。Unified Managerを使用してMetroCluster構成の両方のクラスタの健全性を確認できます。また、パートナー クラスタのパフォーマンス イベントの確認と分析もUnified Managerで実行できます。