在前台 I/O 与后台恢复间分配服务
Ceph OSD 的 mClock 用保留份额、权重与上限协调客户端请求、后台恢复和后台尽力服务。
相关概念
工程问题#
故障恢复需要资源，但抢占太多会拖慢前台业务；只设置优先级难以同时表达最低服务、余量分配与最高限额。
实际实现#
不同服务类由 reservation、weight、limit 约束调度，内置 profile 给出不同资源侧重；参数与 OSD 能力估计共同影响服务分配。
处理流程#
- 把操作归入对应服务类
- 读取所选 profile 的参数
- 按保留份额和上限约束调度
- 用权重竞争剩余能力
源码片段#
固定版本 · 原文摘录src/osd/scheduler/mClockScheduler.ccv19.2.0 · L97–L107
97 // Set external client infos98 double res = conf.get_val<double>(99 "osd_mclock_scheduler_client_res");100 double lim = conf.get_val<double>(101 "osd_mclock_scheduler_client_lim");102 uint64_t wgt = conf.get_val<uint64_t>(103 "osd_mclock_scheduler_client_wgt");104 default_external_client_info.update(105 get_res(res),106 wgt,107 get_lim(lim));mClockScheduler::ClientRegistry::update_from_config
客户端服务类分别读取 reservation、limit、weight，再更新 dmClock ClientInfo。get_res/get_lim 在前文把比例乘以每个 shard 的估算能力，weight 无量纲；这段是工程参数接入，实际请求排序由 dmClock 调度队列完成。
收益与取舍#
工程分析带来的收益
- 分别表达最低保障、竞争权重和限额
- 可以调整业务延迟与恢复进度的侧重
付出的代价
- 工程分析：能力估计不准会影响参数效果
- 单个 OSD 的队列控制不等于端到端延迟保证
可比较的选择
严格优先级队列规则直接，但持续高优先级流量可能挤压低优先级服务。
版本与适用范围#
对应 Ceph Squid / v19.2.0 OSD 的 mClock 调度。普通操作按 OSD shard 进入队列；immediate、优先级达到 cutoff 的操作及部分前插请求走独立高优先级队列，并非所有操作都受相同 mClock 约束。