Ceph 生产环境搭建 | 第 1 天：架构概述与生产环境选型指南

第 1/20 天

引言

在云原生与大数据时代，分布式存储已成为基础设施的基石。Ceph 作为开源分布式存储系统的标杆，凭借其统一存储架构（块、文件、对象三合一）、无中心化设计和线性扩展能力，被广泛应用于 OpenStack、Kubernetes 及企业级生产环境。本系列将基于 Ceph Squid（v19）稳定版，在 Ubuntu 24.04 LTS 上从零搭建一套生产级 Ceph 集群，共 20 篇，覆盖架构选型、节点部署、存储池管理、监控运维及升级全流程。

本篇作为系列开篇，将系统讲解 Ceph 的核心架构设计、组件职责、数据分布原理，并提供生产环境硬件选型与版本规划指南，为后续部署奠定理论基石。

Ceph 核心架构概述

统一存储架构

Ceph 的核心设计理念是”一个集群，多种接口”。底层 RADOS（Reliable Autonomic Distributed Object Store）提供对象存储能力，上层通过不同的访问接口实现三种存储形态：

存储类型	接口组件	典型场景	协议
块存储	RBD (RADOS Block Device)	虚拟机磁盘、数据库卷	librbd / kernel module
对象存储	RGW (RADOS Gateway)	S3 兼容存储、备份归档	S3 / Swift REST API
文件存储	CephFS	共享文件系统、HPC	POSIX (FUSE / kernel)

核心组件拓扑

Ceph 集群由以下守护进程组成，各司其职，协同工作：

Monitor (MON)：维护集群拓扑地图（cluster map），提供仲裁与法定人数服务。生产环境至少部署 3 节点，保证仲裁可用。
Manager (MGR)：提供管理面板、监控指标和插件模块（如 balancer、devicehealth、dashboard）。至少部署 2 节点做主备高可用。
OSD (Object Storage Daemon)：实际存储数据的核心进程，每个磁盘对应一个 OSD。负责数据复制、恢复、回填，是集群性能与容量的决定性因素。
MDS (Metadata Server)：仅 CephFS 使用，管理文件系统元数据（inode、目录树），不影响块存储和对象存储。
RGW (RADOS Gateway)：对象存储网关，提供 S3/Swift 兼容 API，是 Ceph 对外暴露对象存储服务的入口。

CRUSH 数据分布算法

Ceph 不依赖中心化的元数据服务器来定位数据，而是使用 CRUSH（Controlled Replication Under Scalable Hashing）算法计算数据位置。客户端通过 librados 直接计算对象应存储的 OSD，实现 O(1) 时间复杂度的数据定位，消除了传统分布式存储中元数据服务器的性能瓶颈。

CRUSH Map 定义了集群的层级故障域拓扑，以下是一个典型的三层级结构：

💻 代码示例

root default {

row rack-1 {

row rack-1-row-1 {

cabinet rack-1-row-1-cab-1 {

host ceph-osd-01 { osd.0 osd.1 osd.2 }

host ceph-osd-02 { osd.3 osd.4 osd.5 }

}

这种层级结构使得 CRUSH 可以按机架（rack）、主机（host）等故障域分布副本，避免同一物理机架故障导致多副本同时丢失。生产环境中合理规划故障域是数据安全的基础。

数据写入流程

Ceph 的数据写入遵循”主副本写入，再异步分发”的策略，客户端直连 OSD，无中间代理层：

客户端通过 CRUSH 计算对象的主 OSD（primary）
客户端将数据直接写入主 OSD
主 OSD 将数据同步到副本 OSD
所有副本写入完成后，主 OSD 返回 ACK
客户端收到写入确认

这种”客户端直连 OSD”的设计消除了写瓶颈，使集群吞吐量随 OSD 数量线性增长。以三副本为例，一次写入的实际数据流动为：客户端 → Primary OSD → Replica OSD × 2，延迟主要取决于最慢的副本链路。

生产环境选型指南

硬件规格规划

生产环境的硬件选型直接决定 Ceph 集群的性能和可靠性。以下是各角色的推荐配置：

节点角色	CPU	内存	网卡	磁盘配置
MON (×3)	8 核	16GB	2×10GbE	1× SSD 100GB (系统盘)
MGR (×2)	8 核	16GB	2×10GbE	1× SSD 100GB
OSD (≥3)	8-16 核	每盘 2GB+	2×25GbE	NVMe/SSD 数据盘
RGW (×2+)	8 核	16GB	2×10GbE	SSD 200GB
MDS (×2)	8 核	16GB	2×10GbE	SSD 100GB

OSD 内存建议：BlueStore 的每个 OSD 至少 2GB 内存用于缓存（bluestore_cache_size）。使用 NVMe SSD 的 OSD 建议 4GB 以上缓存，以充分利用高速存储带宽。MON 节点虽然不存储实际数据，但其内存占用随集群规模增长，大集群建议 32GB+。

网络规划

生产环境必须分离集群网络（Cluster Network）和公共网络（Public Network），这是性能和安全的双重需求：

💻 代码示例

# 公共网络：客户端与 MON/OSD 通信

# 集群网络：OSD 之间数据复制与恢复（独立 VLAN）

# 示例配置

public_network: 10.10.1.0/24 # 客户端访问网段

cluster_network: 10.20.2.0/24 # OSD 复制与恢复（建议独立交换机）

# 在 ceph.conf 中设置

[global]

public_network = 10.10.1.0/24

cluster_network = 10.20.2.0/24

分离网络可避免数据恢复流量抢占客户端访问带宽，在大规模集群中尤为重要。当某个 OSD 故障触发数据恢复时，恢复流量可能达到数十 GB/s，若与公共网络共用带宽将严重影响客户端读写性能。

版本选择策略

Ceph Squid（v19）是当前最新稳定版本，推荐生产环境使用。其 BlueStore 性能优化、CephFS 增强和 cephadm 自动化管理能力相比前代显著提升：

💻 代码示例

# 查看 Ceph 版本信息

ceph –version

# 预期输出: ceph version 19.2.x (squid) …

# cephadm 拉取 Squid 镜像

docker pull quay.io/ceph/ceph:v19

# 检查 cephadm 可用版本

./cephadm version

版本选择应遵循”跟随稳定 LTS，不追最新 minor”的原则。每个 Ceph 大版本在发布后会持续提供安全补丁和 bugfix。Squid v19.2.x 系列是目前经过充分生产验证的稳定线。

环境准备实战

操作系统验证

部署 Ceph 前必须确认系统满足基线要求。Ubuntu 24.04 LTS 内置 6.8 内核，已包含 Ceph 所需的全部内核模块（rbd、ceph）：

💻 代码示例

# 确认 Ubuntu 24.04 LTS

cat /etc/os-release | grep PRETTY_NAME

# 预期: PRETTY_NAME="Ubuntu 24.04.1 LTS"

# 内核版本检查（建议 5.15+，24.04 默认 6.8）

uname -r

# 预期: 6.8.0-xx-generic

# 确认 systemd 已正常运行

systemctl is-system-running

# 预期: running

# 确认 LVM2 已安装（BlueStore 部署依赖 LVM）

lvm version

时间同步配置

Ceph 对时间一致性要求极为严格，MON 节点之间时钟偏差超过 0.05 秒会触发告警，偏差过大可能导致 MON 退出法定人数。Ubuntu 24.04 默认使用 chrony 作为 NTP 客户端：

💻 代码示例

# 安装并配置 chrony

apt update && apt install -y chrony

cat > /etc/chrony/chrony.conf << 'EOF'

server ntp.aliyun.com iburst

server ntp.tencent.com iburst

driftfile /var/lib/chrony/drift

makestep 1.0 3

rtcsync

allow 10.10.1.0/24

local stratum 10

EOF

systemctl enable –now chrony

chronyc sources -v

# 确认 ^* 标记表示已同步到 NTP 源

防火墙与端口规划

Ceph 各组件使用不同端口，需提前在防火墙放行。以下是生产环境的标准端口清单：

💻 代码示例

# Ceph 默认端口清单

# MON: 6789/tcp (v1 messenger) 3300/tcp (v2 messenger)

# MGR: 8443/tcp (dashboard HTTPS)

# OSD: 6800-7300/tcp (动态分配，每个 OSD 约 8 端口)

# RGW: 8080/tcp (默认 S3 端口)

ufw allow 6789/tcp

ufw allow 3300/tcp

ufw allow 6800:7300/tcp

ufw allow 8080/tcp

ufw allow 8443/tcp

ufw status numbered

依赖工具安装

Cephadm 使用容器化方式部署 Ceph 守护进程，需要安装容器运行时和 cephadm 工具链：

💻 代码示例

# 安装基础依赖

apt install -y lvm2 python3 chrony docker.io

# 下载并安装 cephadm

curl –silent –remote-name

https://download.ceph.com/rpm-19.2.0/ubuntu/noarch/cephadm

chmod +x cephadm

./cephadm add-repo –release squid

apt update

apt install -y cephadm ceph-common

# 验证安装

cephadm version

ceph –version

# 预期: ceph version 19.2.x (squid)

SSH 免密配置

cephadm 通过 SSH 管理集群中所有节点，需在 bootstrap 节点生成密钥并分发到各目标节点：

💻 代码示例

# 在 bootstrap 节点生成 ed25519 密钥

ssh-keygen -t ed25519 -N "" -f /root/.ssh/id_ed25519

# 分发公钥到各节点

for host in ceph-mon-01 ceph-mon-02 ceph-mon-03 ceph-osd-01; do

ssh-copy-id -i /root/.ssh/id_ed25519.pub root@$host

done

# 验证免密登录

ssh root@ceph-mon-01 "hostname && uptime"

生产环境注意事项

踩坑提示

MON 节点数量必须是奇数：3 或 5 个 MON 节点，确保法定人数（quorum）投票不产生脑裂。偶数 MON 在网络分区时可能同时形成两个法定人数组，导致数据不一致。
BlueStore 的 WAL/DB 分区规划：BlueStore 的 WAL（Write-Ahead Log）和 DB（RocksDB 元数据）建议放在独立的 NVMe SSD 上，对于 HDD OSD 尤为重要。共用 HDD 做 WAL 会导致随机写放大，性能下降数倍。
不要在系统盘上部署 OSD：虽然技术上可行，但生产环境应使用独立数据盘，便于故障隔离和磁盘热替换。系统盘故障会导致整个节点不可用。
容器运行时选择：Cephadm 默认使用 Docker 或 Podman 运行守护进程。Ubuntu 24.04 默认 Docker 兼容良好；若安全要求高可使用 Podman rootless 模式。

安全考量

Ceph 生产集群的安全配置不容忽视。以下为关键安全配置项的 JSON 格式速查：

💻 代码示例

{

"security_notes": {

"cephx": "默认启用，密钥位于 /etc/ceph/ceph.client.admin.keyring，务必离线备份",

"firewall": "Cluster Network 应限制为内部 VLAN，不暴露公网，防止数据窃取",

"dashboard": "MGR Dashboard 默认使用自签证书，生产环境应替换为正式 CA 签发证书",

"updates": "CVE 安全补丁通过 ceph orch upgrade 滚动更新，不中断服务",

"keyring_perms": "keyring 文件权限应为 600，仅 root 可读"

}

性能基线建议

部署前应了解各类存储介质的预期性能基线，用于后续容量与性能规划：

NVMe OSD：随机读写 4K IOPS 单盘可达 100K+，集群水平扩展后线性增长
SSD OSD：顺序读写吞吐约 500MB/s 每盘，适合温数据存储
HDD OSD：顺序读写约 150MB/s，适合冷数据和大容量归档
网络带宽：集群网络建议 25GbE+，大规模集群推荐 100GbE 以避免恢复瓶颈

常见问题

Q1: Ceph 与 GlusterFS、MinIO 相比有何优势？

A: Ceph 提供统一的块、对象、文件三种存储接口，无需部署多套系统。GlusterFS 仅支持文件存储，MinIO 仅支持对象存储。Ceph 的 CRUSH 算法实现真正的去中心化，无元数据服务器瓶颈，扩展性更强。Ceph 已有大规模 PB 级集群生产案例（如 CERN、Deutsche Telekom），稳定性和成熟度经过充分验证。

Q2: 生产环境最小集群规模是多少？

A: 最小生产环境为 3 节点超融合部署（每节点运行 MON + MGR + OSD），可满足基本的冗余要求。但推荐分离部署：3 MON + 2 MGR + N OSD（N≥3），达到更好的故障隔离。存储密集型场景可使用 3 节点每节点多 OSD 的方案，配合 CRUSH 的 host 故障域策略保证三副本落在不同主机。

Q3: Ceph Squid v19 相比 Reef v18 有哪些主要改进？

A: Squid 版本主要改进包括：BlueStore 性能优化（RocksDB 压缩策略改进减少写放大）、CephFS 快照管理增强、RGW 多站点同步性能提升、cephadm 设备生命周期管理自动化增强、新增安全签名验证模块等。建议新部署直接使用 Squid，已有集群可通过 ceph orch upgrade 滚动升级。