第 2/20 天
在 Ceph 分布式存储的生产环境搭建中,操作系统的准备往往是最容易被忽视却最为关键的一环。上一篇我们完成了 Ceph 架构概述与生产环境选型,确定了基于 Ceph Squid(v19)和 Ubuntu 24.04 LTS 的技术路线。今天,我们深入到操作系统层面,聚焦 Ubuntu 系统的内核调优与磁盘规划——这是整个 Ceph 集群稳定运行的基石。
无论是 OSD 的 BlueStore 直接管理裸盘,还是 Monitor 对时钟同步的严苛要求,亦或是集群网络对内核网络栈参数的依赖,都离不开扎实的系统层配置。生产环境中 80% 的 Ceph 故障可以追溯到系统准备阶段的不规范操作。
一、架构与原理:系统层在 Ceph 中的角色
1.1 Ceph 组件对操作系统的依赖矩阵
Ceph 集群由多个组件构成,每个组件对操作系统资源的需求各不相同:
| Ceph 组件 | 主要资源需求 | 系统依赖项 | 调优重点 |
|---|---|---|---|
| MON(Monitor) | 内存、磁盘 I/O | NTP/Chrony 时钟同步 | 时间一致性、磁盘空间 |
| MGR(Manager) | 内存、CPU | Python3 运行环境 | 模块加载、内存 |
| OSD(存储节点) | 磁盘、网络、CPU | 裸盘访问、内核块层 | I/O 调度、网络栈 |
| RGW(对象网关) | 网络、CPU | HTTP/TLS 库 | 连接数、缓存 |
| MDS(元数据) | 内存、CPU | 文件系统接口 | 缓存大小 |
1.2 磁盘规划原理
Ceph 的 BlueStore 引擎直接管理裸块设备(raw block device),绕过了传统的文件系统层。这意味着:
- OSD 数据盘:必须是裸设备(raw device),不能有分区表或文件系统残留。BlueStore 直接对块设备进行读写,利用
RocksDB管理元数据,WAL(Write-Ahead Log)保障数据一致性。 - DB/WAL 设备:RocksDB 的元数据和 WAL 可以放置在独立的 NVMe SSD 上,大幅提升小文件和随机写性能。这是生产环境中最重要的性能优化手段之一。
- 系统盘与数据盘分离:OSD 进程崩溃或磁盘故障不应影响系统启动和监控可达性。
1.3 内核调优原理
Ceph 是一个对 I/O 延迟极其敏感的分布式系统。内核层面影响性能的关键因素包括:
- I/O 调度器:Ceph OSD 使用异步 I/O(
async),none/noop调度器最适合 SSD/NVMe,避免额外的重排序开销。 - 网络栈参数:Ceph 集群网络流量巨大(多副本写入放大),需要调大 TCP 缓冲区、开启
tcp_tw_reuse、调整somaxconn。 - 内存管理:避免 swap 导致的延迟抖动,合理设置
vm.swappiness。 - 文件描述符:每个 OSD 会打开大量文件句柄,需提升
ulimit -n。 - 透明大页(THP):对 Ceph 的内存密集型操作有负面影响,建议关闭。

二、部署实战:Ubuntu 系统准备完整流程
2.1 环境准备
以下操作在所有 Ceph 节点上执行。假设环境为 3 台物理服务器,Ubuntu 24.04 LTS,每台配置双路 CPU、128GB 内存、1 块系统盘 + 4 块数据盘(HDD)+ 1 块 NVMe(用于 DB/WAL)。
# 更新系统到最新补丁
sudo apt update && sudo apt upgrade -y
# 安装基础依赖工具
sudo apt install -y lvm2 chrony cephadm ceph-common
python3-pip curl wget parted gdisk smartmontools
nvme-cli fio hdparm
# 验证 Ubuntu 版本
lsb_release -a
# 预期输出: Description: Ubuntu 24.04.x LTS
# 验证内核版本
uname -r
# 预期输出: 6.8.x-xx-generic (Ubuntu 24.04 默认内核)
2.2 时间同步配置(Monitor 生命线)
Ceph Monitor 使用 Paxos 协议达成一致性,要求节点间时钟偏差不超过 0.05 秒,否则会导致 Monitor 投票异常甚至无法形成法定人数(quorum)。
# 停用默认的 systemd-timesyncd
sudo systemctl disable –now systemd-timesyncd
# 配置 Chrony 使用内网 NTP 服务器
sudo tee /etc/chrony/chrony.conf > /dev/null << 'EOF'
server ntp.aliyun.com iburst
server cn.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
allow 10.0.0.0/8
local stratum 10
EOF
# 启动并设置开机自启
sudo systemctl enable –now chrony
# 验证时间同步状态
chronyc sources -v
chronyc tracking
# 关键指标: System time : 0.0000xxxx seconds
2.3 内核参数调优
以下配置针对 Ceph 生产环境优化,需在所有节点上应用:
# 创建 Ceph 内核调优配置文件
sudo tee /etc/sysctl.d/99-ceph.conf > /dev/null << 'EOF'
# — 网络栈优化 —
# 增大 TCP 缓冲区(Ceph 集群网络流量大)
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 67392 16777216
# 连接复用与 backlog
net.ipv4.tcp_tw_reuse = 1
net.core.somaxconn = 16384
net.ipv4.tcp_max_syn_backlog = 8192
# — 内存管理 —
# 极低 swap 倾向(Ceph 不应使用 swap)
vm.swappiness = 1
vm.min_free_kbytes = 1048576
# — 文件系统 —
fs.file-max = 2097152
fs.aio-max-nr = 1048576
EOF
# 应用内核参数
sudo sysctl –system
# 配置文件描述符限制
sudo tee /etc/security/limits.d/99-ceph.conf > /dev/null << 'EOF'
* soft nofile 1048576
* hard nofile 1048576
root soft nofile 1048576
root hard nofile 1048576
EOF
2.4 关闭透明大页与性能干扰
# 立即关闭透明大页(THP)
sudo bash -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled'
sudo bash -c 'echo never > /sys/kernel/mm/transparent_hugepage/defrag'
# 持久化配置(systemd service)
sudo tee /etc/systemd/system/disable-thp.service > /dev/null << 'EOF'
[Unit]
Description=Disable Transparent Huge Pages
After=sysinit.target local-fs.target
[Service]
Type=oneshot
ExecStart=/bin/bash -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag'
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable –now disable-thp
# 验证 THP 状态
cat /sys/kernel/mm/transparent_hugepage/enabled
# 预期输出: always madvise [never]
2.5 磁盘规划与 BlueStore 设备准备
这是生产环境最关键的步骤之一。以下脚本演示如何对 OSD 数据盘和 DB/WAL 盘进行规范准备:
# — 第一步:识别磁盘 —
# 查看所有块设备及路径
sudo lsblk -o NAME,SIZE,TYPE,MODEL,SERIAL,TRAN
# 查看 NVMe 设备详情
sudo nvme list
# 查看磁盘健康状态
sudo smartctl -a /dev/sdb | grep -E "SMART|Reallocated|Temperature"
# — 第二步:清除旧分区和文件系统签名 —
# 清除所有数据盘的分区表(危险!确认设备名!)
for dev in /dev/sdb /dev/sdc /dev/sdd /dev/sde; do
sudo sgdisk –zap-all "$dev"
sudo dd if=/dev/zero of="$dev" bs=1M count=10
sudo partprobe "$dev"
done
# 清除 NVMe 上的旧数据
sudo sgdisk –zap-all /dev/nvme0n1
sudo blkdiscard /dev/nvme0n1
# — 第三步:创建 LVM 物理卷和卷组 —
# OSD 数据盘各自创建 PV
sudo pvcreate /dev/sdb /dev/sdc /dev/sdd /dev/sde
# NVMe 创建独立 VG 用于 DB/WAL(可选,按 OSD 切分)
sudo pvcreate /dev/nvme0n1
sudo vgcreate ceph-db-wal /dev/nvme0n1
2.6 OSD 部署预检与磁盘 I/O 调度器配置
# 查看当前 I/O 调度器
for dev in sdb sdc sdd sde nvme0n1; do
echo "$dev: $(cat /sys/block/$dev/queue/scheduler)"
done
# 设置 NVMe/SSD 使用 none 调度器(BlueStore 自管理 I/O)
# 持久化规则
sudo tee /etc/udev/rules.d/60-ceph-io-scheduler.rules > /dev/null << 'EOF'
# NVMe SSD: none (direct dispatch)
ACTION=="add|change", KERNEL=="nvme[0-9]+n[0-9]+", ATTR{queue/scheduler}="none"
# SATA/SAS SSD: none
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"
# HDD: mq-deadline (减少 starvation)
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"
EOF
# 应用 udev 规则
sudo udevadm control –reload-rules
sudo udevadm trigger
# 调整块设备 read-ahead(HDD 适当增大,SSD 可关闭)
sudo blockdev –setra 0 /dev/nvme0n1
sudo blockdev –setra 16384 /dev/sdb
# 配置 systemd 挂载选项:禁用 Ceph 数据盘的 atime
# (BlueStore 使用裸盘,此项仅适用于系统盘文件系统挂载)
sudo tee -a /etc/fstab > /dev/null << 'EOF'
# 示例:系统盘挂载加 noatime
# UUID=xxx / ext4 defaults,noatime,nodiratime 0 1
EOF
2.7 磁盘性能基线测试
部署 Ceph 前,务必测量底层磁盘的真实性能,作为后续 OSD 性能调优的基准:
# HDD 随机写 4K 性能测试(模拟 Ceph 小对象写)
sudo fio –name=ceph-hdd-test
–filename=/dev/sdb –ioengine=libaio
–direct=1 –rw=randwrite –bs=4k
–numjobs=4 –iodepth=32 –runtime=60 –time_based
–group_reporting –offset=0 –size=10G
# NVMe 随机写 4K 性能测试(评估 DB/WAL 瓶颈)
sudo fio –name=ceph-nvme-test
–filename=/dev/nvme0n1 –ioengine=libaio
–direct=1 –rw=randwrite –bs=4k
–numjobs=8 –iodepth=64 –runtime=60 –time_based
–group_reporting
# 记录 IOPS 和延迟数据,后续与 Ceph 集群层性能对比
# 经验值参考:
# HDD 4K randwrite: 100-200 IOPS, 延迟 5-10ms
# SATA SSD 4K randwrite: 10000-80000 IOPS
# NVMe 4K randwrite: 100000-500000 IOPS, 延迟 <1ms

三、配置参数详解
3.1 关键内核参数
| 参数 | 推荐值 | 说明 |
|---|---|---|
net.core.rmem_max |
16777216 | TCP 接收缓冲区上限,Ceph 客户端流量大时需增大 |
net.core.wmem_max |
16777216 | TCP 发送缓冲区上限 |
vm.swappiness |
1 | 几乎禁用 swap,避免 Ceph 进程被换出导致延迟尖刺 |
vm.min_free_kbytes |
1048576 | 预留 1GB 空闲内存,避免内存不足时 OOM |
fs.file-max |
2097152 | 系统级文件描述符上限,Ceph OSD 打开大量句柄 |
net.core.somaxconn |
16384 | socket listen backlog,防止连接积满被丢弃 |
3.2 BlueStore 磁盘布局
BlueStore 的标准生产环境磁盘布局如下:
| 设备角色 | 设备类型 | 大小建议 | 用途 |
|---|---|---|---|
| 系统盘 | SSD | 120GB+ | OS + Ceph 容器镜像 |
| OSD 数据盘 | HDD/SSD | 全盘容量 | 对象数据存储(main block) |
| DB 设备 | NVMe SSD | 4GB × OSD 数 | RocksDB 元数据(LSM-tree) |
| WAL 设备 | NVMe SSD | 2GB × OSD 数 | Write-Ahead Log |
关键比例:DB/WAL 的大小取决于 OSD 数据盘的容量。经验值是 DB 大小 = OSD 容量的 1%~4%。对于 4TB HDD,DB 建议 40-160GB。
四、生产环境注意事项与踩坑提示
4.1 踩坑提示
踩坑一:磁盘残留分区导致 OSD 创建失败
在生产环境中,复用旧磁盘是常态。sgdisk --zap-all 之后必须执行 dd if=/dev/zero bs=1M count=10 清除 GPT 备份头,否则 ceph-volume 会报错 Device is already partitioned。推荐使用 ceph-volume lvm zap --destroy 进行彻底清理。
踩坑二:时钟漂移导致 Monitor 无法加入集群
Chrony 启动后需等待足够时间让偏差收敛(通常 2-5 分钟)。如果 Monitor 节点时钟偏差超过 50ms,Monitor 会拒绝加入 quorum 并在日志中报 clock skew 错误。建议监控 chronyc tracking 中的 System time 值。
踩坑三:THP 未关闭导致 OSD 内存碎片和延迟抖动
Ubuntu 24.04 默认开启 THP,在 Ceph 高负载下会导致内存碎片化加剧,OSD 延迟出现周期性尖峰。务必确认 transparent_hugepage/enabled 为 never。
踩坑四:I/O 调度器配置不生效
udev 规则配置后需要 udevadm trigger 确认。NVMe 设备必须使用 none 调度器,因为 BlueStore 使用异步 I/O 直接管理请求队列,额外的调度逻辑反而增加开销。
踩坑五:fsync 性能未验证
Ceph 的数据一致性依赖 fsync 确保数据落盘。如果磁盘的 fsync 延迟过高(某些廉价 SSD 超过 10ms),会导致 OSD 性能严重下降。必须用 fio 的 --sync=1 模式测试 fsync 性能。
4.2 安全考量
- SSH 免密登录:cephadm 部署时需要从 bootstrap 节点 SSH 到其他节点,建议使用非 root 用户 + sudo 方式,密钥单独管理。
- 防火墙规则:Ceph 公共网络(public network)端口 6789(MON)、6800-7300(OSD)需在集群网络层面隔离。
- 磁盘加密:对于合规要求场景,可使用 LUKS 加密 OSD 数据盘,但需评估性能损耗(约 5-10%)。
五、常见问题
Q1:OSD 数据盘必须用 LVM 吗?能不能直接用裸盘?
A:Ceph Squid(v19)中,ceph-volume 默认使用 LVM 方式管理 OSD。虽然 BlueStore 技术上支持直接使用裸块设备,但 LVM 层提供了更灵活的设备管理和 DB/WAL 分区能力。生产环境强烈建议使用 LVM,它不影响性能,但大幅简化运维。cephadm 也要求使用 LVM 方式进行设备发现。
Q2:DB 和 WAL 是否必须分离到独立 NVMe?不分离会有什么影响?
A:不分离时,DB 和 WAL 默认存储在 OSD 数据盘上(称为 “colocated” 模式)。对于 HDD 集群,这意味着 RocksDB 的随机写操作直接落在 HDD 上,4K 随机写性能会从理论上限的 100 IOPS 进一步下降。分离到 NVMe 后,小文件写性能可提升 5-20 倍。生产环境中 HDD 集群强烈建议分离 DB/WAL;全闪存集群可不分离。
Q3:内核版本有硬性要求吗?Ubuntu 24.04 默认的 6.8 内核够用吗?
A:Ceph Squid v19 要求内核版本 >= 5.4。Ubuntu 24.04 LTS 默认的 6.8 内核完全满足要求,且包含了对 io_uring、多队列块层(blk-mq)等特性的完善支持。不建议升级到非 LTS 内核,生产环境应以稳定性为第一优先。
六、总结
本篇详细讲解了 Ceph 生产环境搭建中 Ubuntu 24.04 系统准备的全流程:
- 时钟同步:Chrony 配置确保 Monitor 节点时钟一致性
- 内核调优:网络栈缓冲区、内存管理、文件描述符、THP 关闭
- 磁盘规划:BlueStore 设备布局、LVM 管理、I/O 调度器配置
- 性能基线:用 fio 测量底层磁盘性能,建立调优基准
- 踩坑预防:分区残留、时钟漂移、THP、I/O 调度器、fsync 性能
系统层准备到位,后续的 cephadm 部署和 OSD 创建才能顺畅无阻。这些操作需要在一开始就做对——Ceph 集群部署后再回头修改系统参数的成本极高,甚至需要逐个 OSD 擦除重建。
七、下期预告
第 3 天:Cephadm 部署工具详解与集群引导初始化——我们将正式开始使用 cephadm 工具进行 Ceph 集群的 bootstrap 引导,部署第一个 Monitor 节点,并理解容器化 Ceph 的管理模型。
八、系列目录
- 第 1 天:架构概述与生产环境选型指南 — 已发布 ✅
- 第 2 天:Ubuntu 系统准备:内核调优与磁盘规划 — 本文 📌
- 第 3 天:Cephadm 部署工具详解与集群引导初始化 — 即将发布
- 第 4 天:Monitor 节点部署与高可用配置
- 第 5 天:Manager 节点部署与模块启用
- 第 6 天:OSD 存储节点部署:BlueStore 配置与磁盘管理
- 第 7 天:CRUSH Map 架构解析与故障域规划
- 第 8 天:存储池(Pool)创建与 PG 数量规划
- 第 9 天:副本与纠删码存储池策略对比实战
- 第 10 天:Ceph 块存储 RBD 配置与生产实践
- 第 11 天:Ceph 对象存储 RGW 网关部署与 S3 兼容
- 第 12 天:CephFS 分布式文件系统部署与挂载
- 第 13 天:Ceph 网络架构:集群网络与公共网络分离
- 第 14 天:Ceph 认证体系 cephx 与用户权限管理
- 第 15 天:Ceph 集群监控:Prometheus + Grafana + 内置仪表盘
- 第 16 天:Ceph 性能调优:OSD 参数与缓存分层
- 第 17 天:Ceph 集群扩容实战:OSD 动态添加与 CRUSH 重平衡
- 第 18 天:Ceph 高可用与容灾设计:多副本、跨机房与异地灾备
- 第 19 天:Ceph 故障排查与数据恢复实战
- 第 20 天:Ceph 生产环境升级维护与版本迭代策略

















暂无评论内容