QoSポリシー グループの調整が原因の動的なパフォーマンス イベントへの対処

Unified Managerを使用して、ワークロードのスループット(MBps)を調整しているサービス品質(QoS)ポリシー グループが原因のパフォーマンス イベントを調査できます。この調整によって、ポリシー グループ内のボリューム ワークロードの応答時間(レイテンシ)が増大することがあります。イベント情報を使用して、ポリシー グループに新しい制限値を設定して調整を停止する必要があるかどうかを判断できます。

開始する前に

手順

  1. [イベントの詳細]ページを表示してイベントに関する情報を確認します。
  2. [説明]で、調整の影響を受けたワークロードの名前を確認します。
    注:調整の結果、あるワークロードは自身のVictimになるため、VictimとBullyに同じワークロードが表示されることがあります。
  3. テキスト エディタなどのアプリケーションを使用して、ボリュームの名前を記録します。
    あとでボリューム名で検索できます。
  4. [ワークロード レイテンシ]および[ワークロード アクティビティ]のグラフで、[Bully ワークロード]を選択します。
  5. グラフにカーソルを合わせると、ポリシー グループに影響を与えている上位のユーザ定義ワークロードが表示されます。
    偏差が最も大きく、調整の原因となったワークロードがリストの最上位に表示されます。アクティビティは、ポリシー グループ制限に対して各ワークロードが使用している割合です。
  6. 上位のワークロードの[パフォーマンス / ボリュームの詳細]ページに移動します。
  7. [データ内訳の基準]を選択します。
  8. [レイテンシ]の横のチェック ボックスをオンにして、レイテンシの内訳グラフをすべて選択します。
  9. [IOPS]で、[読み取り / 書き込み / その他]を選択します。
  10. [送信]をクリックします。
    内訳グラフは[レイテンシ]グラフと[IOPS]グラフの下に表示されます。
  11. [ポリシー グループの影響]グラフを[レイテンシ]グラフと比較して、イベント発生時に調整の何パーセントがレイテンシに影響したかを確認します。
    ポリシー グループの最大スループットが1秒あたり1,000op/secの場合、ポリシー グループ内のワークロードの合計がこの値を超えることはできません。イベントの発生時、ポリシー グループ内のワークロードの合計スループットが1,200op/secを超えたため、ポリシー グループのアクティビティが1,000op/secに調整されました。[ポリシー グループの影響]グラフからは合計レイテンシの10%が調整に起因していることがわかり、調整が原因でイベントが発生したことを確認できます。
  12. クラスタ コンポーネント別の合計レイテンシを示す[クラスタ コンポーネント]グラフを確認します。
    レイテンシが最も高いのはポリシー グループで、調整が原因でイベントが発生したことを確認できます。
  13. [読み取り / 書き込みレイテンシ]グラフと[読み取り / 書き込み / その他]グラフを比較します。
    どちらのグラフでも、レイテンシが高い読み取り要求が多数ある一方で、書き込み要求の数は少なくレイテンシも低くなっています。これらの値からは、レイテンシを増加させた大量のスループットまたは処理の有無を判断できます。これらの値は、スループットまたは処理数にポリシー グループの制限を設定するかどうかを決定する際に使用できます。
  14. OnCommand System Managerを使用して、ポリシー グループの現在の制限値を1,300op/secに増やします。
  15. 1日後、手順3で記録したワークロードの名前をUnified Managerで検索します。
    [パフォーマンス / ボリュームの詳細]ページが表示されます。
  16. [データ内訳の基準] > [IOPS]を選択します。
  17. [送信]をクリックします。
    [読み取り / 書き込み / その他]グラフが表示されます。
  18. ページの下部で、ポリシー グループ制限の変更イベント アイコン(変更イベント アイコン)にカーソルを合わせます。
  19. [読み取り / 書き込み / その他]グラフと[レイテンシ]グラフを比較します。
    読み取り要求と書き込み要求の数は変わっていませんが、調整は停止し、レイテンシも低下しています。