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

作者 | 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】