存储技术交流会-Ceph的开发与应用

问题导读
1、什么是Ceph？
2、你如何看待，Ceph的稳定性与大规模部署？
3、如何减少Copy Set个数，降低丢数据的概率？







Ceph是开源的分布式存储系统，也能够同时提供块、文件和对象接口服务。Ceph的块接口服务(RBD)非常适合作为云平台的块存储服务，可以满足高性能、高可靠、高扩展性的要求。


从最近的巴黎OpenStack Summit来看，Ceph是软件存储的明星，大部分厂商都选择 Ceph作为其主要或可选的解决方案。你可以在大多数OpenStack发行版、云解决方案、软硬一体机中看到Ceph的身影，这表明Ceph已经成为开源社区重点关注的开发项目。

Ceph最近两年发展很快，而且Ceph的块接口服务和OpenStack Cinder项目非常匹配，几乎是开源后端存储的首选，而且Ceph FS的前景也很光明，这引起了Redhat的注目，并导致RedHat以1.75亿美元收购 inktank公司，大家都知道inktank是ceph背后的母公司。完成收购之后，Redhat还开源了Inktank之前为企业用户提供的Ceph管理工具，使得Ceph更加开放。

国内的存储技术交流群很多，研究Ceph的工程师也不少，UnitedStack更是拥有多位Ceph存储开发的大牛。最近Meet Up上的一个存储技术交流群China Ceph Meetup比较引人关注，笔者了解到其第一次的Ceph线下技术交流会在2014年末举行。这是目前国内的一个既开放又高质量的存储技术交流群，如有对Ceph开发感兴趣的同仁不妨加入一起参与讨论。



除了China Ceph Meetup交流之外，国内还有很多存储业界人士发起的技术交流活动。

上周末在北京的中关村创业街一群存储同仁就进行了一次《Ceph技术》交流会。本次交流会的嘉宾邀请到的是UnitedStack的两位资深的存储开发工程师袁冬和朱荣泽。

交流会气氛很轻松，首先是各位参会者的自我介绍，到场的大多数都是存储业界人士，还有很多存储大V，大家寒暄之后就进入了演讲正题。



第一位演讲者是来自UnitedStack的高级工程师朱荣泽，他积累了很多云平台上分布式块存储的开发、运维、测试、调优的经验，对此他专门分享了基于OpenStack和Ceph打造高性能高可靠的分布式块存储系统的方法和经验。这次演讲的内容和上次UnitedStack在巴黎OpenStack Summit的演讲主题一样，UnitedStack在分布式块存储上的成果和方法引起了大家激烈的讨论。



朱荣泽从四个方面展开演讲：

1，块存储系统；

朱荣泽介绍到：分布式存储有出色的性能，非常可靠，并且能够轻松扩展。在UnitedStack公有云平台中因为使用了分布式块存储系统，避免了下载镜像的过程，所以云主机的创建时间可以缩短到10秒以内，而且云主机还能快速热迁移，方便了运维人员对物理服务器上硬件和软件的维护。

分布式块存储的支撑了UnitedStack云平台上的云主机、云硬盘服务，现在我们能做到每个云硬盘最大支持 6000 IOPS和170 MB/s的吞吐率，95%的4K随机写操作的延迟小于2ms ，并且所有数据都是三副本，强一致性，持久性高达10个9。其中关于创建、删除、挂载、卸载都是秒级操作，同时也提供秒级的实时快照。

通过对软硬件配置的选型，部署架构的优化，以及把原生的OpenStack三大服务的后端存储（云主机服务Nova、镜像服务Glance、云硬盘服务Cinder）统一起来，我们的云主机可以秒级创建，云硬盘超高的性能可以满足数据库的需求，还同时提供性能型和容量型两种云硬盘。我们云平台部署架构极易扩展，在扩容期间不影响虚拟机的使用，用户是感知不到底层的扩容。



2，高性能；

整个分布式块存储系统有着长长的I/O栈，每个I/O请求要穿过很多线程和队列。因此需要优化操作系统、Qemu、Ceph，以便榨干硬件的性能，达到企业级存储的要求。

对于操作系统的优化主要是关闭CPU节能模式、关闭NUMA、关闭SWAP、设置SSD的调度算法为noop、设置OSD上文件系统的挂载参数为“noatime nobarrier”，这些数据库的调优方法其实也适用于我们。

对于Qemu的优化主要是backport社区最新的patch，比如Throttle算法，可以实现更平滑的QoS功能。下一步工作中，我们还会在Qemu中引入IO Burst功能，目前也仅有AWS公有云提供这种功能。

朱荣泽说：我们对Ceph的代码和配置做了大量优化，而且有很多问题是时间长，规模上去之后才暴露出来的。主要优化点是增大文件标识符数量、增大队列长度、使用更高效的网络模型、优化处理线程模型、优化Cache算法、优化空洞读写等等，最终的成果非常显著，我们版本的Ceph的4K随机写IOPS比原生的Ceph提高了3~6倍，4K随机写的延迟接近1ms。

3，高持久性；

存储需要高可靠性，保证数据可用并且数据不丢失，这是云平台最重要的事情。提高持久性的方法有很多，比如增加副本数，使用Erase Code等。不过这些方法都有弊端，增加副本数势必会扩大成本；使用Erase Code会导致Latency提高，不适合于块存储服务。我们在成本和Latency的制约下，还有什么办法可以提高持久性呢？我们对于Ceph的持久性有计算模型和量化公式，通过量化公式，我们知道该往哪个方向努力，去提高持久性。

降低恢复时间

我们需要增加更多的OSD用于数据恢复，以便减少恢复时间，但是目前host bucket不能增加更多的OSD，这是因为主机的网络带宽限制和硬盘插槽限制。解决办法是从CRUSH MAP入手，增加一种虚拟的Bucket: osd-domain， 不再使用host bucket。这种虚拟的bucket就不会对OSD的个数有限制了。

减少Copy Set个数，降低丢数据的概率

如何减少Copy Set的个数呢？Copy Sets数量和PG的映射有关的，我们从CRUSH MAP的规则和条件入手，减少Copy Set的个数。解决办法增加虚拟的Bucket: replica-domain， 不再使用rack bucket。每个PG必须在一个replica-domain上，PG不能跨replica-domain，这样可以显著减少Copy Set的个数。

在我们公司的博客中详细介绍Ceph持久性的计算模型、量化公式、优化手段，读者如有兴趣，可深入阅读：https://www.ustack.com/blog/build-block-storage-service/。

4，分布式存储的故障处理。

朱荣泽在现场“自曝家丑”—-UnitedStack云平台上线已经快一年了，遇到的大小事故诸如：SSD GC问题，会导致读写请求的Latency非常大，飙到几百毫秒；网络故障，会导致Monitor把OSD设置为down状态；Ceph Bug， 会导致OSD进程直接崩掉；XFS Bug， 会导致集群所有OSD进程直接崩掉；Ceph数据恢复时把网络带宽跑满等等。

“对于这些故障，我们已经做了更多的改进，也有很多应对措施，保证用户服务不受影响，保证SLA。”朱荣泽说，“我们基于puppet-ceph模块的部署有：更短的部署时间，支持Ceph所有的参数，支持多种硬盘类型，使用WWN-ID替代盘符等优势，使得整个利用Puppet部署云平台变得更加稳健。”

朱荣泽还补充道：加上UnitedStack云平台在升级Ceph、替换硬盘、重启机器、扩展集群方面有完善的维护准则，同时具有收集（使用diamond，增加新的colloctor，用于收集更详细的数据），保存（使用graphite，设置好采集精度和保存精度），展示（使用grafana，挑了十几个工具，发现还是grafana好看好用），报警（zabbix agent && ceph health）功能的监控系统的支持。“在处理这些事故的时候，Ceph表现出是非常稳定和可靠的性能。”

UnitedStack存储团队总结了一套Ceph运维的准则：就是尽量减少不必要的数据迁移，减少慢速请求，保证可用性。工程师们还自己开发了Ceph监控系统，用于收集Ceph每层的性能数据。

总的来说，Ceph是非常可靠和稳定的，不过需要前提是的运维人员需要对Ceph有非常深刻的理解。

第二位演讲者，袁冬博士，对存储有着深刻的见解和分析能力，有着多年存储开发经验，目前是UnitedStack资深的存储开发工程师。袁冬就如何做一个高性能分布式的文件系统为引子开始了非常有趣的演讲。


袁冬此次演讲的主题是：《CephFS,基于RADOS的高性能分布式文件系统》

他主要为大家介绍了Ceph FS的架构设计，其本质是一个高性能分布式的文件系统,在客户端进入内核运用后，也是该版本文件系统稳定之后，解决了两个核心问题：
1，如何实现高性能吞吐：分布式存储系统（RADOS)
2，如何实现高性能OPS: 分布式元数据储存（MDS Cluster)

Ceph FS的架构设计的故事非常有意思，笔者在此贴出PPT：











袁冬讲到：由于Ceph FS的架构严重依赖于底层存储的延迟，而旧的版本在这方面没有做到很好地优化，导致延迟严重，实用性不高。而在UnitedStack基于SSD大幅度优化了RADOS延迟之后，CephFS无论是元数据处理能力还是数据处理能力都得到了大幅度改善。另一方面，UnitedStack还提供Windows原生客户端，能够提供媲美Linux原生客户端的性能，解决了跨平台的问题。

接下来袁冬介绍到Ceph FS的两个创新，也是他这次演讲的重点内容：RADOS和 MDS。

RADOS:

RADOS是一个分布式对象存储系统。所谓对象，可以理解为一个独立的数据片段，对象之间没有关系，每个对象具有对象名称，数据和扩展属性。

RADOS通过CRUSH算法实现了对象的定位，同时能够保证数据的负载平衡，冗余和容灾，为CephFS提供了一个稳定、可靠的底层数据存储系统。

CephFS充分利用了RADOS的冗余，容灾，负载平衡等特性等特性，大幅度简化了系统的架构复杂性。

MDS:

CephFS的另一个创新基础在于其基于RADOS对象存储实现的元数据集群，实现了元数据性能的线性扩展。

袁冬在这一部分详细的讲解了元数据是如何保存到RAODS、如何在多个MDS之间做负载平衡，以及CephFS的杀手锏——如何将单个目录负载平衡到多个MDS上。

CephFS的动态子树分区的算法和工程问题引起了在场听众极大的兴趣，进行了热烈的讨论。大家普遍关心如何在动态子树分区如此复杂的负载平衡模式下，做到足够的稳定和可靠，特别是分布式锁控制和数据同步、容灾问题，来自不同厂商的同学各抒己见，理论结合实际，提出了缓存镜像、数据异步同步、共享存储等多种方案。

最后，Ceph FS意图成为下一代高性能文件系统的雄心壮志会实现吗？来看看袁冬整理的Ceph FS和Lustre的对比：



袁冬最后指出Ceph FS将会是社区下一阶段的开发重点。


Ceph作为SDS的典型，在软件定义存储上有重大的推动贡献：在文件、对象、块级的存储市场上，“软件定义”平台将会持续领先于其他解决方案的发展速度。这一增长的原动力来自于各行各业和各地区对于一整套的丰富多样的数据密集型使用场景的需求。

但是Ceph的稳定性与大规模部署还需要进一步验证，UnitedStack将持续投入到Ceph的生产实践中。






本文转载自：优思德