关于热备件

Question

我对 ZFS 还不太熟悉，但我正在建立一个包含 12 个物理驱动器的新存储池。

我当前的计划是在 10 个驱动器和两个热备用驱动器上安装 RAIDZ2。

但我想知道，如果所有 12 个驱动器都使用 RAIDZ3 并且没有热备件，效果会不会更好。

原因是热备件基本上是通电的空闲驱动器。它们可能要几个月或几年才会被调用，到那时我可能会发现它们不可行。如果它们是 RAID 条带的一部分，我至少可以得到关于它们是否良好的反馈。

我在网上没有看到太多关于此问题的讨论。有人能提供建议吗？

Answer 1

关于热备件

热备件设置为特定池，但可以附加到任何 vdev在发生故障时自动合并池。如果您只有一个由所有磁盘组成的 vdev，则最好直接合并磁盘（除非您已经拥有 RAIDZ3 并且仍有备用磁盘）。

此外，重新同步需要时间，并且发生在易受攻击（RAIDZ1，双向镜像）或性能降低的状态（RAIDZ2，RAIDZ3，三向镜像），如果您已经将设备连接到 vdev，则不会发生这种情况。

基本上，热备件是大型阵列的必备品。如果您在 RAIDZ3 中将 27 个磁盘分成 3 个 vdev，每个 vdev 有 9 个磁盘，则可以添加 3 个热备件，以减少“现在是凌晨 2 点，3 个磁盘崩溃了，现在我必须起床并修复这个烂摊子”的情况（假设系统有 32 个驱动器托架）。较小的系统通常没有足够的磁盘，甚至无法达到“2+ vdev 和 Z2/Z3”的情况。镜像（例如 6 x 2）是个例外，在这种情况下，崩溃对池来说更接近致命（并且您没有足够的磁盘将它们变成 6 x 3）。

---

最佳泳池布局

一些建议Nex7 的博客关于泳池布局：

• 不要将 raidz1 用于 1TB 或更大的磁盘。
• 对于 raidz1，每个 vdev 中不要使用少于 3 个磁盘，也不要使用超过 7 个磁盘（同样，它们的大小应在 1 TB 以下，最好在 750 GB 以下）（5 是典型的平均值）。
• 对于 raidz2，每个 vdev 中请勿使用少于 6 个磁盘，也不要使用超过 10 个磁盘（8 个是典型的平均值）。
• 对于 raidz3，每个 vdev 中请勿使用少于 7 个磁盘，也不要使用超过 15 个磁盘（13 和 15 是典型平均值）。
• 镜像几乎每次都胜过 raidz。在驱动器数量相同的情况下，镜像池的 IOPS 潜力远高于任何 raidz 池。唯一的缺点是冗余 - raidz2/3 更安全，但速度要慢得多。唯一不以性能换取安全性的方法是三向镜像，但它会牺牲大量空间（但我见过客户这样做 - 如果您的环境需要它，那么成本可能是值得的）。
• 对于 >= 3TB 大小的磁盘，三向镜像开始变得越来越引人注目。

这意味着，对于您来说，您可以有以下选择：

1. 9 个可用磁盘：（Z3 和 9+3）
2. 8 个可用磁盘：（Z2 带 4+2）++（Z2 带 4+2）
3. 5 个可用磁盘：（2 个镜像）* 5 ++（热备用）* 2
4. 4 个可用磁盘：（3 个镜像）* 4

我会按照 (降序) 顺序排列它们：

• 就可用空间而言：1、2、3、4
• 安全性方面：1、2/4、3
• 速度方面：4、3、2、1
• 就扩展/添加驱动器的能力而言：3、4、2、1

无论大小，我都不会使用 RAIDZ1，因为您可能以后想用更大的磁盘替换它们，然后问题就会出现（这意味着您不想以这种方式升级，并且可能无法在不添加额外磁盘的情况下增加存储空间）。

Answer 2

我刚刚对一个测试 ZFS 设置进行了基准测试，以回答有关性能的问题（在一对从灰烬中复活的旧服务器上）。

我的设置是：

• 2x Intel Xeon L5640 CPU @ 2.27GHz（总计：12 个核心；禁用 HT）

• 96GiB DDR3 内存 @ 1333MHz

• Adaptec 5805Z 控制器，将所有磁盘导出为 JBOD（启用写入缓存，得益于控制器的电池供电的 NVRAM）

• 12x 15kRPM 146GB SAS 磁盘（Seagate ST3146356SS）

• 每-通过 IP-over-Infiniband (20Gb/s Mellanox MT25204) 进行磁盘 DRBD 复制 (协议 C)

• Debian/Stretch 上的 ZFS 0.7.6

• zpool create -o ashift=12 ... /dev/drbd{...} （注意：DRBD 使用的复制“单元”大小为 4KiB）

• zfs create -o recordsize=128k -o atime=off -o compression=off -o primarycache=metadata ... （最后两个仅用于基准测试目的）

以下是 RAIDz2 和 RAIDz3 所有可能的有趣组合的 bonnie++ 结果（5 次运行的平均值12 个同步的 bonnie++ 进程):

TEST: # data bandwidth
      bonnie++ -p <threads>
      for n in $(seq 1 <threads>); do
        bonnie++ -r 256 -f -s 1024:1024k -n 0 -q -x 1 -y s &
      done
      # create/stat/delete operations
      bonnie++ -p <threads>
      for n in $(seq 1 <threads>); do
        bonnie++ -r 256 -f -s 0 -n 128:0:0:16 -q -x 1 -y s &
      done

CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=278273, RW=150845, RD=487315
 ops/s: SCr=132681, SDl=71022, RCr=133677, RDl=71723

CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=276121, RW=158854, RD=480744
 ops/s: SCr=132864, SDl=71848, RCr=127962, RDl=71616

CASE: 1*RAIDz2(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=260164, RW=151531, RD=541470
 ops/s: SCr=137148, SDl=71804, RCr=137616, RDl=71360

CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=269130, RW=184821, RD=672185
 ops/s: SCr=134619, SDl=75716, RCr=127364, RDl=74545

CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=255257, RW=135808, RD=509976
 ops/s: SCr=136218, SDl=74684, RCr=130325, RDl=73915

CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5(data)/3(ops)
 MiB/s: WR=379814, RW=225399, RD=586771
 ops/s: SCr=120843, SDl=69416, RCr=122889, RDl=65736

DATA: WR  = Sequential Write
      RW  = Sequential Rewrite
      RD  = Sequential Read
      SCr = Sequential Create
      SDl = Sequential Delete
      RCr = Random Create
      RDl = Random Delete

就性能而言：

• 2*RAIDz2(4d+2p+0s) 是读/写性能均衡的赢家

• 1*RAIDz3(8d+3p+1s) 可实现最大读取性能（相当奇怪）

至于如何解释这些结果；我的看法是：

• 8 个数据磁盘精确划分了 128k 记录大小，这也许可以解释（？）为什么它们总是优于 9 个或 10 个数据磁盘（假设测试以 1024k 块大小运行，该块大小与所有磁盘完全对齐）

• 我预计 RAIDz3 的性能会比 RAIDz2 差，但 1*RAIDz3(8d+3p+1s) 的情况却非常奇怪地与此相矛盾

• 2*RAIDz2(4d+2p+0s) 案例的 VDEV 大小明显较小，这或许可以解释（？）为什么其写入性能明显更好

编辑1

针对 @AndrewHenle 的评论，下面是具有不同“块”大小的附加基准。不幸的是，邦尼++不允许 2 的幂以外的块大小；因此我恢复为（平均 5 次运行） 的日：PS：请记住，ZFS 读取缓存（ARC）是已禁用

TEST: # WR: Sequential Write
      rm /zfs/.../dd.*
      for n in $(seq 1 <threads>); do
        dd if=/dev/zero of=/zfs/.../dd.${n} bs=<chunk> count=<count> &
      done
      # RD: Sequential Read
      for n in $(seq 1 <threads>); do
        dd of=/dev/null if=/zfs/.../dd.${n} bs=<chunk> count=<count> &
      done

CASE: 1*RAIDz2(10d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  418.64   (n/a)  434.56  404.44  361.76
        RD  413.24   (n/a)  469.70  266.58   15.44

CASE: 1*RAIDz3(9d+3p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024    1024    1024   10240  327680(32768 for RD)
 MiB/s: WR  428.44  421.78  440.76  421.60  362.48
        RD  425.76  394.48  486.64  264.74   16.50

CASE: 1*RAIDz3(9d+2p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024    1024    1024   10240  327680(32768 for RD)
 MiB/s: WR  422.56  431.82  462.14  437.90  399.94
        RD  420.66  406.38  476.34  259.04   16.48

CASE: 1*RAIDz3(8d+3p+1s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  470.42   (n/a)  508.96  476.34  426.08
        RD  523.88   (n/a)  586.10  370.58   17.02

CASE: 1*RAIDz2(8d+2p+2s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  411.42   (n/a)  450.54  425.38  378.38
        RD  399.42   (n/a)  444.24  267.26   16.92

CASE: 2*RAIDz2(4d+2p+0s), ashift:12(4k), recordsize:128k, threads:12, runs:5
 chunk:      1280k   1152k   1024k    128k      4k
 count:       1024   (n/a)    1024   10240  327680(32768 for RD)
 MiB/s: WR  603.64   (n/a)  643.96  604.02  564.64
        RD  481.40   (n/a)  534.80  349.50   18.52

至于我的 1 便士：

• ZFS 显然可以足够智能地优化写入（即使对于低于记录大小的块大小）和/或(?) Adaptec 控制器（非挥发性, 512MiB) 缓存在这方面有很大帮助

• 显然，禁用 ZFS 读取缓存 (ARC) 对于接近或低于记录大小的块大小非常不利；而且 Adaptec 控制器缓存似乎（令人惊讶？）不用于读取目的。底线：禁用 ARC 以进行基准测试可以深入了解“原始、低级”性能，但不建议用于生产用途（除了特定情况，例如很少使用的大型文件库）

• 调整块大小以匹配 VDEV 大小不是发挥积极作用[错误假设；参见编辑2]

编辑2

关于 RAIDz 和块大小（ashift）以及记录大小（ZFS 文件系统）：

• RAIDz 通过数据/奇偶校验块填充底层设备，其大小由 ashift 大小决定

• 记录（而非块）是校验和以及写时复制操作的“基本单位”

• 理想情况下，ZFS 文件系统记录大小应该可以被 VDEV 中的数据盘数量 (D) 整除（但由于它必须是 2 的幂，因此可能很难实现）

• https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzHowWritesWork

• https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSRaidzHowWritesWorkII

• https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSLogicalVsPhysicalBlockSizes

警告：

• 热的备件可能不是除非经过非常仔细的配置，否则无法工作，并且功能已测试

• https://www.reddit.com/r/zfs/comments/4z19zt/automatic_use_of_hot_spares_does_not_seem_to_work/

底线 （确认其他回复中已经说过的内容）

• （条带化）较小的 VDEV（具有较少的数据磁盘）比大型 VDEV 性能更好；计算/验证奇偶校验显然是一项昂贵的操作，随着数据磁盘数量的增加，其性能会呈线性增长（参见 8d <-> 2*4d 的情况）

• 具有更多奇偶校验磁盘的相同大小的 VDEV 的性能优于具有较少奇偶校验磁盘和热备用磁盘的 VDEV，和提供更好的数据保护

• 如果在优先使用奇偶校验磁盘后仍有磁盘可用，请使用热备用来解决“不要在半夜叫醒我”的问题[警告！请参阅编辑 2]

后记

我最终的用例是托管一个（长期）时间序列数据库（稳定的中等大小的写入和可能非常大的零星读取），对于该数据库，我几乎没有关于 I/O 模式的详细文档（除了“针对 SSD 进行优化”的建议），我个人会选择 1*RAIDz2(8d+3p+1s)：最高安全性，容量稍小，（第二）最佳性能

Answer 3

我的建议是：

2 x 5 磁盘 RAIDZ1 + 两个备用磁盘

或者

3 x 3 磁盘 RAIDZ1 + 备件

或者

10 磁盘 RAID 镜像

或 2 个 RAIDZ2，包含 5 个或 6 个磁盘，带或不带备用磁盘

这取决于使用的磁盘类型。如果 7200 RPM 驱动器超过 2TB，则选择 RAIDZ2。如果是 2TB 和用户，则 RAIDZ1 就足够了。