香港葵涌机房客户的数据库临时扩容窗口只剩 3 小时，而仓库盘位里只剩下“东拼西凑”的 NVMe：有 2TB 的、1.92TB 的，还有一块 960GB 的老将，甚至混着两家厂的固件版本。客户一句话把我锤在机房过道里：“能不能先混上去让业务顶住？”

我深吸一口冷气：混搭能用，但要有章法。于是我边接盘边开测，边踩坑边补救。这篇文章，就是那一夜的复盘与方法论。

测试与部署环境（CentOS 7，贴近生产）

机房：香港葵涌，冷通道温控 23±1℃，热通道最高 34℃。

服务器：Supermicro 2U（双路 Xeon Silver 4214R，128GB DDR4-2933，2×25GbE）。

背板/拓扑：U.2 NVMe 直连 CPU（无硬 RAID），PCIe 3.0 x4 通道。

系统：CentOS 7.9（为 NVMe 稳定性与 io_uring/队列性能，使用 ELRepo 内核）

• kernel-ml 5.4.x（ELRepo）
• mdadm 4.1，fio 3.33，nvme-cli 1.14，smartmontools 7.3

文件系统：XFS（对齐 RAID 条带参数），测试时关闭 atime、启用 no discard（定时 fstrim）。

调优要点

• NVMe 调度器设为 none：echo none > /sys/block/nvmeXn1/queue/scheduler
• IRQ 亲和 & NUMA 绑核，irqbalance 禁用，tuned 使用 throughput-performance
• 读写前预热、进入稳态后采数，采集 CPU/温度/热降速事件（throttle）与 p99/p99.9 延迟。

待测 SSD 列表（全部为真实在产的企业级类型）

注：容量按可用命名空间展示；为公平，混用场景会人为“等容+OP”处理（后文详解）。

*QLC 的写入为短时冲写高、稳态显著下滑（SLC 缓存耗尽后降至 ~0.3–0.6 GB/s；4K 随机写 IOPS 也大幅下降），这是后文混搭的关键风险点之一。

四种阵列组合与测试设计

我以 mdadm 软件阵列测试 RAID10 与 RAID5，文件系统为 XFS，条带与对齐参数严格配置。为保证对比公平，所有场景都进行预热（全盘写 1 次 + 30 分钟混合负载），采集稳态数据。

场景 S1（同品牌同容量，基线）：4× P4510 2TB → RAID10

场景 S2（同容量不同品牌）：2× P4510 2TB + 2× PM983 1.92TB → 统一至 1.92TB 命名空间，再做 RAID10

场景 S3（不同容量不同品牌）：2× P4510 2TB + 1× PM983 960GB + 1× Micron 7300 3.84TB

• 阵列按最小盘容量对齐；演示容量浪费与性能拖拽

场景 S4（TLC+QLC 混用）：3× P4510 2TB + 1× P4320 3.84TB(QLC) → RAID10

• 重点观察稳态写入坍塌与尾延迟

阵列创建与对齐关键命令（可直接复现）

# 统一 LBA 格式：强烈建议全部使用 512e 或全部 4Kn（混用会掉坑）
# 以 NVMe 为例，查看 LBA 格式：
nvme id-ns /dev/nvme0n1 | grep -i "lbaf" -A2

# 必要时重建命名空间，实现“等容+OP”（示例：限制到 1.92TB 并留 10~20% OP）
# !! 注意：此操作会销毁数据，请在维护窗口执行
nvme detach-ns /dev/nvme0 -n 1
nvme delete-ns /dev/nvme0 -n 1
# 1.92TB ≈ 1.92 * 1024^4 / 512 LBAs
nvme create-ns /dev/nvme0 -s 3758096384 -c 3758096384 -f 0
nvme attach-ns /dev/nvme0 -n 1 -c 0

# 创建 RAID10（条带 512K），并对齐 XFS（sunit=条带/4K，swidth=条带*（盘数/2）/4K）
mdadm --create /dev/md0 --level=10 --raid-devices=4 \
  /dev/nvme0n1 /dev/nvme1n1 /dev/nvme2n1 /dev/nvme3n1 \
  --chunk=512

mkfs.xfs -f -d su=512k,sw=2 /dev/md0   # RAID10 四盘 sw=2
mount -o noatime,nodiratime,nobarrier /dev/md0 /data

# fio 典型 job（随机 4K，QD=64，numjobs=4，稳态 5 分钟）
cat > 4k-rand.fio <<'EOF'
[global]
ioengine=libaio
direct=1
bs=4k
time_based=1
runtime=300
ramp_time=60
iodepth=64
numjobs=4
group_reporting=1
filename=/data/fio.test
size=200g

[randread]
rw=randread

[randwrite]
rw=randwrite
EOF

fio 4k-rand.fio

完整测试数据（稳态）——RAID10 重点

单位说明：吞吐 MB/s 或 GB/s；IOPS 以千为单位（K）；延迟毫秒（ms）；CPU 为系统层面核心占用峰值。

表 1：RAID10 稳态性能对比（S1~S4）

解释：

• S2 的下降主要来自固件调度/GC 策略差异与尾延迟增大，阵列性能被“慢一档”的 PM983 拉低。
• S3 既有容量浪费（按 960GB 对齐）又有性能拖拽，顺序写与随机写尤为明显。
• S4（混 QLC）稳态写直接坍塌至 2.1 GB/s，4K 随机写跌到 150K，并出现热节流与尾延迟炸裂；适合做冷数据，不建议与 TLC 放在同一写密集阵列。

表 2：RAID5（补充）——对“混搭”的更敏感

结论：RAID5 对混搭尤其敏感，写放大+校验开销叠加“慢盘效应”，写入抖动、尾延迟更剧烈。混搭场景更建议 RAID10 或 RAID6，或分层架构替代。

关键坑点与现场解决

1) 512e / 4Kn 扇区混用导致延迟抖动

症状：md 组阵列后，写入延迟 p99 偶发飙高、XFS log 写锁加重。

原因：不同 LBAF（扇区大小）触发对齐/拆分问题。

解决：统一为 512e 或统一为 4Kn（倾向全 512e，生态兼容更好）；必要时重建命名空间或低级格式化。

2) QLC 稳态写入坍塌

症状：20 分钟持续 128K 顺序写后，阵列写速从 3.8 GB/s 断崖到 1.8~2.2 GB/s，4K 写 p99 飙升至 20ms+。

原因：SLC 缓存耗尽 + QLC 编程慢，GC 压力大。

解决：

不把 QLC 放在热写阵列；将其作为冷数据/只读缓存落地层。

若必须混用：对全阵列做等容+较高 OP（≥20%），并通过 LVM/调度将随机写倾斜到 TLC 盘。

3) Gen4 盘插在 Gen3 背板

症状：“明明是新盘，速度没快多少”。

原因：整机拓扑/背板仅 PCIe Gen3，链路被降速。

排查：lspci -vv 查看 LnkSta；必要时在 BIOS 固定链路速率，避免自协商不稳。

4) 条带/对齐设置不当

症状：顺序吞吐低于预期、随机 IO 抖动。

解决：RAID10 四盘 --chunk=512K，XFS su=512k, sw=2；RAID5 四盘 sw=3。

读缓存：根据工作集大小设置 read_ahead_kb（如 4096~16384），批量顺序读会收益明显。

5) fstrim 定时导致抖动

症状：业务高峰碰上 fstrim，个别盘出现瞬时 p99 尖峰。

解决：将 fstrim.timer 调整到业务低谷；或分卷错峰。

混搭可行性的“红线与黄线”

红线（尽量避免）

• TLC 与 QLC 同阵列承载热写（数据库/日志/消息队列等）。
• 512e 与 4Kn 混用。
• RAID5 + 混搭承载写重负载。
• 固件家族跨度太大（GC、写缓存策略差异显著）。

黄线（可行但要控制）

• 同容量不同品牌：务必做等容 + 10~20% OP，统一 LBAF、统一条带与文件系统对齐。
• 不同容量同品牌：以最小盘为锚等容，评估可接受的容量浪费；或把大盘切 namespace做其他卷。
• 热数据/冷数据分卷，通过 LVM/调度把写入集中在“更能扛”的 TLC。

规避与优化清单（落地执行）

• 等容化：用 NVMe 命名空间或 LVM/分区把所有盘裁成相同容量，并预留 ≥10~20% 的 OP。
• 统一扇区：全部 512e（或全部 4Kn），不要混。
• 条带/对齐：RAID10 chunk >= 512K，XFS su/swidth 对齐；顺序读多则调大 read_ahead_kb。
• 分层：TLC 承载热写卷，QLC 做只读/冷数据或次级缓存。
• 温控：U.2 风道补风，保持 NVMe < 70℃；避免热节流。
• 固件统一：同一品牌尽量同一固件家族；不同品牌至少确保写缓存/GC 策略相近。
• 定时 TRIM：错峰执行，避免业务高峰。
• 监控尾延迟：业务看 p95/p99/p99.9，而不是只看平均值。
• 备份/校验：混搭阵列更要定期校验（scrub）与可用性演练。
• RAID 策略：混搭优先 RAID10 或 RAID6，不推荐 RAID5 抗写。
• 驱动/内核：CentOS 7 建议用 ELRepo kernel-ml 5.x，NVMe 栈更成熟。
• 链路速率：确认背板/链路代际，避免“Gen4 盘跑在 Gen3 心态崩”。

如果你也要复现：我的最小可行配置与脚本片段

# 安装新内核（CentOS 7）
yum install -y https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
yum --enablerepo=elrepo-kernel install -y kernel-ml
grub2-set-default 0 && reboot

# 性能调优（示例）
tuned-adm profile throughput-performance
systemctl stop irqbalance && systemctl disable irqbalance

# NVMe 队列与调度
for d in /sys/block/nvme*n*; do
  echo none > $d/queue/scheduler
  echo 1024 > $d/queue/nr_requests
done

# 周期性 fstrim（错峰到凌晨 03:30）
systemctl enable fstrim.timer
sed -i 's/OnCalendar=.*/OnCalendar=*-*-* 03:30:00/' /usr/lib/systemd/system/fstrim.timer
systemctl daemon-reload && systemctl restart fstrim.timer

给正在犹豫“混搭盘”的你一个决策清单

先问三件事：

• 你的工作负载是否写入密集？（数据库、消息队列、日志）
• 你能否接受容量浪费来换取阵列稳定性？
• 你是否能做等容 + 统一 LBAF + 足额 OP + 分层？

选择建议：

• 优先：同品牌同容量（S1 模型），省心省力，尾延迟最稳。
• 退而求其次：同容量不同品牌（S2），务必等容 + OP，能满足大多数生产需求。
• 谨慎：不同容量不同品牌（S3），会有明显容量浪费 + 性能拖拽；仅在短期过渡可接受。
• 不建议：TLC+QLC 混阵承载热写（S4），稳态写与尾延迟风险高；请分层/分卷。

那晚 4 点半，我把 QLC 从热写阵列里剥离出来，做了冷数据卷；把剩下的 TLC 盘等容+OP后重建了 RAID10。数据库的 p99 写延迟从 20ms 回落到 5~6ms，客户在晨会上只说了句“稳了”。
机房外，天边发白。混搭不是不行，但要有边界、有方法、有监控。当你掌控了尾延迟，业务就掌控在你手里。