6789 是什么
6789 是 Ceph 集群 MON（监视器）的默认端口，负责维护集群地图（monmap、OSDMap 等）与仲裁。新版本 Ceph 使用 msgr2 消息层，MON 同时监听 3300。MON 是集群的决策中枢：三台 MON 通常构成仲裁组，任何一次网络抖动都可能引发全集群卡顿。排查 ceph -s 卡住或超时，第一步就是确认所有 MON 的 6789 与 3300 是否都可达。
基本信息
| 服务 | Ceph Monitor（MON） |
|---|---|
| 协议 | TCP，传统 6789 与 msgr2 的 3300 |
| 用途 | 集群成员、地图与仲裁管理 |
| 安全等级 | 仅存储网段 |
| 依赖关系 | OSD 与客户端都依赖 MON 下发集群地图 |
典型使用场景
- 集群健康检查：ceph -s 卡住时先查 MON 连通性
- 扩容变更：新增 MON 后确认仲裁正常
- 网络规划：存储网与业务网隔离
- 版本升级：从传统消息层过渡到 msgr2 时端口双开
- 故障恢复：核对 MON 数量与仲裁状态
- 安全收敛：MON 端口不应暴露到业务网段
集群状态与端口核对
集群状态与端口核对
ceph mon stat # 查看仲裁状态与 MON 列表
ceph -s | head -20 # 集群总体状态
ss -lntp | grep -E '6789|3300' # 主机侧确认消息层端口
telnet mon01 6789 # 单点连通性验证相关端口与异常表现
| 端口 | 用途 | 异常表现 |
|---|---|---|
| 6789 | 传统消息层，兼容旧客户端 | 客户端与 OSD 无法获取集群地图 |
| 3300 | msgr2 消息层 | 新客户端连接失败 |
| 9283 | 集群指标导出（管理组件模块） | 监控缺口，不影响数据面 |
MON 数量与仲裁关系紧密：三台能容忍一台故障；偶数台并不会更安全，反而可能让仲裁陷入不确定状态。
MON 网络抖动会放大成全集群问题：客户端与 OSD 都依赖它下发地图，地图更新延迟会让整体变慢而不是直接报错。
存储网与业务网混跑时，业务高峰的延迟会直接传导到 MON 与 OSD 的通信上，这是性能问题的常见根因。
排查 MON 之前先保存一份当前集群状态输出：事件过后状态就会变化，缺少基线很难复盘。
集群上线后建议做一次 MON 故障演练：停掉一台 MON，确认仲裁仍正常、客户端无感知。演练记录要留档，真出问题时它就是最直接的参照。