PowerFlex：過多的資料角色切換會導致 IO 延遲和錯誤

Summary: 本文說明過多資料的角色切換如何導致 I/O 延遲和錯誤。

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Symptoms

在某些群集狀態轉換下，MDM 角色平衡邏輯可以跨多個梳理（跟蹤哪些 SDS 節點存儲每個卷數據的內部數據結構）生成快速、重複的主要/次要角色切換。每個角色切換都會使用戶端 （SDC） 梳狀圖失效，並強制 I/O 重試。當同時影響足夠多的梳理時，累積重試開銷會導致 SDC 主機上出現 I/O 延遲尖峰和 I/O 錯誤。視主機環境而定，這可能會導致應用程式 I/O 逾時、VM 進入唯讀狀態，或檔案系統無法使用。

此行為已在多個觸發器情況下觀察到，不限於任何單一操作過程。

通用指標

  • MDM_DATA_DEGRADED 事件後接續 I/O 延遲，持續 1-15+ 分鐘
  • SDC 主機在降級時段回報 I/O 錯誤和/或 I/O 逾時
    • VMware （ESXi）：VMFS 活動訊號逾時， SCSI 硬體錯誤 （sense data: 0x4 0x0 0x0）， VM 進入唯讀狀態， 潛在的 HA 容錯移轉
    • Linux：系統記錄中的 I/O 錯誤 （/var/log/messages, dmesg），應用程式可能會遇到 I/O 逾時或檔案系統重新掛接唯讀
  • MDM 事件記錄顯示系統處於降級狀態的時間比單一 SDS 遺失預期的時間更長
  • 系統最終會自行復原至正常狀態，無須手動介入 （通常）
 
注意：在撰寫本文時，僅在使用 VMware （ESXi） 和 Linux SDC 主機的環境中回報此問題。雖然沒有已知會影響 Windows SDC 主機的行為報告，但底層缺陷位於 MDM 核心邏輯中，且並非特定作業系統。


案例 1：非正常 SDS 遺失 （無維護模式）

何時可能發生這種情況：

  • 這種情況很少見。若要在意外 SDS 遺失期間發生快速、重複的角色切換事件，必須同時具備幾個特定條件：
    • 大規模環境 - 大量的 SDS 節點和磁碟區
    • 生產 I/O 負載繁重 - SDS 故障時的大量 I/O 活動
    • 重建工作負載超過處理容量 - 需要重新生成的元數據行數超過了 MDM 平衡器的每週期限制 1,024 行

每個重新平衡週期最多可以處理 1,024 個元數據行。當必須重新生成更多行時，平衡器無法在生成下一個計劃之前完成當前計劃。

會發生什麼：

  • SDS 會突然從 MDM 分離 （事件 SDS_DECOUPLED）
  • → SDC 中斷連線事件，連接到該 SDS 的所有 SDC 都會失去連線
  • MDM 將叢集標記為降級 （事件 MDM_DATA_DEGRADED)
  • 由於要重新生成的行數超過 1,024，因此 MDM 平衡器無法完成當前的重新平衡計劃
  • 平衡器在上一個計劃仍在運行時啟動新計劃，從而生成快速、重複的角色切換事件
  • 用戶端 SDC 看到連續的 I/O 故障 （IO_FAULT_NOT_PRI, SCSI sense 0x4)。重試用盡後，主機作業系統會報告 I/O 錯誤、逾時或檔案系統唯讀
  • MDM 追蹤證據：

當重新平衡工作負載超過 1,024 行限制時，MDM 追蹤會顯示超過閾值：

2026/03/28 22:43:53.246702 MED:7f1f984aedb0:balanceExec_HandleDegradedRows:00343: BALANCER: Storage Pool: 1193844800000000 - 1024 rows processed out of 1098 degraded rows. 0 allocation failures. 0 cumulative allocation failures.

這表明需要重建 1,098 行，但在當前週期中只能處理 1,024 行。其餘行在上一個計劃完成之前觸發新的重新平衡計劃，從而啟動反饋迴圈。

事件鏈：

Log Source     Event / Pattern
MDM events     SDS_DECOUPLED — SDS formally declared dead
MDM events     MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces     Flood of IO_FAULT_NOT_PRI — SDS received IO for a comb it is no longer primary for
ESXi vmkernel  SCSI sense data: 0x4 0x0 0x0 — Hardware error
MDM events     MULTIPLE_SDC_CONNECTIVITY_CHANGES — Mass SDC connectivity storm
MDM events     SDC_DISCONNECTED_FROM_SDS_IP — SDCs losing contact with the failed SDS
MDM 事件順序範例： 
SDC_DISCONNECTED_FROM_SDS_IP    SDC disconnected from SDS <name>
SDS_DECOUPLED                   SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

案例 2：在 PMM 輸入期間關閉 SDS 電源

何時可能發生這種情況：
這種情況很少見，需要同時發生兩個事件：

  • SDS 正在進入受保護的維護模式 （PMM）
  • SDS 在 PMM 轉換完成之前失敗或關閉電源

會發生什麼： 

  • MDM 接收 PMM 條目命令，並將其記錄為成功
  • 當 PMM 條目仍在進行時，SDS 意外分離
  • MDM 會將叢集標記為降級
  • 角色平衡器會在整個 PMM 進入階段進入持續的角色切換迴圈
  • 非 PMM 資料列在整個儲存池中重複進行角色切換
  • 風暴持續存在，直到 SDS 重新加入群集並完成維護模式轉換

事件鏈：

Log Source  Event / Pattern
MDM events  CLI_COMMAND_SUCCEEDED — enter_protected_maintenance_mode command succeeded
MDM events  SDS_DECOUPLED — SDS decoupled before maintenance mode started
MDM events  MDM_DATA_DEGRADED — Cluster enters DEGRADED state
SDS traces  Repeated role-switch operations across non-PMM rows

MDM 事件順序範例：

CLI_COMMAND_SUCCEEDED            Command enter_protected_maintenance_mode succeeded
SDS_DECOUPLED                    SDS <name> decoupled
MDM_DATA_DEGRADED               The system is now in DEGRADED state

當 SDS 重新加入且 PMM 完成時：

SDS_MAINTENANCE_MODE_STARTED     SDS maintenance mode started
MDM_DATA_NORMAL                 The system is now in NORMAL state

案例 3：SDS 處於即時維護模式 （IMM）

何時可能發生這種情況：
SDS 進入或結束即時維護模式 （IMM）。當單個 SDS 處於維護模式且系統無法決定哪個 SDS 應處理特定數據的 I/O 時，就會發生這種情況。

會發生什麼：

  • 系統會反覆變更哪個 SDS 負責提供相同的資料
  • 這些持續變化意味著應用程式不知道將其 I/O 請求發送到何處
  • I/O 傳送至錯誤的 SDS，導致重試和延遲
  • 應用程式在嘗試存取受影響的資料時遇到延遲或逾時

影響：

  • 客戶影響：當 SDS 處於 IMM 中時，應用程式會報告延遲和逾時
  • 持續時間：當 SDS 處於 IMM 狀態時繼續
  • 復原：自動 - 在 SDS 退出 IMM 時解析

事件鏈：

Log Source  Event / Pattern
SDS traces  Repeated role-switch operations on the same data
SDS traces  Primary and secondary role switches on identical data

案例 4：SDS 退出受保護維護模式 （PMM）

何時可能發生這種情況：
SDS 會退出受保護的維護模式 （PMM）。這種情況發生在每次 PMM 退出期間 - 這不是罕見的事件，但嚴重性取決於維護模式操作持續的時間。

會發生什麼：

  • SDS 退出 PMM 時，角色平衡器必須重新指派資料區段，以納入傳回的 SDS
  • 重新平衡過程會影響整個存儲池，而不僅僅是返回的 SDS 上的數據
  • 在重新整合期間，多個資料區段中都會發生角色切換
  • 隨著角色分配的穩定，應用程式可能會遇到短暫的 I/O 錯誤或延遲

影響：

  • 客戶影響：對於較短的維護視窗（少於 5 秒），影響幾乎不明顯。若要延長使用使用中 I/O 的維護時間，可能會發生數千個角色切換，導致 I/O 持續停滯
  • 持續時間：在重返社會階段持續，直到重新平衡完成
  • 復原：自動

事件鏈：

Log Source  Event / Pattern
MDM events  Role-switch operations across the storage pool during exit
SDS traces  Repeated role-switch operations during reintegration

MDM 事件順序範例：

SDS_MAINTENANCE_MODE_EXIT_STARTED    SDS maintenance mode exit started
SDS_MAINTENANCE_MODE_EXIT_COMPLETED   SDS maintenance mode exit completed

記錄輸出：
 

注意：以下記錄範例為在多次發生此問題時所觀察到之模式的通用表示。它們與上面列出的任何特定方案無關 - 無論觸發器如何，都會出現相同的模式。


MDM 事件記錄：MDM 事件記錄會顯示叢集層級的順序。關鍵指標是維護模式退出期間的角色切換操作。

SDS 追蹤記錄：在 SDS 節點上，追蹤記錄會顯示重新整合期間重複的角色切換作業： 

raidComb_SetPriTgtGenNum: combId <id> combGenNum: cur <gen> new <gen>
contCmd_SetCombState: CombId <id> devId <id> PRI->SEC Switch roles
contCmd_SetCombState: CombId <id> devId <id> SEC->PRI Switch roles

在短時間內（在幾秒鐘內）大量切換角色條目是此問題的最終 SDS 端指標。

SDC/主機記錄：VMware （ESXi） SDC I/O 重試，顯示梳子、目標 SDS 和故障代碼：

vmkernel log
PowerFlex mapVolIO_Do_CK:1496 :Mit: <addr>. Retrying IO Type WRITE. Failed comb: <id>. SDS_ID <id>. Comb Gen <gen>. Head Gen <gen>.
PowerFlex mapVolIO_Do_CK:1510 :Mit: <addr>. Vol ID <id>. Last fault Status IO_FAULT_NOT_PRI(12). Retry count (1)

如果重試用盡，則傳回 SCSI 錯誤： 

sense data: 0x4 0x0 0x0   -- SCSI Hardware Error

診斷秘訣：如果在多個 SDS 節點（不僅僅是發生問題的節點）上看到 I/O 錯誤，這可能表示角色切換風暴，而不是正常的降級狀態行為。如果 I/O 錯誤隔離至單一 SDS，這是預期的降級狀態行為。

案例 5：維護模式階段轉換 

何時可能發生這種情況：
在 SDS 進入或退出維護模式 （IMM 或 PMM） 的轉換期間，狀態從正常變為 MM，或從 MM 變回正常。

會發生什麼：

  • 角色均衡器重新分配數據責任以適應更改
  • 當系統適應新的安排時，會出現短暫的角色切換突發
  • 應用程式在轉換期間可能會遇到短暫的延遲峰值

影響：

  • 客戶影響：短暫的延遲高峰持續數秒至數分鐘。通常低於應用程式逾時閾值
  • 持續時間：持續數秒至數分鐘，然後穩定下來
  • 復原：自動

事件鏈：

Log Source  Event / Pattern
SDS traces  Brief role-switch operations during phase transitions

Cause

當群集由於 SDS 丟失或維護模式操作而轉換狀態時，MDM 角色平衡邏輯中的軟體缺陷會導致反饋迴圈。

在某些情況下，MDM 會反覆重新指派負責為受影響的梳子提供 I/O 的 SDS 節點。每次重新指派都會使 SDC 的資料所在位置快取檢視失效，強制執行 I/O 重試。當多個梳子同時受到影響時，重新分配的數量會超過SDC的更新能力，從而導致多個主機之間持續的I/O錯誤。

風暴通常是自限性的。它會在叢集穩定後解決，但持續時間取決於保護網域的大小和事件發生時的 I/O 負載。

Resolution

此問題已在 PowerFlex Core 4.5.6 版中解決。一旦可用，請升級至此版本。請聯絡 Dell 支援 以取得版本時間表資訊。

對於計劃內維護操作：

  • 在 MDM 記錄之前，請勿重新啟動或重新啟動 SDS SDS_MAINTENANCE_MODE_STARTED。請先確認 SDS 已完全進入維護模式，再繼續進行實體維護。
  • 監控進入或退出維護模式時的延遲尖峰。

若為意外 SDS 服務中斷：

  • 風暴具有自限性，通常會在星團穩定下來后幾分鐘內消退。如果發現此問題，請收集 getinfo 在事件發生後，儘快從保護網域中的所有 SDS 節點、所有管理員 MDM 記錄，並聯絡 Dell 支援。

在極少數情況下，如果問題無法自行解決，暫時停用並重新啟用重建可讓 MDM 穩定下來：

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --disable_rebuild

# 等待 5-10 秒，然後啟用重建： 

scli --set_rebuild_mode --protection_domain_name <pd_name> --storage_pool_name <sp_name> --enable_rebuild

 

重要：在停用重建時，叢集已減少冗餘。僅停用重建足以讓系統穩定下來，然後立即重新啟用。建議您在 Dell 支援指引下執行此動作。 

 

注意：重建在存儲池級別進行管理。如果受影響的 SDS 在多個儲存集區中有裝置，請將此動作套用至每個受影響的儲存集區。未包含受影響軟體定義儲存 （SDS） 裝置的儲存集區不會受到影響。保護網域、儲存集區和 SDS 至裝置的對應可從 scli --query_all 命令輸出。 

Affected Products

PowerFlex rack, PowerFlex Appliance, PowerFlex rack connectivity, PowerFlex Software
Article Properties
Article Number: 000450312
Article Type: Solution
Last Modified: 12 أيار 2026
Version:  5
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.