硬件SATA RAID-10arrays中的单个磁盘如何使整个arrays停止响应？
序幕：
我是一个代码猴，越来越多地为我的小公司承担了系统pipe理职责。 我的代码是我们的产品，越来越多的我们提供与SaaS相同的应用程序。
大约18个月前，我把我们的服务器从一个高级托pipe中心的供应商转移到了一个四级数据中心的准系统机架推进器。 （字面意思是在街对面）。这种做法比我们自己做得更多，比如networking，存储和监控。
作为这一举措的一部分，为了从托pipe公司中replace我们租用的直连存储，我构build了一个基于SuperMicro机箱，3ware RAID卡，Ubuntu 10.04，二十几个SATA磁盘，DRBD和RAID的9TB双节点NAS。 以下三篇博文都详细logging了这些内容： 构build和testing新的9TB SATA RAID10 NFSv4 NAS： 第I 部分 ， 第II 部分和第III部分 。
我们还设置了一个Cacit监控系统。 最近我们添加了越来越多的数据点，如SMART值。
如果没有ServerFault上 真棒的 boffins ，我不能完成所有这些工作。 这是一个有趣和教育的经验。 我的老板很高兴（我们节省了桶的$$$） ，我们的客户很高兴（存储成本下降） ，我很高兴（有趣，有趣，有趣） 。
直到昨天。
停电和恢复：
午餐后的一段时间，我们开始从我们的应用程序 – 一个按需stream媒体CMS获取性能低下的报告。 与此同时，我们的仙人掌监控系统发送了一封电子邮件。 其中一个更有说服力的警报是iostat等待的图表。
性能变得如此退化，Pingdom开始发送“服务器closures”通知。 整体负荷适中，没有交通高峰。
在login到NAS的NFS客户端之后，我确认几乎所有事情都经历了高度间歇性的，非常长的IO等待时间。 一旦我跳到主NAS节点本身，尝试导航问题arrays的文件系统时，相同的延迟是明显的。
时间到了崩溃，那很好。 在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]:
所以我去检查数组中的磁盘的仙人掌图。 在这里，我们看到，是的，磁盘7正在像syslog所说的那样滑落。 但是我们也看到磁盘8的SMART Read Erros波动。
系统日志中没有关于磁盘8的消息。 更有意思的是， 磁盘8的波动值直接关系到高IO等待时间！ 我的解释是：
- 磁盘8正在经历一个奇怪的硬件故障，导致间歇性的长时间运行。
- 不知何故，磁盘上的这种故障状态正在locking整个arrays
也许有更准确或更正确的描述，但最终的结果是一个磁盘影响整个arrays的性能。
问题（S）
- 硬件SATA RAID-10arrays中的单个磁盘如何使整个arrays停止响应？
- 我是否天真地认为RAID卡应该已经处理了？
- 我怎样才能防止一个单一的行为不端的磁盘影响整个arrays？
- 我错过了什么吗？
我不想在关键的生产环境中说“不要使用SATA”，但我经常看到这种情况。 SATA驱动器通常不是针对您所描述的工作周期而devise的，尽pipe您已经在您的设置中专门针对24×7的操作评估了驱动器 。 我的经验是，SATA驱动器可能以不可预知的方式故障，即使在使用RAID 1 + 0时，也经常影响整个存储arrays，就像您所做的那样。 有时候驱动器会以可能拖延整个总线的方式失效。 有一点需要注意的是，您是否在您的设置中使用SAS扩展器。 这可能会影响剩余磁盘如何受到驱动器故障的影响。
但是使用中线/近线（7200 RPM）的SAS驱动器与SATA相比，可能更为合理 。 与SATA相比，价格有小幅上涨的趋势，但驱动器的运行/失败更可预测。 SAS接口/协议中的错误纠正和报告比SATA设备更为稳健。 因此，即使硬盘的机制相同 ，SAS协议的差异也可能避免了您在硬盘故障期间所经历的痛苦。
一个磁盘怎么能打倒arrays呢？ 答案是不应该，但是这取决于是什么原因导致停机。 如果磁盘是以某种方式死去的，那就不应该把它拿下来。 但有可能是因为控制器无法处理的“边缘情况”而失败。
你是否天真认为这不应该发生？ 不，我不这么认为。 像这样的硬件RAID卡应该已经处理了大部分问题。
如何预防呢？ 你不能期望这样的奇怪的边缘情况。 这是作为系统pipe理员的一部分…但是您可以使用恢复程序来避免影响您的业务。 现在唯一能解决这个问题的方法就是尝试使用另一个硬件卡（不太可能是你想做的），或者将你的硬盘改成SAS硬盘而不是SATA硬盘。 你也可以联系你的RAID卡供应商，告诉他们发生了什么事，看看他们说什么; 毕竟，他们是一家专门研究无序驱动电子元件的公司。 他们可能会有更多关于驱动器如何工作以及可靠性方面的技术build议……如果您可以find合适的人员进行交stream。
你错过了什么？ 如果要validation驱动器是否存在边缘故障，请将其从arrays中拉出。 arrays将被降级，但是不应该有更多奇怪的减速和错误（除了降级的arrays状态）。 你现在说它似乎工作正常，但如果它有磁盘读取错误，你应该尽可能地更换驱动器。 高容量驱动器有时会出现URE错误（最好不要运行RAID 5，注意事项），直到另一个驱动器出现故障才显示。 如果您遇到来自该驱动器的边缘情况行为，则不希望损坏的数据迁移到arrays中的其他驱动器。
我不是专家，但是我会根据我在RAID控制器和存储arrays方面的经验，在黑暗中拍摄一张照片。
磁盘以许多不同的方式失败。 不幸的是，磁盘可能会出现故障，或者出现故障，其性能受到严重影响，但RAID控制器看起来不是故障。
如果磁盘出现故障，任何RAID控制器软件都应该很好地检测到磁盘没有响应，将其从池中删除，并发出任何通知。 不过，我对这里发生的事情的猜测是，磁盘遭受了一个不寻常的故障，由于某种原因，在控制器端没有触发故障。 因此，当控制器正在执行写入刷新或从受影响的磁盘读取时，需要很长时间才能返回，从而挂起整个IO操作，因此挂起arrays。 不pipe出于什么原因，这对RAID控制器来说是不够的，可能是因为数据最终回来了。
我的build议是立即更换发生故障的磁盘。 之后，我会看看你的RAID卡的configuration（这是3ware，我认为它们非常好），并找出它认为是一个失败的磁盘。
PS好点子将SMART导入仙人掌。
您需要企业级存储设备的function。 具体而言，WD RE 4企业级驱动器具有防止RAIDarrays中的这种行为所需的两个function。 下面列出的第一项技术可防止旋转谐波振动对硬盘机械部件造成不必要的磨损。 第二个技术是什么导致你的问题，SATA协议没有这个function。 要获得这些function，您需要SAS，如果您坚持使用SATA驱动器，则可以购买SAS到SATA插卡（如LSISS9252）。
增强型RAFF技术先进的电子元件可以监测驱动器并实时校正线性和旋转振动。 与以前的驱动器相比，高振动环境下的性能显着提高。
特定于RAID的时间限制错误恢复（TLER）防止由台式机驱动器常见的扩展硬盘错误恢复过程引起的硬盘崩溃。
http://en.wikipedia.org/wiki/Error_recovery_control#Overview
另请参阅下面的链接：
http://en.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers
另请参阅：Western Digital TLER文档深入解释错误恢复过程。 WD Caviar RAID版本中的错误恢复辐射防护串行ATA硬盘：
只是猜测：硬盘configuration为重试读取错误，而不是报告错误。 虽然这在桌面环境中是理想的行为，但是在RAID（控制器应该重写任何从其他磁盘读取失败的扇区，因此驱动器可以重新映射它）的情况下会起反作用。
我在黑暗中的镜头：
-
驱动器7正在失败。 它有一些失败的窗口，它不可用。
-
驱动器8也有一些“较轻”的错误; 通过重试纠正。
-
RAID10通常是“几个RAID1对的RAID0”，是同一对驱动器中的第7个和第8个成员？
如果是这样的话，那么看起来你在同一对中出现了“不应该发生”双盘故障的情况。 几乎是唯一可以杀死RAID10的东西。 不幸的是，如果你所有的驱动器都是来自同一批货物的话，就会发生这种情况，所以它们有可能同时死亡。
我猜想，在驱动器7发生故障时，控制器将所有读取redirect到驱动器8，所以任何错误重试都会导致严重的延迟，从而导致一系列冻结任务的崩溃，导致性能暂时下降。
你很幸运，驱动器8似乎还没有死，所以你应该能够修复没有dataloss。
我会开始更换两个驱动器，不要忘记检查电缆。 松散的连接可能会导致这种情况，如果路由不稳定，则更可能发生在相邻的驱动器中。 此外，一些多端口卡有几个双端口连接器，如果驱动器7和驱动器8在同一个端口上，则可能是您的麻烦来源。
SATA内插卡是另一种解决scheme。
我最近经历了同样的命运，发现了这个线索。 总的来说，SAS 协议比SATA更适合RAID，因为SATA缺乏function。 这就是为什么相同的物理驱动器配备SAS控制器，然后作为Nearline SAS出售。
进一步search，我发现：
http://www.lsi.com/products/storagecomponents/Pages/LSISS9252.aspx
我正在研究用一批这种方式升级我的一个存储库。 目前，3TB SATA与SAS之间的价格差异为400％（香草价格，同一品牌，规格和商店，德国）。 我显然不知道这个策略是否运作良好，但值得一试。
评论非常欢迎:-)
我已经看到一个SATA电子盘破损的电子产品locking了Areca 12的固件初始化，没有办法访问BIOS，更不用说从任何介质启动机器，直到通过在二进制文件中取出磁盘发现有问题的硬盘驱动器search时尚。