这是Ceph开发每周谈的第十篇文章，记录从16年2月8号到16年2月15号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落，想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼，但对于社区的方向和实况仍有所脱节，笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新，围绕几个热点进行深度解析，如果正好有产业届新闻的话就进行解读，最后有读者反馈问题的话并且值得一聊的话，就附上答疑部分。
-
上周综述
上周是春节假期，主要的事件是 Josh Durgin 即 Ceph RBD CTL，为 RBD 模块工作了五年，并分别给 OpenStack Cinder(Core developer)，QEMU 和 Kernel 等下游 upstream 贡献 RBD 对接代码，在上周正式宣布将 RBD CTL 交给 Jason Dillaman，Josh 在接下来的时间会回到 RADOS 模块工作。Josh 在最近时间的主要工作内容是为 RBD Mirror 提供 Daemon 框架，为实现卷级双活努力。这部分任务接下来会交接给 Jason 完成。Jason Dillaman 实际上是 14 年底才加入 Ceph 社区，是在 Inktank 被 Redhat 收购以后作为 Redhat 支持 Ceph 的路线图进入的。完成的第一个 BP 是承接笔者的 Image ObjectMap 工作。在整个 15 年，Jason 总共提交了五百多次 commits，堪称年度最勤奋贡献者。
-
NFS on RADOS Gateway
Ceph 的多平台，多协议支持一直是被用户津津乐道的一点，在 nfs-ganesha(著名的 nfs 用户态服务端实现)维护者 Matt Benjamin 随着 cohortfs 加入 Redhat 以后，其将 NFS 协议带入了 Ceph 生态系统内。NFS 作为文件存储领域的业界标准对于存储平台具有重要意义，Matt 在考虑 NFS 在 Ceph 的落脚点选择了 Rados Gateway。众所周知，对象存储实际上是对传统 NAS 最有力地替换，而传统应用对于 Posix 协议的要求和迁移的困难，还有 S3/Swift 作为 HTTP 协议的应用方都在传统企业内有落地困难，因此，NFS 协议支持的加入使得 RadosGW 同时支持 S3/Swift/NFS，几乎完成了对象存储协议的闭环，使用 NFS 作为 legancy 应用兼容，S3/Swift 作为新应用的协议，而且 NFS 和 S3/Swift 可以共享同一个资源池。
当然，这个方案并不是适合传统 NAS 的所有领域，仅仅是大文件读写场景比较合适。因为 NFS 在 RadosGW 上的实现仍然是以粗粒度对象作为基础。目前，Ceph 端代码已经进入主线，而 nfs-ganesha 部分相信在维护者 Matt 的支持下也很快落地。
-
全用户态 Ceph
在上月为 Ceph OSD 的新存储引擎 BlueStore 增加支持 SPDK 后，XSky 筹划的用户态网络引擎也在紧锣密鼓的推动，由于 Ceph 的强有力生态系统支撑，所有已有用户态客户端和服务器端都是使用同一个网络引擎(负责网络会话维护，分发)，因此在用户态网络引擎完成后，所有客户端和服务器端都可以使用用户态网络驱动(under DPDK)。同时，用户态网络也是基于 TCP/IP 协议标准，因此不管是内核网络还是用户态网络都可以混合部署在同一个集群中沟通，交互。
值得期待的是如 RADOS GW 通过 25Gib 以上网络加上用户态协议栈驱动可以以更少的 CPU 和更高效的分发，避免成为网络瓶颈。而 Ceph 集群通常采用三个副本，客户端每次写请求要经过至少 3 次 roundtrip，网络栈的损耗在全闪存集群中占据大量的时间，通过用户态网络方案来大大降低延迟使得整体性能突发。另外，虚拟化场景下，配合 ovs-dpdk 方案，使得整个云平台的计算虚拟化，网络(SDN)，存储(SDS)都可以运行在用户态，这些质变都可以驱动整个云平台性能的飞跃。
在传统存储精打细算硬件资源和内核模块的情况下，通过用户态驱动的开放架构和软件化使得服务器在弹性和性能都几乎可以不输给任何传统硬件方案。
扯的远了，附上 OpenStack Summit Topic 投票地址: https://www.openstack.org/summit/austin-2016/vote-for-speakers/presentation/7347