当你建立自己的DIY回家NAS,在将重要数据放在NAS上之前,模拟和测试驱动器故障是很重要的。如果需要更换驱动器,知道该怎么做是有意义的。我还建议在NAS上放置大量数据,并查看一个resilver需要多长时间,这样您就知道会发生什么。
有许多关于人们构建自己的(基于zfs的)NAS的报告,他们在驱动器故障后发现恢复需要几天时间。如果您为VDEV选择的冗余级别不能防止同一VDEV (Mirror、RAID-Z)中的第二个驱动器故障,那么事情可能会变得可怕。特别是因为驱动器忙于重建数据,其余驱动器上的额外负载可能会增加第二次故障的风险。
为您的VDEV选择的RAID级别会影响到中继器的性能。您可以选择接受较低的中继器性能以换取额外的冗余(RAID-Z2, RAID-Z3)。
我确实想知道在不同的RAID级别之间,这些恢复时间会有多大不同。这就是为什么我决定做一些测试来得到一些数字。
测试硬件
我用了一些测试设备在Linux上运行Debian Jessie + ZFS。硬件相当旧,CPU可能会对结果产生影响。
CPU: Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz RAM: 8gb HBA卡:HighPoint RocketRaid 2340(每个驱动器在一个jbod中)磁盘:Samsung Spinpoint F1 - 1tb - 7200 RPM (12 x)
测试方法
我创建了一个脚本自动运行所有测试。下面是脚本的工作原理:
- 创建存储池+ vdev。
- 在池上写入数据(池容量的XX %)
- 将任意驱动器替换为另一个驱动器。
- 等待转盘完成。
- 日志resilver duration o csv文件。
对于每次测试,我在测量继电器性能之前,都会将数据池填充到25%。
警告
池只被填满25%的问题是,驱动器在开始时速度很快,但当它们被填满时性能会显著下降。这意味着您不能推断结果并计算50%或75%池使用率的resilver时间,实际数字可能比这更糟。
我应该以50%的使用率再次运行测试,看看我们是否能证明这种效果。
当心这种测试方法可能只适用于DIY家庭NAS构建。企业中使用的生产文件系统可能更加碎片化,有人告诉我,这可能会大大减缓恢复时间。
测试结果(越低越好)
结果只能用于演示不同RAID级别和每个VDEV的磁盘计数之间的相对中继器性能差异。
您不应该期望您自己的NAS得到相同的性能结果,因为硬件可能与我的测试设置有很大不同。
观察
我认为可以提出以下几点看法:
- 即使所涉及的驱动器数量增加,镜像也能以最快的速度恢复。
- 当使用5个或更少的磁盘时,RAID-Z resilver的性能与使用镜像相当。
- RAID-Zx resilver性能随着VDEV中驱动器数量的增加而下降。
我发现一个有趣的现象:在RAID-Z VDEV中,由于驱动器数量较少,重建性能与镜像设置大致相当。如果长时间的重新构建会让您对使用RAID-Z望而却步,那么也许不应该这样做。可能还有其他原因导致您回避RAID-Z,但这似乎不是其中之一。
RAID-Z2通常在家庭NAS构建者中非常流行,因为它在容量和冗余之间提供了非常好的平衡。更宽的RAID-Z2 vdev空间效率更高,但同样明显的是,resilver操作需要更长的时间。因为RAID-Z2可以容忍两个驱动器的损失,我认为更长的恢复器时间似乎是一个合理的权衡。
很明显,当您在单个RAID-Zx VDEV中放入更多磁盘时,重新构建时间就会增加。这可以用作参数,以保持每个VDEV的驱动器数量“合理”或切换到RAID-Z3。
25% vs 50%的池使用率
对我来说,这里没什么特别的。回轮时间平均略差于25%回轮持续时间的两倍。随着磁盘被填满(内径更短/更慢),磁盘性能开始下降。这就是为什么我要解释结果比完美线性缩放略差。
最后的话
我希望每个人都能对这个基准测试感兴趣,更重要的是,您可以使用前面提到的基准测试来运行自己的基准测试脚本.如果您想运行自己的基准测试,那么脚本可能要运行好几天。如果您对这些测试结果或测试的方式有疑问或评论,请留下您的评论。欧宝体育直播官网
评论