☰

为什么 mdadm 无法处理“几乎失败”的磁盘？

tag-icon • tag-icon storage mdadm
为什么 mdadm 无法处理“几乎失败”的磁盘？

在我的职业生涯中，我多次在各种环境（例如 CentOS/Debian 机箱、Synology/QNAP NAS）中遇到 mdadm RAID 集（RAID1+0、5、6 等），它们似乎根本无法处理故障磁盘。这是一个没有完全坏掉的磁盘，但有数万个坏扇区，根本无法处理 I/O。但是，它并没有完全坏掉，它仍然可以工作。内核日志通常充满了 UNC 错误。

有时，SMART 会将磁盘识别为故障，有时除了 I/O 速度慢之外没有其他症状。

缓慢的 I/O 实际上会导致整个系统冻结。通过 ssh 连接需要很长时间，webGUI（如果是 NAS）通常会停止工作。通过 ssh 运行命令也需要很长时间。直到我断开/故意将磁盘从阵列中“故障”，然后一切才会恢复“正常” - 这是降级阵列所能达到的最正常状态。

我只是想知道，如果磁盘读取/写入需要这么长时间，为什么不直接将其从阵列中剔除，在日志中留下一条消息并继续运行呢？似乎因为一个磁盘有点问题而使整个系统陷入停顿，完全抵消了使用 RAID 的主要好处之一（容错 - 如果磁盘发生故障，仍能继续运行的能力）。我可以理解，在单磁盘情况下（例如，您的系统连接了单个 SATA 磁盘，并且无法正确执行读取/写入），这是灾难性的，但在 RAID 集中（尤其是容错“个性”），这似乎不仅令人讨厌，而且违背常识。

mdadm 的默认行为基本上是使盒子瘫痪，直到有人远程登录并手动修复它，这是否有一个非常好的理由？

答案1

一般来说，袭击根据所选的突袭等级，在关键目标之间提供不同的平衡 数据冗余， 可用性， 表现和容量。

根据具体要求，仓储所有者的责任决定各种因素之间的哪种平衡对于既定目的而言是正确的，创造一个可靠的解决方案。

所选 Raid 解决方案（此处我们讨论的是软件mdadm）的工作首先是确保数据保护。考虑到这一点，很明显，raid 解决方案的工作不是将业务连续性置于数据完整性之上。

换句话说：mdadm 的工作是避免 raid 失败。只要“行为异常的磁盘”没有完全损坏，它仍然有助于 raid。

那么为什么不直接把行为异常的磁盘从阵列中剔除，在日志中删除一条消息然后继续运行呢？因为这样做会增加丢失数据的风险。

我的意思是，你是对的，就目前而言，从业务角度来看，继续下去似乎是更好的解决方案。但实际上，被丢弃到日志中的消息可能仍未被发现，因此 raid 的降级状态仍未被发现。一段时间后，最终同一个 raid 中的另一个磁盘发生故障，结果故障 raid 上存储的数据最终消失了。

此外：很难准确定义什么是“行为异常的磁盘”。换言之：在磁盘阵列中操作的单个磁盘的可接受操作行为是什么？

我们中的一些人可能会回答“磁盘显示一些错误”。其他人可能会回答：“只要错误可以纠正，一切都很好”。其他人可能会回答：“只要磁盘在给定时间内响应所有命令，一切都很好”。其他人说“如果磁盘温度与同一阵列内所有磁盘的平均温度相差超过 5°C”。另一个答案可能是“只要清理没有显示任何错误”，或“只要 SMART 没有显示错误”。

所写的并不是一个很长的清单，也不是一个完整的清单。

关键在于“磁盘可接受行为”的定义是一个解释的问题，因此也是存储所有者的责任，而不是 mdadm 应该自行决定的事情。

答案2

关键问题是，发生故障的 SATA 磁盘驱动器有时会在其内部错误恢复过程期间冻结整个总线。因此，应该使用启用 TLER仅在 RAID 阵列中驱动（最好是企业级型号）。

SAS 驱动器受此问题的影响较小，但也无法完全避免。

答案3

除了所说的内容之外，我还想补充一些我的看法，但这一点是重要的考虑因素。

什么开车当扇区读取速度很慢时会发生什么？

据称，设计为单独运行的驱动器（例如典型的“台式机”驱动器）假定没有其他方法可以检索存储在该坏扇区中的数据。它们会不惜一切代价尝试检索数据，在很长一段时间内不断重复。当然，它们也会将该扇区标记为故障，因此它们会在您下次写入时重新映射它，但您必须为此写入。在您重写它之前，每次您从该位置读取时它们都会阻塞。在 RAID 设置中，这意味着对于 RAID，驱动器仍然有效，没有理由将其踢出，但对于应用程序，阵列将变慢到爬行。

另一方面，“企业”硬盘，尤其是“品牌”硬盘，通常认为它们总是在 RAID 设置中使用。“品牌”控制器看到“品牌”硬盘时，实际上甚至可能通知他们的固件会记录 RAID 存在情况。因此，即使可以进行多次尝试并读取扇区，驱动器也会提前停止并报告 I/O 错误。然后控制器有机会更快地做出响应，将读取指令镜像到同级驱动器（并将坏驱动器踢出阵列）。当您拉出并彻底探索/测试被踢出的驱动器时，您不会发现任何明显问题 — 根据控制器逻辑，它只是速度减慢了一会儿，这足以停止使用它。

我猜测这可能是唯一的“台式机”硬盘与“品牌”/“企业”NL-SAS 和 SATA 硬盘之间的区别。这可能就是为什么当您购买实际上由东芝制造的“HPE”硬盘时，与购买“东芝”品牌的硬盘相比，您要多付三倍的费用。

但是，有些驱动器确实支持一些通用控制。它被称为 SCT ERC，用于SMART 命令传输错误恢复控制。它看起来是这样的smartctl：

不支持

# smartctl --all /dev/sda
=== START OF READ SMART DATA SECTION ===
SCT capabilities:              (0x3037) SCT Status supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

支持的

=== START OF READ SMART DATA SECTION ===
...
SCT capabilities:              (0x003d) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

如果你幸运的话，你可以用 来控制这个功能smartctl。你可以检索或设置两个超时时间，即尝试重新读取多长时间以及尝试重新写入多长时间：

# smartctl -l scterc /dev/sda
SCT Error Recovery Control:
           Read:     70 (7.0 seconds)
          Write:     70 (7.0 seconds)

# smartctl -l scterc /dev/sde
SCT Error Recovery Control:
           Read: Disabled
          Write: Disabled

# smartctl -l scterc /dev/sdd
Warning: device does not support SCT Error Recovery Control command

smartctl -l scterc,120,60 /dev/sde

意思是：120 秒后重试读取；60 秒后重试写入。零表示“重试直至死机”。不同的驱动器对此有不同的默认设置。

因此，如果您单独使用“RAID 版”驱动器，最好将 ERC 超时设置为零，否则可能会丢失数据。另一方面，如果您在 RAID 中使用驱动器，最好设置一些合理的低非零设置。

来源：amarao @ Habrahabr，俄语。

PS 还有关于 SAS 的说明。使用sdparm，它支持更多控制。

答案4

我遇到过磁盘无法工作的情况，但以某种方式取出了控制器。

从历史上看，这在 PATA 中是可能的，因为主驱动器和从驱动器位于同一条电缆上，一个驱动器发生故障可能会干扰对另一个仍然良好的驱动器的访问。移除故障驱动器可能会重新启用对剩余驱动器的访问，或者可能需要关闭电源，但 RAID 可能会降级，然后可以开始恢复。

SATA 不太容易受到这种影响，但控制器仍然可能受到影响。从我对软件突袭的经验来看，软件突袭暴露的更多内部零件会被更精致的专用突袭控制器隐藏起来。

我没有在 SAS 或 NVME 上遇到过这种情况，但 SAS 通常意味着硬件 raid 控制器在内部具有更多的磁盘处理智能。

相关内容