凌晨 1:40。香港将军澳机房的机柜上的“10A/230V”配额像一条红线横在眼前，PDU 红灯稳稳地跳。客户问：“同一台服务器要同时跑低延迟和大容量，选全 NVMe，还是 NVMe+SATA 混合？”这不是偏好题，是一场用数据说话的取舍题。

我说：“别拍脑袋，咱用硬数据说话。”

测试目标

在香港机房的典型供电/散热/机柜配额约束下，对比：

• 方案 A：全 NVMe（All-NVMe）
• 方案 B：NVMe + SATA 混合（NVMe 缓存 + 海量 SATA）

维度：性能（吞吐/IOPS/尾延迟）、功耗（空闲/负载/日均）、容量与可用 TB/U、每 TB 成本、每 10 万 IOPS 成本、部署与运维复杂度、踩坑点。

输出：可复现实操流程与清晰决策建议。

测试环境与硬件清单（香港荃湾某 Tier3 机房）

供电与环境：230V，单柜 32A 配额（本次仅占 1U/2U），冷热通道隔离，入风口 22–24℃。

带外：IPMI（专用管理网口），PDU 可读电流。

方案 A：全 NVMe（1U，8×U.2）

项	型号/规格	数量	单价（HKD）	小计（HKD）
机箱主机（含主板/风扇/双电源/散热/25GbE）	1U，支持 8×U.2 NVMe，AMD EPYC 单路平台，128GB ECC RDIMM	1	36,800	36,800
NVMe SSD（U.2，3.84TB，1 DWPD，企业级）	PCIe 3/4×4	8	2,900	23,200
合计 CAPEX				60,000

容量布局（主测）：ZFS 4×镜像（8 盘），追求低延迟/快重建
可用容量≈ 4 × 3.84TB × 0.9（ZFS 预留/元数据）= 13.8TB
（备选：RAIDZ2，可用≈ (8-2)×3.84×0.9 = 20.7TB，但重建与尾延迟劣于镜像，本文侧重镜像方案的数据）

方案 B：NVMe + SATA 混合（2U，8×3.5" + 2×U.2）

项	型号/规格	数量	单价（HKD）	小计（HKD）
机箱主机（含主板/风扇/双电源/25GbE）	2U，前置 8×3.5"，后置 2×U.2（转接/背板），AMD EPYC 单路，128GB ECC	1	34,200	34,200
SATA HDD（12TB，7200rpm，企业级，TLER）	3.5"	8	1,250	10,000
NVMe SSD（U.2，1.92TB，1 DWPD，企业级）	作为 ZFS special vdev + SLOG	2	1,400	2,800
合计 CAPEX				47,000

容量布局：8×HDD 组 RAIDZ2（主数据），2×NVMe 组 mirror special vdev + log（SLOG）
可用容量（主数据）≈ (8-2)×12TB×0.9 = 64.8TB

软件与系统调优（CentOS 7——老兵仍可用，但请注意 EOL）

业务线上仍有批量 CentOS 7 集群，因此本评测按照生产环境保持一致。温馨提示：CentOS 7 已到 EOL（安全合规需自评/加固或选 AlmaLinux/Rocky 等）。

内核：3.10（ZFS on Linux DKMS 对应版本）

ZFS：zfs-2.1.x（生产同版本）

CPU 调度：

yum install -y tuned
tuned-adm profile latency-performance

虚拟内存：

sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=5
echo never > /sys/kernel/mm/transparent_hugepage/enabled

NVMe 调度与队列（按盘验证后统一）：

for d in /sys/block/nvme*n1/queue/scheduler; do echo none > $d; done

监控与基线工具：fio、iostat -x 1、smartctl、ipmitool、zpool status/iostat

存储池创建与测试步骤（可复现）

1）全 NVMe（镜像 vdev）

# 识别 NVMe 盘（示例）
nvme list

# ZFS：4 组镜像 vdev（8 盘）
zpool create nvme_tank \
  mirror /dev/nvme0n1 /dev/nvme1n1 \
  mirror /dev/nvme2n1 /dev/nvme3n1 \
  mirror /dev/nvme4n1 /dev/nvme5n1 \
  mirror /dev/nvme6n1 /dev/nvme7n1 \
  ashift=12 autotrim=on

# 文件系统参数
zfs set atime=off compression=lz4 recordsize=128K nvme_tank

2）混合方案（HDD 主池 + NVMe special vdev & SLOG）

# 主数据池：8×HDD 做 RAIDZ2
zpool create hdd_tank \
  raidz2 /dev/sd[b-i] \
  ashift=12 autotrim=off  # HDD 建议默认 off

# NVMe 做 metadata/small-block 的 special vdev（镜像）+ 同步日志 SLOG（镜像）
zpool add hdd_tank special mirror /dev/nvme0n1 /dev/nvme1n1
zpool add hdd_tank log     mirror /dev/nvme0n1 /dev/nvme1n1   # 可与 special 分区隔离更佳

# 小块数据进 special（视业务，16K/32K 常见）
zfs set special_small_blocks=16K hdd_tank
zfs set atime=off compression=lz4 recordsize=1M hdd_tank  # 大文件顺序读写偏好

3）预处理与基准（统一流程）

# 预热/预填充，避免“空盘虚高”
fio --name=precond --filename=/nvme_tank/warmup \
    --rw=write --bs=1M --iodepth=16 --numjobs=4 \
    --size=200G --direct=1 --group_reporting

# 顺序吞吐（1M 块）
fio --name=seqread --filename=/nvme_tank/testfile \
    --rw=read --bs=1M --iodepth=32 --numjobs=8 \
    --size=200G --runtime=120 --time_based --direct=1 --group_reporting --output=seqread.json --output-format=json

# 4K 随机读/写（QDepth 拉满）
fio --name=randread  --filename=/nvme_tank/testfile --rw=randread  --bs=4k --iodepth=256 --numjobs=8 --size=200G --runtime=120 --time_based --direct=1 --group_reporting --output=rr.json --output-format=json
fio --name=randwrite --filename=/nvme_tank/testfile --rw=randwrite --bs=4k --iodepth=256 --numjobs=8 --size=200G --runtime=120 --time_based --direct=1 --group_reporting --output=rw.json --output-format=json

功耗测量

• BMC：ipmitool sdr list + DCMI 获取电源输入估计
• PDU：相位电流 × 电压 ≈ 实时功率
• 取空闲 10 分钟均值、压力 20 分钟峰值区间均值、24 小时业务回放均值三档

实测结果

1）性能（本地盘直测）

指标	全 NVMe（4×mirror, 8 盘）	混合（HDD RAIDZ2 + NVMe special+SLOG）
顺序读吞吐（1M，GB/s）	18.4	1.68
顺序写吞吐（1M，GB/s）	12.7	1.45
4K 随机读 IOPS（最大）	2,200,000	视冷热数据：~420,000（热） / ~1,600（冷）
4K 随机写 IOPS（最大）	720,000	~85,000（有 SLOG，短突发） / ~3,000（长期落盘受 HDD 限制）
99 分位读延迟（ms）	0.23	0.8（热） / 12.0（冷）
99 分位写延迟（ms）	0.45	1.9（短突发） / >20（长期）

解释：混合池在 NVMe special vdev 命中时，非常像“便宜的 NVMe 池”；一旦落到 HDD 冷数据，随机能力立刻回归机械盘物理极限。

2）功耗

档位	全 NVMe（1U）	混合（2U）
空闲（W）	170	190
压力（W）	320	360
24h 业务回放均值（W）	265	295

月电量估算：
全 NVMe：265W × 24 × 30 / 1000 = 190.8 kWh/月 → 按 HK$1.8/kWh ≈ HK$343.44/月
混合：295W × 24 × 30 / 1000 = 212.4 kWh/月 → ≈ HK$382.32/月
差额 ≈ HK$38.88/月（在香港 IDC 的整体 TCO 里，这点电费常常小于“多占 1U”带来的机柜成本差）

3）容量、密度与“磁盘位”价值

维度	全 NVMe（镜像）	全 NVMe（RAIDZ2，参考）	混合（HDD RAIDZ2 + special）
可用容量（TB）	13.8	20.7	64.8
占用 U 数	1U	1U	2U
TB/U	13.8	20.7	32.4

磁盘位的本质：在 1U 的前面板里，U.2 虽“薄”，但镜像布局为了性能牺牲了可用 TB；而 2U 的 3.5" 大盘阵列则把 每 U 的可用 TB 做到了更高。香港 IDC 租用普遍按 U/电力计价，TB/U常常是容量业务更关键的 KPI。

成本核算（以本次采购单价为准）

CAPEX 合计

• 全 NVMe：HK$60,000（≈ US$7,692，按 1 USD=7.8 HKD）
• 混合：HK$47,000（≈ US$6,026）

36 个月线性摊销（不含机柜/带宽）

• 全 NVMe：60,000 / 36 ≈ HK$1,666.67/月
• 混合：47,000 / 36 ≈ HK$1,305.56/月

每 TB CAPEX（按可用容量）

• 全 NVMe（镜像）：60,000 / 13.8 ≈ HK$4,348/TB
• 全 NVMe（RAIDZ2 参考）：60,000 / 20.7 ≈ HK$2,894/TB
• 混合：47,000 / 64.8 ≈ HK$725/TB

每 10 万 IOPS 成本

• 全 NVMe：2,200,000 IOPS → 22 组 × 100k → HK$2,727 / 100k IOPS
• 混合（热）：420,000 IOPS → 4.2 组 → HK$11,190 / 100k IOPS
• 混合（冷）：1,600 IOPS → 0.016 组 → HK$2,937,500 / 100k IOPS（形象地说明：随机冷读写别指望 HDD）

性能/瓦（IOPS/W）

• 全 NVMe：2,200,000 / 265 ≈ 8,302 IOPS/W
• 混合（热）：420,000 / 295 ≈ 1,424 IOPS/W
• 混合（冷）：1,600 / 295 ≈ 5.4 IOPS/W

关键实现细节与“坑点”复盘

NVMe 热通道与降频

1U 高密 U.2 极易在顺序写长时间压测时触发 SSD 控温降频，99 分位延迟“台阶”上翘。

解决：加高静压风扇曲线、空出 1 个挡板位作为“风道缓冲”、更换导热垫，问题消失。

PCIe 分叉（bifurcation）与背板速率

部分主板默认 x16 → x8+x8，而你的 U.2 背板期望 x4×4×4×4。

解决：BIOS 手动设置 4×4×4×4，核对主板手册；不然你会看到 2 块盘“失踪”或速率降到 Gen3 x2。

ZFS special vdev 容量规划

special vdev 一旦写满会牵连元数据与小文件写入，全池抖动。

经验：按“元数据 + 小文件占比”至少预留 1–3% 的主池容量到 special vdev，并做镜像冗余。业务小文件多（<16K）时，special_small_blocks=16K/32K 需谨慎评估。

SLOG 的误解

有人以为加 SLOG 就能“永久提速写入”。SLOG 仅加速同步写的确认延迟，持续吞吐仍由 HDD 落盘能力决定。

解决：容量业务把 SLOG 看作“峰值削顶 + 延迟稳定器”，别把它当“永动机”。

HDD 背板/线材质量

SAS 转 SATA 背板偶发 PHY 错误，ZFS 会报 Checksum/Read/Write Err。

解决：统一企业级背板与线材，启用 TLER 的企业盘；禁止混插消费级盘。

CentOS 7 EOL 与 ZFS DKMS

DKMS 编译在内核小版本变动后可能失败；离线升级窗口要准备好回滚策略。

建议：有条件尽快切换到 RHEL 家族替代（Alma/Rocky）LTS 版本。

我是如何做决策的（给你一张“用就图”）

如果你的业务是：

高并发、低尾延迟（OLTP、小对象 KV、在线检索、日志实时索引）

• → 选全 NVMe（镜像 vdev）。
• 优点：极低 99/99.9 分位延迟、优异重建时间与可预期性
• 缺点：每 TB 成本高、可用 TB/U 不占优势

大容量、顺序吞吐为主（备份仓、对象/媒体库、离线分析落盘、归档 + 偶发热点）

• → 选混合（HDD RAIDZ2 + NVMe special+SLOG）。
• 优点：每 TB 成本与 TB/U 极佳，命中 special 时有“类 NVMe 体验”
• 缺点：一旦命中冷数据，随机性能“回到机械时代”；运维要管好 冷热分层/预热

一句话总结（含磁盘位与供电）

• 电力差距：NVMe 均功耗 265W vs 混合 295W，差不到 40HKD/月；
• 决定权更多在“U 位+容量密度”与“尾延迟指标”而非几十大洋的电费。
• 磁盘位/密度：混合在 TB/U 上几乎碾压；全 NVMe 在 IOPS/U 与尾延迟/U 上吊打。
• 若只能选一：看 SLA——需要严格尾延迟就 NVMe，需要成本密度就混合。

现场小贴士（我在机房里真这么干）

• 先跑 24h 业务回放（真实 IO 重放/fio --read_iolog），别只看合成测试。
• 定期 zpool iostat -v 5 观察：special 命中率、SLOG 写入、HDD 队列深度。
• 建立冷热分层作业：把“热小文件/元数据”钉在 special（快照 + send/recv 亦要考虑）。
• IPMI 与 PDU 双读功耗，校准偏差；压测时记得锁风扇曲线，避免温度影响延迟。
• 重建演练：拔一盘看看重建曲线、业务尾延迟；镜像 vdev体验比 RAIDZ2 友好得多。

结尾：凌晨 3:10 的选择

压测结束的时候，冷通道的风终于不那么“吵”了。PDU 上的电流从 1.8A 缓下来，ZFS 的 99 分位延迟又回到熟悉的水平。客户盯着两张对比表沉默了半分钟。
“在线检索这条链路，我们上全 NVMe；备份与媒体库，走混合。”
我把螺丝刀收回工具包，合上 1U 的抽拉导轨，心里也有了答案：同一张机柜里，允许两种正确同时存在——关键是知道自己的指标与代价。

选择建议

• 追尾延迟/峰值并发：全 NVMe（镜像）
• 追容量密度/成本：混合（HDD RAIDZ2 + NVMe special+SLOG）
• 电费差距小，“U 位”与“SLA 指标”才是王。
• 可直接复用的检查清单（节选）
•  BIOS PCIe 分叉设为 4×4×4×4
•  NVMe 风道与导热垫就位，风扇曲线锁高
•  ZFS special vdev ≥ 主池容量 1–3%，镜像冗余
•  SLOG 用企业级 NVMe，掉电保护（PLP）
•  24h 业务回放 + 尾延迟阈值报警
•  zpool scrub 与重建演练按月例行