1. 项目概述为什么今天还要亲手搭一套 Ceph不是云盘更不是 NASCeph 分布式存储安装及简单使用——这标题看着像十年前的老派运维笔记但恰恰是现在最值得沉下心来实操的一课。我带过不少刚转行的运维新人也帮某高校实验室重构过三套边缘计算平台的数据底座发现一个反直觉的事实越是在对象存储服务唾手可得的今天越需要有人真正理解 Ceph 的底层脉络。它不是替代品而是“数据主权”的基础设施锚点你清楚每一块磁盘在哪个节点、数据副本如何跨机架调度、PG 如何分裂而不抖动、OSD 故障后恢复时 IO 怎么被限流……这些细节公有云控制台不会告诉你NAS 管理界面更不会暴露。Ceph 分布式存储安装及简单使用本质是一次对“数据如何真正可靠地躺在硬件上”的溯源实践。它适合三类人正在搭建私有云或混合云的数据平台工程师需要长期归档科研数据、拒绝被厂商锁定的实验室技术负责人以及想跳出“只会调 API”怪圈、真正吃透分布式系统原理的开发者。这不是一个“装完就扔”的玩具而是一把能打开存储底层逻辑的钥匙——哪怕你最终用的是其他方案亲手走一遍 Ceph 的部署链路也会让你对一致性哈希、CRUSH 算法、RADOS 层抽象的理解比读十篇论文都扎实。2. 整体设计与思路拆解为什么选 LuminousCentOS 7.9 而非最新版2.1 版本选择不是跟风而是权衡稳定与可维护性很多人一上来就冲最新版 Ceph如 Quincy 或 Reef结果卡在 Python 3.11 兼容性、systemd 依赖冲突、或者某个已废弃的 ceph-deploy 工具报错上。我试过四套环境从 Nautilus 到 Quincy最终在生产级模拟环境中锁定了Ceph Luminous12.2.13 CentOS 7.9这个组合。原因很实在Luminous 是第一个将 mgr 模块正式纳入核心、并稳定支持 dashboard 的版本同时彻底弃用了已暴露出严重扩展瓶颈的 ceph-deploy转向更可控的 ceph-ansible 和原生命令行部署。CentOS 7.9 则提供了足够长的生命周期支持EOL 延至 2024 年 6 月内核 3.10.0-1160 系列对 XFS 文件系统和 bluestore 后端的兼容性经过了海量集群验证。更重要的是Luminous 的文档最完整社区问答最密集——当你在ceph osd tree输出里看到某个 OSD 处于down状态却查不到日志时Stack Overflow 上大概率已有某位同行贴出journalctl -u ceph-osdX的具体排查路径。这不是保守而是把有限的调试精力聚焦在理解 Ceph 本身而不是和发行版包管理器死磕。2.2 架构设计三节点最小可行集群的物理与逻辑分层我们不搞单机伪分布那只是 demo不是实践也不一上来就堆二十台服务器。一个真正能体现 Ceph 核心价值的最小集群必须满足三个硬性条件故障域隔离、数据多副本、服务角色分离。因此我采用三台物理机或 KVM 虚拟机但必须独占 CPU 和磁盘构建基础单元Node1mon0 mgr0 osd0承担 Monitor仲裁、Managerdashboard 和指标采集和首个 OSD对象存储守护进程角色Node2mon1 osd1第二个 Monitor 和第二个 OSD确保 quorum 不因单点失效而崩溃Node3mon2 osd2第三个 Monitor 和第三个 OSD完成法定人数quorum2和三副本基础。这里的关键设计意图是Monitor 必须奇数个且跨节点部署这是 Paxos 共识算法的硬约束而 OSD 必须每个节点至少一个才能让 CRUSH map 实现真正的故障域failure domain划分——当 Node2 整机宕机数据仍能从 Node1 和 Node3 的 OSD 中读取且写入操作会自动降级为两副本degraded write而非直接失败。很多初学者把所有角色塞进一台机器结果ceph -s显示 HEALTH_WARN却找不到根因问题就出在架构违背了 Ceph 的基本假设。2.3 存储后端抉择Bluestore 是唯一选项别碰 FilestoreCeph 支持两种 OSD 后端古老的 Filestore基于 ext4/XFS LevelDB和现代的 Bluestore直接管理裸设备内置 RocksDB。2024 年还在用 Filestore就像在 SSD 上装 Windows XP。Bluestore 的优势不是纸面参数而是实操中能规避的坑无文件系统开销Filestore 要求先格式化磁盘为 XFS再挂载OSD 日志还得单独配一块 SSD。Bluestore 直接ceph-volume lvm create --data /dev/sdb一步到位省去 mount point 权限、inode 耗尽、日志盘 IOPS 瓶颈等十多个潜在故障点元数据强一致性Bluestore 将对象元数据xattr和数据块统一存于同一块设备通过 WALWrite-Ahead Log保证原子性。Filestore 的元数据存在 LevelDB数据在 XFS崩溃后极易出现“对象存在但元数据丢失”的静默损坏压缩与加密原生支持bluestore compression algorithmzstd一行配置即可启用而 Filestore 需要整个文件系统层做透明压缩效果差且不可控。我曾在一个归档项目中对比过同样 10TB 视频素材Bluestore 开启 zstd-3 压缩后实际占用 7.2TB而 Filestore 即使挂载时加-o compresslzo利用率仅提升 8%。这不是理论差异是每天省下的电费和扩容成本。3. 核心细节解析与实操要点从零开始的每一步都在对抗“默认陷阱”3.1 环境预检比安装更重要的是让系统准备好迎接 CephCeph 对底层环境极其敏感跳过预检等于埋雷。以下检查项必须逐条执行不能靠“应该没问题”蒙混时间同步chronyd必须启用且指向同一 NTP 源。执行timedatectl status确认System clock synchronized: yes且NTP service: active。我见过太多集群ceph health报clock skew detected结果发现是 Node3 的 chronyd 服务没开时间漂移超 0.5 秒直接导致 OSD 间心跳超时被踢出集群主机名与解析hostname -s输出必须是短名如node1且/etc/hosts中必须有192.168.10.11 node1这样的静态映射。DNS 解析不稳定会导致 Monitor 间无法建立 peering 连接错误日志里满屏connect refusedSELinux 与防火墙setenforce 0临时关闭 SELinux生产环境需配策略但初学务必先关firewall-cmd --permanent --add-port{6789,6800-7300}/tcp开放 Ceph 端口Monitor 6789OSD 6800 起然后firewall-cmd --reload。别信“云服务器默认关防火墙”很多国产云厂商的 CentOS 镜像默认开着 firewalld内核模块加载modprobe rbd和modprobe nbd必须成功。lsmod | grep -E (rbd|nbd)应有输出。缺失会导致后续 RBD 块设备无法映射rbd map命令直接报错Operation not supported。提示把这些检查写成precheck.sh脚本三台节点循环执行。我放在 GitHub Gist 上的模板里还集成了df -h | grep -E (sdb|sdc)磁盘空闲空间校验——Ceph 初始化时若磁盘不足 5GBceph-volume会静默失败只在 journal 日志里留一行No space left on device极难定位。3.2 Monitor 部署不是ceph-deploy mon create-initial而是手动初始化Luminous 废弃了 ceph-deploy官方推荐cephadm但它依赖容器运行时对新手反而增加复杂度。我们采用最透明的原生命令方式全程可控在 Node1 创建 monitor mapmkdir -p /etc/ceph cd /etc/ceph ceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon allow *这行命令生成ceph.mon.keyring其中--cap mon allow *是关键——它赋予 Monitor 全权限因为 Monitor 需要读写自己的 map、协调 OSD peering、处理 client 认证请求。少写一个*后续ceph-mon --mkfs会因权限不足失败。初始化 Monitor 数据目录mkdir -p /var/lib/ceph/mon/ceph-node1 ceph-mon --mkfs -i node1 --monmap /etc/ceph/monmap --keyring /etc/ceph/ceph.mon.keyring注意-i node1必须与hostname -s输出一致否则启动后ceph -s看不到该 Monitor。--monmap是 Monitor 地图此时还是单点后续再加入其他节点。启动 Monitor 服务systemctl enable ceph-monnode1 systemctl start ceph-monnode1检查状态systemctl status ceph-monnode1应显示active (running)。若失败立刻看journalctl -u ceph-monnode1 -n 5090% 的问题是/var/lib/ceph/mon/ceph-node1目录权限不对必须是ceph:ceph用户组。注意Monitor 启动后会自动生成/var/lib/ceph/mon/ceph-node1/keyring这是它自己的认证密钥。不要手动修改或覆盖否则集群会“失联”。3.3 OSD 部署ceph-volume的 LVM 模式是唯一安全路径Ceph 官方文档提到了ceph-volume lvm、ceph-volume raw、ceph-disk三种方式但raw模式要求磁盘完全裸露无分区表ceph-disk已废弃。ceph-volume lvm是唯一兼顾安全与灵活性的选择——它用 LVM 逻辑卷封装物理磁盘既避免直接操作/dev/sdb的风险又保留了 Bluestore 直接管理设备的能力。以 Node1 上的/dev/sdb磁盘为例完整流程如下清理磁盘残留重要虚拟机克隆或重装系统后必做wipefs -a /dev/sdb # 清除所有文件系统签名 pvremove /dev/sdb # 清除 LVM PV 签名创建 LVM 物理卷和逻辑卷pvcreate /dev/sdb vgcreate ceph-vol-group /dev/sdb lvcreate -l 100%FREE -n osd-block ceph-vol-group这里lvcreate -l 100%FREE是精髓它让逻辑卷占满整块磁盘不留空隙。Ceph 的 Bluestore 需要连续大块空间存放对象数据若 LV 只分 50%剩余空间会被视为“不可用”OSD 初始化直接失败。使用ceph-volume初始化 OSDceph-volume lvm create --data /dev/ceph-vol-group/osd-block执行后它会自动格式化逻辑卷为 Bluestore创建/var/lib/ceph/osd/ceph-0目录0 是 OSD ID生成keyring并注入集群启动ceph-osd0服务。检查ceph osd tree应看到osd.0在host node1下状态为up。若显示down八成是ceph-volume没权限读写/dev/ceph-vol-group/osd-block执行chown ceph:ceph /dev/ceph-vol-group/osd-block即可。4. 实操过程与核心环节实现从集群健康到创建第一个 RBD 镜像4.1 集群初始化与健康检查读懂ceph -s的每一行含义当三台节点的 Monitor 和 OSD 全部启动后执行ceph -s你会看到类似这样的输出cluster: id: a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 health: HEALTH_WARN Reduced data availability: 1 pg inactive Degraded data redundancy: 132/441 objects degraded services: mon: 3 daemons, quorum node1,node2,node3 mgr: no daemons active osd: 3 osds: 3 up, 3 in data: pools: 0 pools, 0 pgs objects: 0 objects, 0 B usage: 0 B used, 0 B / 0 B avail pgs: 0.000% pgs not active别慌HEALTH_WARN是正常起步状态。关键信息在services和data段mon: 3 daemons, quorum node1,node2,node3表示三个 Monitor 已形成法定人数这是集群的“大脑”在线osd: 3 osds: 3 up, 3 in表示三个 OSD 进程运行中up且全部被集群接纳in这是数据“四肢”健全pools: 0 pools是重点——Ceph 不像传统存储它没有默认存储池。所有数据必须显式创建 pool 才能写入。HEALTH_WARN中的1 pg inactive正是因为没有 poolPGPlacement Group无法分配。解决方法创建一个名为rbdpool的存储池设置副本数为 3匹配我们的三节点ceph osd pool create rbdpool 64 64 replicated ceph osd pool set rbdpool size 3这里64 64是 PG 和 PGPPlacement Group for Placement的数量。为什么是 64计算公式是PG 数 ≈ (OSD 数 × 100) / 副本数。我们有 3 个 OSD副本数 3所以3×100÷3100但 64 是 Luminous 推荐的最小值既能保证负载均衡又避免 PG 过多导致内存压力每个 PG 占约 1MB 内存。执行后ceph -s的HEALTH_WARN会消失pools变为1 poolspgs状态变为100.000% pgs activeclean——这才是真正的健康起点。4.2 启用 Manager 模块与 Dashboard让集群“看得见”ceph -s只给文本而ceph dashboard提供可视化界面。但默认它是禁用的且需要额外密钥启用 mgr 模块ceph mgr module enable dashboard生成自签名证书生产环境请换为正规证书ceph dashboard create-self-signed-cert创建管理员用户ceph dashboard set-login-credentials admin admin123开放 dashboard 端口默认 8443firewall-cmd --permanent --add-port8443/tcp firewall-cmd --reload重启 mgr 服务systemctl restart ceph-mgrnode1现在访问https://node1-ip:8443用admin/admin123登录就能看到实时 OSD 利用率、PG 分布热力图、IOPS 曲线。这个界面的价值远超“好看”——当你发现某个 OSD 的op_w_latency_ms突然飙升到 200ms而其他 OSD 是 5ms立刻就知道该磁盘可能要坏了比等ceph -s报HEALTH_ERR提前数小时。4.3 创建并挂载 RBD 块设备从集群到本地文件系统的最后一公里RBDRADOS Block Device是 Ceph 最常用的功能它把分布式对象存储虚拟成一块本地磁盘。我们以在 Node1 上创建一个 10GB 的镜像为例创建镜像rbd create rbdpool/image1 --size 10G --image-feature layering--image-feature layering是关键参数它启用克隆clone功能。没有它后续rbd clone会报错Operation not supported。查看镜像rbd ls rbdpool rbd info rbdpool/image1rbd info会显示stripe_unit条带大小默认 4MB、stripe_count条带数量默认 1这些决定了并发 IO 性能。映射为本地块设备rbd map rbdpool/image1执行后ls /dev/rbd*会多出/dev/rbd0。注意rbd map默认映射到/dev/rbd0如果已有rbd0它会尝试rbd1但最好显式指定rbd map rbdpool/image1 --id admin。格式化并挂载mkfs.xfs /dev/rbd0 mkdir -p /mnt/ceph-rbd mount /dev/rbd0 /mnt/ceph-rbd现在df -h就能看到/mnt/ceph-rbd了。往里面dd if/dev/zero of/mnt/ceph-rbd/test bs1M count100写入 100MB 数据ceph -w会实时显示pgs: ... activeclean证明数据已均匀分散到三个 OSD 上。实操心得RBD 映射后若执行umount /mnt/ceph-rbd再rbd unmap /dev/rbd0一定要按顺序先 umount 再 unmap。反过来会导致内核 panic必须重启。我踩过两次第三次就写了个safe-unmap.sh脚本自动检查挂载状态。5. 常见问题与排查技巧实录那些文档里不会写的“血泪经验”5.1 OSD 启动失败的三大高频原因与速查表现象日志关键词根本原因速查命令解决方案ceph-osd0.service: main process exited, codeexited, status1/FAILUREfailed to open block device/dev/ceph-vol-group/osd-block权限非ceph:cephls -l /dev/ceph-vol-group/chown ceph:ceph /dev/ceph-vol-group/osd-blockceph-osd0.service: Failed with result core-dumpsegmentation faultBluestore 初始化时磁盘有坏道或 SMART 错误smartctl -a /dev/sdb更换磁盘wipefs -a /dev/sdb后重试ceph-osd0.service: start request repeated too quicklystart request repeated/var/lib/ceph/osd/ceph-0目录残留旧数据ls /var/lib/ceph/osd/ceph-0rm -rf /var/lib/ceph/osd/ceph-0 ceph-volume lvm activate --all最隐蔽的是第三种当你重复执行ceph-volume lvm create它不会覆盖旧数据而是试图在残留的whoami文件上继续初始化导致 core dump。解决方案不是删整个目录而是用ceph-volume lvm activate --all让它重新识别已存在的逻辑卷。5.2 “HEALTH_WARN: too few PGs per OSD” 警告的深度解读当集群扩容到 6 个 OSD 后ceph -s突然报这个警告。表面看是 PG 数太少但直接ceph osd pool set rbdpool pg_num 128会触发 PG 分裂split期间集群性能下降 30%。正确做法是分两步先设pgp_numPlacement Group for Placement等于目标pg_numceph osd pool set rbdpool pgp_num 128PGP 控制数据重分布设为 128 后CRUSH map 会立即开始迁移但不改变 PG 数量IO 影响小等ceph -s显示pgs: ... activeclean后再设pg_numceph osd pool set rbdpool pg_num 128此时 PG 分裂才真正开始但因 PGP 已就绪分裂过程更平滑。这个“先 PGP 后 PG”的顺序是 Ceph 社区资深运维反复验证的最佳实践官方文档却一笔带过。5.3 Dashboard 无法访问的五个排查层次Dashboard 白屏或连接拒绝按此顺序逐层检查网络层telnet node1-ip 8443是否通不通则检查firewall-cmd --list-ports和iptables -L服务层systemctl status ceph-mgrnode1是否 active若 failed看journalctl -u ceph-mgrnode1 -n 100模块层ceph mgr module ls \| jq .enabled_modules是否包含dashboard若无ceph mgr module enable dashboard证书层ceph dashboard get-ssl-cert是否返回证书内容若为空ceph dashboard create-self-signed-cert用户层ceph dashboard get-login-credentials是否返回用户名密码若无ceph dashboard set-login-credentials user pass。我曾在一个项目中卡在第 4 步get-ssl-cert返回空但create-self-signed-cert执行无报错。最后发现是/var/lib/ceph/mgr/ceph-node1目录权限为root:rootmgr 进程无法写入证书。chown ceph:ceph /var/lib/ceph/mgr/ceph-node1后秒解。5.4 RBD 克隆失败“Image has no parent” 的真相执行rbd clone rbdpool/image1 rbdpool/clone1报错。原因只有一个image1创建时没加--image-feature layering。但修复不能简单重建镜像——已有数据会丢失。正确方案是rbd feature enable rbdpool/image1 layering rbd snap create rbdpool/image1snap1 rbd clone rbdpool/image1snap1 rbdpool/clone1即先启用 layering 特性再打快照最后克隆快照。rbd feature enable是在线操作不影响业务。这个技巧救过我两个客户的生产库迁移。6. 进阶思考与个人体会Ceph 不是终点而是理解现代存储的起点亲手完成 Ceph 分布式存储安装及简单使用后我最大的体会是它教会我的不是“怎么配一个存储”而是“数据在大规模系统中如何被信任”。当ceph osd tree里看到三个节点整齐排列ceph df显示容量均匀分布rbd map后dd写入的数据能在任意节点上rbd info查到——这种确定性是任何黑盒服务都无法替代的掌控感。Ceph 的价值从来不在它多快而在它多“诚实”每一个警告WARN、每一个降级degraded、每一个 PG 的 active/clean 状态都是对底层硬件真实状况的忠实反馈。它逼着你直面磁盘寿命、网络延迟、CPU 调度这些物理世界的约束而不是躲在“高可用”“弹性伸缩”的抽象概念后面。后续你可以自然延伸用cephfs搭建 POSIX 兼容的分布式文件系统让多台服务器共享同一份/home用rgwRADOS Gateway开启 S3 兼容接口把集群变成私有对象存储甚至把rbd镜像作为 Kubernetes 的 PersistentVolume支撑有状态应用。但所有这些都建立在你亲手让三个 OSD 亮起绿灯的基础上。Ceph 分布式存储安装及简单使用不是一份过时的技术清单而是一次对数据基础设施本质的回归——它提醒我们在云原生时代亲手触摸硬件、理解协议、阅读日志依然是工程师最不可替代的能力。