Ceph集群上线之后真正考验人的不是部署而是日常运维。而日常运维里MON相关的命令又是绕不开的第一道门槛。不管是看集群健康状态、排查某个MON进程挂掉还是扩容缩容MON节点最终都要落到一串串的ceph命令上。我见过不少刚接触Ceph的朋友集群搭起来了但遇到ceph -s报HEALTH_WARN就懵了不知道从哪条命令入手也有一些人把MON命令和OSD命令混在一起概念没搞清楚排查方向就跑偏了。这篇东西就把Ceph MON相关的命令好好梳理一遍从状态查看、节点管理到故障排查把每个命令背后的原理和实际使用场景讲清楚。这篇内容不是简单的命令罗列我会把每个命令常见的输出片段、关键字段含义、什么时候用、有哪些坑都拆开讲。适合刚入门Ceph的运维新手也适合那些已经管了一段时间集群但还没系统整理过MON命令的人。1. MON在Ceph中的地位与命令全景先说清楚MON到底是什么。Ceph的MonitorMON是整个集群的“大脑”和“仲裁者”。它维护着集群的元数据包括OSD的映射关系OSD Map、PG的分布状态PG Map、CRUSH规则、认证信息等同时通过Paxos协议保证这些元数据的一致性。换句话说客户端要读写数据前必须先找MON拿到最新的集群地图Cluster Map才能定位到具体的OSDOSD之间要做数据迁移或者处理异常也要通过MON获取全局状态。所以MON挂了不只是“一个进程挂了”这么简单它可能意味着整个集群的读写路径被卡住。理解这一点你会发现掌握MON命令的优先级非常高。从命令形态上看MON相关的命令主要有三类第一类是ceph开头的CLI命令比如ceph mon stat、ceph mon dump、ceph quorum_status这类命令通过管理socket与MON通信第二类是直接操作MON守护进程的命令比如ceph-daemon、systemctl等用于启动、停止、重启MON服务第三类是一些底层工具比如ceph-monstore-tool用于MON存储数据的导出、修复、重建。三类命令定位完全不同很多人容易混淆。ceph mon dump是查看MON集群配置状态systemctl restart ceph-monnode1才是控制具体的MON进程这两件事在日常运维里经常要配合使用。2. 状态查看从ceph -s到mon dump的一层层拆解2.1 ceph -s一切排查的起点不管你是老手还是新手遇到任何Ceph问题第一件事永远是跑ceph -s看整体状态。这个命令几乎人人都用过但你真的看得懂输出吗我随便贴一段$ ceph -s cluster: id: 7a5c2d1e-8f4b-4a3c-9d2e-1b3f5a7c9e01 health: HEALTH_WARN mon.osd-1 is down (out of quorum) mon.osd-1 (rank 1) addr 10.0.0.12:6789/0 is down (out of quorum) services: mon: 3 daemons, quorum osd-1,osd-2,osd-3 (age 5m) mgr: 2 daemons, active: mgr.osd-2 osd: 10 osds, 10 up, 10 in rgw: 1 daemon active data: pools: 8 pools, 256 pgs objects: 1.02M objects, 3.1 TiB usage: 9.4 TiB used, 15.6 TiB / 25 TiB pgs: 255 activeclean, 1 activeremapped io: client: 45 KiB/s rd, 12 KiB/s wr, 26 op/s rd, 4 op/s wr很多人只看HEALTH_WARN后面的提示其实前面几行信息量很大。services.mon这一行会明确告诉你集群一共配置了3个MON当前有2个在quorum里哪个节点掉线了。这里有一个非常容易被忽略的点健康提示里写的“mon.osd-1 is down”和“out of quorum”是两回事——前者是进程层面没起来后者是Paxos选举层面被踢出去了。虽然实践中经常同时发生但排查思路不一样。进程挂了直接拉起来就行进程活着但out of quorum那多半是网络、时钟、存储IO或者磁盘空间的问题。pgs那行也要学会看。activeclean是理想的activeremapped一般提示有OSD在迁移或者backfill这个如果持续超过一两个小时就要留意了可能是MON判定某个OSD异常导致数据重新分布。2.2 ceph mon stat三秒判断MON集群规模ceph mon stat是查看MON节点规模最快的方式它的输出非常精简$ ceph mon stat e1: 3 mons at {osd-110.0.0.11:6789/0,osd-210.0.0.12:6789/0,osd-310.0.0.13:6789/0}, election epoch 42, quorum 0,1,2 osd-1,osd-2,osd-3逐字段拆解e1mon map的版本号。每次增删MON节点、修改地址这个版本号都会递增。如果这个数字异常大说明集群的mon map被反复修改过要查一查有没有人不小心重复执行了添加命令。3 mons at {...}总共配置了几个MON后面的地址列表把每个MON所在的节点和端口都列出来了。注意IPv4和IPv6都会在这里显示。election epoch 42这是选举的纪元数。每发生一次MON选主这个数字就加1。如果这个数字剧烈增长说明MON之间频繁发生选举这通常意味着网络不稳或者时钟不同步。quorum 0,1,2 osd-1,osd-2,osd-3当前在quorum里的MON序号和节点名。quorum后面的序号对应mon map里的rank。如果某个节点名字不在这个列表里就说明它不在quorum中。这个命令特别适合在监控脚本里用比如定时捕获election epoch的变化一旦发现短时间内增长超过某个阈值立即告警大概率是节点间网络抖动或者时钟漂移。2.3 ceph quorum_status深入Paxos选举现场ceph quorum_status展示了更细节的选举与quorum信息排障时非常有用$ ceph quorum_status { election_epoch: 42, quorum: [ 0, 1, 2 ], quorum_leader_name: osd-1, quorum_age: 294, monmap: { epoch: 1, mons: [ { rank: 0, name: osd-1, addr: 10.0.0.11:6789/0, public_addr: 10.0.0.11:6789/0 }, { rank: 1, name: osd-2, addr: 10.0.0.12:6789/0, public_addr: 10.0.0.12:6789/0 }, { rank: 2, name: osd-3, addr: 10.0.0.13:6789/0, public_addr: 10.0.0.13:6789/0 } ] } }重点看三个字段quorum_leader_name当前谁是Leader。Paxos机制里Leader负责发起提案和推进状态更新。如果Leader频繁变化说明选举不稳定。quorum_age当前quorum已经稳定存在多长时间。这个数值越大越好如果经常归零重来那基本可以判定集群存在间歇性的通信问题。monmap.mons里面除了地址还有rank信息。rank在MonMap里是固定的排序值通常是生成monmap时按加入顺序分配的。rank不影响业务逻辑但很多运维习惯用rank来引用MON节点。有一个特别要注意的细节输出里可能出现public_addr和addr两个字段不一致的情况。addr是MON之间内部通信以及客户端连接的地址public_addr是集群对外公告的地址。正常情况下两者一致但如果配置了多网络或VIP就会不一样。排查客户端连不上MON的问题时一定要确认客户端访问的是public_addr。2.4 ceph mon dumpMonMap的完整档案如果说ceph mon stat是速览ceph mon dump就是完整档案。它会输出MonMap里所有字段包括每个MON的地址、公网地址、权重、持久化标志等。重要字段如下$ ceph mon dump dumped monmap epoch 1 epoch 1 fsid 7a5c2d1e-8f4b-4a3c-9d2e-1b3f5a7c9e01 last_changed 2024-06-01 10:00:00.123456 created 2024-01-15 09:30:00.654321 min_mon_release 17 (quincy) election_strategy: 1 0: [v2:10.0.0.11:3300/0,v1:10.0.0.11:6789/0] mon.osd-1 1: [v2:10.0.0.12:3300/0,v1:10.0.0.12:6789/0] mon.osd-2 2: [v2:10.0.0.13:3300/0,v1:10.0.0.13:6789/0] mon.osd-3election_strategy是很多人忽略的一个字段。Ceph从Nautilus开始引入了多种选举策略策略1默认经典模式优先选择连接的节点策略2稳定模式尽量保持现有的Leader不变减少不必要的切换这种策略在节点数较多、网络偶尔抖动的环境里能减少“惊群”式的反复选举。如果你的集群经常出现Leader跳变可以考虑把选举策略改成2。修改方式ceph mon set election_strategy 2但要注意尽量不要在集群故障还没恢复的时候调整选举策略否则可能让情况更复杂。另外min_mon_release字段用来标识MON最小支持的Ceph版本。在混合版本集群里这个字段决定了新老MON之间能不能协同工作。跨大版本混布MON本来就是高危操作看到这个字段可以帮助你判断当前集群的“地板版本”。3. MON节点管理增删改查全流程实操3.1 添加MON节点从三个到五个的完整步骤生产环境里把MON从3个扩到5个是常见的操作。为什么要做这一步因为3个MON最多只允许挂1个2个在quorum里5个MON允许挂2个。对于跨机柜、跨机房的场景多一个MON就是多一份容灾。但代价是Paxos通信次数增加写延迟会略有上升所以也不是越多越好一般5个足够。添加MON的标准步骤如下第一步准备目录与认证文件# 在新节点上创建目录 mkdir -p /var/lib/ceph/mon/ceph-hostname # 将集群的认证key复制到新节点 scp /etc/ceph/ceph.client.admin.keyring rootnew-node:/etc/ceph/ scp /etc/ceph/ceph.conf rootnew-node:/etc/ceph/第二步获取monmap并注入# 在任意一个现有MON节点上导出monmap ceph mon getmap -o /tmp/monmap # 在新节点上用monmaptool注入新节点信息 monmaptool --add hostname ip:6789 --fsid fsid /tmp/monmap这里用monmaptool修改的是本地monmap文件并不会直接改集群配置。真正的改动是在后续创建MON进程时通过ceph-mon -i作用的。第三步创建MON数据目录sudo -u ceph ceph-mon -i hostname --mkfs --monmap /tmp/monmap --keyring /etc/ceph/ceph.client.admin.keyring第四步启动MON并加入集群systemctl start ceph-monhostname # 或者手动前台启动便于看日志 ceph-mon -i hostname --public-addr ip:6789启动之后可以在原有节点上执行ceph mon add hostname ip:6789也可以等MON通过monmap自动起来后自己加入。实际操作中我倾向于手动add因为可控性更强。执行后等几秒钟再跑ceph mon stat确认quorum里多了新成员。这里有几个典型坑新节点的时间如果偏差超过mon_max_sync_skew默认5秒MON启动后会拒绝加入quorum日志里报clock skew。所以执行之前先同步时间chronyc makestep或者重启chronyd都行。数据目录的属主必须是ceph用户否则MON进程直接起不来报权限错误。我见过有人用root创建目录忘了chown排查了半天。防火墙只放行了6789端口忘了新版本Ceph默认还有3300端口v2协议。如果你看到MON起来但客户端连不上检查一下3300通不通。3.2 删除MON节点降级同样要谨慎删除MON的操作比添加更敏感因为存量MON越少quorum容错能力越差。三节点MON集群删掉一个就退化成两节点任何一个MON再挂整个集群的读写就中断了。所以在执行删除前一定要确认剩余MON数量仍然是奇数且健康。删除流程# 1. 踢出MON ceph mon remove hostname # 2. 停止进程 systemctl stop ceph-monhostname # 3. 清理数据目录确认无误后再删 rm -rf /var/lib/ceph/mon/ceph-hostnameceph mon remove执行后MON会立刻从monmap里被移除剩下的MON会重新形成quorum。这里有个细节如果被删的节点还在运行并持有旧monmap它可能还会往外广播错误信息所以先stop进程再remove更稳妥。我习惯的顺序是先停进程再执行remove命令避免它反复尝试加入已经被移除的quorum。还有一个容易被坑的点是如果集群已经处于quorum丢失状态比如只剩一个MON存活这时候执行ceph mon remove是会被拒绝的因为命令本身需要quorum才能执行。因此删除操作一定要在集群健康的时候做。3.3 修改MON地址mon host配置的更新方式MON节点IP变更虽然不频繁但遇到机房迁移、网络调整就躲不开。如果你直接改ceph.conf里的mon host配置重启MON后会发现集群里的monmap还是老地址两者不一致MON之间互相找不到quorum直接分裂。正确做法是# 1. 更新monmap ceph mon set_addr hostname new-ip:6789 # 2. 同步修改所有节点上的ceph.conf # 包括MON节点自身和所有客户端节点ceph mon set_addr会同时更新monmap和对应MON的地址这个命令需要quorum可用。执行之后记得在所有客户端也更新ceph.conf里的mon host或mon addr配置否则客户端拿着旧地址连不上MON。如果新老IP同时在公网和专网生效建议提前在ceph.conf里使用public network和cluster network来区分这样MON会自动绑定到对应网段后遗症少很多。4. 排障实战MON挂掉、quorum丢失与性能异常4.1 mon down从进程层面排查问题“mon down”是出现频率最高的告警之一。但“down”只是一个结果原因可能丰富多彩。我遇到过的情况包括磁盘满了、内存不够被OOM杀掉、网络闪断导致被踢出quorum、甚至有人手动stop了服务忘了启动。先说rook环境里的mon down这个热词现在搜出来不少本质都是一样的。排查思路按顺序来第1步看进程状态systemctl status ceph-monhostname如果进程没起来看journal日志journalctl -u ceph-monhostname -n 200常见日志关键词包括failed to open monstoremonstore损坏或权限不对clock skew时间偏移超过阈值disk fullmonstore所在磁盘满了MON拒绝写入paxos相关错误通常和网络相关比如long partition导致Paxos卡住。第2步看磁盘和内存df -h /var/lib/ceph/mon free -hMON的数据量虽然不大但存储monstore的磁盘如果写满MON会直接进入只读甚至退出状态。这条好多人会漏掉因为在OSD那边磁盘满的情况比较常见下意识觉得MON目录那么小不会满。实际上如果和系统日志、监控数据共用一块盘很容易被无关数据填满。第3步看网络连通性# 从当前节点尝试连接其他MON的6789和3300端口 nc -vz 10.0.0.12 6789 nc -vz 10.0.0.12 3300MON之间的网络要求很低但很敏感偶尔丢包都会引发选举抖动。如果两个节点之间跨VLAN或有防火墙策略优先检查。4.2 out of quorum进程活着但被隔离进程活着不代表就在quorum里。我在2.1节已经提到过这个问题这里展开讲。ceph -s显示mon.x is down (out of quorum)但systemctl status ceph-monx显示进程明明在跑这就是典型的“进程存活但网络隔离”。遇到这种我的排查顺序是看MON日志grep -i paxos\|elect /var/log/ceph/ceph-mon.hostname.log。日志里一般会写清楚是收不到其他MON的lease还是选举超时。检查时钟在三台MON上分别执行timedatectl status对比UTC时间偏差。偏差大于mon_max_sync_skew默认5秒MON就不会参与quorum。实际经验是偏差超过1秒就要警惕。检查网络QoS或限流有些机房会对节点间流量做策略限流导致MON之间的心跳消息被延迟。这种问题在生产环境特别隐蔽sflow/netflow才能看出来。确认防火墙规则有些环境下mon_host配置变更导致MON试图连接新端口但防火墙没放行。定位到原因后修复手段就相对直接时间不准就重新同步网络问题就联系网络组调整策略如果是MON自身数据异常可能需要用ceph-monstore-tool重建这个工具后面单独讲。4.3 quorum丢失最后的手段与重建流程三节点MON集群如果两个节点同时挂了或者存储损坏整个Ceph集群会进入“全拒”状态——任何读写请求都被拒绝。这时候你别慌还有办法恢复。恢复的前提是至少有一个MON的数据目录是完好的或者能通过备份恢复。操作思路是“单节点强行拉起quorum”。具体步骤第一步确认存活节点挑一个数据最完整、日志显示最近还在正常工作的MON节点这个节点将成为恢复原点。第二步修改配置临时降级quorum要求# 在恢复节点上编辑ceph.conf临时加上 [mon] mon initial members 存活节点名 mon host 存活节点IP:6789这其实是告诉MON让这个节点作为唯一的初始成员。第三步重启MON进程systemctl restart ceph-monhostname此时由于monmap里其他节点不可用MON会尝试独占总quorum。过一会儿ceph -s应该能恢复响应但状态是异常的显示其他MON out of quorum。第四步清理或重建其余MON如果剩下两个节点只是进程挂了但数据没坏直接启动它们让它们重新同步monstore即可。如果数据损坏就要把对应节点的mon目录删掉然后用ceph-monstore-tool从存活节点重建数据再加入集群。这一部操作量很大建议在测试环境先演练一遍。这种恢复方式有一句忠告不到最后关头不要动单节点重建操作因为操作过程中任何一个细小的失误比如误删了唯一的monstore都会让整个集群陷入彻底不可恢复的状态。生产环境建议始终保留monstore的定期备份。4.4 monstore备份与修复ceph-monstore-tool实战ceph-monstore-tool是一个底层运维工具很多运维甚至不知道它存在。它的核心能力是读取、修改、打包MON节点本地的kv存储也就是monstore可以在MON离线时直接操作。备份monstore# 在线状态下也可以用ceph-monstore-tool导出但最稳妥的是停掉MON后再导出 ceph-monstore-tool /var/lib/ceph/mon/ceph-hostname dump /backup/monstore-$(date %F)导出后就是一个普通目录你可以tar打包。从备份重建monstorerm -rf /var/lib/ceph/mon/ceph-hostname mkdir -p /var/lib/ceph/mon/ceph-hostname ceph-monstore-tool /backup/monstore-2024-06-01 rebuild # 然后执行mkfs并导入这个工具最有价值的使用场景是当MON节点的kv存储出现损坏比如非正常关机后monstore里有些key读不出来MON进程一直在日志里报corruption错误时用备份做rebuild往往能救回来。需要注意ceph-monstore-tool操作的是本地文件系统不需要quorum所以适合在紧急情况下“脱离集群干活”。但正因为如此操作前务必做好原目录的完整备份否则一步错就可能把最后的救命稻草也烧了。5. 问题排查与实操心得下面把我实际工作中遇到的MON高频问题整理成一个速查表这些场景基本覆盖了日常告警的90%现象可能原因定位手段解决方案ceph -s提示mon.x is down (out of quorum)MON进程挂了/网络隔离/时钟漂移systemctl status ceph-monx、ceph quorum_status拉进程/修网络/同步时钟MON日志报clock skew节点间时间偏差超过mon_max_sync_skewtimedatectl status三节点对比配置NTP并重启chronydelection epoch快速增长MON之间网络抖动或反复超时ceph mon stat观察epoch变化排查网络、考虑切换election_strategyMON进程反复重启磁盘满、OOM、数据损坏df -h、journalctl -u ceph-mon清理磁盘/调内存/修复monstore客户端连不上MON防火墙挡了3300/6789mon host配置不一致nc -vz测试、检查ceph.conf放行端口/修正配置文件ceph -s卡住不返回MON不具备quorummonmap异常直接对每个MON执行status按4.3节恢复流程处理这里多提一句新版Ceph的MON默认同时监听v2协议3300端口和v1协议6789端口很多老文档只提6789导致新手配防火墙时只放行6789客户端配置里也只用v1:前缀。如果集群配置了v2客户端会优先尝试3300连不上才回退到6789这种“半通不通”的状态在日志里很难一眼看出来。在实际运维中我还摸索出几个比较实用的习惯一并分享每个MON节点都配置独立的监控脚本。脚本只要干两件事每30秒抓一次ceph quorum_status里的quorum_age以及每5分钟记录一次ceph mon stat里的election epoch。这两个指标一个反映稳定性一个反映选举频率集群若有不稳定苗头基本能第一时间发现。MON数据目录单独划盘。这个建议看似简单实践中能规避掉大量和磁盘满相关的故障。尤其是和系统日志、临时文件共享磁盘的情况随便一个日志风暴就能把目录挤爆。给monstore做定期备份。生产环境至少每天备份一次保存最近7份。恢复集群是最紧张的时刻这时候有一份可用的monstore备份心里完全不慌。6. 写在最后的几个小技巧Ceph MON的命令体系说大不大说小也不小但掌握了这些你已经能应对绝大部分日常和应急场景了。最后分享一个我自己的习惯每次操作MON节点之前都会先把当前ceph mon dump的输出保存一份。这个文件几十行而已但在你做完改动后做对比时非常有用——能立刻看出monmap哪里变了、epoch跳到多少了、哪个rank被动了。这个习惯看起来琐碎关键时刻却能救场。另外一个实用技巧是学会用ceph --admin-daemon去查询MON实时的内部状态。当集群quorum完全不可用时ceph -s是跑不了的但你对还在运行的MON进程执行ceph --admin-daemon /var/run/ceph/ceph-mon.hostname.asok mon_status这个命令不需要quorum能直接看到这个MON自己掌握的monmap、quorum信息和本机视角对判断“是网络隔离还是全局故障”很有帮助。Ceph MON命令的掌握程度几乎可以直接映射到你对Ceph集群的理解深度。多敲几遍、多读几遍输出慢慢你就会发现集群在你脑子里越来越透明。