Ceph 各组件端口使用分析
一、基础信息
本文总结了 Ceph 集群及其监控组件的关键端口信息。 Ceph 核心服务（MON、MGR、OSD、MDS）主要监听 6789 、 3300 及 6800-7568 范围内的端口，用于集群通信与管理。其中， MON 使用 6789 （旧协议）和 3300 （新协议）端口； MGR 额外监听 9283 （Prometheus指标）、 8080/8443 （Dashboard）及 8765 （Agent） 等端口。 OSD 在 6800-7568 范围内使用八个端口处理不同通信类型。此外，监控栈组件（如node-exporter的 9100 、 prometheus 的 9095 、 alertmanager 的 9093/9094 、grafana 的 3000 ）也列出了默认端口及修改方法。文中还提供了查看服务状态和修改端口配置的相关命令。
注意: 以下的分析基于 Ceph V20.2.0
相关命令:
|
二、端口使用情况
| 组件 | 端口 | 端口简介 |
|---|---|---|
| mon | 6789 | 处理旧版（TYPE_LEGACY）协议的监听端口。 |
| mon | 3300 | 处理新版（TYPE_MSGR2）协议的监听端口，已在IANA注册。 |
| mgr | 6800-7568 (2个) | Active mgr用于集群内部通信的随机端口。 |
| mgr | 9283 | Prometheus模块端口，暴露集群监控指标。 |
| mgr | 8080 / 8443 | Dashboard面板的HTTP/HTTPS访问端口。 |
| mgr | 7150-7300 (1个) | Cephadm Agent的HTTP/HTTPS服务端口（开发中）。 |
| mgr | 8765 | Cephadm Agent默认端口，用于接收mgr指令（开发中）。 |
| osd | 6800-7568 (8个) | 用于公共服务、集群通信、前后端心跳的四个通信实例，各占2个端口。 |
| mds | 6800-7568 (2个) | 元数据服务用于通信的随机端口。 |
| ceph-exporter | 9926 (默认) | 暴露Prometheus格式的Ceph监控指标。 |
| node-exporter | 9100 (默认) | 暴露主机节点的监控指标。 |
| prometheus | 9095 (默认) | Prometheus Web服务与数据检索端口。 |
| alertmanager | 9093 (默认) | Alertmanager Web访问与API端口。 |
| alertmanager | 9094 (默认) | 多实例集群间的通信与状态同步端口。 |
| grafana | 3000 (默认) | Grafana监控面板的Web访问端口。 |
2.1、MON 端口情况
监听端口:
6789:- 处理 TYPE_LEGACY 协议的监听端口；
- 对应变量为 CEPH_MON_PORT_LEGACY；
- 端口监听执行链路为 main -> make_mon_addrs -> AsyncMessenger::bindv ；
3300:- 处理 TYPE_MSGR2 协议的监听端口，该端口已经在 IANA 注册；
- 对应变量为 CEPH_MON_PORT_IANA；
- 端口监听执行链路为 main -> make_mon_addrs -> AsyncMessenger::bindv ；
相关配置:
- public_addr: 外网可访问的 ip 地址；
- public_bind_addr : 监听绑定的 ip 地址；
| 类别 | 示例 Monitor A | 示例 Monitor B | 作用 | 存储位置 |
|---|---|---|---|---|
| public_addr | 203.0.113.1:6789 | 203.0.113.2:6789 | 对外公布的逻辑地址 | monmap、消息头 |
| public_bind_addr | 192.168.1.1:6789 | 10.0.1.1:6789 | 实际绑定的物理地址 | socket绑定 |
| NAT映射 | 203.0.113.1 → 192.168.1.1 | 203.0.113.2 → 10.0.1.1 | 网络地址转换 | 路由器配置 |
| 客户端看到 | 203.0.113.1:6789 | 203.0.113.2:6789 | 连接目标地址 | 客户端 monmap |
2.2、MGR 端口情况
监听端口:
6800 ~ 7568 范围内的两个端口:- 只有 active 的 mgr 才会在这个端口范围内选择两个端口执行监听；
- 端口监听执行链路:
- 收到 mgr_map 更新消息: MgrStandby::handle_mgr_map -> 判断当前 mgr 为 active 后执行 Mgr::background_init -> 向 finisher 队列中添加 Mgr::init 函数
- finisher 线程执行任务: Finisher::finisher_thread_entry -> Mgr::init -> DaemonServer::init -> AsyncMessenger::bindv -> Processor::bind
9283:- 这是 mgr 服务中的 prometheus 模块的监听端口，用于将 Ceph 集群的监控指标暴露给 Prometheus 监控系统；
- 可以直接访问对应 ip:9283 来查看对应的 node exporter 的指标数据；
- 无论是 active 还是 standby 的 mgr 服务，启动后都会监听该端口；
- 端口监听执行链路:
- 对于 active 节点:
- 收到 mgr_map 更新消息: MgrStandby::handle_mgr_map -> 判断当前 mgr 为 active 后执行 Mgr::background_init -> 向 finisher 队列中添加 Mgr::init 函数
- finisher 线程执行任务: Mgr::init -> PyModuleRegistry::active_start -> 执行 ActivePyModules::start_one -> -> 加入 finisher 线程延迟创建 module 线程服务
- 对于 standby 节点:
- 收到 mgr_map 更新消息: MgrStandby::handle_mgr_map -> PyModuleRegistry::standby_start -> 筛选 mgr 中含有 MgrStandbyModule 基类的模块后执行 StandbyPyModules::start_one -> 加入 finisher 线程延迟创建 module 线程服务
- 对于 active 节点:
8080或8443:8080是 dashboard 面板不使用 ssl 的默认监听端口；8443是 dashboard 面板使用 ssl 的默认监听端口；- 无论是 active 还是 standby 的 mgr 服务，启动后都会监听该端口中一个，使用了 ssl 的端口就无法使用非 ssl 的端口；
- 端口监听执行链路: 与
9283端口的监听执行链路相同；
7150 ~ 7300 范围内的一个端口:- 这是 cephadm agent 的 http/https 服务端口，用于接收来自 mgr 的指令和配置更新；
- 使用 CherryPy 作为服务器提供服务；
- 主要处理两个路径的请求，/data 路径处理主机元数据上报， /node-proxy 路径处理节点代理相关功能；
- 按照官方的解释，该功能处于开发中的状态，https://docs.ceph.com/en/latest/cephadm/compatibility/ ；
- 只有 active 的 mgr 才会监听该端口；
- 端口监听执行链路: 和其他 active mgr 的模块的流程一致；
8765:- 这是 cephadm agent 在集群节点上运行的默认监听端口，接收来自 mgr 的推送配置，还在 prometheus 容器的配置文件中使用，用于拉取集群的配置信息；
- 可以访问 http://10.1.1.10:8765/sd/ 查看支持的接口列表；
- 按照官方的解释，该功能处于开发中的状态，https://docs.ceph.com/en/latest/cephadm/compatibility/ ；
- 只有 active 的 mgr 才会监听该端口；
- 端口监听执行链路: 和其他 active mgr 的模块的流程一致；
相关配置:
- ms_bind_port_min: 定义了 Ceph 相关服务进程端口池的起始端口号，默认为
6800； - ms_bind_port_max : 定义了 Ceph 相关服务进程端口池的结束端口号，默认为
7568；
相关命令:
|
相关日志:
|
2.3、OSD 端口情况
监听端口:
6800 ~ 7568 范围内的八个端口:- 这八个端口分别给 ms_public、ms_cluster、ms_hb_front_server、ms_hb_back_server 这四个不同的 messenger 实例，每个实例两个端口（TYPE_LEGACY/TYPE_MSGR2），用于处理不同类型的网络通信；
- ms_public: 处理来自客户端的请求（如 rados 客户端、rbd、cephfs 客户端等）；
- ms_cluster: 处理 osd 之间的集群内部通信，处理 pg 相关的复制、恢复、再平衡等操作，处理 mon 的集群管理通信；
- ms_hb_front_server: 接收来自其他 osd 的前端心跳探测，用于检测 osd 的公共服务是否可达；
- ms_hb_back_server: 接收来自其他 osd 的后端心跳探测，用于检测 osd 的集群服务是否可达；
- 端口监听执行链路:
- 以上四个 messgnger 实例的绑定链路相同: main -> AsyncMessenger::bindv -> Processor::bind -> set_port ；
- 这八个端口分别给 ms_public、ms_cluster、ms_hb_front_server、ms_hb_back_server 这四个不同的 messenger 实例，每个实例两个端口（TYPE_LEGACY/TYPE_MSGR2），用于处理不同类型的网络通信；
相关配置:
- ms_bind_port_min: 定义了 Ceph 相关服务进程端口池的起始端口号，默认为
6800； - ms_bind_port_max : 定义了 Ceph 相关服务进程端口池的结束端口号，默认为
7568；
相关日志:
|
2.4、MDS 端口情况
监听端口:
6800 ~ 7568 范围内的两个端口:- 无论 mds 处于 active 还是 standby 都会监听这两个端口；
- 端口监听执行链路: main -> AsyncMessenger::bindv -> Processor::bind -> set_port ；
相关配置:
- ms_bind_port_min: 定义了 Ceph 相关服务进程端口池的起始端口号，默认为
6800； - ms_bind_port_max : 定义了 Ceph 相关服务进程端口池的结束端口号，默认为
7568；
相关日志:
|
2.5、ceph-exporter 端口情况
监听端口:
9926:- 当使用 cephadm 部署服务的时候，默认会部署一个 ceph-exporter 的服务，该服务默认监听 9926 端口，并对外暴露 prometheus exporter 格式的监控指标数据；
- 该服务的入口文件为: src/exporter/ceph_exporter.cc ；
- 端口监听执行链路: main -> web_server_thread_entrypoint -> run_http_server -> http_server ；
相关配置:
- exporter_http_port: 定义了 ceph-exporter 服务进程的监听端口号，默认为
9926； - exporter_addr: 定义了 ceph-exporter 服务进程的监听地址，默认为 0.0.0.0 ；
相关命令:
|
2.5.1、修改端口
修改已部署服务端口:
|
2.6、node-exporter 端口情况
监听端口:
9100:- 部署社区 node-exporter 镜像来获取机器节点粒度的监控指标数据；
- 所有的 server 机器上都应该部署该服务；
2.6.1、修改端口
注意: 实际测试的时候，修改已部署服务的端口操作可以执行，但是最终 node-exporter 监听的端口还是 9100 , 应该是实际没有设置。
修改已部署服务端口:
|
2.7、prometheus 端口情况
监听端口:
9095:- 提供 prometheus 的 web 访问服务，并为 grafana 服务提供监控数据检索等功能；
- 该服务内部配置了 9283, 9926, 9100 这些 exporter 的地址，用于采集监控指标数据；
- 只需要在一个 server 节点上部署即可，如果在每个 server 节点上部署则会相当于会在每台机器上都存储一份监控指标数据；
2.7.1、修改端口
修改已部署服务端口:
|
2.8、alertmanager 端口情况
监听端口:
9093:- 提供 alertmanager 的 web 端访问服务，可用于查看报警信息，执行报警静默等操作；
- 提供 api 服务，可用于查询告警信息，创建/管理静默规则，接收来自 prometheus 的告警推送等；
9094:- 集群通信端口，如果配置了多个 alertmanager 服务，则在其内部集群中，多个实例通过此端口进行通信，实现状态同步，领导选举，告警去重和协调等；
- 如果只是部署了一个单节点的 alertmanager 节点，该端口则不会使用，但是仍然会监听；
2.8.1、修改端口
修改已部署服务端口:
|
2.9、grafana 端口情况
监听端口:
3000:- 提供 grafana 的监控面板访问服务；
- 通常只部署一个节点即可；
2.9.1、修改端口
修改已部署服务的端口:
|
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 咕咕！
相关推荐
2023-05-01
Ceph 常用命令汇总
一、常用命令1.1、Pool# 查看 poolceph osd pool ls detail# 创建 poolceph osd pool create testpool 32 32ceph osd pool set testpool pg_autoscale_mode off# 调整 pool pg/pgp , 并关闭自动调整ceph osd pool set testpool pg_num 32ceph osd pool set testpool pgp_num 32ceph osd pool set testpool pg_autoscale_mode off# 设置 pool 最小副本ceph osd pool set testpool min_size 1ceph osd pool set testpool size 1 --yes-i-really-mean-it# 移除 poolceph tell mon.\* injectargs '--mon-allow-pool-delete=true'ceph osd pool delete testpoo...
2025-08-09
CephFS Inode 编号的申请与释放
一、Inode 编号介绍1.1、编号规则在 CephFS 中 MDS 负责管理所有的 Inode 信息。CephFS 本身支持 多MDS 策略，为了避免多MDS 分配的 Inode 出现冲突，所以 MDS 在分配 Inode 的时候需要使用 RankID 来区分 Inode 的范围。每个 MDS 中限制 Inode 分配范围的函数为 InoTable::reset_state ，每个 MDS 中负责的 Inode 范围为：[(rank+1) << 40, ((rank+1) << 40)) ，即从 (rank+1) << 40 开始的连续 1 << 40 个 Inode 。 MDSRank 起始Inode编号(十进制) 起始Inode编号(十六进制) 结束Inode编号(十六进制) 管辖的Inode数量 0 1,099,511,627,776 0x10000000000 0x1FFFFFFFFF 1,099,511,627,776 1 2,199,023,255,552 0x20000000000 0x2FFFFFF...
2025-01-12
Ceph Crimson 集群部署教程
当前 ceph 集群搭建部署的方式主要有三种: ceph-ansible, vstart.sh 和 cephadm 。 其中 vstart.sh 脚本用于在开发环境中快速搭建测试集群。 ceph-ansible 是之前推荐的部署 ceph 集群的方式，支持在直接在宿主机上部署或者通过容器部署的方式，目前社区已不推荐使用。 cephadm 是当前最新的支持部署生产集群的方式，仅支持容器部署。接下来主要介绍通过 vstart.sh 和 cephadm 部署 crimson 集群的方式。 一、vstart.sh 搭建集群通过这种方式部署的时候理论上对于 Ceph 版本没有特殊的要求，本文中使用的版本为 v19.2.1 。 vstart.sh 常用于在开发环境环境中快速搭建集群，且在部署集群前我们需要编译出对应的二进制包。由于编译环境可能会有各种依赖缺失，版本异常等问题，这里推荐使用 bugwz/ceph-images 中提供的 CentOS Stream 9 的编译打包环境。同时后续的集群的搭建也可以在容器内部进行。 搭建集群操作步骤如下: 软件编译: 使用开发容器镜像，编...
2023-06-20
译 - CRUSH: Controlled, Scalable, Decentralized Placement of Replicated Data
译作: 可控的、可扩展的、分布式的副本数据放置算法，论文原文 。 该论文于 2006 年 11 月发布于 SC2006 。 CRUSH 是一种用于大规模分布式存储系统的数据分布算法，它通过伪随机函数将数据对象映射到存储设备上，无需依赖中央目录。CRUSH 算法设计考虑了系统的动态性，支持在添加或移除存储设备时高效地重组数据，并最小化不必要的数据移动。此外，CRUSH 支持多种数据复制和可靠性机制，并允许根据用户定义的策略进行数据分布，这些策略能够在故障域之间有效地分离副本，增强数据安全性。 CRUSH 的核心是其层级集群图，该图描述了存储集群的物理和逻辑结构，并通过一系列规则来确定数据的放置位置。CRUSH 算法通过将数据均匀分布在加权设备上，保持存储和设备带宽资源的平衡利用。算法还考虑了设备的故障和过载情况，能够在设备发生故障或过载时重新分配数据，避免数据丢失并优化系统性能。 CRUSH 的映射性能高效，计算复杂度为 O(logn) ，适用于管理大规模（多 PB 级）的存储系统。CRUSH的设计不仅提高了系统的可扩展性和性能，还通过智能的数据分布策略提高了系统的可靠性和数据...
2023-06-01
Ceph 集群性能测试工具详解
本文详细介绍了包括 rados bench、rbd bench、dd 、fio 、vdbench 、mdtest 、iozone、cosbench、cbt 等测试工具对于 Ceph 集群的性能压测的使用。对于每个工具都提供了压测命令参数、示例命令等使用说明，实现了对 Ceph 块存储、文件存储、对象存储、rados 对象存储等存储类别的性能压测。文中重点阐述了各命令的使用格式、基本功能和参数选择，为用户在 Ceph 环境中进行性能评估提供了实用指南。 一、rados bench以下基于 v19.2.1 版本进行测试。 用途: 测试 ceph rados 对象存储性能； 1.1、测试配置参数命令格式: rados bench $seconds $type [args...] $seconds : 压测运行时间； $type : 压测类型，可选值为 write/seq/rand （分别代表写/连续读/随机读）； -p : 指定压测的目标 pool ； -b : 只有当压测类型为 write 时可用，用于设置写入 block 的大小，默认为...
2023-04-12
ceph-ansible 集群部署运维指南
本文详细介绍了使用 ceph-ansible 部署和运维 Ceph 集群的过程，包括各版本及其依赖的 Ansible 版本的对应关系、自定义模块与任务的结构、集群部署、运维操作及相关示例。特别强调了环境配置、节点连通性验证、MDS 和 OSD 组件的管理，以及安全和性能优化注意事项。 一、项目介绍以下分析基于 ceph-ansible stable-6.0 分支代码。 1.1、版本与对应关系目前 ceph-ansible 采用不同的代码分支来支持部署不同版本的 ceph 集群，且每个代码分支需要特定的 ansible 版本支持，具体的对应关系如下（以下对应关系更新于 2025/05/23 ）： ceph-ansible 分支 支持的 ceph 版本 依赖的 ansible 核心版本 依赖的 ansible 发布版本包 stable-3.0 Jewel(V10), Luminous(V12) 2.4 - stable-3.1 Luminous(V12), Mimic(V13) 2.4 - stable-3.2 Luminous(V12), M...
评论
