Skip to main content
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

EDA ワークロードのボリュームレイテンシを監視する

共同作成者 netapp-sineadd

EDAワークロードを管理するIT管理者またはDevOpsエンジニアは、レイテンシ分析を使用して、FSx for ONTAPファイルシステム全体の読み取り / 書き込みレイテンシメトリックを追跡することで、ボリュームのパフォーマンスをプロアクティブに監視できます。警告イベントおよび重大なイベントのカスタマイズ可能なしきい値を設定して、シミュレーションの実行時間や市場投入までの時間に影響する前に、潜在的なパフォーマンスのボトルネックを特定します。レイテンシイベントが検出されると、自動化された基本分析により根本原因を特定できます。

概要

高いレイテンシは、EDA プロジェクトのシミュレーション実行時間と市場投入までの時間に直接影響します。正常でないボリュームはパフォーマンスの大幅な低下を引き起こし、コストのかかる本番環境の遅延につながる可能性があります。レイテンシ分析は、ワークロードに影響が及ぶ前に、ストレージ資産全体にわたる運用上の問題をプロアクティブに特定し、トラブルシューティングし、修復するのに役立ちます。

レイテンシ分析は、CloudWatchメトリクスを収集・監視し、ボリュームの読み取りおよび書き込み操作を追跡します。指定された時間範囲内のすべてのデータポイントでレイテンシとIOPSの両方のしきい値が超過した場合、システムはレイテンシイベントテーブルにアラートを生成します。

遅延イベントが検出されると、システムは ONTAP QoS 遅延センターメトリックを使用して基本的な分析を自動的に実行し、遅延の原因を特定します。

これにより、次のことが可能になります:

  • パフォーマンスの低下が発生しているボリュームを特定します。

  • 警告レベルと重大レベルのパフォーマンスの問題を区別します。

  • レイテンシの問題の根本原因を自動的に分析します。

  • 時間の経過に伴うレイテンシの傾向を追跡し、ストレージ構成を最適化します。

  • レイテンシがワークロードのパフォーマンスに影響を与える前に、プロアクティブなアクションを実行します。

要件

レイテンシ監視および分析機能を使用するには、次の要件を満たしていることを確認してください:

AWS の認証情報と権限

読み取り / 書き込み権限を持つAWS認証情報をWorkload Factoryに追加する必要があります。レイテンシ監視機能では、AWS認証情報に関連付けられたすべてのFSx for ONTAPボリュームのCloudWatchメトリクスへのアクセスが必要です。

レイテンシ監視では、Basic モードと read-only モードの権限はサポートされていません。

AWS 認証情報をまだ設定していない場合は、"AWS認証情報を追加する"を参照してください。

FSx for ONTAPファイルシステム

AWS 環境にデプロイされたボリュームを持つ少なくとも 1 つの FSx for ONTAP ファイルシステムが必要です。レイテンシー監視機能は、設定された AWS 認証情報に関連付けられているすべてのボリュームのメトリクスを自動的に収集します。

FSx for ONTAP へのリンク

基本的な分析から洞察を得るには、FSx for ONTAP ファイルシステムにリンクを関連付ける必要があります。リンクがまだ関連付けられていない場合は、EDA で リンクの関連付け を選択し、新しいリンクを作成するか既存のリンクを関連付けるかを選択してから、続行 を選択すると、Storage workloads のリンク作成ページに自動的に移動します。

リンクの作成と関連付けの手順については、"リンクを作成"を参照してください。

アラートについて

レイテンシ分析機能はCloudWatchアラームを使用してボリュームのパフォーマンスを監視します。アラートがどのようにトリガーされるかを理解することで、適切なしきい値を設定し、結果を解釈するのに役立ちます。

収集されたメトリック

システムは各ボリュームについて次のCloudWatchメトリックを収集します:

  • 読み取りレイテンシしきい値:1000 * m2/(m1+0.000001)として計算されます。ここで、m1 = DataReadOperations、m2 = DataReadOperationTime

  • 書き込みレイテンシしきい値:1000 * m2/(m1+0.000001)として計算されます。ここで、m1 = DataWriteOperations、m2 = DataWriteOperationTime

アラートのトリガー条件

次の条件がすべて満たされると、アラートがトリガーされます:

  • 操作タイプ(読み取りまたは書き込み)のレイテンシしきい値を超えています。

  • 操作タイプの IOPS しきい値を超えています。

  • 両方の条件は、構成された時間範囲内のすべてのデータポイントに対して持続します。

たとえば、デフォルトの警告しきい値では、読み取りレイテンシが 6 ms を超え、かつ 10 分間にすべてのデータポイントの読み取り IOPS が 100 ops/sec を超えた場合にのみ読み取りアラートがトリガーされます。

イベントの重大度

  • 警告イベント:注意が必要な可能性のある、待機時間の増加を示します。

  • 重大なイベント:すぐに調査する必要がある重大な遅延を示します。

レイテンシしきい値を設定する

適切なレイテンシしきい値を構成すると、ボリュームでパフォーマンスの問題が発生したときにタイムリーな通知を受け取ることができます。警告しきい値と重大しきい値の両方を設定することで、注意が必要な問題と即時の対応が必要な問題を区別することができ、ストレージ資産をより効果的に管理し、パフォーマンスの問題が本番環境のワークロードに影響を与えるのを防ぐことができます。

警告イベントと重大イベントの両方にしきい値を設定できます。各イベントタイプには、読み取り操作と書き込み操作の個別のしきい値が含まれます。システムはこれらのしきい値を継続的に評価し、条件が満たされるとアラートを生成します。

メモ 適切なアラートエスカレーションを確実に行うには、重大イベントのしきい値を警告イベントのしきい値よりも高く設定する必要があります。そうでない場合、設定を保存できません。
タスク概要

アラートをトリガーするには、指定された時間範囲内のすべてのデータポイントにおいて、レイテンシしきい値とIOPSしきい値の両方を超過する必要があります。この二重条件ロジックにより、大きな負荷下で高レイテンシが持続していることを保証することで、誤検知を削減できます。

手順
  1. 次のいずれかを使用してログインします "コンソール体験"

  2. メニューハンバーガーメニューアイコンを選択し、*EDA*を選択します。

  3. EDA メニューから、Latency を選択します。

  4. EDA レイテンシ構成ページで、次のしきい値を構成します:

    • 警告イベント

      • 読み取りレイテンシしきい値:レイテンシしきい値をミリ秒単位で入力します。デフォルト:6 ms。

      • 読み取りIOPSしきい値:IOPSしきい値を1秒あたりの操作数で入力します。デフォルト:100 ops/sec。

      • 読み取り時間範囲:時間範囲を分単位で入力します(5~20分)。デフォルト:10分。

      • 書き込みレイテンシしきい値:レイテンシしきい値をミリ秒単位で入力します。デフォルト:8 ms。

      • 書き込みIOPSしきい値:IOPSしきい値を1秒あたりの操作数で入力します。デフォルト:100 ops/sec。

      • 書き込み時間範囲:時間範囲を分単位で入力します(5~20)。デフォルト:10分。

    • 重大なイベント

      • 読み取りレイテンシしきい値:レイテンシしきい値をミリ秒単位で入力します。デフォルト:12 ms。

      • 読み取りIOPSしきい値:IOPSしきい値を1秒あたりの操作数で入力します。デフォルト:100 ops/sec。

      • 読み取り時間範囲:時間範囲を分単位で入力します(5~20分)。デフォルト:10分。

      • 書き込みレイテンシしきい値:レイテンシしきい値をミリ秒単位で入力します。デフォルト:15 ミリ秒。

      • 書き込みIOPSしきい値:IOPSしきい値を1秒あたりの操作数で入力します。デフォルト:100 ops/sec。

      • 書き込み時間範囲:時間範囲を分単位で入力します(5~20)。デフォルト:10分。

  5. *適用*を選択します。

結果

Workload FactoryはAWS認証情報に関連付けられたすべてのFSx for ONTAPボリュームのレイテンシメトリクスの収集を開始します。メトリクスは少なくとも20分ごとに収集されます。レイテンシイベントテーブルには、設定されたしきい値を超えたボリュームが表示されます。

レイテンシイベントを表示する

複数のファイルシステムとボリュームを管理する管理者にとって、レイテンシイベントテーブルは、注意が必要なすべてのパフォーマンスの問題を一元的に表示します。表には、過去72時間以内に検出されたすべての警告および重大なイベントが表示されます。各イベントの詳細列には自動化された基本分析結果が含まれており、レイテンシ問題の根本原因を迅速に特定し、資産全体で修復作業の優先順位を付けるのに役立ちます。

  • 各ボリュームの最新の侵害のみが表に表示されます。ボリュームで複数の侵害が発生した場合は、最新のイベントのみが表示されます。

  • イベントは 72 時間後に自動的に削除されます。

  • 表には最大200件のイベントが表示されます。新しいイベントが追加されると、古いイベントは削除されます。

手順
  1. レイテンシ タブで、レイテンシイベントテーブルを表示します。

  2. 以下を含む各イベントの情報を確認します:

    • 重大度:イベントが重大か警告かを示します。

    • ボリューム名:影響を受けるボリュームの名前。

    • ボリューム ID:影響を受けるボリュームの ID。

    • ファイルシステム:ボリュームを含む FSx for ONTAP ファイルシステム。

    • 検出時刻:侵害が検出された時刻

    • 中央値レイテンシ:違反期間中の中央値レイテンシ。

    • 詳細:遅延の原因と推奨されるアクションを特定する自動化された基本分析結果。

  3. 表を並べ替えるには、任意の列ヘッダーを選択します。デフォルトでは、まず重大なイベントが時間順に並び替えられ、次に警告イベントが時間順に並び替えられて表示されます。

  4. 1 つ以上のイベントを却下するには、各イベントの横にある 却下 を選択します。

  5. テーブルに列を追加するには、列アイコンを選択し、列を選択して、*適用*を選択します。

基本的な分析について

基本的な分析により、手動で調査することなくレイテンシー問題の根本原因を迅速に特定できます。レイテンシーイベントが検出されると、Workload FactoryはONTAP QoS delay centerメトリックを使用して自動的に基本分析を実行します。この分析は、どのコンポーネントがレイテンシーの原因となっているかを特定し、レイテンシーイベントテーブルの詳細列で実行可能なガイダンスを提供することで、根本原因の理解を可能にします。

メモ ONTAP QoS分析とCloudWatchデータのレイテンシ値には、収集方法の違いにより若干の差異がある可能性があります。基本的な分析では、根本原因の特定にONTAPデータを使用します。

分析シナリオ

基本分析では、複数のレイテンシコンポーネントを評価し、各シナリオの結果に基づいて具体的なガイダンスを提供します:

  • Flexcache:FlexCache操作のI/O操作ごとのレイテンシ

  • 容量プール:容量プール処理の I/O 処理あたりのレイテンシ

  • QoS min:QoS ポリシーグループフロアの I/O 処理あたりのレイテンシ

  • QoS 最大:QoS ポリシーグループ上限の I/O 処理あたりのレイテンシ

  • ディスク:ストレージサブシステムのI/O操作ごとのレイテンシ

  • データ: I/O 操作ごとのレイテンシ(WAFL サブシステムファイルシステムにおける CPU 処理、メタデータ更新、キャッシュ管理などのタスクを含む)

  • クラスタ:クラスタ内の内部接続ノード間の I/O 処理あたりのレイテンシ

  • その他:FSx for ONTAP サブシステムでの I/O 操作ごとのレイテンシ

レイテンシ設定を管理する

初期設定後、しきい値を編集できます。

手順
  1. Latency ページで、Edit を選択します。

  2. 必要に応じて、しきい値を変更します。

    メモ 重要しきい値が警告しきい値よりも高い値に設定されていることを確認してください。重要しきい値を警告しきい値よりも低く設定した場合、システムはエラーを表示します。
  3. 変更を保存するには、*適用*を選択します。

ベストプラクティス

レイテンシ分析を構成および使用するときは、次の推奨事項を考慮してください:

  • 現実的なしきい値を設定する:ワークロード要件に基づいてしきい値を設定します。デフォルト値は出発点となりますが、特定の環境に合わせて調整が必要になる場合があります。

  • 警告しきい値から開始:重要なしきい値を微調整する前に、警告イベントを使用してベースラインパフォーマンスの期待値を確立します。

  • 時間範囲を慎重に検討してください:短い時間範囲(5~10分)では問題の検出が速くなりますが、アラートが多く生成される可能性があります。長い時間範囲(15~20分)では誤検知は減りますが、検出が遅れる可能性があります。

  • 傾向の監視:レイテンシ イベント テーブルを定期的に確認して、根本的な構成の問題を示唆する可能性のあるパターンや繰り返し発生する問題を特定します。

  • IOPSとレイテンシのしきい値を調整する:二重条件ロジックでは、両方のしきい値を超える必要があります。IOPSしきい値を非常に高く設定すると、レイテンシが問題となる場合でもアラートが発生しない可能性があります。

  • 却下されたイベントを確認する:イベントが却下された理由を定期的に確認し、しきい値の調整やインフラストラクチャの改善の機会を特定します。