Ceph开发每周谈 Vol 16—Jewel RC Release!

2016年03月 · 麦子迈

这是Ceph开发每周谈的第十六篇文章,记录从16年3月21号到16年3月28号的社区开发情况。笔者从前年开始做Ceph的技术模块分析到今年中告一段落,想必有挺多人期待下一篇Ceph技术分析。考虑到Ceph的发展已经从前年的一穷二白到现在的如火如荼,但对于社区的方向和实况仍有所脱节,笔者考虑开始Ceph开发每周谈这个系列。每篇文章都会综述上周技术更新,围绕几个热点进行深度解析,如果正好有产业届新闻的话就进行解读,最后有读者反馈问题的话并且值得一聊的话,就附上答疑部分。

  • 上周综述

Sage Weil 在 Core Standup 正式宣布 Jewel Candidate Release,随之社区的集成和构建系统在周末完成了各个版本和不同OS的构建包。这次release也正式宣布将 ARM 64 架构列入 Ceph 社区的支持生态体系,未来 ARM 架构下的主流 OS 都将支持 upstream 的 Ceph 软件包。Ceph Hackathon 本周四和周五将在 San Jose, CA Samsung 办公室举行。Scheduler 在 http://pad.ceph.com/p/2016_ca_hackathon

  • AsyncMessenger 去除 experiment feature

在 Jewel 版本将正式宣布 async messenger 达到生产可用级别,在过去的 2 个月时间里所有 QA 测试全部通过。在 Jewel 用户可以设置 ms-type = async 来完成切换,正式告别海量线程的痛苦。

  • PG Async Read

随着 Ceph 从阻塞线程调度模式转向全异步非阻塞模式,IO 路径中的巨无霸 PG Async Read 正在 Sammul Just 的工作日程中。目前 PG Threads 需要大量的工作线程来完成 IO 请求的处理,特别是对于读请求,和没有命中元数据缓存的写请求,整个 PG thread 都会陷入等待读的阶段,造成巨大的资源浪费。因此,PG Layer 会实现 Async Read 机制来解决阻塞问题。同时,底下 ObjectStore 也将提供 async read 接口。目前的 BlueStore 天然支持 async read,使得整个 IO 路径的异步化指日可待。在全异步化以后,从网络到底下落盘极有可能实现单一线程处理,彻底实现请求 Sharding 来达到无锁化。