这是Ceph开发每周谈的第八十篇文章，记录从17年6月19号到17年6月25号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
• 一句话消息
社区上周发布了 12.1.0 用户 L RC，但实际上 Sage 后面就补了一封邮件提醒不要用于生产系统，实际上目前版本离正式还有差距，特别是 BlueStore 以及相关 PG 流程。
• Service Map Feature
Service 的目标主要期望用于这些情况，跟踪整个 Ceph 生态内所有 librados client 的服务，包括 rgw daemon，rbd mirror daemon，rbd iscsi target。同时这些服务提供必要的元数据和状态信息用于外部，并且能够动态展示。又或者动态选举，产生 HAProxy 配置。
目前主要使用 MON 的 ConfigKey 来存储这些信息，https://github.com/ceph/ceph/pull/15815 用于解决 ConfigKey 的性能问题。ConfigKey 会用 key 的组成来表示 service，value 来存储信息。
– – stored in config-key
services/$service/
services/$service/foo = bar # service metadata (if any)
services/$service/daemons/$daemon/
services/$service/daemons/$daemon/gid = client.NNN
services/$service/daemons/$daemon/metadata/foo = bar # any other random metadata
Service Map 可以在 “ceph -s” 中，看到，除了已有的 MDS，MON，Client，MGR 以外一个新的区域。同时，以下命令也可以用于该部分的显示。
– ‘service ls’ – list services
– ‘service get [service]’ – get full service map (json dump of above structure)
– ‘service daemon ls [service]’ – list daemons
– ‘service daemon get [service.daemon]’
最后会增加 librados interface，用于新服务的注册
int service_daemon_register(
const char *service, ///< service name (e.g., ‘rgw’)
const char *name, ///< daemon name (e.g., ‘gwfoo’)
const map<string,string>& metadata); ///< static metadata about daemon
int service_daemon_unregister();
int service_daemon_update_status(const map<string,string>& status);
但实际上，笔者并不是非常认同这种，虽然内置的 RGW，RBD Mirror 有需要，但是这种管理的复杂度远远会超过社区所能提供的，同时会带来更大的复杂管理。