Ceph Manager Module Design and Operation, an in-Depth Review
summary
Ceph MGR architecture is described end-to-end: C++ core spawns a daemon server, Python modules load via P_module_load into per-module python subinterpreters while acquiring the GIL deadlock‑prone G lock, standby managers beacon the monitors and promote via a published manager map, and failover triggers execve respawn. An op tracker records lifecycle states, flags ops over 30s, shows queued vs blocked ops, and helps pinpoint whether latency lives in a module or in core; collecting PG stats every 5s at 10,000 OSDs is noted as a scalability concern.
AI-written summary · about
chapters (10)
- 0:00Introduction and overview
- 2:30Purpose of the Ceph Manager
- 3:34Manager architecture breakdown
- 5:46Module loading process
- 8:21Standby to active transition
- 11:40Python GIL usage and deadlocks
- 15:35Introduction to op tracker
- 19:51Op tracker metrics and commands
- 25:23Future scalability concerns
- 30:47Future enhancements and Q&A
related talks
11mKeynote: From Busy to Impactful: Maximizing Ceph’s Collective Resources
18mEffective Resource Management: Through Systems Design
01h 01mBecoming an Engineering Manager Without Losing Your Technical Soul
07mAre MCPs Overhyped? A Rant about MCPs
27mSRE Drives Maturity Models
01h 27mMeet the Maintainers: Discuss Roles and Responsibilities, Areas of Improvements and...
28mThe Curse of SRE Autonomy and How to Manage It
55mA Decade of Progress: The Evolution of Production Engineering and Reliability