凌晨三点，香港葵涌的数据中心。冷气口吹出的风混合着淡淡的金属味，机柜风扇的轰鸣声像一首单调的鼓点，让人心跳加快。监控屏幕的绿光照在脸上，像是永远不会亮起的日出。

一、凌晨三点的香港机房

我坐在一排 Dell R7525 前，笔记本接着 IPMI，背后是同事阿豪，他正靠在机柜门上，一边啃冷掉的饭团一边问我：

• 阿豪：“今晚目标很明确嘛，不是撑死就是救活。”
• 我：“说得轻巧，万一数据库又卡死，客户明早直接飞过来砸机柜。”

客户在微信群里不停催：“凌晨六点前能上线吗？我们结算报表等着跑。”看着跳动的消息提示，我深吸一口气，开始了这场夜战。

二、硬件配置与参数

部署之前，我们拿到的硬件清单如下：

背景对话

• 客户 IT：“为啥一定要 NVMe，不用企业级 SATA SSD？”
• 我：“你们的 MySQL 随机写压力，SATA 早就撑不住了。PM9A3 单盘 800K IOPS，你们 6 台聚合，才有可能压住。”
• 客户：“行，那就信你们一次。”

三、部署日志（逐小时记录）

03:10 - BIOS 调整

1. 关掉 C-State，NUMA awareness 打开。阿豪一边改 BIOS 一边吐槽：
2. 阿豪：“真想一脚踹开 Dell 工程师，这 BIOS 菜单比迷宫还难找。”
3. 我：“你别骂了，赶紧调，不然 CPU 调度不均衡，OSD 又要爆。”

03:45 - 网络调优

ethtool -G ens1f0 rx 4096 tx 4096
ethtool -K ens1f0 gro off lro off
sysctl -w net.core.rmem_max=134217728
sysctl -w net.core.wmem_max=134217728

我盯着屏幕，阿豪突然说：“你发现没？风扇声音大了，估计温度飙了。”我摸了下机柜边，果然烫手，只好调高冷通道风速。

04:20 - 磁盘初始化

for disk in /dev/nvme{0..7}n1; do
  parted -s $disk mklabel gpt
  parted -s $disk mkpart primary 1MiB 100%
done

手指有点抖，我笑着自嘲：“别手滑了，不然就成灾难片。”阿豪回我：“放心，今晚最怕的不是你手抖，是客户上线时没 IOPS。”

05:00 - Ceph 部署

ceph-deploy new mon1 mon2 mon3
ceph-deploy install --release nautilus mon1 mon2 mon3 osd1 osd2 ...
ceph-deploy mon create-initial
ceph-deploy osd create --data /dev/nvme0n1 osd1

阿豪一边看日志一边说：“这一步最像买彩票。”我盯着屏幕心跳加快，直到看到 cluster created，才算松口气。

05:40 - 压测数据出炉

fio --name=randwrite --ioengine=libaio --rw=randwrite --bs=4k \
--numjobs=16 --iodepth=32 --size=20G --runtime=60 --group_reporting

结果：

我盯着数据笑了：“1.8M IOPS，兄弟，咱们救回来了。”阿豪伸手跟我击掌：“英雄诞生。”

四、踩坑瞬间：故障日志

06:10 - NVMe 队列堵塞

现象：dmesg 报 nvme timeout，心里凉了一半。

对话：

我：“不会吧？新盘就挂？”

阿豪：“冷静，查驱动。”

解决：升级内核到 3.10.0-1160.88.1.el7，加载最新 nvme_core 模块，问题解决。

06:40 - OSD CPU 占用爆表

现象：top 显示 OSD 进程 CPU 占用 200%+。

解决：调低 bluestore_cache_size 并绑核：

taskset -c 0-15 ceph-osd -i 0

心理：那一刻，我只想跪谢 NUMA 绑核这条“救命秘籍”。

07:20 - 25GbE 网络丢包

现象：心跳超时，OSD 被标记 down。

客户远程喊：“是不是硬件问题？要不要换网卡？”

我心里一急，但还是硬着头皮回：“先别慌，我们调交换机。”

解决：关闭交换机 ECN，启用服务器端 GSO，问题消失。

五、经验教训总结清单（Checklist）

在这次凌晨机房的 Ceph 部署中，我们踩过的坑、总结的优化要点如下，整理成 checklist，方便以后上线复用：

硬件与系统层面

 BIOS 调优：关闭 CPU C-State，启用 NUMA Awareness，避免 CPU 调度不均。

 NVMe SSD 选型：优先选 PM9A3 / P4510 等企业级 NVMe，单盘 IOPS ≥ 600K。

 网络带宽：高并发数据库必须 ≥ 25GbE，否则 Ceph OSD 吞吐会打满 10GbE。

 内核版本：CentOS 7.9 搭配 3.10.0-1160.88.1.el7，避免 NVMe 超时 Bug。

Ceph 配置与优化

 OSD 独立盘：每块 NVMe 单独作为 OSD，不做 RAID。

 Bluestore 调优：合理设置 bluestore_cache_size，避免 CPU 占用过高。

 日志/Journal 大小：osd_journal_size=10240，保证写入性能。

NUMA 绑核：通过 taskset 将 OSD 与 CPU 绑定，减少跨 NUMA 延迟。

 网络调优

 网卡参数优化：ethtool -G rx/tx=4096，关闭 gro/lro，提升小包处理效率。

 内核缓冲区：net.core.rmem_max / wmem_max 调到 128MB。

 交换机配置：关闭 ECN，避免 Ceph heartbeat 丢包。

运维与监控

 压测必跑：用 fio 模拟 4K 随机写，确认 IOPS 和延迟符合预期。

 日志实时跟踪：关键环节盯 dmesg、ceph -s，防止 OSD 异常。

 容错准备：随时准备备用节点或 NVMe，保证凌晨替换时不掉链子。

 团队分工：一人部署、一人监控、一人应急，避免忙乱。

✅ 最终成果：

数据库 I/O 延迟：从 0.9ms → 0.35ms

集群写入 IOPS：从 320K → 1.8M

系统高峰期稳定通过

这一套 checklist，不仅是对那一夜机房战斗的总结，更是未来任何一场分布式存储部署的“作战指南”

六、FAQ（常见问题解答）

1. 为什么选择 Ceph 而不是 ZFS / GlusterFS？

Ceph 优势：

天然分布式架构，具备强大的扩展性和自愈能力。

RADOS 后端支持对象存储、块存储、文件系统，灵活适配数据库和 VM。

社区活跃，生态成熟，和 Kubernetes、OpenStack 集成度高。

ZFS/GlusterFS 限制：

ZFS 更适合单机或有限节点的高性能存储，不适合大规模分布式。

GlusterFS 在小文件和高并发写入时性能瓶颈明显，不如 Ceph 稳定。

2. NVMe SSD 是否必须用企业级型号？

必须。企业级 NVMe（如 Samsung PM9A3、Intel P4510）有以下优势：

更高的写入耐久度（DWPD ≥ 1），适合数据库这种写入密集型场景。

更好的固件优化，避免消费级盘在高负载下掉速。

提供电容保护，避免掉电数据丢失。

消费级 NVMe 在测试环境可以用，但在生产数据库集群上一定会出问题。

3. 25GbE 网络是否足够？是否需要 100GbE？

对于中型数据库业务，25GbE 足够支撑单节点 NVMe 的 I/O 带宽。

如果集群节点扩展到 12 台以上，或者业务需要 PB 级吞吐，建议直接上 100GbE，减少未来扩容时的瓶颈。

实际项目里，我们常见的配置是 25GbE 接入 + 100GbE Spine-Leaf 核心交换架构。

4. Ceph 集群如何保证稳定性？

三副本策略：保证数据安全性。

监控告警：结合 Prometheus + Grafana，实时监控 OSD、PG 状态。

定期压测：上线后定期使用 fio 压测，防止性能劣化。

热备硬件：机房里必须准备备用 NVMe、网卡和交换机模块，随时替换。

5. Ceph Nautilus 还能继续用吗？要不要升级到 Octopus/Pacific？

Nautilus（14.2.x）目前依旧在部分企业使用，但社区更新已逐渐减少。

如果集群长期运行，建议规划升级到 Pacific (16.x) 或更新版本：

• 提升性能
• 优化 BlueStore
• 更好的仪表盘和监控

但升级前必须做好测试，避免线上数据库直接受影响。

七、尾声：夜尽天明

当最后一个错误消失，集群稳定运行，天窗透进来微弱的晨光。阿豪递给我一罐冰咖啡：“兄弟，今晚熬得值了。”

微信群里客户发来一句话：“谢谢，报表准时跑完。”那一刻，机房的轰鸣声忽然没那么刺耳，反而像是一种胜利的背景乐。

八、总结：运维的真实一面

这场凌晨的战斗，让我再次确认——分布式存储不是概念，而是硬件、驱动、网络与人力的较量。

技术结果：

• 数据库 I/O 延迟从 0.9ms 降到 0.35ms
• IOPS 从 320K 提升到 1.8M
• 集群具备横向扩展能力

运维感受：

• 机房冷风再冷，手心还是会冒汗。
• 键盘上的每一行配置，不是照抄文档，而是救命稻草。
• 客户的一句“谢谢”，能让一夜的疲惫瞬间化解。

这就是运维的日常。没人记得你在凌晨三点和机器死磕，但系统稳了、业务跑通了，你就赢了。