The manager active and standby model

Intermediate⏱ ~17 mincephcephadm

What you'll learn

Describe how the monitors track and promote managers
Distinguish daemon promotion from service availability
Explain why a manager standby holds no state
Choose a manager count and placement deliberately

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

Manager failover is advertised in seconds, and the number that matters to users is not the promotion but how long the dashboard, metrics, and orchestrator take to come back after it.

One active, the rest idle

The MgrMap lives in the monitors. Exactly one manager is active; every other manager registered with the cluster is a standby that runs almost nothing.

ceph mgr stat

{
    "epoch": 214,
    "available": true,
    "active_name": "ceph-a.qkjvzt",
    "num_standby": 2
}

ceph mgr dump | python3 -c '
import sys,json
d = json.load(sys.stdin)
print("active:   ", d["active_name"], d["active_addrs"]["addrvec"][0]["addr"])
print("standbys: ", [s["name"] for s in d["standbys"]])
print("modules:  ", ",".join(sorted(d["modules"])))
print("services: ", d.get("services"))'

How failover is triggered

Step	Actor	Timing
Active stops sending beacons	the failed manager	at failure
Monitors wait out the grace period	monitors	`mon_mgr_beacon_grace`
A standby is promoted in the MgrMap	monitors	immediate
The promoted daemon loads every enabled module	new active	seconds to a minute
Modules bind ports and repopulate	new active	module dependent

ceph config get mon mon_mgr_beacon_grace
ceph mgr fail                    # force the active to yield
ceph mgr fail ceph-c.wtnxpb      # fail one specific manager

What a standby is not doing

A standby manager subscribes to nothing, caches nothing, and holds no
copy of the active manager working state. It is a process waiting to be
told it is now the active one.

Behaviour	Standby
Receives OSD PG statistics	no
Runs enabled modules	no — only the standby module, if enabled
Holds module configuration	no; it reads it from the monitors on promotion
Serves the dashboard	only a redirect, when `mgr_standby_modules` is on

ceph config get mgr mgr_standby_modules
ceph config set mgr mgr/dashboard/standby_behaviour redirect

Placement and count

ceph orch ls mgr --export
ceph orch apply mgr --placement="ceph-a,ceph-b,ceph-c"
ceph orch ps --daemon-type mgr

Count	Suitable for
1	never in production — the next failure is a total outage
2	the normal case
3	large clusters, or where a whole rack can go at once

Manager memory scales with the cluster: the prometheus module holds a
metric set proportional to OSD, pool, and PG counts, so a manager on a
large cluster is not a small process.

Quiz

Knowledge check · 4 questions

Q1. What determines how long a manager failover takes to restore service?

The monitor election round, which must finish before a manager is chosen The time the promoted daemon spends loading and starting every enabled module The size of the MgrMap, which the promoted daemon has to replay before it serves The number of standbys, since the monitors poll each one before promoting it
Q2. Promoting a standby manager restarts every enabled module from scratch.

True False
Q3. Explain a monitoring gap that follows every manager restart.

Prometheus alerts fire for 40 seconds after each planned manager restart, reporting the Ceph exporter as down, then clear on their own. Operators have started ignoring them.
Q4. Why does Ceph not keep manager standbys warm the way it keeps MDS standbys warm?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Run two managers minimum and treat the module warm-up, not the MgrMap promotion, as the real failover duration when you commit to a recovery time. Disable modules you do not use — each one is startup time added to every failover, paid by the people waiting for the dashboard.

Cross-course references

Kubernetes: a leader-elected controller also restarts its work queues from empty on promotion
Linux: readiness of the process is not readiness of the service it fronts