☰

序幕：

tag-icon • tag-icon performance hard-drive hardware-raid sata sas
序幕：

序幕：

我是一名代码猿，越来越多地承担我小公司的系统管理员职责。我的代码就是我们的产品，我们越来越多地提供与 SaaS 相同的应用程序。

大约 18 个月前，我将我们的服务器从以优质托管为中心的供应商转移到四级数据中心的准系统机架推杆上。（就在街对面。）这意味着我们自己可以做更多的事情——比如网络、存储和监控。

作为这次大迁移的一部分，为了替换我们从托管公司租用的直接连接存储，我基于 SuperMicro 机箱、3ware RAID 卡、Ubuntu 10.04、二十几个 SATA 磁盘、DRBD 等构建了一个 9TB 双节点 NAS。这一切都在三篇博客文章中进行了详尽的记录：构建和测试新的 9TB SATA RAID10 NFSv4 NAS：第一部分，第二部分和第三部分。

我们还设置了 Cacti 监控系统。最近我们添加了越来越多的数据点，例如 SMART 值。

如果没有惊人的 科学家 在 服务器故障。这是一次有趣且有教育意义的经历。我的老板很高兴（我们节省了大笔资金），我们的客户很高兴（存储成本下降）， 我很高兴（有趣，有趣，有趣）。

直到昨天。

中断与恢复：

午饭后不久，我们开始收到应用程序（一款按需流媒体 CMS）性能低下的报告。大约在同一时间，我们的 Cacti 监控系统发送了大量电子邮件。其中一个更有说服力的警报是 iostat await 图表。

在此处输入图片描述

性能变得如此糟糕以至于 Pingdom 开始发送“服务器宕机”通知。总体负载适中，没有出现流量高峰。

登录到应用服务器（NAS 的 NFS 客户端）后，我确认几乎所有东西都经历了高度间歇性和极长的 IO 等待时间。一旦我跳到主 NAS 节点本身，在尝试导航问题阵列的文件系统时，同样的延迟显而易见。

故障转移时间到了，一切进展顺利。20 分钟内确认一切恢复正常并正常运行。

事后分析：

在所有系统故障发生后，我都会进行事后分析以确定故障原因。我做的第一件事就是通过 ssh 重新登录系统并开始查看日志。系统完全处于离线状态。是时候去数据中心了。硬件重置、备份并运行。

我/var/syslog发现了这个看起来很吓人的条目：

Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_00], 6 Currently unreadable (pending) sectors
Nov 15 06:49:44 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_07], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 171 to 170
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 16 Currently unreadable (pending) sectors
Nov 15 06:49:45 umbilo smartd[2827]: Device: /dev/twa0 [3ware_disk_10], 4 Offline uncorrectable sectors
Nov 15 06:49:45 umbilo smartd[2827]: Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
Nov 15 06:49:45 umbilo smartd[2827]: # 1  Short offline       Completed: read failure       90%      6576         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 2  Short offline       Completed: read failure       90%      6087         3421766910
Nov 15 06:49:45 umbilo smartd[2827]: # 3  Short offline       Completed: read failure       10%      5901         656821791
Nov 15 06:49:45 umbilo smartd[2827]: # 4  Short offline       Completed: read failure       90%      5818         651637856
Nov 15 06:49:45 umbilo smartd[2827]:

所以我去检查了阵列中磁盘的 Cacti 图表。在这里我们看到，正如系统日志所言，磁盘 7 确实正在消失。但我们也看到磁盘 8 的 SMART Read Erros 正在波动。

在此处输入图片描述

系统日志中没有关于磁盘 8 的消息。更有趣的是磁盘 8 的波动值与高 IO 等待时间直接相关！ 我的解释是：

  • 磁盘 8 出现奇怪的硬件故障，导致间歇性长时间运行。
  • 磁盘上的这种故障情况不知何故锁定了整个阵列

也许有更准确或正确的描述，但最终结果是，一个磁盘正在影响整个阵列的性能。

问题

  • 硬件 SATA RAID-10 阵列中的单个磁盘如何导致整个阵列突然停止？
  • 我是不是太天真了，认为 RAID 卡应该能够解决这个问题？
  • 如何防止单个行为异常的磁盘影响整个阵列？
  • 我是否遗漏了什么？

答案1

我讨厌在关键生产环境中说“不要使用 SATA”，但我经常看到这种情况。SATA 驱动器通常不适合您描述的占空比，尽管您确实指定了专门为全天候运行而设计的驱动器在您的设置中。我的经验是，SATA 驱动器可能会以不可预测的方式发生故障，通常会影响整个存储阵列，即使使用 RAID 1+0 也是如此，就像您所做的那样。有时驱动器的故障方式可能会导致整个总线停滞。需要注意的一件事是您是否在设置中使用 SAS 扩展器。这可能会对驱动器故障对其余磁盘的影响产生影响。

但也许更有意义的是中线/近线 (7200 RPM) SAS 驱动器与 SATA 相比。价格略高于 SATA，但驱动器的运行/故障更可预测。SAS 接口/协议中的错误更正和报告比 SATA 集更强大。因此，即使驱动器其机制相同，SAS 协议的差异可能已经避免了您在驱动器故障期间所经历的痛苦。

答案2

单个磁盘如何导致阵列瘫痪？答案是不应该，但这在某种程度上取决于导致故障的原因。如果磁盘以正常的方式损坏，则不应将其关闭。但它有可能以控制器无法处理的“边缘情况”方式发生故障。

您认为这种情况不应该发生，是不是太天真了？不，我不这么认为。像这样的硬件 RAID 卡应该可以处理大多数问题。

如何预防？您无法预料到这种奇怪的极端情况。这是系统管理员职责的一部分……但您可以制定恢复程序以防止其影响您的业务。现在尝试修复此问题的唯一方法是尝试另一张硬件卡（可能不是您想要做的）或将驱动器更改为 SAS 驱动器而不是 SATA，以查看 SAS 是否更强大。您还可以联系 RAID 卡的供应商，告诉他们发生了什么，看看他们怎么说；毕竟，他们是一家专门了解不稳定驱动器电子设备的公司。他们可能会对驱动器的工作原理以及可靠性提供更多技术建议……如果您能找到合适的人来谈谈的话。

你错过了什么吗？如果你想验证驱动器是否发生了极端情况故障，请将其从阵列中拉出。阵列将降级，但你不应该再遇到更多奇怪的减速和错误（降级的阵列状态除外）。你说现在它似乎运行良好，但如果它有磁盘读取错误，你应该尽可能更换驱动器。大容量的驱动器有时会出现 URE 错误（不运行 RAID 5 的最佳原因，附注），直到另一个驱动器发生故障才会显示出来。如果你遇到该驱动器的极端情况行为，你不希望损坏的数据迁移到阵列中的其他驱动器。

答案3

我不是专家，但我将根据我对 RAID 控制器和存储阵列的经验进行尝试。

磁盘故障有很多种方式。遗憾的是，磁盘可能会发生故障或出现故障，其性能会受到严重影响，但 RAID 控制器却不会将其视为故障。

如果磁盘明显出现故障，任何 RAID 控制器软件都应该能够很好地检测磁盘的响应缺失，将其从池中移除并发出任何通知。但是，我猜测这里发生的情况是磁盘出现了异常故障，但由于某种原因，它并没有触发控制器端的故障。因此，当控制器对受影响的磁盘进行写入刷新或读取时，需要很长时间才能恢复，从而导致整个 IO 操作和阵列挂起。无论出于什么原因，这都不足以让 RAID 控制器发出“啊，磁盘故障”的警报，可能是因为数据最终会恢复。

我的建议是立即更换故障磁盘。之后，我会查看 RAID 卡的配置（它是 3ware，我认为它们相当不错）并找出它认为故障磁盘是什么。

PS 将 SMART 导入 Cacti 是个好主意。

答案4

我的猜测：

  • 驱动器 7 出现故障。它有一些不可用的故障窗口。

  • 驱动器 8 也有一些“较轻”的错误；已通过重试纠正。

  • RAID10 通常是“几个 RAID1 对中的 RAID0”，驱动器 7 和 8 是同一对的成员吗？

如果是这样，那么似乎您遇到了“不应该发生”的同一对两个磁盘发生故障的情况。这几乎是唯一可以杀死 RAID10 的事情。不幸的是，如果您的所有驱动器都来自同一批货物，则可能会发生这种情况，因此它们同时损坏的可能性略有增加。

我猜测在驱动器 7 发生故障期间，控制器将所有读取重定向到驱动器 8，因此任何错误重试都会导致很大的延迟，从而引起大量冻结任务，暂时影响性能。

你很幸运，8 号驱动器似乎还没有坏掉，所以你应该能够在不丢失数据的情况下进行修复。

我会先更换两个驱动器，并且不要忘记检查电缆。连接松动可能会导致这种情况，如果连接不牢固，则更有可能发生在相邻的驱动器中。此外，一些多端口卡有几个双端口连接器，如果驱动器 7 和驱动器 8 位于同一个驱动器上，则这可能是问题的根源。

相关内容