Skip to main content
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

在 Workload Factory 中監控 EDA 的磁碟區延遲

貢獻者 netapp-sineadd

身為管理 EDA 工作負載的 IT 管理員或 DevOps 工程師,您可以使用延遲分析來監控 FSx for ONTAP 磁碟區讀取和寫入延遲。設定警告和嚴重臨界值,以便及早偵測效能問題。事件發生時,Workload Factory 會提供自動化的基本分析,您還可以選擇執行 AI 代理分析,以獲取根本原因詳細資訊、受影響的用戶端以及建議的補救步驟。

概況

延遲分析會收集與您的 AWS 憑證關聯的所有 FSx for ONTAP 磁碟區的讀寫操作 CloudWatch 指標。當配置時間範圍內所有資料點的延遲閾值和 IOPS 閾值均被突破時,系統會產生警報。這透過確保在實際負載下保持較高的延遲來減少誤報。您可以查看所有偵測到的事件,如果您已設定通知,則會收到包含受影響磁碟區詳細資訊的電子郵件或 Amazon SNS 通知。

當偵測到事件時、Workload Factory 會使用 ONTAP QoS 延遲中心指標執行基本分析、以識別主要的延遲因素(例如 FlexCache、容量池、QoS 限制、磁碟、資料、叢集或其他子系統)。然後、您可以"分析延遲趨勢"使用互動式圖表進行檢視。

對於資料和叢集案例,您可以選擇執行 AI 代理程式分析,以取得詳細的根本原因說明、受影響的 EC2 用戶端清單,以及建議的補救步驟。

要求

若要使用延遲監控和分析功能,請確保滿足以下要求:

AWS憑證和權限

您必須將具有讀取 / 寫入權限的 AWS 憑證新增至 Workload Factory 。延遲監控功能需要存取與您的 AWS 憑證關聯的所有 FSx for ONTAP 磁碟區的 CloudWatch 指標。

延遲監控不支援 Basic 模式和 Read-only 模式權限。

如果您尚未配置 AWS 憑證,請參閱 "新增 AWS 憑證"

FSx for ONTAP檔案系統

您的 AWS 環境中至少需要一個 FSx for ONTAP 檔案系統及其磁碟區。延遲監控功能會自動收集與您設定的 AWS 憑證關聯的所有磁碟區的指標。

連結至 FSx for ONTAP

若要檢視基本分析深入見解,您必須將連結與 FSx for ONTAP 檔案系統建立關聯。若沒有連結,仍可偵測到事件,但分析提供的深入見解有限。如果尚未建立任何連結關聯,請在 EDA 中選取 Associate link、選擇要建立新連結或建立現有連結的關聯,然後選取 Continue 以自動前往 Storage workloads 中的連結建立頁面。

有關建立和關聯連結的說明,請參閱 "建立連結"

Amazon Bedrock 模型 ARN (選用)

若要使用選用的 AI 代理程式分析功能、您必須在 Workload Factory 設定中提供 Amazon Bedrock 模型 ARN。

如需更多詳細資料、請參閱 "基本 GenAI 需求"

如果您未設定 Bedrock 模型 ARN,您仍然可以使用延遲監控和自動化基本分析,但無法使用 AI 代理分析。

通知組態(選用)

若要在偵測到延遲事件時接收電子郵件或 Amazon SNS 通知,請在 Workload Factory 設定中設定通知偏好設定。詳情請參閱設定延遲通知

了解警示

延遲分析使用 CloudWatch 警示來監控磁碟區效能。了解警示的觸發方式有助於您設定適當的臨界值並解讀結果。

收集的指標

系統會針對每個磁碟區收集以下 CloudWatch 指標:

  • 讀取延遲閾值:計算公式為 1000 * m2/(m1+0.000001),其中 m1 = DataReadOperations 且 m2 = DataReadOperationTime

  • 寫入延遲閾值:計算公式為 1000 * m2/(m1+0.000001),其中 m1 = DataWriteOperations 且 m2 = DataWriteOperationTime

警示觸發條件

當滿足以下所有條件時,就會觸發警示:

  • 操作類型 (讀取或寫入) 的延遲閾值已超過。

  • 該操作類型的 IOPS 閾值已超過。

  • 在設定的時間範圍內,所有資料點都符合這兩個條件。

例如,使用預設警告閾值,只有當 10 分鐘內所有資料點的讀取延遲超過 6 毫秒且讀取 IOPS 超過 100 ops/sec 時,才會觸發讀取警報。

事件嚴重性

  • 警告事件:表示延遲升高,可能需要注意

  • 關鍵事件:表示存在嚴重的延遲,需要立即調查

設定延遲臨界值

您可以為讀取和寫入作業設定警告和嚴重臨界值。系統會持續評估臨界值,並在符合條件時產生警示。

註 您必須將關鍵事件閾值設定得高於警告事件閾值,以確保警報能夠正確升級。否則,您將無法儲存配置。
步驟
  1. 使用以下任一方式登入 "主機體驗"

  2. 選擇選單 漢堡選單圖示,然後選擇 EDA

  3. 選取 Latency 標籤。

  4. 在 EDA 延遲組態頁面中,設定以下臨界值:

    • 警告事件

      • 讀取延遲閾值:輸入延遲閾值(以毫秒為單位)。預設值:6 ms。

      • 讀取 IOPS 閾值:輸入每秒操作數的 IOPS 閾值。預設值:100 操作/秒。

      • 讀取時間範圍:請輸入時間範圍,單位為分鐘(5-20)。預設值:10 分鐘。

      • 寫入延遲閾值:輸入延遲閾值(以毫秒為單位)。預設值:8 ms。

      • 寫入 IOPS 閾值:輸入每秒操作數的 IOPS 閾值。預設值:100 操作/秒。

      • 寫入時間範圍:輸入時間範圍(以分鐘為單位)(5-20)。預設值:10 分鐘。

    • 重大事件

      • 讀取延遲閾值:輸入延遲閾值,單位為毫秒。預設值:12 毫秒。

      • 讀取 IOPS 閾值:輸入每秒操作數的 IOPS 閾值。預設值:100 操作/秒。

      • 讀取時間範圍:請輸入時間範圍,單位為分鐘(5-20)。預設值:10 分鐘。

      • 寫入延遲閾值:輸入延遲閾值(以毫秒為單位)。預設值:15 毫秒。

      • 寫入 IOPS 閾值:輸入每秒操作數的 IOPS 閾值。預設值:100 操作/秒。

      • 寫入時間範圍:輸入時間範圍(以分鐘為單位)(5-20)。預設值:10 分鐘。

  5. 選擇*應用*。

結果

Workload Factory 開始收集與您的 AWS 憑證關聯的所有 FSx for ONTAP 磁碟區的延遲指標。指標至少每 20 分鐘收集一次。任何超出您配置閾值的磁碟區都會顯示出來。

檢視延遲事件

延遲事件表提供過去 72 小時內偵測到的所有警告和嚴重事件的集中檢視。

  • 每個磁碟區僅顯示最新一次洩漏事件。如果一個磁碟區發生多次洩漏事件,則僅顯示最近一次事件。

  • 事件會在 72 小時後自動刪除。

  • 最多顯示 200 個事件。隨著新事件的新增,較舊的事件將被移除。

  • 即使沒有與檔案系統相關聯的連結,事件仍會顯示。需要連結才能檢視基本分析詳細資料並執行 AI 代理分析。

步驟
  1. Latency 標籤中、檢閱每個事件的資訊、包括:

    • 嚴重程度:指示事件是嚴重還是警告

    • Volume name:受影響 Volume 的名稱

    • Volume ID:受影響磁碟區的 ID

    • 檔案系統:包含磁碟區的 FSx for ONTAP 檔案系統

    • * 中位數延遲(毫秒)*:違規期間的中位數延遲值

    • % above threshold:延遲超過設定臨界值的百分比

    • 偵測到的時間:偵測到漏洞的時間

  2. 若要檢視延遲事件的詳細資訊,請在 Severity 欄中選取該事件。這將開啟該事件的延遲分析面板。

  3. 若要對表格進行排序,請選取任何欄標題。根據預設,重大事件會先依時間排序顯示,接著是依時間排序的警告事件。

  4. 若要關閉一個或多個事件,請在每個事件旁邊選取 動作功能表圖示 Dismiss

  5. 若要新增欄至表格,請選擇 欄圖示,選擇欄,然後選擇 套用

  6. 若要分析一段時間內的延遲趨勢,請選擇事件以開啟延遲分析面板。使用 Over time 標籤查看互動式延遲圖表。詳情請參閱 "分析延遲趨勢"

分析延遲事件

基本分析功能可協助您快速識別延遲問題的根本原因,無需手動調查。偵測到延遲事件時,Workload Factory 會自動使用 ONTAP QoS 延遲中心指標執行基本分析。此分析會識別導致延遲的組件,並提供簡要描述。

註 由於資料擷取方法不同,ONTAP QoS 分析所得的延遲值與 CloudWatch 資料之間可能存在細微差異。基礎分析使用 ONTAP 資料進行根本原因識別。

延遲分析面板

Severity 欄位中選擇延遲事件,即可開啟該事件的延遲分析面板。此面板包含多個選項卡,可提供延遲事件的不同視圖:

  • 概覽:顯示基本分析結果,指出導致延遲的元件

  • 隨時間變化:顯示包含歷史資料的互動式延遲圖表

概況

Overview 標籤會顯示自動化基本分析的結果,識別造成延遲的元件:

  • FlexCache:FlexCache 操作的延遲

  • 容量池:容量池作業的延遲

  • QoS 最低值:來自 QoS 原則群組下限的延遲

  • QoS 最大值:來自 QoS 原則群組上限限制的延遲

  • Disk:儲存子系統的延遲

  • 資料:WAFL 子系統的延遲、包括 CPU 處理、中繼資料更新和快取管理

  • Cluster:內部連線節點間的延遲

  • 其他:來自其他子系統(例如 NVRAM 和網路)的延遲

如果已設定 Amazon Bedrock 模型 ARN,Overview 標籤也會包含一個選項,用於執行 AI 代理程式分析以評估資料和叢集案例。如果未設定 Bedrock,該標籤會顯示一個連結,指向特定檔案系統的 Storage workloads 組態頁面,您可以在該頁面設定 Bedrock 存取。

隨著時間推移

Over time 標籤會顯示一個互動式延遲圖表,其中顯示受影響磁碟區的 CloudWatch 延遲指標隨時間的變化。此圖表會根據觸發事件的警示類型顯示讀取延遲或寫入延遲。您可以選擇不同的時間範圍(1H、3H、12H、24H、72H)來檢視不同期間的延遲行為。

有關使用圖表的詳細說明,請參閱 "分析延遲趨勢"

執行 AI 代理分析

雖然基礎分析可以識別延遲來源,但涉及資料或叢集組件的複雜場景通常需要更深入的調查,才能確定具體的根本原因和潛在的修復步驟。AI 代理分析能夠提供這種更深層的故障排除,它可以識別出基礎分析無法偵測到的問題,例如 bully Volume、非最佳組態或橫向擴展需求等。

開始之前

在 Workload Factory 設定中設定 Amazon Bedrock 模型 ARN,請參閱 "基本 GenAI 需求"

關於此任務

執行 AI 代理程式分析時,系統會自動重新整理基礎分析資料並將其用作 AI 代理程式的輸入。AI 代理程式會評估延遲情況並提供以下資訊:

  • 潛在根本原因:詳細說明導致延遲問題的原因

  • 受影響的用戶端:受延遲影響的 EC2 執行個體名稱清單

  • 潛在的補救步驟:解決問題的兩個或多個特定動作

AI 代理程式遵循基本分析準則來識別以下場景:

  • 大量磁碟區消耗過多資源(導致資料延遲)

  • 非最佳掛載點組態(針對叢集延遲)

  • FlexGroup 重新平衡需求(針對叢集延遲)

  • 橫向擴展要求(針對叢集延遲)

步驟
  1. Latency 標籤中,找到要分析的事件。

  2. Severity 欄位中,選擇一個延遲事件,開啟該事件的分析面板。

    如果檔案系統未關聯任何連結,系統會提示您將連結關聯到受影響的檔案系統。選擇提示即可跳到該檔案系統的連結設定頁面。

  3. 請檢閱 Overview 標籤以瞭解基本分析結果並識別延遲來源。

  4. 如果延遲來源被識別為資料或叢集,請選取 * 分析 * 以執行 AI 代理程式分析。

  5. 檢閱 AI 代理程式分析結果。

  6. 實施建議的補救步驟以解決延遲問題。

  7. 修復後,請監控延遲事件表以驗證問題是否已解決。

管理延遲組態

完成初始配置後,您可以編輯閾值。

步驟
  1. Latency 頁面中,選擇 Edit

  2. 根據需要修改任何臨界值。

    註 請確保關鍵臨界值高於警告臨界值。如果將關鍵臨界值配置得低於警告臨界值,系統將顯示錯誤。
  3. 選擇 Apply 以儲存變更。

設定延遲通知

您可以設定電子郵件或 Amazon SNS 通知,以便在偵測到延遲事件時接收警報。每次磁碟區超出您配置的閾值時,系統都會發送通知,讓您即時了解效能問題。若要啟用通知,請參閱 "設定通知設定"

延遲通知是按檔案系統發送的。當檔案系統中的一個或多個磁碟區違反延遲臨界值時,您會收到一則列出所有受影響磁碟區的通知。

註 如果受影響的磁碟區超過 10 個,電子郵件將顯示前 10 個磁碟區,並指出還有多少其他磁碟區受到影響。您可以在 Workload Factory 主控台中檢視所有受影響的磁碟區。

通知內容包括:

  • 檔案系統詳細資料

  • 超出臨界值的磁碟區清單

  • 事件嚴重程度(警告或嚴重)

  • 延遲值與臨界值比較

  • 直接連結至延遲頁面以進行調查

通知管道:

  • 電子郵件:傳送至您在 Workload Factory 通知設定中設定的電子郵件地址

  • Amazon SNS:發佈到您配置的 SNS 主題,以便與其他系統整合

最佳實務

配置和使用延遲分析時,請考慮以下建議:

  • 設定合理的閾值:根據您的工作負載需求配置閾值。預設值提供了一個起點,但可能需要根據您的特定環境進行調整。

  • 從警告閾值開始:在微調關鍵閾值之前,使用警告事件來建立基準效能預期。

  • 請仔細考慮時間範圍:較短的時間範圍 (5-10 分鐘) 能更快地偵測到問題,但可能會產生更多警報。較長的時間範圍 (15-20 分鐘) 能減少誤報,但可能會延遲偵測。

  • 監控趨勢:定期檢閱延遲事件表格,以識別可能表示潛在組態問題的模式或重複出現的問題。

  • 協調 IOPS 和延遲閾值:雙重條件邏輯意味著兩者都必須被超越。設定過高的 IOPS 閾值可能會導致即使延遲存在問題也無法發出警報。

  • 審查被駁回的事件:定期審查事件被駁回的原因,以發現調整門檻或改進基礎設施的機會。

  • 策略性地使用 AI 代理分析:在基礎分析建議使用 AI 代理分析的資料和叢集場景中執行 AI 代理分析。AI 代理分析能夠為需要詳細故障排除的複雜效能問題提供更深入的見解。

如需分析延遲趨勢的最佳實務做法,請參閱 "圖表解讀"