ZFS 热备件与更多奇偶校验

Question

ZFS 热备件与更多奇偶校验

Ala*_*ect 9 raid zfs

我对 ZFS 有点陌生，但我正在创建一个包含 12 个物理驱动器的新存储池。

我目前的计划是在 10 个驱动器和两个热备件上使用 RAIDZ2。

但是我想知道在所有 12 个驱动器上使用 RAIDZ3 并且没有热备件是否会更好。

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

我在网上没有看到太多关于这个的讨论。有没有人有建议？

Answer 1

use*_*391 14

关于热备件

热备件被设置到特定的池，但可以在出现故障时自动附加到池的任何 vdev。如果您只有一个包含所有磁盘的 vdev，则最好直接合并这些磁盘（除非您已经有 RAIDZ3 并且还有备用磁盘）。

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

基本上，热备件适用于大型阵列。如果您在 RAIDZ3 中将 27 个磁盘拆分为 3 个 vdevs 的 9 个磁盘，则可以添加 3 个热备件以减少“凌晨 2 点，3 个磁盘崩溃，现在我必须起床解决这个烂摊子”的时刻（假设 32驱动器托架系统）。较小的系统通常没有足够的磁盘来达到“2+ vdevs 和 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 大小的磁盘，3 路镜像开始变得越来越引人注目。

这意味着在您的情况下，您将有以下选择：

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

我会将它们（降序）排列为：

在可用空间方面：1, 2, 3, 4
在安全方面：1、2/4、3
速度方面：4, 3, 2, 1
在扩展/添加驱动器的能力方面：3、4、2、1

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

Answer 2

Céd*_*our 5

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

我的设置是：

2x Intel Xeon L5640 CPU @ 2.27GHz（总计：12 核；禁用 HT）
96GiB DDR3 RAM @ 1333MHz
Adaptec 5805Z 控制器，将所有磁盘导出为 JBOD（启用写入缓存，这要归功于控制器的电池供电 NVRAM）
12 个 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++ 结果（12 个同步 bonnie++ 进程的5 次运行的平均值）：

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

Run Code Online (Sandbox Code Playgroud)

就表演而言：

2*RAIDz2(4d+2p+0s) 是平衡读/写性能的赢家
1*RAIDz3(8d+3p+1s) 实现最大读取性能（很奇怪）

至于如何解释/解释这些结果；我的 1 便士：

8 个数据磁盘准确地划分了 128k 记录大小，这可以解释（？）为什么它们总是优于 9 或 10 个数据磁盘（假设测试以 1024k 块大小运行，它在所有磁盘上完全对齐）
我预计 RAIDz3 的性能比 RAIDz2 差，但 1*RAIDz3(8d+3p+1s) 的情况与此非常奇怪地矛盾
2*RAIDz2(4d+2p+0s) 情况的 VDEV 大小明显更小，这可以解释（？）为什么它的写入性能明显更好

编辑1

为了回应 @AndrewHenle 评论，下面是具有不同“块”大小的附加基准。不幸的是，bonnie++不允许 2 的幂以外的块大小；所以我恢复到（5次平均运行）dd：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

Run Code Online (Sandbox Code Playgroud)

至于我的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 的性能优于较少奇偶校验磁盘和热备用的性能，并提供更好的数据保护

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

后脚本

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

归档时间：	7 年，10 月前
查看次数：	7677 次
最近记录：	7 年，4 月前