ZFS:各种RAID模式的弹性性能

2016年1月31日 类别:存储

当你建立自己的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)

测试方法

我创建了一个脚本自动运行所有测试。下面是脚本的工作原理:

  1. 创建存储池+ vdev。
  2. 在池上写入数据(池容量的XX %)
  3. 将任意驱动器替换为另一个驱动器。
  4. 等待转盘完成。
  5. 日志resilver duration o csv文件。

对于每次测试,我在测量继电器性能之前,都会将数据池填充到25%。

警告

池只被填满25%的问题是,驱动器在开始时速度很快,但当它们被填满时性能会显著下降。这意味着您不能推断结果并计算50%或75%池使用率的resilver时间,实际数字可能比这更糟。

我应该以50%的使用率再次运行测试,看看我们是否能证明这种效果。

当心这种测试方法可能只适用于DIY家庭NAS构建。企业中使用的生产文件系统可能更加碎片化,有人告诉我,这可能会大大减缓恢复时间。

测试结果(越低越好)

重新挂银图

结果只能用于演示不同RAID级别和每个VDEV的磁盘计数之间的相对中继器性能差异。

您不应该期望您自己的NAS得到相同的性能结果,因为硬件可能与我的测试设置有很大不同。

观察

我认为可以提出以下几点看法:

  1. 即使所涉及的驱动器数量增加,镜像也能以最快的速度恢复。
  2. 当使用5个或更少的磁盘时,RAID-Z resilver的性能与使用镜像相当。
  3. 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%回轮持续时间的两倍。随着磁盘被填满(内径更短/更慢),磁盘性能开始下降。这就是为什么我要解释结果比完美线性缩放略差。

最后的话

我希望每个人都能对这个基准测试感兴趣,更重要的是,您可以使用前面提到的基准测试来运行自己的基准测试脚本.如果您想运行自己的基准测试,那么脚本可能要运行好几天。如果您对这些测试结果或测试的方式有疑问或评论,请留下您的评论。欧宝体育直播官网

评论

Baidu
map