CSDN|“不要害怕 RAID!”
本文插图
作者 |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仍然是一个有效和可靠的数据存储选项 。如果你想发表任何观点 , 请在评论中分享 。【CSDN|“不要害怕 RAID!”】
附注在撰写本文时 , 我对我的包含8个硬盘驱动器的RAID 5阵列(基于2 TB硬盘)进行了一次清理 。 我的服务器只有在我需要的时候才开机 , 关机的时候 , 很容易错过它们的定期清理窗口 。为了验证我的观点 , 我做了一次清理实验 。 你瞧 , 其中一个驱动器被从我的Linux软件RAID阵列中踢了出来: sd0:0:4:0: [sde] tag#29 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
sd0:0:4:0: [sde] tag#29 Sense Key : Medium Error [current]
sd0:0:4:0: [sde] tag#29 Add. Sense: Unrecovered read error
sd0:0:4:0: [sde] tag#29 CDB: Read(10) 28 00 9f 42 9e 30 00 04 00 00
print_req_error: critical mediumerror, dev sde, sector2671943216
接送出现:md/raid:md6: Disk failureonsde, disabling device.
md/raid:md6: Operation continuingon7 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
- CSDN|牛!2020年,这项技术将获得99000000000元人民币“国家领投”!
- CSDN|儿童节教你用 Python 画出童年回忆
- CSDN|Rust 让人奔溃的那些特性!
- CSDN|基础软件,未来只有开源一条路?
- CSDN|本来想用“{{”秀一波,结果却导致了内存溢出!
- CSDN|云计算,巨头们的背水一战
- CSDN|2020 AI 产业图谱启动,勾勒中国 AI 技术与行业生态
- CSDN|如何在容器内高效编程?
- CSDN|“编程能力差,90%输在了选择上!”CTO:多数程序员都是瞎努力!
- CSDN|你的 AI 程序无人问津?不是不够好,而是缺一个展示的舞台