当前位置: 代码迷 >> 综合 >> “不要害怕 RAID!”-kafka磁盘必备
  详细解决方案

“不要害怕 RAID!”-kafka磁盘必备

热度:14   发布时间:2023-12-13 16:21:51.0

作者 | louwrentius@gmail.com

译者 | 苏本如,责编 | 郭芮

头图 | CSDN 下载自视觉中国

出品 | CSDN(ID:CSDNnews)

以下为译文:

我在互联网上经常看到这样的说法:RAID很危险,RAID磁盘阵列在重建过程中失败的可能性几乎是100%,因为硬盘驱动器已经变得非常大。

我觉得没有什么比这种说法更离谱了,所以我写了这篇文章来反驳这种荒诞的说法。

对于家庭用户和小型企业来说,RAID磁盘阵列仍然是在一个地方存储大量数据的可靠和高效的方法。

对RAID可靠性的认识

互联网上有很多关于居家用户突然发现他们的RAID磁盘阵列失效的可怕故事。这些故事可能导致了人们普遍对RAID持消极态度。

你可能会指责我责怪受害者,但在很多情况下,我确实想知道这些事件到底是由于用户错误、运气不佳或真正由于RAID导致的问题。我们都知道,报道总有一种偏见:你不会听到无数没有问题的人的声音。

无论如何,对RAID的伤害已经造成了,但我仍然认为(软件)RAID是完美的。

关于不可恢复读取错误(URE)的荒谬说法

这个问题是从2007年ZDNET上发表的一篇糟糕的文章开始的。

在那篇文章中,有人认为,随着驱动器变得更大,但是由于没有同时变得更加可靠,你将看到更多的不可恢复读取错误(URE)。更多的容量意味着更多的扇区,因此任何一个驱动器出现问题的风险变得更大。

不可恢复读取错误(URE)是硬盘驱动器无法读取扇区的严重事件。对于我这样的老人来说,这听起来像是“坏扇区”的定义。那篇文章认为,平均每读取12.5TB的数据就会遇到一个URE错误。

根据ZDNET上这篇文章的逻辑,从14 TB驱动器复制所有数据可能是一个不可能完成的任务,因为在完成复制之前,你可能会遇到一个错误的扇区。

这对于RAID磁盘阵列来说是一个非常大的问题。RAID磁盘阵列重建包括完整读取所有剩余驱动器的内容。所以在RAID重建期间,你一定会遇到URE错误。

好消息是你不必担心这些。因为这不是真的。

实际上,硬盘并不是那么不可靠。相反地。我认为它们非常可靠。如果你不确认,你可以参考Backblaze 2020年第1季度硬盘统计报告。

那篇臭名昭著的ZDNET文章的预言并没有实现。硬盘驱动器的URE规范描述的是最坏的情况,它似乎更多的是关于营销(一种区分企业驱动器和消费者驱动器的方法)而不是现实。

如果ZDNET上的那篇文章是真的,那么我自己应该会遇到很多URE错误,因为许多RAID阵列的scrub/patrol读取已在不同的RAID阵列中完成。

RAID从来没有停止工作,而且将会继续发展。

清理(Scrubbing)可以抵御不良扇区的影响

当一个只能容忍一个硬盘驱动器出现故障的RAID磁盘阵列中的一个驱动器出现故障时,非常重要的一点是,所有剩余的硬盘都不能再出现任何读取错误。由于这个阵列不再有冗余,由坏扇区引起的任何读取错误都可能意味着整个阵列丢失,或者至少某些文件损坏。

每个RAID磁盘阵列都支持“清理”。它是一个RAID阵列中每个扇区都被读取的过程,这实际上会导致所有硬盘驱动器的所有扇区都会被读取。

清理(Scrub)是预先检查坏扇区的过程。如果在一个硬盘驱动器上发现坏扇区,则可以更换该硬盘驱动器,以便在将来可能的重建过程中不会造成问题。更换硬盘驱动器本身将导致磁盘阵列的重建,但是如果清理没有发现任何其他硬盘驱动器上有坏扇区,重建将不会出现问题。

一个没有经过常规清理的RAID磁盘阵列随时可能有灾难性的后果。坏扇区可能在另一个硬盘驱动器上累积,当一个硬盘驱动器实际发生故障时,整个磁盘阵列可能会因为剩余硬盘驱动器(其中一个)上未检测到的坏扇区而丢失。

如果要在RAID磁盘阵列上以可靠的方式存储数据,则需要确保对磁盘阵列进行定期的清理。即使你不使用RAID,我还是建议每个月对你拥有的每个硬盘进行一次长时间的SMART测试。

默认情况下,Ubuntu会对Linux软件RAID磁盘阵列一周进行一次清理。有关这方面的详细信息,请查看/etc/cron.d/mdadm的内容。

如果你在Linux上使用ZFS,而且运行的Linux发行版是Ubuntu,你的磁盘阵列会在每个月的第二个周日自动进行一次清理。

默认情况下,Synology或QNAP等NAS供应商都启用了数据清理。请根据你的特定NAS手册来调整清理频率。我建议每个月至少安排一次清理,且在夜间进行。

为什么RAID 5被认为是有害的?

坦白说,我也很好奇。

我注意到网上有很多人声称不应该使用RAID 5,但是这一点我不能苟同。这完全取决于具体情况。在成本和风险之间找到平衡是很重要的。

这篇文章可以追溯到2003年,它提倡不要使用RAID 5,但是它关注的是企业环境,然而即使在企业,我也看到了RAID 5的价值。

对于具有5个或更少驱动器的小型RAID磁盘阵列,我认为RAID 5非常适合。特别是如果你运行一个4托架的小型NAS,那么使用RAID 5将完全有意义。你可以在容量和可用性成本之间获得很好的平衡。

不建议创建更大的RAID 5阵列。与单个硬盘驱动器相比,具有8个硬盘驱动器的RAID磁盘阵列发生硬盘驱动器故障的可能性要高8倍。这样做的话,你就将单个硬盘驱动器出现故障的风险放大了8倍。对于较大的阵列,双驱动器故障将成为一个严重的风险。

这就是为什么对更大的RAID磁盘阵列建议使用RAID 6,因为RAID 6可以容忍两个同时发生的驱动器故障。我以前使用过RAID 6,现在我使用RAIDZ2(ZFS)作为当前NAS的基础。

我仍然在我的一台服务器上运行了一个8个硬盘驱动器的RAID 5,它承载的数据不太重要,我仍然想保留这些数据,我希望不丢失它们,但并非不惜一切代价。这都是关于风险和成本之间的平衡。请同时阅读这篇文章的后记,你会喜欢的。

确实,在重建过程中,硬盘驱动器的压力会更大,但除非RAID磁盘阵列也被大量使用,否则硬盘驱动器上的负载不会太大:数据是按顺序读取的,这对硬盘驱动器来说非常容易。

RAID的重建性能主要由硬盘驱动器的大小决定,而不是由RAID磁盘阵列中的硬盘驱动器数量决定。

几年前,我运行了一个带有20个1 TB硬盘驱动器的RAID 6,它在5小时内完成了重建。最近,我在RAID 5中测试了8个硬盘驱动器的重建(使用相同的硬盘驱动器),它也花费了将近5个小时(4小时45分)。

RAID写漏洞(write hole)

RAID 5/6的“写漏洞”经常被认为是你应该害怕的东西。

基于奇偶校验的RAID(如RAID 5和RAID 6)可能会受到一个称为“写漏洞”的问题的影响。简而言之:如果计算机突然断电,对RAID阵列的写操作可能会中断。这可能会导致对RAID阵列的部分写入,使其处于不一致的状态。

作为补充说明,我始终建议使用UPS(电池备份)来保护你的NAS,以便你的服务器可以在电池耗尽而断电之前以干净的方式关闭。

ZFS RAIDZ不受“写漏洞”问题的影响,因为它在将数据写入实际阵列之前先将数据写入日志。

Linux MDADM软件RAID还通过使用位图(默认情况下启用)来防止“写漏洞”现象。

硬件RAID还通过使用缓存的电池备份来防止这种情况。计算机重新开机后,高速缓存内存中的数据就会被写入磁盘。

对重要的数据设置警报

我认为关于RAID的可怕故事都是基于这样的一个事实:人们可能永远没有注意到关于RAID的任何问题,直到为时已晚,因为他们从未设置过任何类型的警报报(通过电子邮件或其他方式)。

理想情况下,你还应该确保系统监视硬盘驱动器的智能数据,并在关键数字(如:重新分配的扇区计数和当前挂起的扇区计数)开始上升时发出警报。

这也是个人反思的时刻。你在运行RAID磁盘阵列吗?你是否设置了警报?或者你的RAID磁盘阵列是否会在此时失败而你却不知道呢?

不管怎么说,我认为缺乏合适的警报是使RAID陷入困境的一个“好”方法。事实上,任何不受监控的存储解决方案都将是一场等待发生的灾难。

为什么人们选择不使用RAID?

如果RAID磁盘阵列发生故障,所有数据都将丢失。人们对这种风险感到不安。他们可以接受丢失一些硬盘驱动器的数据,但不能是全部。

Unraid和SnapRAID等解决方案使用一个或多个专用硬盘来存储冗余(奇偶校验)数据。其他硬盘驱动器是用你选择的文件系统格式化的,可以作为普通硬盘驱动器访问。虽然我没有使用这个产品的经验,但StableBit DrivePool的工作方式似乎与此类似。

如果你有六个硬盘驱动器,即五个硬盘用于存储数据和一个硬盘用作存储奇偶校验位,那么两个硬盘驱动器的失效将导致数据丢失,就像RAID 5一样。但是,其余四个驱动器上的数据仍然是完整的。数据丢失仅限于一个硬盘驱动器上的数据。

这样就降低了在常规软件RAID上会发生的“全有或者全无”的风险。我自己并不认为这些风险没有那么大,但Unraid和snapraid是流行的产品,我认为它们是合理的替代品。。

Mergerfs也可能是一个有趣的选项,尽管它只支持镜像。

备份仍然很重要

将数据存储在任何类型的RAID磁盘阵列上都不能替代备份。

如果要保护数据,你仍然需要将数据复制到其他存储区。你可能会选择只备份所有数据的一个子集,但至少你要承担知情的风险。

结束语

希望在以上部分,我已经充分说明了为什么RAID仍然是一个有效和可靠的数据存储选项。

如果你想发表任何观点,请在评论中分享。

附注

在撰写本文时,我对我的包含8个硬盘驱动器的RAID 5阵列(基于2 TB硬盘)进行了一次清理。我的服务器只有在我需要的时候才开机,关机的时候,很容易错过它们的定期清理窗口。

为了验证我的观点,我做了一次清理实验。你瞧,其中一个驱动器被从我的Linux软件RAID阵列中踢了出来:

sd 0:0:4:0: [sde] tag#29 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd 0:0:4:0: [sde] tag#29 Sense Key : Medium Error [current] 
sd 0:0:4:0: [sde] tag#29 Add. Sense: Unrecovered read error
sd 0:0:4:0: [sde] tag#29 CDB: Read(10) 28 00 9f 42 9e 30 00 04 00 00
print_req_error: critical medium error, dev sde, sector 2671943216

接送出现:

md/raid:md6: Disk failure on sde, disabling device.
md/raid:md6: Operation continuing on 7 devices.

这个硬盘驱动器显然被踢出了,因为它遇到了坏扇区。对智能数据(SMART data)的快速检查显示,已有300多个扇区被重新映射,但其中存储的数据无法恢复,从而导致读取错误。

这项清理工作显然已经完成,因为RAID仍然可以工作。

在将这个有缺陷的硬盘驱动器替换为备用硬盘驱动器后,我启动了重建过程,耗时4小时20分钟。我的RAID 5重建完成,现在一切都很好。

如果这样的事件还不能让你明白清理的重要性,那我真的无话可说了。

1.有时我读到人们用来存储的硬件时,我就会想起John Glenn(译注:传奇宇航员,第一个绕地球飞行的美国人)的这句话:“如果你准备好发射,并且你知道你坐在200万个部件的上面,我完全能体受你的感受,因为这些部件都是由政府合同中出价最低的人建造的。”

2.ZFS的工作方式不同,它只读取包含实际数据的扇区。

3.当你向RAIDZ(2/3)VDEV添加更多硬盘驱动器时,ZFS重建或“resilver”的速度似乎会变慢。我不确定最近的ZFS版本是否仍然如此。

4.ZFS和MDADM都会因为使用日志/位图来影响性能。两种解决方案都支持使用SSD来加速日志/位图以消除性能影响。大多数家庭用户可能不需要这个。

5.对于旧而小的硬盘驱动器来说,它能够存储的最小存储单元,通常是4K或512字节。

6.硬盘驱动器最好在一个有着良好空调环境的数据中心工作,你在家里可能没有这种环境。但是只要你能够将硬盘的温度控制在一定范围内,我认为这没什么大不了的。

7.ZFS既是一个RAID解决方案,又是一个文件系统,可以准确地告诉你哪个文件受到了影响。这是一个很好的功能。

原文:https://louwrentius.com/dont-be-afraid-of-raid.html

【END】

  相关解决方案