前奏:
我是一个代码猴子,越来越多地为我的小公司承担SysAdmin的职责。我的代码是我们的产品,并且越来越多的我们提供与SaaS相同的应用程序。
大约18个月前,我将服务器从以托管主机为中心的高级供应商迁移到了IV数据中心的准系统机架推动器。 (字面上就是街对面。)这项工作本身就可以做很多事情-网络,存储和监控之类的事情。
作为一项重大举措,为了取代托管公司租用的直接连接存储,我建造了一个9TB的存储空间节点的NAS基于SuperMicro机箱,3ware RAID卡,Ubuntu 10.04,两打SATA磁盘,DRBD和。这三个博客文章都记录了这些内容:构建和测试新的9TB SATA RAID10 NFSv4 NAS:第一部分,第二部分和第三部分。
我们还建立了一个Cacit监控系统。最近,我们已经添加了越来越多的数据点,例如SMART值。
没有ServerFault的出色功能,我无法完成所有这些工作。这是一次有趣的教育经历。我的老板很高兴(我们节省了很多钱),我们的客户很高兴(存储成本降低了),我很开心(乐趣,有趣,有趣)。
直到昨天。
停电与恢复:
午饭后的一段时间,我们开始从我们的应用程序(按需流媒体CMS)中收到有关性能不佳的报告。大约在同一时间,我们的仙人掌监测系统发送了大量电子邮件。更具说服力的警报之一是iostat等待的图形。

性能变得如此差,以致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就像syslog所说的那样滑落了。但是我们还看到磁盘8的SMART Read Erros波动。

syslog中没有有关磁盘8的消息。更有趣的是,磁盘8的波动值直接与高IO等待时间相关!我的解释是:

磁盘8遇到奇怪的硬件故障,导致间歇性的长时间运行。
以某种方式,磁盘上的这种故障情况将锁定整个阵列。

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

硬件SATA RAID-10阵列中的单个磁盘如何使整个阵列陷入停顿?
我天真地认为RAI​​D卡应该已经解决了吗?
如何防止单个异常运行的磁盘不会影响整个阵列?
我遗漏了什么吗?


评论

您提出的另一个精心编写的问题+1。总是很乐于阅读(但不幸的是,我什至无法理解)。

@daff:购买这种设置的持续预算,与惠普的同类产品相比,我们节省了66%。我们在此盒子上放置了一年的寿命,不需要持续更长的时间。请记住,这是一个储物盒,成本逐年下降。

3Ware本身还不错。我在Dell系统上的PERC卡上有过奇怪的举动,该系统应该是不错的服务器硬件。 3Ware卡应该带有板载电池等,因此我对该决定不会感到太糟糕。好的,您可能会对SAS与SATA的决定感到震惊,但是您并没有丢失数据,因此从您的问题来看,您似乎已经拥有备份和监视功能,因此您的表现不错:-)

@StuThompson:当然,预算和使用消费类硬件会更便宜,并且大多数情况下它会运行良好,尤其是在您的情况下,当它背后有一个很好的HA概念时。但是,正如您所展示的,在某些情况下,当不良情况发生时,消费类硬件只是无法削减它。我可以向您保证,良好的PERC(Dell)或SmartArray(HP)控制器上的单个故障SAS磁盘不会给您带来任何问题,除了获得更换磁盘的支持电话外。多年来,我们在生产中已经有大量失效的SAS磁盘,但从未使它们停机而导致服务器停机。

大多数SATA磁盘不支持TLER(限时错误恢复)。当典型的SATA磁盘遇到物理问题时,它会向磁盘子系统发送“我在进行此操作时保持”状态(通常是这样执行的)。然后,磁盘将继续在发现的每个错误上花费10-30秒(通常),直到达到“我死了”的阈值。支持TLER的SAS磁盘和SATA磁盘由其HBA配置为告诉磁盘子系统“我有问题,我该怎么办?”因此HBA基本上可以立即决定采取适当的措施。 (为简化起见)

#1 楼

我讨厌在关键的生产环境中说“不要使用SATA”,但是我经常看到这种情况。尽管您在设置中专门针对24x7全天候运行的规格驱动器,但SATA驱动器通常不适合您描述的占空比。我的经验是,即使您使用RAID 1 + 0,SATA驱动器也会以无法预料的方式发生故障,甚至常常影响整个存储阵列,即使您使用RAID 1 + 0。有时,驱动器会以使整个总线停顿的方式发生故障。需要注意的一件事是您是否在设置中使用SAS扩展器。这可能会影响其余磁盘如何受到驱动器故障的影响。

但是中线/近线(7200 RPM)SAS驱动器而不是SATA可能更有意义。与SATA相比,价格略有溢价,但驱动器的运行/故障可预测性更高。 SAS接口/协议中的错误纠正和报告功能比SATA集更强大。因此,即使在机械原理相同的驱动器上,SAS协议的不同也可能避免了驱动器出现故障时的痛苦。

评论


当我写这个问题时,我只是知道我会选择SAS。 :/ IOPS和吞吐量都在我的设置范围内。但是我没有完全理解一些更细微的差异。我们在此盒子上放置了3年的使用寿命。下次一定会使用SAS。

– Stu Thompson
2011年11月16日14:56



是的,下次需要考虑。我提到的近线SAS驱动器的性能不一定比SATA好,但是诸如错误恢复和驱动器故障之类的地方,SAS更易于管理。我有一个带有6个控制器的Sun Fire x4540 48驱动器SATA存储系统,单个驱动器故障往往会锁定服务器。刻苦的教训。

–ewwhite
2011年11月16日15:34

我的好伙伴在企业存储领域。他读完所有这些内容后说:“这个家伙是对的。发生的事情是SATA设计为表示完全故障,而间歇性故障将重新查询总线而没有执行故障转移。通常,这是从未见过的,因为大多数SATA配置都是一个驱动器”

– Stu Thompson
11年11月16日在18:10

@StuThompson从那以后,您是否使用近线SAS构建了一个新包装?我很想阅读您的经历。您的问题已经对我有很大帮助,在不久的将来我可能会建立一个类似的盒子。

–chrishiestand
2013年9月19日21:48在

@chrishiestand不,我没有。我于1月13日离开公司;如果我留下来的话,我们会用近线建造替换盒。 las,NAS的存在与我自己的联系太紧密了,数据被转移到了服务提供商的SAN中。

– Stu Thompson
2013年9月20日下午2:26

#2 楼

单个磁盘如何关闭阵列?答案是不应该的,但这取决于造成中断的原因。如果磁盘以某种正常方式消失,则不应将其拆除。但是,它有可能以控制器无法处理的“边缘情况”失败。

您是否天真地认为这不应该发生?不,我不这么认为。像这样的硬件RAID卡应该已经解决了大多数问题。

如何预防?您无法预料到这种奇怪的情况。这是成为系统管理员的一部分...但是您可以制定恢复程序,以防止其影响您的业务。立即解决此问题的唯一方法是尝试使用另一个硬件卡(可能不太想要做)或将驱动器更改为SAS驱动器而不是SATA,以查看SAS是否更可靠。您也可以与RAID卡供应商联系,告诉他们发生了什么,然后看看他们说什么。毕竟,他们是一家应该专门了解电子驱动电子设备来龙去脉的公司。他们可能对驱动器的工作方式以及可靠性有更多的技术建议。如果您可以找合适的人与之交谈。

您错过了什么吗?如果要验证驱动器出现边缘故障,请将其从阵列中拉出。阵列将降级,但除了降级的阵列状态之外,您不应有更多怪异的减速和错误。您是说现在似乎工作正常,但如果磁盘读取错误,则应尽可能更换驱动器。高容量驱动器有时可能会出现URE错误(不运行RAID 5的最佳理由,请注意),直到另一个驱动器发生故障后才会显示。而且,如果您在该驱动器上遇到边缘情况行为,则不希望将损坏的数据迁移到阵列中的其他驱动器。

评论


是的...我们已经制定了新的替换策略,例如“如果读取错误发生波动,则将其删除”。现在我考虑了一下,这些驱动器的故障率很高。 18个月内,有22个中的4个。嗯...

– Stu Thompson
2011年11月16日的15:00

18个月内有4个硬盘?那是相当高的速度...虽然可能是驱动器不在规格范围内,但也可能存在冷却/气流问题。或控制器有些奇怪。只是有些想法...请留意原木。如果您能够与3Ware中的任何人联系并完成卡片上的实际工作,而不仅仅是脚本,那么您可能希望由他们来运行它并查看他们在说什么。

–巴特·银线
2011年11月16日15:19

根据看到错误的位置,您还可以检查电缆是否也没有异常或边缘现象。如果错误似乎集中在同一端口上,则故障的发生可能不是偶然的。

–巴特·银线
2011年11月16日15:20

我刚刚看到,该烧录驱动器的SMART值在〜31°C的温度下运行,比所有其他驱动器高4°C。让你走的东西……

– Stu Thompson
2011年11月16日17:41

@DanNeely:在14个驱动器(11个数据,3个系统)中,它是唯一一个温度较高的驱动器。我相当确定气流很好,但是明天会明确检查。

– Stu Thompson
11年11月16日在18:07

#3 楼

我不是专家,但是根据我在RAID控制器和存储阵列方面的经验,我将在黑暗中大开眼界。

磁盘以多种方式发生故障。不幸的是,磁盘可能会以严重影响其性能的方式发生故障或出现故障,但RAID控制器并不会出现故障。

如果磁盘发生明显故障,则任何RAID控制器软件应该非常擅长检测磁盘响应不足,将其从池中删除并发出任何通知。但是,我对这里发生的情况的猜测是磁盘遭受了异常故障,由于某种原因,该故障不会触发控制器端的故障。因此,当控制器执行写刷新或从受影响的磁盘读取数据时,要花很长时间才能恢复过来,从而挂起了整个IO操作并因此挂起了阵列。无论出于何种原因,这都不足以使RAID控制器“出现故障的磁盘”,这可能是因为数据最终最终会返回。

我的建议是立即更换故障的磁盘。之后,我将查看您的RAID卡的配置(它是3ware,我认为它们还不错),并找出它认为故障磁盘的含义。

P.S.将SMART导入仙人掌的好主意。

评论


一旦将点连接起来,我首先想到的是从阵列中取出磁盘。充满了热备用。那是昨晚。今天,我拉出磁盘并进行RMA处理。令人讨厌的驱动器:geekomatic.ch/images/wd-re4-flux-read-error.jpg

– Stu Thompson
2011年11月16日15:19

我认为每个关键任务系统都需要有一块进行数据清理的卡,这是原因之一。我已经看过太多次了,尤其是在SATA阵列上,然而,众所周知,即使是高端SAS磁盘也会在不触发控制器的情况下发生故障。

–詹斯·埃里希(Jens Ehrich)
16 Dec 9'在17:35

#4 楼

只是一个猜测:硬盘配置为重试读取错误,而不是报告错误。尽管这在桌面环境中是理想的行为,但在RAID中却适得其反(在RAID中,控制器应重写无法从其他磁盘读取数据的任何扇区,以便驱动器可以对其进行重新映射)。

评论


很有可能。如果是这样,这绝对不是一件很酷的事情,因为它们被指定为“ RAID版本”单元。 :|

– Stu Thompson
2011年11月16日15:01

绝对不酷,因为该设置正是“ RAID版本”的定义:)

–西蒙·里希特(Simon Richter)
11年11月16日在16:16

#5 楼

我在黑暗中的镜头:


驱动器7出现故障。它有一些无法使用的故障窗口。
驱动器8也有一些“较轻”的错误;通过重试纠正。
RAID10通常是“几个RAID1对中的一个RAID0”,驱动器7和8是同一对中的成员吗?

如果是这样,那么看来您打了“应该在同一对上发生两个磁盘故障的情况“不会发生”。几乎唯一可以杀死RAID10的东西。不幸的是,如果所有驱动器都来自同一批次,则可能发生这种情况,因此它们更有可能同时死亡。

我想在驱动器7发生故障期间,控制器会将所有读取重定向到驱动器8,因此任何错误重试都会导致大的延迟,从而导致大量冻结任务,从而导致性能下降。

您很幸运,驱动器8似乎还没死,所以您应该能够在不造成数据丢失的情况下进行修复。

我将从更换两个驱动器开始,并且不要忘记检查电缆。松动的连接可能会导致这种情况,如果布线不牢固,则很有可能在相邻驱动器中发生。另外,某些多端口卡具有多个两个端口的连接器,如果驱动器7和驱动器8位于同一端口上,则可能是造成麻烦的原因。

评论


驱动器8是导致服务中断的原因,我已经将其拉出。驱动器7,虽然已经失去了一些性能,但处于这种状态已经有一段时间了,并且总体上仍然表现良好。不,它们的驱动器成对出现。 (这是我考虑过的问题,还有我的Cacti / SNMP查询可能未对齐的问题。)该卡有16个端口,4条电缆,每条电缆有4个端口进入后面板。如果问题是卡,电缆或背板,则在插入驱动器8的替换件后,我很快就会知道。

– Stu Thompson
2011年11月16日15:23



#6 楼

您需要企业级存储设备的功能。具体地说,WD RE 4企业级驱动器具有防止RAID阵列中此行为所需的两项功能。下面列出的第一种技术可防止旋转谐波振动对硬盘驱动器机械组件造成不必要的磨损。第二种技术是造成您的问题的原因,SATA协议不具有此功能。要获得这些功能,您需要SAS,并且如果您坚持使用SATA驱动器,则可以购买SAS至SATA Interposer卡,例如LSISS9252。

增强的RAFF技术先进的电子设备可以监控驱动器并校正线性和旋转状态实时振动。结果是与上一代驱动器相比,在高振动环境中的性能得到了显着改善。

RAID特定的限时错误恢复(TLER)可以防止由于扩展的硬盘驱动器错误恢复而导致的驱动器故障桌面驱动器通用的进程。

http://en.wikipedia.org/wiki/Error_recovery_control#Overview

还请参见下面的链接:

http://zh.wikipedia.org/wiki/Error_recovery_control#Raid_Controllers

另请参阅:Western Digital TLER文档,深入解释了错误恢复过程。
WD Caviar中的错误恢复沉降预防RAID版串行ATA硬盘驱动器:

http://www.3dfxzone.it/public/files/2579-001098.pdf

#7 楼

SATA插入器卡是另一种解决方案。

我最近经历了同样的命运,发现了这个线程。总的来说,因为SATA缺少功能,所以SAS协议比SATA更适合RAID。这就是为什么相同的物理驱动器都装有SAS控制器,然后以Nearline SAS出售的原因。
进一步搜索,我发现:

http://www.lsi.com /products/storagecomponents/Pages/LSISS9252.aspx

我正在研究使用一批存储来升级我的一个存储。目前,3 TB SATA与SAS之间的价格差为400%(原始价格,相同品牌,规格和商店,德国)。我显然无法确定这种策略是否行得通,但是值得一试。

评论非常欢迎:-)

评论


很好的理论。在收集了一些信息之后,只有存储托盘制造商才能集成这些板,添加它们并不一定意味着更好的错误处理。

–科克曼
2012年3月2日在13:28

#8 楼

我已经看到损坏的电子设备的SATA磁盘牢固地锁定了Areca 12的固件初始化,无法访问BIOS,更不用说从任何介质引导计算机了,直到通过以二进制方式拉出磁盘找到有问题的硬盘驱动器为止。搜索时尚。