这是Ceph开发每周谈的第二十三篇文章，记录从16年5月9号到16年5月15号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
上周综述
上周 WDLab 发布了基于 SuperMicro 的 ARM 存储，大约有 500 个节点。http://ceph.com/community/500-osd-ceph-cluster/
-
BlueStore Userspace Cache
BlueStore 现在的两个 Backend 一个是 Kernel Driver 另一个是 NVMEDevice。现在的 data cache 主要依赖于 pagecache，但是为了让 io 流程更好的异步化，写流程的 aio dio 也引入。这个就造成混乱的 aio 和 buffer io 混用。
同时 NVMEDevice 由于使用 Userspace NVME Library，Data Cache 目前是缺失的。因此 Sage 提出在 BlueStore 总体实现 buffer cache，解决 page cache 的问题。
目前的实现是基于对象的，类似于 ObjectCacher 的设计，当然 ObjectCacher 需要考虑实现的语意更多更复杂。
-
Ceph 配置集中存储
之前提到过 Ceph 目前的配置是通过 /etc/ceph/ceph.conf 来下发的，对于小集群或者依赖其他运维工具如 puppet 等可能还不会太麻烦，但是对于手动或者需要全局看到配置的场景，我们需要有一个集中化配置管理的地方。同时解决配置的下发问题。
目前是通过 Mon 集群进行管理和维护，通过 ceph config-key 命令存取。
主要的问题:
- 配置选项的分类，部分是可以动态，部分必须本地修改
- 配置更新以后下发的方式，是轮训还是订阅
- 这个配置系统的可用性，现在mon是CP系统，很容易导致kv不可用，所以预期是这个配置系统变成AP系统