Ceph 生产环境搭建 | 第 5 天：Manager 节点部署与模块启用

第 5/20 天 · Ceph 生产环境搭建系列

引言：Manager 在 Ceph 集群中的定位

在前四天的内容里，我们已经完成了 Ceph 架构选型、Ubuntu 系统调优、cephadm 引导初始化以及 Monitor 节点的高可用部署。一个 Ceph 集群的最小骨架（MON + 初步引导）已经就位，但此时集群还处于「只能维持一致性、无法对外提供完整管理能力」的状态。

Ceph Manager（ceph-mgr） 正是补齐这一能力的关键组件。它是一个与 Monitor 并肩运行的管理守护进程，负责：

对外暴露集群管理接口（Dashboard Web UI、Prometheus 指标、RESTful API）
实现高级调度能力（PG 自动均衡、PG 数量自动伸缩、设备健康巡检）
汇聚集群状态、告警、遥测信息

在 Squid v19 中，Manager 的模块体系更加成熟，Dashboard 的可视化能力已接近商业存储产品。本篇将围绕 Manager 节点的架构原理、高可用部署、核心模块启用与生产级配置 展开完整实战。

一、架构与原理：ceph-mgr 的工作机制

1.1 Active/Standby 模型

ceph-mgr 采用 主备（Active/Standby） 模型运行。在同一个集群中：

同一时刻只有一个 mgr 实例处于 Active 状态，负责处理所有模块的请求与后台任务。
其余 mgr 实例处于 Standby 状态，持续同步状态，一旦 Active 实例故障，会在数秒内完成 failover 切换。
Monitor 通过 MGRMAP 维护 mgr 实例列表并选举 Active 实例。

生产环境铁律：至少部署 2 个 mgr 实例，且分布在不同的故障域（不同物理机/机柜）。Squid 版本推荐「每个 MON 节点各部署一个 mgr」，实现 1:1 对应。

1.2 Manager 模块体系

Manager 的能力完全由其加载的模块（Module） 决定。模块分为两类：

类型	代表模块	说明
always-on 模块	balancer、crash、devicehealth、pg_autoscaler、status、iostat、progress	集群引导后默认启用，构成核心管理能力
可选模块	dashboard、prometheus、alerts、telemetry、nfs、rgw、restful	按需手动 enable，提供外部接口

1.3 数据流向与组件拓扑

💻 代码示例

┌─────────────────────────────────────┐

│ Monitor (Paxos) │

│ 维护 MGRMAP / OSDMAP / PG MAP │

└──────────────┬──────────────────────┘

│ 同步 map

┌──────────────▼──────────────────────┐

│ ceph-mgr (Active) │

│ ┌───────────┐ ┌────────────────┐ │

│ │ dashboard │ │ prometheus │ │── :9283/metrics ──► Prometheus Server

│ │ :8443 │ │ exporter │ │

│ └───────────┘ └────────────────┘ │

│ ┌───────────┐ ┌────────────────┐ │

│ │ balancer │ │ pg_autoscaler │ │

│ │ (upmap) │ │ (per-pool) │ │

│ └───────────┘ └────────────────┘ │

│ ┌────────────────────────────────┐ │

│ │ devicehealth / crash / alerts │ │

│ └────────────────────────────────┘ │

└──────────────┬──────────────────────┘

│ standby mgr 实时同步

┌──────────────▼──────────────────────┐

│ ceph-mgr (Standby) │

└─────────────────────────────────────┘

设计考量：
– mgr 不参与数据 IO 路径，即使 mgr 全部宕机，OSD 间的客户端读写仍可正常进行（前提是 MON 存活）。
– 但 mgr 宕机会导致 Dashboard、指标采集、PG 自动均衡等管理功能中断，因此必须保证高可用。
– mgr 通过 mgr_module_path 加载模块代码，每个模块独立运行在 mgr 进程内的协程中，模块异常不会拖垮整个 mgr。

二、部署实战：Manager 节点高可用与模块启用

2.1 环境准备

承接第 4 天的 5 节点 MON 集群（ceph-node01 ~ ceph-node05，Ubuntu 24.04 LTS，Ceph Squid v19），我们将 mgr 与 MON 同机部署。首先确认当前 mgr 状态：

💻 代码示例

# 查看 mgr 选举状态与活跃实例

ceph mgr stat

# 查看所有 mgr 实例（含 standby）

ceph mgr dump | jq '.available_mgrs, .active_name'

# 列出已加载模块

ceph mgr module ls

典型输出示例（ceph mgr stat）：

💻 代码示例

{

"epoch": 12,

"available": true,

"active_name": "ceph-node01",

"num_standby": 1

}

2.2 通过 cephadm 部署 mgr 实例

cephadm 在引导时会自动在第一个 MON 节点部署一个 mgr 实例。为满足生产高可用要求，我们显式指定 mgr 与 mon 同机部署在全部 5 个节点：

💻 代码示例

# 方式一：spec 文件统一管理（推荐生产做法）

cat > /tmp/mgr-spec.yaml << 'EOF'

service_type: mgr

placement:

host_pattern: "ceph-node0[1-5]"

EOF

ceph orch apply -i /tmp/mgr-spec.yaml

# 方式二：命令行直接指定

ceph orch apply mgr "ceph-node01,ceph-node02,ceph-node03"

验证部署结果：

💻 代码示例

# 查看守护进程清单

ceph orch ps –service-type mgr

# 确认 active/standby 关系

ceph mgr stat

预期输出应显示 5 个 mgr 守护进程，其中 1 个 active、4 个 standby。

2.3 启用并配置 Dashboard 模块

Dashboard 是 Squid 版本最具价值的管理模块，提供集群拓扑、OSD 状态、Pool 管理、RGW/CephFS 可视化等能力。

💻 代码示例

# 1. 禁用 dashboard（先关后配，避免配置过程中暴露未加密端口）

ceph mgr module disable dashboard

# 2. 生成自签名证书（生产环境应替换为正规 CA 证书）

ceph dashboard create-self-signed-cert

# 3. 创建管理员账户（密码需满足复杂度要求）

ceph dashboard ac-user-create admin -i <(echo 'CephAdmin@2026!') administrator

# 4. 配置监听端口与绑定地址

ceph config set mgr mgr/dashboard/ssl true

ceph config set mgr mgr/dashboard/server_port 8443

ceph config set mgr mgr/dashboard/server_addr 0.0.0.0

# 5. 启用 dashboard 模块

ceph mgr module enable dashboard

# 6. 查看访问入口

ceph mgr services

ceph mgr services 输出示例：

💻 代码示例

{

"dashboard": "https://ceph-node01:8443/",

"prometheus": "http://ceph-node01:9283/"

}

2.4 启用 Prometheus 指标导出

Prometheus 模块将集群指标以 OpenMetrics 格式导出，是后续接入 Grafana 监控的基础（第 15 天详解）。

💻 代码示例

# 启用 prometheus 模块

ceph mgr module enable prometheus

# 配置采集间隔（默认 15s，生产环境建议保持）

ceph config set mgr mgr/prometheus/scrape_interval 15

# 关闭高基数标签（避免指标爆炸，重要生产参数）

ceph config set mgr mgr/prometheus/exclude_perf_counters false

# 验证指标端点

curl -s http://ceph-node01:9283/metrics | head -20

2.5 启用其他核心模块

💻 代码示例

# balancer：使用 upmap 模式实现精细化 PG 均衡（生产首选）

ceph balancer mode upmap

ceph balancer on

# pg_autoscaler：自动调整每个 pool 的 PG 数量

ceph mgr module enable pg_autoscaler

# devicehealth：OSD 磁盘 SMART 健康巡检

ceph mgr module enable devicehealth

ceph config set mgr mgr/devicehealth/scrape_frequency 3600

# crash：收集并归集守护进程 crash dump

ceph mgr module enable crash

# alerts：基于 health check 生成告警（可对接 SNMP/Prometheus alertmanager）

ceph mgr module enable alerts

2.6 一键验证全部模块状态

💻 代码示例

# 模块启用状态总览

ceph mgr module ls | jq '.enabled_modules, .disabled_modules'

# 集群健康与 mgr 状态联合检查

ceph status

ceph mgr stat

ceph health detail

三、核心配置参数详解

配置项	默认值	说明	生产建议
`mgr/dashboard/ssl`	true	是否启用 HTTPS	生产必须 true
`mgr/dashboard/server_port`	8443	Dashboard 监听端口	保持 8443，前方加反代
`mgr/dashboard/crt` / `key`	–	自定义 TLS 证书路径	生产环境使用正规 CA 证书
`mgr/prometheus/scrape_interval`	15	指标采集间隔（秒）	15~30，过低会增大 mgr 压力
`mgr/balancer/mode`	none	PG 均衡模式	生产用 `upmap`，迁移平滑
`mgr/pg_autoscaler/pg_num_min`	1	自动 PG 下限	大池设为 32，防止过小
`mgr/devicehealth/scrape_frequency`	3600	SMART 巡检间隔（秒）	3600~86400
`mgr/telemetry/enabled`	false	遥测上报	涉敏环境必须关闭
`mgr/dashboard/rgw_api_*`	–	Dashboard 对接 RGW 凭据	启用 RGW 后必配
`mgr/cache_size`	自动	mgr 内存缓存大小	大集群可适当上调

upmap balancer 与 pg_autoscaler 协同

生产环境推荐组合：balancer mode upmap + pg_autoscaler on。

balancer 通过 ceph-osd 的 upmap 权限微调 PG 映射，迁移量极小、对业务几乎无感知。
pg_autoscaler 则在创建 pool 时根据容量自动计算 pg_num，避免人工估算错误。
但两者同时运作时要注意：autoscaler 触发 PG 分裂会与 balancer 的 upmap 请求叠加，建议在扩容窗口集中操作，平时用 ceph balancer pause 暂停。

四、生产环境注意事项与踩坑提示

4.1 mgr 高可用必须跨故障域

踩坑：若所有 mgr 都部署在同一台机器或同一机柜，该节点故障将导致全部管理功能中断。虽然数据 IO 不受影响，但监控告警、Dashboard 全部失明，排障将极其被动。

正确做法：mgr 的 host_pattern 必须跨机柜分布，至少保证 2 个 mgr 位于不同物理故障域。

4.2 Dashboard 证书与端口暴露

自签名证书仅适合内部测试，生产环境必须使用受信任 CA 签发的证书，可通过 ceph dashboard set-ssl-certificate 导入。
Dashboard 端口 不应直接暴露到公网。建议在前面部署 Nginx/Caddy 反向代理，叠加 IP 白名单与 SSO 认证。
admin 账户密码需纳入密钥管理流程，定期轮换。

4.3 Prometheus 指标基数爆炸

踩坑：Squid 版本默认导出大量 per-OSD、per-PG 的性能计数器，在 100+ OSD 的大集群中，单次 scrape 可能产生数十万个时间序列，导致 Prometheus 内存暴涨甚至 OOM。

解决：

💻 代码示例

# 关闭高频 perf 计数器导出

ceph config set mgr mgr/prometheus/exclude_perf_counters true

# 仅保留核心指标

ceph config set mgr mgr/prometheus/enable_host_metadata true

4.4 pg_autoscaler 的「误伤」

pg_autoscaler 在 pool 创建后会根据 target_size_ratio 自动调整 PG 数量。踩坑：若创建 pool 时未指定预期容量，autoscaler 可能将 pg_num 设为极小值（如 1），导致 PG 过载、性能骤降。

正确做法：每个 pool 创建时务必声明 pg_num_min 与 target_size_ratio：

💻 代码示例

ceph osd pool create mypool 32 –autoscale-mode on

ceph osd pool set mypool pg_num_min 32

ceph osd pool set mypool target_size_ratio 0.1

4.5 模块内存占用

每个 always-on 模块都会占用 mgr 进程内存。在大规模集群（200+ OSD）中，devicehealth、balancer 模块可能使 mgr 内存升至 2~4GB。建议在 systemd 或 cephadm 层面对 mgr 容器设置内存上限，并预留充足内存。

五、常见问题 FAQ

Q1：mgr 全部宕机，客户端读写会中断吗？

不会。 ceph-mgr 不在数据 IO 路径上。只要 Monitor 存活且 OSD 正常运行，客户端的 RBD/CephFS/RGW 读写可继续。但 Dashboard、Prometheus 指标、PG 自动均衡等管理功能会中断，应尽快恢复 mgr。

Q2：Dashboard 登录后显示「Cluster is in error state」怎么办？

通常是后台 health check 触发的告警（如 HEALTH_WARN、PG 降级等）。Dashboard 只是在展示集群真实状态，应优先用 ceph health detail 定位根因并修复，Dashboard 警告会自动消除。切忌在 Dashboard 上直接「静默（silence）」告警而忽略底层问题。

Q3：如何强制切换 Active mgr 实例进行 failover 演练？

💻 代码示例

# 查看当前 active

ceph mgr stat

# 在 standby 所在节点手动重启该节点的 mgr 守护进程，触发重新选举

ceph orch restart mgr –host ceph-node02

# 或直接禁用当前 active 上的模块，强制 failover

ceph mgr fail

演练建议在业务低峰期进行，观察 failover 耗时（通常 < 10 秒）及 Dashboard 是否自动恢复。

六、总结

本篇完成了 Ceph Manager 节点的生产级部署：

架构层面：理解了 Active/Standby 模型、模块体系与数据流向，明确 mgr 不在 IO 路径但承载全部管理能力。
部署层面：通过 cephadm spec 实现了 5 节点 mgr 高可用，启用了 dashboard、prometheus、balancer、pg_autoscaler、devicehealth 等核心模块。
配置层面：掌握了 SSL 证书、指标采集、PG 均衡等关键参数的生产取值。
踩坑层面：规避了 mgr 单点、指标基数爆炸、pg_autoscaler 误伤等典型生产陷阱。

至此，集群已具备「看得见、管得住」的能力，为后续 OSD 存储节点部署打好了管理基座。