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

監控 EDA 工作負載中的磁碟區延遲

貢獻者 netapp-sineadd
PDF

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

概況

延遲分析會收集與您的 AWS 憑證相關聯之所有 FSx for ONTAP 磁碟區上讀取和寫入作業的 CloudWatch 指標。當設定時間範圍內所有資料點的延遲臨界值和 IOPS 臨界值均被突破時，系統會產生警示。這種雙重條件邏輯透過確保在實際負載下延遲持續升高，從而減少誤報。

當偵測到事件時，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 代理分析功能將無法使用。

了解警示

延遲分析功能使用 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 標籤中，查看延遲事件表。

  2. 請查看各項事件的相關資訊，包括：

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

    • Volume name：受影響 Volume 的名稱

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

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

    • * 中位數延遲（毫秒）*：違規期間的中位數延遲值

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

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

  3. 若要檢視延遲事件的詳細資訊，請在延遲事件表的 嚴重性 欄中選取該事件。這會開啟該事件的延遲分析面板。

  4. 若要對表格進行排序，請選擇任意欄標題。預設情況下，重大事件會先依時間排序顯示，接著是依時間排序的警告事件。

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

  6. 若要新增欄至表格，請選擇 欄圖示，選擇欄，然後選擇 套用。

瞭解基本分析

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

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

延遲分析面板

在延遲事件表的 Severity 欄位中選擇延遲事件，即可開啟該事件的延遲分析面板。

  • FlexCache：FlexCache 操作的延遲

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

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

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

  • Disk：儲存子系統的延遲

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

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

  • 其他：來自其他子系統（例如 NVRAM 和網路）的延遲

如果配置了 Amazon Bedrock 模型 ARN，面板還會提供一個選項，用於執行 AI 代理分析，以評估資料和叢集場景。如果未配置 Bedrock，面板會顯示一個鏈接，指向特定檔案系統的儲存工作負載配置頁面，您可以在該頁面配置 Bedrock 存取。

執行 AI 代理分析

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

開始之前

您必須在 Workload Factory 設定中設定 Amazon Bedrock 模型 ARN。

關於此任務

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

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

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

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

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

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

  • 非最佳掛載點組態（針對叢集延遲）

  • FlexGroup 重新平衡需求（針對叢集延遲）

  • 橫向擴展要求（針對叢集延遲）

步驟

  1. 在 Latency 標籤中，找到要分析的事件。

  2. 在延遲事件表的 Severity 欄中，選取延遲事件以開啟該事件的分析面板。

    如果檔案系統未關聯任何連結，系統會提示您將連結關聯到受影響的檔案系統。選擇提示即可跳到該檔案系統的連結設定頁面。工具提示會解釋此重新導向，並指出關聯連結並設定 Bedrock 存取（建議）可啟用完整的事件分析。

  3. 在分析面板中、檢閱基本分析結果、以瞭解延遲來源。

  4. 如果延遲來源被識別為資料或叢集，請選擇 Analyze 。

  5. 檢閱 AI 代理程式分析結果，其中包括：

    • 根本原因說明

    • 受影響的 EC2 用戶端清單

    • 潛在的補救步驟

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

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

管理延遲組態

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

步驟

  1. 在 Latency 頁面中，選擇 Edit。

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

    註 請確保關鍵臨界值高於警告臨界值。如果將關鍵臨界值配置得低於警告臨界值，系統將顯示錯誤。

  3. 選擇 Apply 以儲存變更。

最佳實務

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

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

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

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

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

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

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

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