这是Ceph开发每周谈的第八十九篇文章，记录从17年8月21号到17年8月27号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
一句话消息
Grafana Ceph 插件列表: https://grafana.com/dashboards?search=ceph
-
Luminous 特性一览
ceph-dashboard: 在之前的文章中也提到过，Ceph 在 Luminous 开始，基于 Ceph-MGR 的监控收集能力，内置了一个简易监控面板，提供集群的性能，容量以及日志输出，针对文件系统，块也分别具有查看和列表功能。目前能做的还比较有限，只能满足特定需求，不足以支持普通用户的运维，比如历史数据。同时，由于跟着 Ceph 核心一起走，迭代速度太慢也会影响可用性。因此，Luminous 仍然推荐使用 Zabbix，Collectd 以及普罗米修斯等监控工具进行可视化。
BlueStore: 在 Luminous，BlueStore 大约经历了若干时间的稳定开发后，已经可以一用，特别是在对象存储场景，相信各方面性能和稳定性都能超越 FileStore。但是目前仍然有几个潜在风险，第一个是内存消耗，BlueStore 虽然针对分配容量能够做控制，当时实际容量消耗仍然更大，大约在 1.5x 相较于默认 BlueStore cache memory 配置。第二个是老生常谈的元数据缓存问题，在元数据大部分命中情况下，有较好的性能结果，但是当元数据超过 SSD 容量时，这个时候性能下降是非常大的，但是目前这个性能下降是无声的，对大量用户使用会有较大影响。第三个是块存储性能上，基于目前的情况来看，在闪存下性能可以大致相当于 FileStore，但是延迟会更高，在 HDD 情况下性能会好一些，在大块场景下，可以完全超越 FileStore，目前主要是小块性能仍然不足。如果基于想尝试 Luminous 的生产用户，仍然推荐用 FileStore 先行，目前社区仍然太缺乏 BlueStore 的用例和实践，会存在较大运维困难和问题触发。
EC Overwrite: EC Overwrite 需要显式打开，预示着用户仍然需要经历足够多的测试才能在生产情况下启用该特性，目前该性能社区仍然关注较少，主要还是非 EC 场景的性能仍然不足够，很难去尝试 EC Overwrite。
扩展能力: 在 Luminous 集群扩展能力得到提高，不管是针对 OSDMap 的优化，还是 AsyncMessenger 的默认启用，都大大提高了单一集群或者单一存储池的扩展能力。
稳定性: Luminous 引入了 OSD 过载机制，当 PG 处于异常情况时，众多客户端 IO 会卡在 OSD 端，消耗大量内存资源。现在，这些 IO 会被挂载到客户端侧，避免 OSD 资源消耗。同时引入了`osd_recovery_sleep`，`osd_snap_trim_sleep` 和 `osd_scrub_sleep`，会潜在降低后端非业务 IO 影响，但是也有其他负面作用，特别是降低恢复的性能。
另外，Luminous 在 Cli 上会引入变化，常见的 “ceph -s” 会有完全不同的输出，一些命令输出格式也有不兼容修改，所有面向 Ceph 的自动化工具如果有涉及格式依赖，都需要针对性修改。