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 角色平衡逻辑可跨多个 Comb（跟踪哪些 SDS 节点存储每条卷数据的内部数据结构）生成快速、重复的主要/辅助角色切换。每个角色切换都会使客户端 （SDC） 梳子映射失效，并强制重试 I/O。当有足够多的 comb 同时受到影响时，累积重试开销会导致 SDC 主机上出现 I/O 延迟峰值和 I/O 错误。根据主机环境的不同，这可能会导致应用程序 I/O 超时、虚拟机进入只读状态或文件系统不可用。

此行为已在多个触发情形下观察到，并且不限于任何单个操作过程。

常见迹象

  • MDM_DATA_DEGRADED 事件后跟持续 1-15+ 分钟的持续 I/O 延迟
  • SDC 主机在降级窗口内报告 I/O 错误和/或 I/O 超时
    • VMware （ESXi）：VMFS 心跳超时，SCSI 硬件错误 （sense data: 0x4 0x0 0x0），虚拟机进入只读状态，潜在的 HA 故障切换
    • Linux：系统日志中的 I/O 错误 （/var/log/messages, dmesg），应用程序可能会遇到 I/O 超时或文件系统重新装载只读的情况
  • MDM 事件日志显示，对于单个 SDS 丢失，系统处于 DEGRADED 状态的时间比预期的要长
  • 系统最终自行恢复到正常状态，无需手动干预（通常）
 
提醒：在撰写本文时，仅在具有 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）
  • 连接到该 SDS 的所有 SDC 都会在 SDC 断开连接事件→失去连接
  • MDM 将群集标记为 DEGRADED（事件） 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：SDS 在 PMM 条目期间关闭电源

何时可能发生：
这是一种罕见的方案，需要同时有两个事件：

  • SDS 正在进入受保护维护模式 （PMM）
  • 在 PMM 转换完成之前，SDS 发生故障或已关闭

会发生什么情况： 

  • MDM 接收 PMM 条目命令并将其记录为成功
  • 当 PMM 条目仍在进行时，SDS 意外分离
  • MDM 将群集标记为“DEGRADED”
  • 角色平衡器在整个 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：即时维护模式 （IMM） 下的 SDS

何时可能发生：
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 中得到解决。一旦可用，请升级到此版本。有关发布时间表信息，请联系 戴尔支持 。

对于计划内维护操作：

  • 在 MDM 记录之前，请勿重启或重新启动 SDS SDS_MAINTENANCE_MODE_STARTED。在继续物理维护之前，验证 SDS 是否已完全进入维护模式。
  • 在进入或退出维护模式时监视延迟峰值。

对于计划外 SDS 中断：

  • 风暴具有自我限制性，通常会在群集稳定后几分钟内解决。如果发现问题，请收集 getinfo 在事件发生后尽快从保护域中的所有 SDS 节点和所有管理器 MDM 收集日志，并联系 戴尔支持。

在问题无法自行解决的极少数情况下，临时禁用并重新启用重建可使 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

 

重要提示：群集减少了冗余，同时禁用了重建。请禁用重建的时间，以使系统稳定下来，然后立即重新启用。建议在戴尔支持的指导下执行此操作。 

 

提醒：重建在存储池级别进行管理。如果受影响的 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.