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

Сводка: 本文說明過多資料的角色切換如何導致 I/O 延遲和錯誤。

Данная статья применяется к Данная статья не применяется к Эта статья не привязана к какому-либо конкретному продукту. В этой статье указаны не все версии продуктов.
Ознакомьтесь с другими ресурсами

Симптомы

在某些群集狀態轉換下，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

Причина

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

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

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

Разрешение

此問題已在 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 命令輸出。 

Затронутые продукты

PowerFlex rack, PowerFlex Appliance, PowerFlex rack connectivity, PowerFlex Software
Свойства статьи
Номер статьи: 000450312
Тип статьи: Solution
Последнее изменение: 12 May 2026
Версия:  5
Получите ответы на свои вопросы от других пользователей Dell
Услуги технической поддержки
Проверьте, распространяются ли на ваше устройство услуги технической поддержки.