PowerFlex：过多的数据角色切换会导致 IO 延迟和错误

Сводка: 本文介绍了数据过多的角色切换如何导致 I/O 延迟和错误。

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

Симптомы

在某些群集状态转换下，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

Причина

当群集由于 SDS 丢失或维护模式操作而转换状态时，MDM 角色平衡逻辑中的软件缺陷会导致反馈循环。

在某些情况下，MDM 会反复将负责为 I/O 提供服务的 SDS 节点重新分配给受影响的梳子。每次重新分配都会使 SDC 的数据所在位置的缓存视图失效，从而强制重试 I/O。当多个梳子同时受到影响时，重新分配量会超过 SDC 的更新能力，从而导致跨多个主机的持续 I/O 错误。

风暴通常是自限性的。群集稳定后会解决问题，但持续时间取决于事件发生时保护域的大小和 I/O 负载。

Разрешение

此问题已在 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 命令输出。 

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

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