KubeVirt 生態系分析

Appearance

Ceph — Manager (MGR) 與模組系統 ​

核心定位

Ceph Manager（MGR）是 Ceph 在 MON 之外補上的「觀測、擴充與對外整合層」。它不負責 Paxos 仲裁，也不直接保存 object 資料，而是聚焦在 metrics、模組化擴充、REST API 與外部編排整合。

相關章節

MGR 的角色：指標蒐集、REST API、編排整合 ​

MGR 可以視為一個「站在控制平面旁邊的營運層 daemon」，主要負責：

  • 蒐集 OSD、MDS、MON 等 daemon 的統計與健康資訊
  • 對外提供模組化介面
  • 暴露 dashboard / REST API / Prometheus exporter
  • 承接 cephadm 等編排整合能力

與 MON 相比，MGR 更像是 operations hub，而不是共識核心。

DaemonServer：接收 OSD / MDS 回報的入口 ​

src/mgr/DaemonServer.h 中可以看到：

cpp
// 檔案: ceph/src/mgr/DaemonServer.h
class DaemonServer : public Dispatcher, public md_config_obs_t

這個類別的職責很關鍵：它負責接收來自各類 daemon 的報告，並把資訊送進 MGR 內部狀態管理。從名稱就能看出它像是 MGR 的前門：

  • OSD 回報效能與健康資料
  • MDS 回報 CephFS metadata 相關統計
  • 其他 daemon 回報事件、命令結果或狀態變更

ClusterState 則扮演本地快取與聚合層角色，將來自各 daemon 的觀測資訊整理成 MGR 可供模組使用的叢集視圖。

Active vs Standby MGR ​

MGR 採用 active / standby 模式：

  • Active MGR：實際載入模組、處理報告、提供 dashboard / exporter 等服務。
  • Standby MGR：待命節點，通常維持基本同步狀態，當 active 故障時接手。

在 src/mgr/ActivePyModules.h 可以看到大量與 active beacon、模組啟動完成、通知模組有關的介面，代表「哪個 MGR 真正對外工作」是被明確管理的，而不是所有 MGR 同時對外提供相同功能。

與 MON 的差異

MON 的 leader / quorum 是強一致控制平面的一部分；MGR 的 active / standby 則較偏向高可用服務切換。兩者都會選主，但責任與一致性要求不同。

Python 模組系統：MGR 最有特色的部分 ​

Ceph MGR 的一大特色是 Python 模組系統。ActivePyModules 與 mgr_module.py 是理解這一層的關鍵入口。

cpp
// 檔案: ceph/src/mgr/ActivePyModules.h
class ActivePyModules
python
# 檔案: ceph/src/pybind/mgr/mgr_module.py
class MgrModule(object):

這表示 Ceph 不是把所有營運功能都寫死在 C++ 裡，而是提供一個 C++ core + Python extension model：

  • C++ 層：維護 daemon 通訊、叢集狀態與模組執行框架
  • Python 層：以較高開發效率快速擴充營運功能

src/pybind/mgr/ 中的重要模組 ​

根據原始碼目錄，可直接看到多個常用模組：

  • dashboard
  • prometheus
  • cephadm
  • balancer
  • crash
  • alerts

這些模組大致各自扮演：

模組角色
dashboardWeb UI 與 REST API 入口
prometheus暴露 Prometheus 可抓取的 metrics
cephadm容器化部署與編排整合
balancer根據叢集分布狀態提出或套用平衡策略
crash收集與管理 crash 報告
alerts整理告警與通知相關能力

REST API 與 dashboard 模組 ​

Ceph 的 REST API 並不是由核心 C++ daemon 直接硬編碼提供，而是高度依賴 dashboard 模組。這種做法的好處是：

  • UI 與 API 可以獨立演進
  • 不需把所有 HTTP 邏輯混進核心 daemon
  • 權限控管與業務流程能在模組層快速迭代

對使用者來說，常見的體驗是「透過 dashboard 跟 Ceph 互動」；對程式架構來說，實際上是「MGR 載入 dashboard 模組，由其實作對外介面」。

ClusterState：模組可見的叢集快照 ​

src/mgr/ClusterState.h / .cc 負責整理叢集中的 daemon 資訊、狀態與快取，使得 Python 模組不需要直接和每個 OSD / MDS 線上對話，而是透過 MGR 聚合後的視圖做決策。

這種設計有兩個重要效果：

  1. 降低模組複雜度：模組作者不必自己重建整個 daemon 訊息流。
  2. 統一觀測來源：dashboard、prometheus、alerts 等模組可共享同一份叢集狀態基底。

MGR 模組系統的整體資料流 ​

text
// 檔案: docs-site/ceph/manager.md
OSD / MDS / MON 報告
        |
        v
+-------------------+
|   DaemonServer    |
+-------------------+
        |
        v
+-------------------+
|   ClusterState    |
+-------------------+
        |
        v
+-------------------+
| ActivePyModules   |
+-------------------+
   |      |      |
   v      v      v
dashboard prometheus cephadm ...

這個資料流顯示 MGR 的價值不是單純「又一個 daemon」，而是把叢集觀測資料轉化成可擴充功能的平台。

為什麼 Ceph 把這些能力放進 MGR ​

如果把指標、告警、REST API、編排整合全部塞進 MON：

  • 會讓共識核心過度膨脹
  • 功能迭代速度受限於核心控制平面
  • Python 這種高生產力擴充路徑會很難導入

把這些能力移到 MGR 後，Ceph 就能把架構分層得更乾淨：

  • MON：一致性與 cluster maps
  • OSD：資料儲存與複寫
  • MDS：CephFS metadata
  • MGR：觀測、API、營運與整合

關鍵原始碼索引 ​

  • ceph/src/mgr/DaemonServer.h — class DaemonServer
  • ceph/src/mgr/ActivePyModules.h — active Python 模組框架
  • ceph/src/mgr/ClusterState.cc / ceph/src/mgr/ClusterState.h — 叢集狀態聚合
  • ceph/src/pybind/mgr/mgr_module.py — Python 模組基底

MGR 的部署與安裝 ​

Bootstrap 階段：第一個 MGR 如何建立 ​

執行 cephadm bootstrap 時，流程會在第一台主機上同時建立初始 MON 與 MGR：

bash
cephadm bootstrap --mon-ip 192.168.1.10

Bootstrap 完成後，叢集會有一個 active MGR。Dashboard、Prometheus exporter 等功能此時就已可以使用。

擴增 MGR：建立 Active/Standby 配置 ​

實務上建議部署 2 個 MGR 以提供高可用性。可用 ceph orch 指定數量：

bash
# 讓 cephadm 在合適的 host 上自動部署共 2 個 MGR
ceph orch apply mgr --placement="count:2"

# 或明確指定跑在哪幾台 host
ceph orch apply mgr --placement="node1,node2"

也可以用 YAML spec：

yaml
# mgr-spec.yaml
service_type: mgr
placement:
  hosts:
    - node1
    - node2
bash
ceph orch apply -i mgr-spec.yaml

Active/Standby 切換

只有一個 MGR 處於 active 狀態，其餘都是 standby。當 active MGR 發生故障，standby 會自動接手，通常在數秒內完成切換，不需要手動介入。

驗證 MGR 狀態 ​

bash
# 查看目前 active MGR 與 standby 狀態
ceph mgr stat

# 查看 MGR daemon 清單
ceph orch ps --daemon-type mgr

# 查看整體健康（含 MGR 相關 health check）
ceph health detail

管理 MGR 模組 ​

MGR 的功能很大程度依賴 Python 模組。常用的模組管理指令：

bash
# 查看已啟用與可啟用的模組清單
ceph mgr module ls

# 啟用特定模組（例如 prometheus exporter）
ceph mgr module enable prometheus

# 停用特定模組
ceph mgr module disable <module-name>

常見需要手動啟用的模組包括：

模組功能
prometheus暴露 Prometheus 可抓取的 metrics
dashboardWeb UI 與 REST API（bootstrap 時通常已啟用）
balancer自動平衡 PG 分布
alerts叢集健康告警整合
rbd_supportRBD 相關擴充操作支援

手動觸發 Active MGR 切換 ​

如果需要讓 standby 接手（例如維護 active 所在節點）：

bash
# 強制讓 active MGR 下線，觸發切換
ceph mgr fail <active-mgr-name>

切換後，原本的 standby 會升為 active。完成維護後，原 MGR daemon 重新上線時會自動變回 standby。

相關章節 ​

延伸閱讀

基於 Apache 2.0 授權

KubeVirt 生態系原始碼分析 — 為工程師而生