什么时候RAID值得麻烦?


14

在我们的商店中,我们忠实地在所有工作站中使用RAID,可能只是因为这似乎是应该这样做的方式。我说的是使用板载RAID芯片进行科学仿真的工作站。

但是我听说过很多RAID恐怖的故事。RAID控制器间接导致 Stackoverflow本身中断

RAID可保护您避免出现非常狭窄的故障(物理磁盘故障),但同时也会引入额外的故障点。RAID控制器可能存在问题,并且经常存在。至少在我们的商店中,RAID控制器的故障似乎至少与磁盘本身一样多。您也可以轻松地更换故障驱动器的过程。

什么时候RAID值得麻烦?通过在备份解决方案中增加更多的冗余,您是否可以获得更好的投资回报?在这方面,哪种类型的RAID更好或更坏?

编辑:我已经从原始的标题更改“ RAID值得麻烦吗?”,所以听起来不太负面


3
当您说在工作站上使用RAID时,我想知道RAID是什么意思。作为台式机级主板芯片组一部分提供的RAID并不是真正的RAID。真正的RAID是昂贵的(几百个,也许几千美元)选项,通常作为某种类型的PCI卡实现。考虑使用Adaptec或LSI,而不是Promise。
贾森·谭

1
没错,我们正在使用一些板载芯片组解决方案。因此,也许我的问题应该稍作修改:便宜的RAID是否值得解决?
amarillion

Answers:


17

不用担心,由于集体思考,RAID并未在整个商业世界中使用!良好的RAID控制器发生故障的机会远远少于磁盘发生故障的机会。我不记得曾经见过RAID控制器在现实生活中发生故障,而我却在办公室和数据中心看到许多磁盘损坏。

PS:我看到了您的标签。RAID不备份!:)


1
是的,它不是备份。那么,这是多余的吗?因此,这实际上与高正常运行时间有关吗?除非您需要五个九,否则您真的不需要RAID吗?
amarillion

6
不,这与可用性有关。需要时取下机器很好。一个硬盘驱动器决定关闭计算机并不是一件容易的事。正确使用RAID可以防止这种情况的发生。
马特·西蒙斯

9
@amarillion。哇,这是一个危险的情绪。您有多少使用硬盘的经验?RAID几乎需要2个 9的可靠性(更多的硬盘需要混合使用),而RAID绝对不能使您达到5 9的可靠性,至少您需要冗余的数据中心。即便如此,这还是个小问题,管理幻想土地BS是5个9,这意味着每十年的停机时间不到一小时(每年约5分钟)。甚至IP主干网都没有。

4
@amarillion:我的一些客户有开发人员在现场收费,每小时200美元。或工人应对生死攸关的情况。YMMV对我来说,用80美元的硬盘来破坏这些工人似乎有些愚蠢。
duffbeer703'2009年

3
否。RAID保护您免受硬盘故障的影响。它不能保护您免受'rm -rf /'的侵害。这就是备份的目的!
亚历克斯·J

9

SUN的ZFS(也是OpenSolaris的一部分; Apple OSX-当前只读)不仅会进行各种级别的突袭,而且还会始终检查写入磁盘的数据是否确实存在。一致性是关键!如果您不能依靠RAID的完整性,则RAID是无用的。选择一个不错的RAID控制器(我更喜欢HP的RAID控制器)并擦洗RAID以定期发现错误。

另一方面,如果RAID控制器死了,而您无法获得确切的替代品,则Softwareraid(作为ZFS)会使您的硬件独立性增强。


8

总是。磁盘便宜,您的信息却不便宜。但是使用软件RAID,因此您可以灵活地向前或稍后更改硬件(相信我,您将需要它)。并且还使用ZFS之类的校验和文件系统来防止静默数据损坏(当今很可能使用大型磁盘)。


8

对于那些说您不会使用硬件RAID的人,是因为如果控制器出现故障并且无法完全替换您的螺丝钉,那么您将以错误的方式进行操作。

  1. 如果正常运行时间对您来说至关重要,那么您不应该购买便宜的硬件。如前所述,请使用良好的RAID控制器,HP,LSI,Dell等。

  2. 如果控制器是从具有Dell RAID控制器的计算机制造商(即Dell服务器)购买的,则Dell会告诉您他们将备有这些零件的库存时间,通常是从该服务器的停产期开始的4年以上。

  3. 如果让某人快速再次运行意味着您不能等待交货,那么无论您是谁制造的,都应该为自己购买第二个备用控制器。

  4. 如果将其设置为RAID 1,则有时可以将其中一个驱动器拖放到普通控制器上以恢复数据。如果这对您很重要,请在危急情况下与控制器确认/测试。

硬件RAID节省了我的两倍。一旦进入电子邮件服务器,其中一个驱动器发生故障,我就从该计算机上的突袭监视软件收到了电子邮件警报,调用了Dell,并在第二天安装了一个新驱动器,将其弹出并自行重建。零停机时间

第二个原因是,原计划在6个月内更换的旧文件服务器出现驱动器故障。控制器使它保持运行状态,我们将更换服务器的时间推迟到了这一周。节省了购买新驱动器的时间(因为它不在保修范围内),并且再次零停机。

我以前使用过软件突袭,但它们的恢复能力不如基于硬件的突袭。您必须测试您的设置,软件或硬件,以确保它能正常工作,并且知道当棕色的东西碰到风扇时该怎么做。


3
人们倾向于将RAID视为一种保险。如果他们没有发生“意外”,那么RAID(保险)的好处就永远不会显现出来。感谢您分享您的故事,因为许多人(我认为)轻率地使用RAID,因为如果他们从未有过糟糕的经历,为什么要投资可能不会发生的事情?对于每个正在阅读的人来说,这应该是一个教训:可靠的硬件RAID控制器可以在一百万/十亿机会中为您省钱。不要把它留给机会;始终使用良好的硬件RAID控制器,尤其是服务器。
osij2is

6

与台式机工作站相比,服务器中的硬盘故障更有可能发生。

您不能只说“添加更多的故障点”,而无需考虑该故障的可能性。尤其是由于这些故障点不太可能被专门用来颠覆更可能的硬盘驱动器崩溃。正如您所说的,您基本上已经创建了一个Pascal's Wager式的谬论。

台式机主板上的大多数RAID系统都是便宜的软件/硬件混合体,其大部分工作都在其软件驱动程序中完成。恕我直言,它们是用来卖给电力使用者的废话的配料。

另一方面,良好的实际硬件RAID是相当可靠的,并且它具有无需操作系统即可完成其任务的硬件。但是它们会变得昂贵,因为真正的硬件通常具有备用电池,以及用于计算校验和的完整XOR'ing阵列等。如果使用SCSI完成,则价格会更高。

简介:如果您运行的是基于主板的RAID系统,那么就不值得了。


3
一位同事在一个大型学校IT环境中运行,拥有18万个工作站和一流的服务台。他们的台式机中有7%在5年的生命周期内需要更换硬件,而其中的85%是硬盘。
duffbeer703'2009年

是的,但是如果工作站出现故障,您只需在修复损坏的计算机时让用户登录另一台计算机。有了那么多工作站,它们成为了中央文件存储库。我想知道,如果有18万台服务器,统计数据将是什么样子。
Ape-in​​ago

1
您在许多情况下都是对的-但并非所有人都对。在我朋友的情况下,其中许多PC都位于教室后面,如果损坏了,那堂课就没有计算机了,而且很大。在我的工作中,我们有备用工作站,并不在乎。
duffbeer703

5

尽管备份和RAID是解决不同问题的解决方案,但是大多数“ RAID问题”与最常见的备份问题非常相似(即,没有人测试还原)-没有人​​测试系统恢复。其他RAID问题通常是人们不了解它做什么和不做什么的直接结果。例如,许多人认为RAI​​D可以保证其数据的完整性,但事实并非如此。

对于工作站,如果您使用RAID-0来提高IO绑定应用程序的性能,或者使用RAID-1 / 5/6来维持每小时$ 100的科学家工作能力,而后者的$ 80硬盘发生故障,则说明您在适当地使用RAID。只是不要将磁盘冗余备份混淆,并已测试了适当的过程,以确保您的IT人员可以进行恢复。


工作站的注意事项。工作站需求与服务器需求完全不同。并且强调,“使用备份..don't迷惑磁盘冗余”是的。
osij2is

4

RAID有两种类型

  • 一种便宜的集成。这不是真正的袭击,实际工作是由软件(特别驱动程序执行袭击计算)完成的。您应该避免这种情况。
  • 另一个很贵,但是您得到的却是真正的突袭。如果您负担得起,那就值得。

某些操作系统具有良好的软件突袭解决方案(与上面提到的the脚卡无关)。Linux软件突袭特别好,其性能确实很好。

突袭只能提高可靠性,它不是备份解决方案。文件可能会被意外删除,有故障的磁盘可能会将不良数据返回(并复制)到RAID阵列中的其他磁盘,因此仍然需要真正的备份解决方案。


4

RAID非常适合正常运行时间,但不能替代备份。正如一位同事曾经评论过的那样:“您不小心删除了某些内容时,'哦,,!'那一刻?RAID意味着您可以同时访问多个驱动器'哦,sh!t'。”

就是说,那天您把头伸进老板的办公室并告诉她,“顺便说一句,昨晚数据库服务器发生了硬盘崩溃-我们从未崩溃,它在凌晨5点重建了备用磁盘,我已将损坏的硬盘送出了保修” –那是RAID的无价之宝。


2

您在硬盘和RAID控制器上的故障率是多少?RAID控制器上的故障应远低于磁盘。如果故障率很高,则可能需要查看环境,例如可能引起问题的静电放电。

对于工作站,您可能希望使用Alakdae建议的软件突袭,因为您不必担心维护精确硬件控制器的库存。但是,您应该将所有重要信息存储在服务器上,这些服务器确实进行了硬件突袭并且已备份到其他介质。

服务器硬件制造商确实会维护RAID控制器,因此,即使它是较旧的控制器,如果需要,通常仍可以从RAID控制器中获取(尽管这样会花很多钱)。


2

似乎上面的许多帖子都忘记了最初的问题,而只是在讨论RAID1。问题是“什么时候RAID值得麻烦?” 好吧,这取决于...如果您的开发人员使用其工作站进行大量数据读写,那么RAID 0配置将是值得的。向该RAID 0添加更多驱动器当然会提高速度,而性能BUT将增加发生故障(磁盘或控制器)的可能性。

我在一家护理学校工作,部署了约500台Dell计算机,几乎没有一台使用任何RAID。在我看来,我的用户类型无法看到增加每台计算机上RAID系统的复杂性的好处。除了RAID 0的速度或RAID 1的冗余之外,我更担心数据恢复和磁盘映像。当然,我不是在谈论我们的生产服务器,这是另一回事。数据恢复至关重要,我们依靠其他备份方法来解决问题,而不仅仅是磁盘冗余。如果用户不小心删除了文件,则任何形式的RAID都无法帮助您。

所以回答您的问题恕我直言...当用户需要性能时,工作站上的RAID 0是值得的。(只需确保已备份所有importa数据。)我确定您可以检查现有设置上的数据吞吐量以查看其是否足够。RAID 1应该在可使用高级RAID控制器的服务器环境中使用。工作站上的麻烦事不值得,因为它会使部署,磁盘映像和维修变得复杂。这些工作站中很多都带有内置在主板上的RAID控制器,很高兴知道主板是否在机器上坏掉了,我总是可以将驱动器放在另一个系统中以获取数据。


2

Linux软件RAID非常出色,它实际上击败了低端硬件RAID。它还具有一些对工作站有用的优化。例如,它可以同时读取每个磁盘上的不同内容,从而有效地使随机访问读取时间增加一倍,这是常见的用例,与RAID 0优化的传输速率限制操作不同。

至于可靠性,它是Linux内核中维护得很好的一部分,已被数以百万计的人使用,它可以很好地处理硬件故障,因此就可用性而言,这显然是一次成功。多年来,我已经在个人工作站和几十台低端服务器上使用了它,其中一些负载非常大,并且永远不会将其归咎于任何故障。但是,与此同时,我遇到了很多打碎的磁盘。

(但是高端硬件RAID卡还有其他功能,例如电池供电的写缓存。它基本上将随机同步磁盘的写速度提高了十倍。这对于数据库是绝对必要的,对于工作站来说可能几乎没有用。)


我希望它将读取/ speed /而不是/ time / :)的随机访问次数增加一倍
Bill Weiss

1

我只是在两台(相同)服务器上使RAID控制器发生故障,因为我们拥有这两台计算机,所以整个公司都没有发生一次硬盘故障。

我认为台式机上的RAID是个坏主意,要放在这些计算机上的廉价RAID控制器早在实际硬盘驱动器出现故障之前就已经失效。

在服务器上,也许我不会再信任RAID控制器,请确保您有备用计算机和良好的备份。


1

我是一名开发人员,我们所有的工作站都将RAID用于内部驱动器。RAID0。这绝对值得。一旦尝试了一对15000,就再也不想从单个7200RPM驱动器进行编译了。
我一直在挑战是缩短编译时间的是RAID还是15k驱动器。我不知道,因为编译单个快速驱动器可能会提供完全相同的性能。但是,单个SAS驱动器对于现代PC而言并不是特别大,因此廉价的板载RAID仍然占有一席之地。而且我怀疑RAID是否会损害系统的性能。
我认为这种RAID当然适合工作站,并且最好使用廉价的板载控制器来完成。从服务器端来看,我们的大多数服务器都具有用于OS磁盘的某种形式的RAID阵列,然后数据就以某种适当形式的单独阵列存储。我不了解我们的生产服务器,但是我们的开发服务器(其中有很多服务器)从未发生控制器故障,但是驱动器发生了故障。在一种情况下,我们有一半的OS阵列在SQL盒上发生故障,而在重新构建时,另一张盘发生了故障!有时RAID1还不够!


1
我必须为此打电话给BS。RAID 0对开发人员工作站无效。RAID 0最好将传输速率提高一倍;它对随机访问没有任何作用。猜猜开发人员会做什么...读取和写入许多小文件,以及偶尔的大文件。唯一有用的工作站是图形设计师进行视频编辑的工作站,在那里您需要获得所有的GB / s。
niXar,2009年

这可能是事实,我没有将单个15k sas驱动器的性能与双驱动器RAID 0的性能进行比较。我已经更新了答案。
pipTheGeek

1
这取决于您的开发人员的工作。我们的人员正在处理大型数据集,他们注意到性能显着提高,尤其是在编译期间。GIS专家也注意到RAID 0的改进。
duffbeer703 2009年

从7.2k驱动器到15k驱动器意味着大量的加速。有没有更多的从RAID 0来获得
罗兰Pechtel

如今,单个固态硬盘肯定会更便宜,更快吗?
Dentrasi 2010年

1

如果您的科学工作站使用本地存储的数据而不是在文件服务器上共享数据,则对于那些科学工作站而言,这可能是值得的。对于普通民众,我会说不。当您真正需要的只是还原应保留在共享中的数据时,就不值得麻烦和头痛。


1

RAID仅在绝对不能让服务器意外关闭时才有用。我们在数据中心中所有没有其他冗余形式的服务器上使用RAID。例如,我们没有在Web服务器上使用RAID,因为还有10个仍在工作。

试金石测试是“如果磁盘在半夜中断,并且不能等到上午9点,则需要RAID”


在其他情况下,它也是有意义的-例如,如果您没有快速简便的方法将计算机还原到以前的状态。
cp.engr

1

如果您有电池供电的控制器,则RAID值得您解决。

对于频繁使用fdatasync()日志文件(在数据库中并不罕见)以确保持久性的服务器应用程序,您最终将一遍又一遍地编写相同的块。如果没有电池支持的控制器,这会降低IO性能。

如果您确实有电池供电的控制器,那么许多写入操作甚至都不会到达光盘,而只是停留在内存中,直到被另一个写入操作取代为止。这是一件好事。

冗余是一个奖励,但不是必需的,因为重要的事情在系统级别上应该是冗余的。


1

廉价的RAID实现非常糟糕。

按照可靠性的顺序,您可以选择:

1)具有硬件RAID的HP DL服务器。
2)3Ware RAID卡。
3)ZFS
4)Linux软件突袭

其他任何事情都会带来麻烦,并且确实可能​​导致整体可靠性比非RAID解决方案低。

考虑如果控制器出现故障而制造商倒闭该怎么办。

考虑您是否可以从由电源/电缆问题引起的明显的双磁盘故障中恢复。

那是数百个例子中的两个。


1

与拥有可以在其上还原数据的新系统相比,对于工作站而言,RAID可能不值得。

许多人都在谈论RAID 0 ...这并不能帮助提高可用性。由于一旦一个驱动器死机,您将失去全部工作,因此卷失败的机会增加了一倍。RAID 0的目的在于提高对卷的读/写的访问速度并提供更多存储空间。在业务环境中提供帮助的唯一方法是采用两个RAID 0,并将它们镜像为RAID 1。

如前所述,RAID不是备份解决方案。

RAID也不完美。我认为此人博客中的这篇文章总结了我对RAID的看法以及何时值得:考虑RAID?

在工作站上,当替代产品推出时,您应该能够使一个人使用另一个系统。为什么要使用RAID?他或她的数据应存储在集中管理,数据完整性和备份的服务器上。应该配置工作站,以便可以在财务允许的情况下对其进行定期升级或更改,而RAID只是管理的另一层成本和麻烦(加上电源使用和加热问题以及增加的驱动器和气流的影响)。在大多数情况下,对于企业而言,将RAID卡中的钱放入更大的驱动器中可能更具成本效益,而且如果您使用板载RAID,则仍然会遇到问题,因为它往往会束缚RAID格式化为主板(无论如何也不是真正的RAID ...在Google搜索中发现为“假冒袭击”)。


0

为什么要在工作站上打扰?当然,您已经将所有主目录和数据集中存储了。那就是您要使用突袭的地方。


0

如果您担心驱动器控制器发生故障,则还需要考虑服务器故障-风扇,主板,RAM,网络..然后还需要考虑路由器故障,电缆连接和电源...以及您还需要考虑数据中心发生故障(洪水,火灾,人为错误),然后需要考虑外部网络发生故障(电缆在某些地方一直被切断!)。

简而言之,您可以担心站点停机,以至于您根本不必担心将任何内容置于在线状态!或者,您可以将故障风险与冗余成本相提并论,并获得更为现实的方法。在我列出的所有内容中,硬盘驱动器是最有可能发生故障单个点。

在人为错误之后,那就是。谁shutdown -h now想要重新启动时键入“ ”。...:(


0

我最担心的是磁盘,因为您似乎无法购买廉价产品:

一个主要供应商指出:

如果磁盘驱动器在给定的时间内无响应,大多数RAID控制器都会设计成使给定的命令超时。结果将导致驱动器脱机显示或标记为错误,并向客户发出警报。企业级驱动器(或为RAID环境设计的驱动器)在将扇区标记为坏之前具有重试限制。此重试限制使驱动器可以在预期的时间范围内响应RAID控制器。尽管台式机驱动器可以与RAID控制器一起使用,但随着磁盘驱动器的老化,阵列将逐渐脱离联机状态,并可能导致数据丢失。

对我来说,这似乎很疯狂,这是另一个确保磁盘供应商从“不了解的人”那里获得大量回报的陷阱。但是,我读到Google做了一份白皮书(无法找到它),表明存储供应商提供的两个“类”在驱动器可靠性上没有区别。我怀疑谷歌在他们的米色盒子车队中使用硬件突袭控制器。

也许mdadm(在Linux raid中)具有可以用来处理台式机驱动器固件中更急躁的设置的设置?

也许实际上,每个人都通过控制器固件的“超时”时间过长而为保修买单吗?

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.