企业官网建设流程全解析

1. 先把Ceph集群的“家底”摸清楚：核心组件到底有哪些

1.1 Ceph凭什么敢叫“统一存储”：RADOS底座与组件分工

Ceph能在一个集群里同时扛起块存储（RBD）、文件存储（CephFS）和对象存储（RGW），靠的不是什么黑魔法，而是底下那层叫RADOS（Reliable Autonomic Distributed Object Store）的底座。这个底座把所有磁盘抽象成对象池，再由一组组件各司其职地调度、复制、恢复数据，上层无论接什么协议，最后都落到同一套数据引擎里。

我见过不少朋友刚接触Ceph时，第一反应是“组件太多，不知道从哪下手”。其实搞懂组件关系后你会发现，Ceph集群的管理，说白了就是对几类角色的生命周期、状态和负载做持续管理。以前端视角看是“集群组件管理”，底层视角看就是“让MON、OSD、MGR这几个进程协同干活，并且能在节点故障、磁盘损坏、版本升级时保持数据可用”。

1.2 组件独立拆分带来的三个好处

Ceph把“管理面”和“数据面”拆得很开，这设计不是拍脑袋拍出来的，实际操作过的人都能体会到三个好处：

• 横向扩展明确：存储容量不够，加OSD节点就行；元数据性能不够，加MON节点或MDS就行，互不拖累。
• 故障隔离清晰：OSD坏了不会导致MON全部不可用，MON故障也不会让数据读写立刻中断（当然PG状态会受影响），组件之间有相对独立的故障域。
• 版本演进灵活：MGR、MON、OSD自成一套管理框架，可以分阶段升级和重启，不用一锅端。

这也是为什么做集群巡检、排障时，我习惯先把“组件角色”和“节点角色”分开看——一台物理机上可能同时跑了MON、MGR和多个OSD，组件管理更贴近进程视角，比单纯看IP更直观。

2. 每个组件在集群里扮演什么角色：从MON到RGW逐一拆解

2.1 MON：集群的“大脑中枢”

MON负责维护整个集群的Map——包括MON Map、OSD Map、PG Map、CRUSH Map等，所有客户端要读写数据前，必须先问MON拿最新的Map。MON之间通过选举机制形成一个quorum（法定人数），只有超过半数的MON在线，集群控制面才正常工作。

一个最常见的坑：MON只配了1台或2台。1台MON挂在那就是单点，2台MON一旦挂1台，剩余只有1台，达不到半数以上的要求，整个集群对外会判为不可用。所以生产环境我至少建议3台，而且要分散到不同物理节点上。

管理MON时，经常用到的命令是：

ceph mon stat ceph mon dump ceph quorum_status --format json-pretty ceph orch host label add node1 mon ceph orch apply mon node1 node2 node3

注意，ceph orch apply mon在cephadm部署模式下可以自动保证MON数量，但如果你用的是手动部署的裸集群，MON增减就得手动改配置文件再逐个起进程，步骤要谨慎，顺序错了容易导致quorum抖动。

2.2 OSD：数据落盘与副本的主战场

OSD是Ceph里干活最多、也最容易出问题的角色。每个OSD背后对应一块磁盘或一个分区，它负责把数据写入物理盘，同时参与数据副本的复制、心跳上报、数据rebalance和恢复。现代Ceph默认用BlueStore引擎，直接管理裸设备，不再依赖文件系统缓存，性能好很多，但这也意味着OSD一旦损坏，恢复数据只能靠副本或纠删码重建。

平时巡检时，我最关注OSD这几个维度：

• 状态：ceph osd tree看osd是否都在up且in。
• 容量：ceph df看整体使用率，超过85%就要警惕rebalance慢。
• 性能：ceph osd perf看commit和apply的延迟。

OSD生命周期管理，包括添加、摘除、替换。摘除OSD不能直接kill进程了事，要先将OSD标记out，让集群把PG迁走，再停进程并删除CRUSH条目：

ceph osd out osd.5 ceph orch osd rm osd.5 --zap

这里面有个关键点：--zap会抹掉盘上的数据标识，一旦执行，旧盘里的数据就找不回来了。所以执行前一定确认PG已经全部迁走，否则数据直接丢。

2.3 MGR：新一代管控入口

MGR是Ceph Luminous版本之后引入的组件，负责收集集群运行指标、暴露Prometheus接口、托管Dashboard和各类RESTful插件。如果没有MGR，Ceph集群虽然还能提供数据读写服务，但很多监控和管控能力会缺失。

我踩过的一个典型问题：MGR只部署了一台，升级或重启节点时，Dashboard偶尔打不开，Prometheus指标断档。后来学会用cephadm把MGR也做成至少2个实例的部署，虽然同一时刻只有一个MGR活跃，另一个standby，但切换速度很快，几乎不影响使用。

ceph orch apply mgr node1 node2 ceph mgr stat ceph mgr module ls ceph mgr module enable prometheus ceph mgr module enable dashboard

2.4 MDS与RGW：文件与对象的“进出口”

MDS只在用CephFS时才会部署，它维护着文件系统的元数据，不存实际文件内容，实际文件内容还是放在RADOS的data pool里。MDS挂掉，CephFS会暂时无法访问，但底层RADOS数据不受影响。所以对MDS组件的管理，我更关注它的活跃态和label列表：ceph fs status能看到哪些MDS是active、哪些是standby。

RGW则是对象存储网关，对外提供S3和Swift协议兼容接口。RGW可以部署多个实例，前面再加一个负载均衡器，比如HAProxy或Nginx，客户端通过VIP访问网关。

ceph orch apply rgw default --realm=default --zone=default ceph orch ls --service-name rgw.default ceph radosgw-admin bucket list

RGW的管理通常还要关注bucket索引、用户配额和访问日志。生产环境我习惯给RGW单独分配节点，避免和OSD抢CPU和网卡带宽，否则高并发时会看到RGW请求延迟明显抬升。

3. 组件管理的核心操作：从部署到日常巡检

3.1 部署第一个Ceph集群时，节点组件如何规划

说实话，规划阶段最容易改、也最难改。很多新手一上来就把MON、MGR、OSD全塞同一批机器，小规模测试没问题，但生产环境一定要按角色和故障域分开。

合理规划建议：

• 3台MON节点同时挂MGR，尽量不部署OSD，控制面机器保持轻载。
• OSD节点按机柜或交换机的故障域分散，CRUSH rule里设好failure domain。
• 网卡上尽量分离cluster network和public network，避免数据复制流量挤占客户端访问带宽。
• CephFS和RGW组件单独规划，和计算、数据库等业务错峰。

部署方式我优先推荐cephadm，它通过容器方式管理组件，背后其实就是一套标准化“组件管理”逻辑。相比手动一个一个装Ceph包、改配置文件，cephadm把组件的添加、删除、升级都做成了标准命令，排障门槛低很多。

3.2 用ceph orch管理组件生命周期：添加、重启、替换OSD

在cephadm模式下，组件管理的大头是ceph orch这套命令。我日常工作最常用这几条：

ceph orch host ls ceph orch host add node1 192.168.1.21 ceph orch host label add node1 osd ceph orch apply osd --all-available-devices ceph orch daemon restart mon.node1 ceph orch daemon restart mgr.node1 ceph orch daemon stop osd.3 ceph orch ps --daemon-type osd

其中apply osd --all-available-devices会自动发现节点上空闲盘并把它们创建成OSD，适合新机器初始化。但如果机器上有系统盘、缓存盘混在一起，我就不会直接用这个参数，而是通过ceph orch daemon add osd node1:/dev/sdb精确指定设备，避免把系统盘给卷进去。

OSD替换流程，标准路径是这样：

1. ceph osd out osd.7，让集群开始把该OSD上的PG迁移走。
2. 观察ceph -s的PG状态，等所有PG都activate+clean后，再停OSD进程。
3. 拔旧盘，插新盘。
4. 如果新盘还能识别，直接ceph orch daemon add osd node1:/dev/sdd；如果想彻底清掉旧盘关联，用ceph orch osd rm osd.7 --zap。

这里我特别提醒一点：osd out之后不是立刻就能拔盘的。PG重新分布需要时间，如果你有很多数据，可能几小时甚至一两天。中途要是看到有PG卡在peering或degraded，千万别急着强制下线，先用ceph health detail查原因。

3.3 组件状态盯哪些指标：健康度、容量、性能

组件管理的日常，其实就是时刻监控几个核心指标。我建议每个运维人员把这几条命令练成肌肉记忆：

• ceph -s：看集群整体状态，是否有HEALTH_WARN或HEALTH_ERR。
• ceph osd tree：看OSD分布和状态。
• ceph df：看存储池容量和对象数。
• ceph pg stat：看PG总数和状态分布。
• ceph osd perf：看每个OSD的延迟数据。

除了命令行，我还在Prometheus里配了告警规则，重点盯这几个维度：

• MON数量低于3，告警。
• OSD down数量大于0，告警。
• 任何OSD使用率超过85%，告警。
• PG数量低于min或inactive状态持续超过N分钟，告警。
• 集群总容量使用率超过85%，告警。
• MGR、MDS、RGW的进程存活状态变化，告警。

有人说运维Ceph很累，其实累的不是组件本身，而是组件之间关联复杂。比如一个OSD down会引发PG degraded，PG degraded会导致数据读写变慢，变慢会让其他OSD心跳超时，又引发更多OSD被标记down——这种连锁反应才是真正的噩梦。所以我一直觉得，组件管理的核心不是“会敲命令”，而是“能解读状态之间的因果关系”。

4. 组件故障排查：我先踩过的坑，你可以绕着走

4.1 MON失联：当大脑失去了“法定人数”

有一次一个测试环境里，因为机房断电导致3台MON中2台起不来，剩下的MON虽然活着，但凑不够quorum，集群直接拒绝服务。当时我以为只要把机器拉起来就恢复，结果发现2台MON的时区不一致，启动后时间差太大，MON之间的Lease总是失败。

排查步骤：

ceph mon dump ceph quorum_status journalctl -u ceph-mon@* -n 200

最终解决办法：强制同步所有节点时间，然后重启MON进程。从那以后，我在所有部署文档里都强调先配好chrony或ntp，不管你是3台还是5台MON，时间不同步迟早让集群出问题。

踩过这个坑之后，我总结出三条MON避坑经验：

• MON节点必须奇数个，且建议跨机架部署。
• 所有节点时间必须同步，偏差控制在几十毫秒以内。
• 不要随便重命名MON节点，CRUSH和ceph.conf里都有mon host关联，改名等于换身份。

4.2 OSD被标记为down：数据不会立刻丢，但别拖

OSD down是Ceph里最常见的告警。刚做Ceph时，我一看到OSD down就紧张，后来知道要先判断是不是单盘故障、网络抖动还是整个节点宕机。

排查顺序：

1. ceph osd tree，确认down的OSD。
2. ssh到对应节点，看dmesg是否有磁盘I/O错误。
3. ceph daemon osd.x status，如果能连上dameon，看内部状态。
4. 如果只是网络抖动，等心跳恢复后OSD会自动up。
5. 如果磁盘真坏了，走替换流程。

这里面有个小技巧：被标记down的OSD，如果进程还活着只是心跳延迟，可以手动把osd拉回来：

ceph osd up osd.7

但别高兴太早，如果根因是磁盘S.M.A.R.T异常或者卡死，拉回来过一会儿还会down。所以遇到反复down的OSD，别心疼磁盘，直接计划替换，省得半夜被叫起来处理。

4.3 PG卡在inactive或peering：集群的“纠结症”

PG状态是最能反映集群是否健康的指标之一。正常情况下所有PG应该是active+clean。如果看到大量PG处于inactive、peering、stale，说明组件之间协调出问题了。

常见原因和对应排查：

• OSD down且没有副本能完成选举，PG会卡peering。
• CRUSH map修改错误，导致PG无法找到合适的OSD组合。
• 存储池大小设置太小，比如replicated池副本数写成了1，数据损坏后想恢复都难。

排查命令集中在：

ceph pg dump | grep -E 'inactive|peering' ceph pg map 4.1 ceph health detail

处理策略一般就是：先恢复down的OSD，再等PG自然recover；不行就ceph pg repair <pgid>，但repair要克制，它可能触发数据回滚，不是万能的。

4.4 MGR故障与Dashboard不可用

MGR不像OSD那么容易被注意到，但一挂也烦人。Dashboard打不开、Prometheus指标没数据、部分ceph命令会报错，比如用ceph dashboard系列命令时。

MGR故障的排查相对简单：直接看进程状态，重启即可。如果是cephadm模式：

ceph orch ps --daemon-type mgr ceph orch daemon restart mgr.主机名

MGR还容易被误操作关闭模块。我曾经开启dashboard端口配置时不小心把两个模块搞冲突，导致dashboard无法访问。所以建议改MGR模块前先ceph mgr module ls看看当前启用列表，改完用ceph config set mgr mgr/dashboard/ssl false这类命令验证配置是否生效。

4.5 容易被忽略的细节：配置、日志与版本

最后分享几个我长期吃过的暗亏，都是文档和教程不会特别强调的：

• Ceph配置复杂，但不要一上来就魔改所有参数。先跑默认配置，稳定后再逐个调优，每次改一个参数并观察几天。
• 日志别全留到出问题时才翻，平时定期看ceph -s的HEALTH_WARN提示，很多隐患提前就有信号。
• 版本升级前先备份monstore和OSD的metadata，万一升级失败还能回滚。
• 对容器的存储需求，我强烈建议用RBD动态供给再加StorageClass，比手动挂载静态卷省心太多。
• Ceph官方文档很全，但不要只看架设。多翻ceph-deploy或cephadm的运维章节，里面写满了最佳实践。

每次处理完生产集群的问题，我都会把异常现象、排查过程、最终解决三件事写成记录。久而久之会发现，那些看起来玄乎的组件故障，90%最后都能归结到“网络是否稳定”“磁盘是否健康”“节点时间是否一致”“配置是否合理”这几件事上。

5. 组件管理的经验沉淀：先记住“稳定”

我个人在实际操作中最深的体会是：Ceph集群组件的管理，核心不是“管”，而是“稳”。第一次部署Ceph时，我喜欢把所有新特性都打开，把能调的性能参数都调到极致，结果生产环境三天两头出问题。后来才明白，存储这行当，稳定压倒一切。组件管理的前提是让每个组件待在它该待的位置、跑在它该跑的版本上，然后才是性能优化和功能扩展。

最后分享一个我日常非常依赖的小习惯：每个节点都提前设置好bash别名和快捷脚本，把ceph -s、ceph osd tree、ceph df、ceph pg stat组合成一个统一巡检命令，每天早中晚各跑一次。组件状态有波动时，人肉盯着总会有看漏的时候，脚本不会。持续跟踪数据曲线的趋势，往往比盯某个瞬间的数值更有价值。希望大家操作Ceph时都能顺风顺水，少踩几个我踩过的坑。