在这个全民上云、云原生泛滥的年代，反而有一批服务器被留在机房里，跑着并不算新的系统。我接手过一个类似运维环境，一水的CentOS 8服务器，业务侧明确要求自建分布式存储，给出的选型是Ceph，版本锁定Octopus（15.2.x）。说实话，初次听到这个组合时我也愣了一下：CentOS 8已经结束生命周期很久了，Octopus也不是最新版本。但当我放下“追新”的心态，把官方文档、社区Issue和实际部署过程走了一遍后，发现这套组合在存量硬件面前，反而呈现出一种难得的踏实。这篇文章就来讲讲我在CentOS 8上安装和配置Ceph Octopus的完整过程，包括环境规划、两种安装路线对比、存储池创建、踩坑记录和调优建议。无论你是要给老服务器续命，还是想在一套离线或不那么新的环境里快速搭出分布式存储，这篇应该都能给你省下不少时间。
我没有在一开始就直奔安装命令，而是先说清楚“为什么选它”，是因为Ceph的部署方式差异极大，如果没有搞清楚版本特性和系统约束，照搬网上的某些教程很容易在第一步就翻车。尤其CentOS 8停止维护后，yum源、驱动兼容、SELinux策略这些默认行为都发生了变化，提前花十分钟读环境，比事后排查十小时更划算。
1. 为什么还选CentOS 8 + Ceph Octopus这套组合
1.1 CentOS 8的生命周期与存量现实
CentOS 8的主流维护在2021年12月31日就正式结束了。按某些运维团队的习惯，系统EOL意味着寸草不生，安全补丁、CVE修复、软件仓库全部停更。但真实机房里的情况往往是：应用层还不能平滑迁移，硬件资源还没到报废年限，业务方对“稳定”的预期大于对“新鲜”的追求。这时候深陷“存量CentOS 8 + 分布式存储需求”的夹缝里，最务实的路径不是在裸金属上强行换新系统，而是在现有系统上把存储层做扎实。
这种选择是无奈的，但也是普遍存在的。Ceph官方在Octopus版本的官方文档中，仍然把CentOS 8列为支持的操作系统之一，这对我而言是一个关键信号：在系统生命周期的末尾，软件生态依然认可它作为承载层。另一方面，CentOS 8内部使用的内核版本是4.18，这个内核版本对大多数SATA盘、SSD、万兆网卡都有成熟的驱动支持，反而比某些过于超前的新内核在兼容性上更有优势。
1.2 Octopus版本的定位与选型理由
Ceph版本演进很快，但从稳定性和管理方式的维度看，Octopus（15.2.x）是最值得记住的版本之一。原因有三点：第一，Octopus开始把cephadm作为推荐的部署方式，一个二进制文件就能完成集群引导、主机管理和守护进程托管，这个变化让部署的复杂度大幅下降；第二，Octopus的Dashboard功能已经相当完整，可以直接在Web界面上看集群状态、管理OSD、查看性能指标，对不愿碰命令行的运维人员友好很多；第三，这个版本是LTS后续维护系列，社区修复了很多早期版本的崩溃和性能问题，在生产环境中的表现和数据安全记录都比较成熟。
我选择Octopus而不是更晚的版本，还有一个非常现实的原因：在CentOS 8这个系统层面上，Octopus的依赖链最为平顺。再往后的版本对Python版本和依赖库有更高要求，在CentOS 8默认软件源受限的情况下，手动凑依赖会变得很痛苦。
1.3 什么场景适合这套组合
如果你现在手里是以下几类环境，这套组合值得考虑：
- 存量CentOS 8服务器，暂时无法迁移系统，但存储容量和可靠性都需要升级。
- 离线或内网环境，软件源的更新需要走本地镜像，而Ceph Octopus的包比较全。
- 测试环境或边缘节点，需要快速跑通一套包含对象存储、块存储、文件存储三种接口的分布式存储原型。
反过来，如果你后续有强烈的扩缩容需求、需要频繁升级版本体验新特性，那我建议换更新的系统与更新的Ceph版本。Octopus在CentOS 8上虽然稳定，但毕竟不是“永久保鲜”。
2. 安装前的环境规划与系统初始化
2.1 集群拓扑与硬件规划
Ceph集群的基本组件包括Monitor（负责维护集群映射）、Manager（负责性能指标和编排）、OSD（负责实际数据存储）。最小可用集群至少需要一个Monitor和一个Manager，但单机部署没有任何冗余意义。我在模拟项目X中使用的拓扑是三台服务器，每台同时运行Monitor、Manager和OSD，另外选其中一台作为部署管理节点。
关于硬件，有两条经验值得记住：第一，Ceph对内存的消耗没有想象中小，OSD进程每个会占用2-4GB内存，Monitor和Manager加起来再占几GB，因此每台机器建议至少16GB内存，如果OSD数量多，要往上加；第二，网卡是分布式存储的生命线。即使是测试环境，也建议至少两张千兆网卡做管理网络与存储网络分离，生产环境直接上万兆。网络不达标，后面出现的性能问题会让你误以为是硬盘的问题。
2.2 网络规划与端口说明
Ceph的端口规划并不复杂，但很多人会在防火墙规则里漏掉。默认情况下，Ceph的守护进程通信使用以下端口：
| 服务 | 默认端口 | 说明 |
|---|---|---|
| Monitor | 3300, 6789 | 客户端和MON通讯 |
| Manager | 6800-7300 | 内部组件通讯 |
| OSD | 6800-7300 | 数据访问和心跳 |
| Dashboard | 8443 | Web管理界面 |
| Prometheus metrics | 9283 | 监控指标暴露 |
在CentOS 8上，我通常的做法是直接关闭firewalld服务来解决通信问题，毕竟内网环境，安全策略由上层防火墙统一控制。如果因为合规要求必须开启firewalld，那就需要把这些端口按节点角色放通。这里补充一句：不要在部署过程中反复调试防火墙规则，成本太高。
2.3 系统初始化的关键操作
在安装Ceph之前，每一台节点都要完成以下几项初始化，缺一个都可能埋雷。
首先是配置DNS或/etc/hosts解析。Ceph集群中节点标识靠主机名，IP解析错误会直接导致Mon选举失败。我在三台机器上分别配置了完整的主机名和IP映射，顺序是IP在前、完整域名在中、短主机名在后。
然后是时间同步。Ceph对时间偏移非常敏感，Monitor之间时钟偏移超过一定阈值就会影响选举。CentOS 8自带了chrony，只需修改/etc/chrony.conf里的server指向一个内网NTP服务器，然后执行systemctl restart chronyd && systemctl enable chronyd。
还有一个容易被忽略的点：关闭SELinux或者调成宽容模式。严格讲，生产的理想状态是让SELinux和Ceph共存，但Octopus在CentOS 8上配置SELinux策略并非一两句话能搞定，涉及SELinux布尔值和文件标签的修改。我统一使用setenforce 0并把/etc/selinux/config里的SELINUX改为permissive，换来部署速度，同时保证能及时发现其他问题。
2.4 CentOS 8的yum源问题
这是今天的第一个大坑，务必先解决。CentOS 8停止维护后，系统默认的AppStream和BaseOS软件源链接全部失效，哪怕你以为网络没问题，yum install也会直接报错。解决办法是把源指向CentOS Stream的vault镜像源，或者用国内可访问的龙蜥镜像。
我用个简单方案，把/etc/yum.repos.d目录下的所有CentOS-*.repo文件的baseurl全部替换为vault镜像地址，并且将enabled=1的项改过来。替换时注意mirrorlist参数要注释掉，只保留baseurl，否则会覆盖你的配置。替换后执行dnf clean all && dnf makecache验证源可用。
实践中的确有很多人在这一步就放弃，因为提示“Could not resolve mirrorlist”完全看不出是源失效还是网络故障，但只要把yum源切到vault上，这个问题立刻消失。
3. 两种安装路线：cephadm与手动rpm方式
3.1 方案对比
Octopus版本提供两条部署路线，我在这里把优缺点放在一张表里：
| 安装方式 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| cephadm | 一条命令引导集群；自动化管理守护进程容器；后续扩容方便 | 依赖容器运行时，出问题排查要懂容器；离线环境需要提前准备镜像 | 有容器环境的现代化部署 |
| 手动rpm | 直接使用系统包管理器；进程生命周期由systemd管理，直观；不依赖容器 | 配置步骤繁琐；服务扩容需要手动执行多步 | 习惯传统运维、内网无容器环境 |
我当时在离线内网环境，容器镜像的获取非常不顺，于是最终选择了手动rpm方式。但如果你的环境能正常访问外网，或者能提前把镜像拉到本地，cephadm是最省力的。两种方式我都在测试环境跑通过，下面分别记录。
3.2 cephadm方式安装步骤
cephadm本质上是一个基于容器技术的管理工具，部署端只要求Python 3.6+和一套容器运行时（Podman或Docker）。在CentOS 8上首先要确认Podman可用，因为默认的container-tools模块自带Podman。如果系统中没有，执行dnf install -y container-tools即可。
然后下载cephadm脚本。这个脚本可以放在/usr/local/bin下并赋可执行权限。完成后在部署节点上执行引导命令，其中关键点是mon-ip参数必须填写部署节点在集群网络中的IP，ssh-user填写当前系统用户；Ceph会用这个用户通过SSH免密方式在其他节点上执行操作。
bootstrap引导完成后，cephadm会在当前节点上启动一个Monitor和一个Manager，同时会生成一个client.admin配置文件和keyring放在/etc/ceph目录下。接着做SSH免密，把整个集群纳入管理，再将其他节点上的OSD添加进来。整个过程对容器的依赖很强，如果Podman版本过低，可能会有权限问题，出现这种情况时优先升级container-tools。
3.3 手动rpm方式安装步骤
手动rpm方式是传统方式，全程不涉及容器，适合内网环境。第一步是安装Ceph官方的yum源，我以Octopus版为例，在拿到repo源文件后需要把gpgcheck根据实际密钥情况选择开启或关闭。内网环境如果没有导入GPG密钥，安装时会有告警，我的建议是把密钥文件也一并放到内网，或者直接临时设置gpgcheck=0，因为集群内部基本不需要操心被篡改的问题。
每个节点上执行：
yum install -y ceph-mon ceph-mgr ceph-osd ceph-mds ceph-radosgw这套包安装完成之后，Ceph的二进制文件、RPM默认配置、systemd服务文件都会就位。然后开始手动初始化Monitor：
mkdir -p /etc/ceph # 在部署节点生成初始密钥 ceph-authtool --create-keyring /tmp/ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *' # 生成管理员keyring ceph-authtool --create-keyring /etc/ceph/ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'再创建ceph.conf配置文件，指定cluster网络、public网络、mon主机名和初始mon成员。这个步骤最容易出错的就是配置路径或fsid不一致，注意mon keyring中记录的fsid必须和ceph.conf中的fsid一致。接着启动mon进程，并把mon加入集群后，再启动mgr和osd。手动方式的每一步都有对应的验证命令，建议每执行一步就用ceph -s观察一下集群状态，而不是一口气把所有组件配完再回头看，那样定位问题会非常困难。
4. 集群初始化、OSD创建与Dashboard配置
4.1 通过cephadm初始化单节点集群
如果选cephadm方式，初始化命令如下：
cephadm bootstrap --mon-ip 192.168.10.10 --ssh-user root --cluster-network 192.168.20.0/24这段命令的意思是：当前节点作为Monitor，IP是管理网络地址；存储网络单独走192.168.20.0/24网段。执行完成后，ceph -s应该可以看到集群状态为HEALTH_OK或存在一些还未完成的告警。首次引导时，集群里只有Monitor的OSD还没有，所以会提示OSD数量不够，这个正常。
拿到bootstrap后可以追加节点，先在别的节点上配置SSH免密，然后通过ceph orch host add命令把节点纳入集群。在Octopus里，OSD的创建可以走ceph orch device zap或者ceph orch daemon add osd这组命令。注意，这里Ceph会自动检测未使用的块设备并部署OSD，也可以手动指定盘符。
4.2 扩容OSD的完整过程
我以手动rpm方式为例说一下追加OSD的正确姿势。OSD的数据存储基于Bluestore，一块磁盘会分三层：数据实际存放的block、存放元数据的WAL（block.wal）和数据库（block.db）。最稳妥的分配方式是block独占整块盘，block.wal和block.db优先放到SSD或NVMe盘上。如果条件允许，最好单独准备一块小容量SSD专门做OSD的WAL和DB，能明显提升随机写性能。
手动创建一个OSD的命令是：
ceph-volume lvm zap /dev/sdb --destroy ceph-volume lvm create --bluestore --data /dev/sdb这里第二条命令会把整块磁盘做成数据盘，WAL和DB默认和数据盘放在一起。如果想指定SSD作为WAL和DB，需要分区后手动指定：
ceph-volume lvm create --bluestore --data /dev/sdb --block.wal /dev/sdc1 --block.db /dev/sdc1创建OSD后，一定要观察ceph -s里的PG状态。如果出现PG在peering或degraded，说明副本还没有完全同步，切成更安静的复制等待即可。这个阶段最忌频繁重启OSD或拔盘，容易把重建过程拖成高负载。
4.3 配置Dashboard和监控
Octopus的Dashboard是很多人选择它的一大原因。开启Dashboard非常简单：
ceph mgr module enable dashboard ceph dashboard create-self-signed-cert ceph dashboard set-login-credentials admin 'your-password'然后Web访问 https://ip:8443 就能看到图形化面板。Dashboard能直接展示集群使用率、OSD延迟、客户端吞吐量，还可以通过内置的Prometheus模块把指标暴露给外部监控。
有个细节要注意：dashboard模块是通过Manager进程提供的，而Manager负责资源调度的角色。如果Manager发生故障切换，Dashboard的URL可能从一台机器跳到另一台机器，所以生产环境最好用一个虚拟IP来代理8443端口，或者把它放在负载均衡后面。
5. 存储池、块设备与客户端实战
5.1 创建存储池
Ceph存储池（Pool）是数据承载的基本单位。在Octopus中，创建池之前需要考虑副本数（size）、PG数量（pg_num）和复制模式。默认副本数是3，数据写一份，另外两份副本写到其他两个OSD上，这种方式安全性高但空间占用大。测试环境可以改成2来节约空间，但生产绝对不值得在副本上省钱。
PG数量估算取决于OSD总数和每个OSD承载的PG数。经验公式大致是：PG总数约等于（OSD总数 × 100）除以副本数。比如10个OSD，副本3，PG总数建议在330左右，然后按最接近的2的幂次来选择pg_num，比如256。
创建命令：
ceph osd pool create mypool 256 256 replicated第三个参数是副本数量，如果使用纠删码（EC）池可以改成ec模式，但这个在手动配置时需要额外创建profile，建议新手先从副本池开始。
5.2 RBD块设备的使用全流程
RBD（RADOS Block Device）是Ceph最常用的块存储接口。创建并挂载一块虚拟盘的完整流程如下。
先创建块设备镜像：
rbd create mypool/disk-image --size 20G把镜像映射到本地设备节点：
rbd map mypool/disk-image --name client.admin首次映射会在/dev下生成一个rbd设备。如果需要开机自动挂载或者让多客户端访问，需要启用rbd kernel模块并配置好ceph客户端关键信息。我通常在内网客户端上用iptables限制访问，再用以下方式挂载：
mkfs.ext4 /dev/rbd0 mount /dev/rbd0 /mnt/ceph-disk这个过程对小白来说会有个理解拐点：Ceph块设备不是本地文件，而是一个分布在不同服务器上的逻辑卷，你在客户端看到的/dev/rbd设备其实是由内核网络驱动抽象出来的，所以单机层面看延迟会比本地盘高。若想追求更低的延迟，需要调优前面提到的网卡参数、队列深度以及客户端端的max_sectors_kb。
5.3 CephFS集群配置（可选）
如果需要文件存储，配置CephFS也不复杂。首先生成两个存储池，一个负责元数据，一个负责数据：
ceph osd pool create cephfs_metadata 64 64 ceph osd pool create cephfs_data 128 128 ceph fs new cephfs cephfs_metadata cephfs_data启用MDS守护进程后，在客户端挂载：
mount -t ceph 192.168.10.10:/ /mnt/cephfs -o name=adminCephFS比较适合存储海量小文件的场景吗？从我的实践看并不绝对，它在千万级文件数量下还是能保持一个可接受的性能。But如果你是小文件高并发写入，CephFS未必比本地文件系统好，这是分布式架构的通病，如果业务对密金属敏感，要提前打预防针。
6. 最容易出问题的七个坑
6.1 yum源失效导致连锁故障
前面提到的CentOS 8仓库失效问题会在两种情况下爆发：第一是在全新安装时，系统包管理器无法拉取任何依赖；第二是中途需要安装某个额外工具时，才发现源已经失效。解决办法就是把软件源换成vault，这在2.4节已经说过。一定要在开始装系统时就把源修正，不要等装到一半再处理，否则卸载重来的成本更高。
6.2 时间同步漂移
Ceph的Monitor对时间非常敏感，如果三台节点之间时间差超过0.5秒，集群可能会出现间歇性告警。我遇到过一次非常诡异的现象：ceph -s状态一直显示HEALTH_WARN，但点开详情只提示clock skew detected。排查了半小时才发现其中一台机器的chrony服务没有随开机启动，时间落后了整整一天。统一写一个定时任务检查chronyc tracking结果，能避免绝大多数这类问题。
6.3 SELinux和权限问题
CentOS 8默认SELinux为enforcing，Ceph在运行时需要访问磁盘设备、pid目录、socket文件，SELinux的安全上下文如果不对，OSD启动日志里全是Permission denied。如果采用permissive模式则不会有这类问题。但有人担心permissive模式降低安全性，我在实际部署中采用的折中方案是：先以permissive跑通全流程，确认集群稳定后，有精力再细化SELinux策略。
6.4 主机名解析
有三台节点时，一个疏忽是把/etc/hosts只写了本机IP和hostname，没写其他两个节点。看似每台机器信息都完整，但Ceph内部使用的是短主机名加域名的方式探测其他节点，最终会导致OSD心跳通信失败、Mon无法连接。写/etc/hosts时务必三台机器的IP和主机名全量写入。
6.5 Bluestore的块设备分配
这是一条非常典型的教训。我在起初把WAL和DB在同一个数据盘上，没有单独分离，结果在重负载写入测试中，随机写性能经常掉到令人发指的程度。后来通过ceph osd blocklist和OSD迁移把WAL和DB挪到SSD分区上，性能才有了质的提升。规划磁盘时建议不要让数据和WAL/DB打架，哪怕拿一块几百GB的SSD做全集群的WAL+DB分区，也比混着用好得多。
6.6 网络参数导致的OSD抖动
Ceph的OSD进程通过心跳相互检测，如果存储网络的ping延迟波动很大，OSD可能被误判为down，然后触发数据恢复。这个现象在千兆网络、网卡负载高的时候很常见。解决方法是先把网卡的tuned-adm配置为latency-performance或network-latency，其次检查MTU是否一致，万一出现混用，跨网段MTU不一致会造成分片丢包。用ethtool -S查看drop、error计数也是快速判断网卡故障的一个方法。
6.7 升级和重启后的集群状态
CentOS 8环境下，如果内核升级或重启服务器，Ceph守护进程会自动拉起，但有时你会发现重启后OSD没有自动上线，特别是手动rpm方式安装时，systemd的enable配置被遗漏。我的习惯是每个节点都执行systemctl enable ceph.target，并在开机后第一时间ceph -s检查状态，而不是等业务报警后才去看。
7. 上线前的性能调优与运维习惯
7.1 内核参数
Ceph对内核参数有几项默认值并不友好。比如系统swap倾向、脏数据回写比例、文件句柄数，都要做针对性调整。
# 提高内存敏感业务的稳定性 vm.swappiness=10 vm.dirty_ratio=20 vm.dirty_background_ratio=5另外，Ceph的OSD进程会消耗大量文件描述符，把limits里的nofile调大到65535或更大。网卡队列方面，如果使用多队列网卡，加载RSS队列并把每个队列绑定到不同CPU核心，中断处理更均衡。默认的irqbalance大概率不够，必要时手动设置。
7.2 OSD关键参数
Octopus的OSD有几个重要配置项值得关注：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| osd_memory_target | 4G或更高 | OSD缓存目标，太低会导致性能下降 |
| osd_max_objects | 自动 | 单OSD对象数上限，不建议手动改 |
| bluestore_cache_size_hint | 自动/手动 | 可以给热点池增加缓存 |
| osd_scrub_during_peak | false | 避免高峰期间进行数据校验 |
如果OSD数量多，内存吃紧，不要盲目调大osd_memory_target，应根据总内存和OSD数量平衡。每个OSD 4G是一个典型配置，16GB内存的机器建议最多放3个OSD。
7.3 日常运维建议
运维Ceph Octopus集群，我最想强调的一点是“不要让存储集群处于不可观测状态”。Octopus自带的Dashboard和Prometheus已经提供了很多数据，至少要配置一个告警规则，比如OSD down超过一个副本、PG数异常、容量超过阈值，这些应该第一时间让值班人知道。
另外是数据备份。Ceph本身是多副本存储，能防单盘故障，但它不能防误删除或者勒索软件。如果有业务需要，还要额外考虑快照、RGW版本控制或定期导出。不要因为分布式存储的可靠性就忽略数据安全的其他维度。
还有一点是版本策略。Octopus在CentOS 8上虽然稳定，但涉及重大安全更新时，还是要关注官方公告，评估灰度升级。不要因为EOL就觉得什么都不用管，存储系统永远是越谨慎越好。
最后分享一个我踩过几次坑后的个人习惯：每次对Ceph做变更（新增OSD、调整池参数、升级系统）前，我都会先记录下ceph -s的输出、ceph osd tree、ceph df，并且把/var/log/ceph目录做一个归档。这些信息在出现问题时是定位和回滚的宝贵线索。养成这样的习惯后，绝大多数存储故障都能在一个可接受的窗口期里解决。
如果你也在部署CentOS 8 + Ceph Octopus，欢迎参考这篇教程，但更重要的是根据你的环境条件做取舍。存储没有银弹，只有贴合现状的方案，才是最实用的方案。
