Manager placement and redundancy

Why this matters in production

The manager handles a great deal that is invisible until it stops: metrics, the dashboard, the orchestrator, and several Ceph operations.

What the manager does

ceph mgr module ls | python3 -c '
import sys,json; d=json.load(sys.stdin)
print("enabled:", d["enabled_modules"])'

Client I/O continues entirely without a manager — the data path does not involve it.

How many to run

One active, the rest standby.
There is no quorum; standbys are simply ready to take over.

ceph mgr stat
ceph mgr dump | python3 -c '
import sys,json; d=json.load(sys.stdin)
print("active:", d["active_name"])
print("standbys:", [s["name"] for s in d["standbys"]])'

Configuring placement

ceph orch apply mgr --placement="label:mgr"
ceph orch host label add ceph-02 mgr
ceph orch ps --daemon-type mgr

Placement guidance:
  on different hosts from each other
  ideally in different failure domains
  co-located with monitors is common and acceptable
  not on hosts under heavy OSD load if avoidable

The last point matters at scale: the metrics endpoint generation is CPU work, and a manager on a saturated OSD host produces slow scrapes.

Failover

The active manager fails
  → the monitors detect it
  → a standby is promoted
  → modules reinitialise
  → the metrics endpoint moves to the new active

ceph mgr fail
ceph mgr stat

Failover is typically seconds, and the metrics gap is the visible part.

Quiz

Production discipline

List every manager host as a Prometheus scrape target — the metrics endpoint moves on failover and a single-target configuration loses all Ceph metrics precisely when they matter. Two managers are adequate; manager count is an availability choice with no quorum arithmetic.

Cross-course references

• Kubernetes: controller manager failover has the same stateless promotion model
• Linux: active-standby services without shared state fail over trivially