服务器应选择哪种RAID级别？

01

首先编写恢复要求

用通俗的语言定义故障模型：一台设备、两台设备、一个控制器、意外删除或整个服务器。RAID仅解决某些设备故障。为服务恢复设定恢复时间目标，为数据丢失设定恢复点目标，然后确定本地阵列可以满足哪些要求，哪些需要异地复制或备份。

还要记录系统在降级时是否必须继续接受写入。以读为主的存档、写入密集型数据库和一次性暂存空间可能使用相同数量的驱动器，但需要不同的布局。因此，容量效率只是一个约束条件，而不是最终结论。

02

将布局与工作负载和设备数量相匹配

对于双设备启动或数据集，镜像简单直接，并且适合独立镜像组有用的随机 I/O。奇偶校验布局以写入工作和重建复杂性换取更多容量。双奇偶校验可以在宽 HDD 集中保留额外的故障余量，而 RAID 10 以一半的原始容量换取镜像对。这些是设计倾向，而非性能保证；控制器、文件系统、队列深度、记录大小和应用模式都很重要。

使用实际目录拓扑。12 驱动器和 24 驱动器存储服务器提供了双 NVMe 计算服务器上不可用的选择。不要将独立的 NVMe 启动对加入数据阵列计算，也不要假设一个非常宽的组比多个组更可取，而不对故障域和 I/O 行为进行建模。

03

选择一层来负责冗余

决定是由硬件控制器、Linux MD 还是诸如 ZFS 的文件系统拥有布局。避免在没有文档说明的情况下堆叠独立的 RAID 层，因为健康和替换状态可能变得模糊。ZFS 冗余通过镜像或 RAIDZ vdev 表达，并依赖校验和；丢失顶级 vdev 可能导致池丢失，因此向原本冗余的池中添加单个非冗余设备会改变故障模型。

在创建阵列之前，确认驱动器身份、更换程序、启动行为以及操作系统可以观察到的内容。以后更改拓扑可能会受到限制或造成中断，特别是对于奇偶校验布局。

• 打开ZFS vdev 结构 ↗

04

规划降级和重建窗口

监控必须区分健康、降级、重建和一致性检查状态。Linux MD公开了重新同步、恢复、检查和修复等操作；收集进度和不匹配情况，而不是仅报告卷已挂载。脏且降级的RAID5或6可能带来损坏风险，因此强制组装绝不能成为常规恢复捷径。

记录警报路由、备用件获取、更换标识、工作负载限制以及何时恢复比继续更安全。切勿在未测量交付设备、阵列负载和控制器的情况下承诺重建持续时间。

05

记录选择及其限制

完成的设计应指明布局、等驱动器假设、可用容量估计、容忍的故障、监控来源和恢复位置。将版本化数据保存在另一个故障域中并测试恢复。预期结果不是声称 RAID 防止丢失；而是在生产数据到达之前，其故障行为和恢复责任已被理解的阵列。