Ceph 生产环境搭建 | 第 2 天:Ubuntu 系统准备:内核调优与磁盘规划

第 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 的内存密集型操作有负面影响,建议关闭。

K8s Logo

二、部署实战: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

K8s Logo

三、配置参数详解

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 系统准备的全流程:

  1. 时钟同步:Chrony 配置确保 Monitor 节点时钟一致性
  2. 内核调优:网络栈缓冲区、内存管理、文件描述符、THP 关闭
  3. 磁盘规划:BlueStore 设备布局、LVM 管理、I/O 调度器配置
  4. 性能基线:用 fio 测量底层磁盘性能,建立调优基准
  5. 踩坑预防:分区残留、时钟漂移、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 生产环境升级维护与版本迭代策略
微信公众号二维码
© 版权声明
THE END
喜欢就支持一下吧
点赞0 分享
评论 抢沙发
头像 - 恒星
欢迎您留下宝贵的见解!
提交
头像 - 恒星

昵称

取消
昵称表情代码图片快捷回复

    暂无评论内容