Ceph 在携程的落地

问题导读：

1.什么是Ceph ？

2.Ceph交互方式有哪些？

3.Ceph使用场景是什么？

携程云平台概要介绍：

随着携程OTA业务的近年来的突飞猛进，业务线对IT基础设施比如计算、存储、网络等资源需求越来越多，服务质量要求也越来越高。通过2年多的持续发展，携程云平台已经形成自己独特的架构体系。

携程云平台基于OpenStack二次开发打造，提供基础设施即服务，用于管理开发、测试、生产环境多数据中心基础设施；打造携程虚拟桌面云以支撑超过万人的多呼叫中心。

携程存储现状：

当前携程也选用了一些商业和开源的存储解决方案。然而，这些方案或多或少存在一些不足。商业方案性能和服务较好，但是价格昂贵。开源方案，如Glusterfs、FastDFS和HDFS，由于其接口单一或者性能问题，也限制了其使用。Ceph作为一个高性能、高可靠的存储系统，因其良好的扩展性、强大的社区支持、完善的接口支持、不断提升的市场占有率等，我们也对此进行了研究，并在携程进行了一定范围的使用。

Ceph 介绍：

这是Ceph官网给出的Ceph整体框架图： Ceph作为一个统一的分布式存储系统，它提供文件系统、块和对象三种访问模式。Rados是Ceph的基石，代表着Ceph集群，它主要由MON、OSD、MDS三个模块组成，Rados本身就是一个key/value存储系统。RADOS是Reliable AutonomousDistributed Object Store的缩写，即：可靠的，自愈的分布式对象存储。

Rados作为一个分布式对象存储，librados提供了与它进行交互的方式，所有基于Ceph的应用都是通过librados来与Rados交互的，这包括RGW和RBD。从这个图可以看出Cephfs比较特殊，它没有使用Librados 接口，真实情况是：Cephfs是内核态的，内核态程序无法使用用户态库，但Cephfs 使用了类似librados功能的内核态接口，这点与kRBD是一致的。内核态专门有个net模块来与Rados进行交互。

Radosgw： 基于Librados开发的对象存储系统，支持S3/Swift接口

RBD： 基于Librados提供块设备接口。主要用于VM

Cephfs： 基于Librados提供的分布式文件系统接口，这个目前还不太成熟，携程也还没有开始使用

携程目前正在使用的有两种方式： RGW和RBD，下面我对这两种方式进行一个更详细的介绍

Ceph RGW介绍：

图的上部分给出了Ceph RGW在Ceph系统中的位置： RGW向下访问调用librados api，对上提供REST访问接口，兼容S3和Swift。

下面的那个流程图，给出了RGW主要的数据流：clients发送http请求到apache，apache通过fastcgi模块转发请求到RGW内部的fastcgi接收端，接收端接收到请求后经过处理转换成后端Ceph Rados集群能理解的对象存储接口，然后借助libradosapi将请求发送给Rados集群。

看到这里，有些人可能会有疑问？既然Rados已经是一个对象存储系统了，为什么还要RGW，我直接用Librados API岂不是更好，多一层还影响性能？RGW给用户提供的是RestFul请求，这对web应用是非常关键的，libradosApi是基于socket的api， 更适合应用开发，适合做产品。另一方面，上图中下面部分只是RGW的最粗略的数据流图，RGW真正的功能远比这要复杂，RGW不仅要处理数据的存取 ，还要处理元数据信息，包括文件元数据，桶元数据，用户信息元数据，配额信息数据，日志等，rgw还有一些后台处理和数据刷新线程，用于垃圾回收和cache机制等。

Ceph RBD 介绍：

RBD是Ceph对外提供的基于块的存储接口。RBD客户端有两种实现：一种是直接集成到内核中的以内核驱动形式的实现，即kRBD，如图的上部分所示，kRBD没有使用Librbd接口，它与Cephfs一样，都是使用内核的一个net模块来直接与Rados通信。

另一种是以动态库形式的用户态实现，即QemuRBD，如图中的下部分所示：它使用了librbd接口，librbd是在librados 上又开发了的块设备接口。另外，为了提升基于用户态的RBD的性能，librbd开发了RBD cache，它是RBD客户端的内存缓存。

内核驱动实现的RBD因为没有使用librbd接口，因此没有RBDcache。内核驱动RBD也无需RBD cache来提升性能，因为它有pagecache可以用来做缓存加速。

这两种实现暂时都只支持GNU／linux系统。相比于以动态库形式实现的RBD，基于内核的RBD会有如下的一些问题：

• 只有较新的内核才支持（2.6.36），对于有些linux 发布版本，比如centos6.4， 要想使用kRBD, 必须先升级内核
• 某些开发版不一定会将RBD支持编译进内核
• 相较于内核，Ceph的开发迭代周期很长，新特性、BUG修复等不可能很及时的合入内核
  
  

介绍完了Ceph RGW和Ceph RBD后，我来讲讲携程使用Ceph的几个案例。在具体案例之前，我先来描述一下Ceph在携程的环境配置：

这个图描述了Ceph在携程的环境配置信息，当前我们使用的版本是0.94.2，即H版本。这个版本比较新，也是LTS版本，我们做过一次升级，从G到H。从使用来看，新版本更稳定，RGW也因为默认采用了内置的civetweb而部署起来更方便。我们使用的系统是 Centos 6.4 ，使用这个版本倒并不是因为它有多好，而是因为我们这边的OPS对这个版本支持的更好，不建议使用这个版本，因为很多调研，比如radosgw-agent、calamari等在这个系统上运行都不太好，会有各种问题。硬件信息不多讲，给的建议是cpu，内存配比要比官方建议的高，因为后续为了管理，可能会在上面部署各种服务。需要注意的是： 我们的网卡是4个千兆网卡， 我们每台机器都配有两个ssd盘用来做raid1存放系统和Ceph 日志。

图的右边是携程单个Ceph集群的部署：集群中的每个服务器部署都完全相同，这么做主要是为了简化运维和机器选型。从图可以看出，我们集群的规模不是很大，共有3台服务器，每台服务器有12个osd，一个mon；每台服务器上面部署了一个RGW，Ceph RGW是通过DNS轮询来实现HA和负载均衡。

在携程目前我们总共部署有4个Ceph集群，分别在福泉、欧阳、金桥和南通。其中福泉、欧阳和金桥是生产环境，南通是测试环境。

Ceph使用场景介绍：

下面我开始具体的携程使用Ceph的场景介绍。第一个是酒店图片特征值：

酒店图片特征值是携程国际酒店部为了自动去除重复或相似的图片，读取图片并计算得到的图片特征值。特征值是20K左右的矩阵，预计在5000万个左右。它是典型的海量小文件存储，具有一次写入，多次读取的特点。在使用Ceph的对象存储之前，国际酒店部的同事在公司内部找了各种各样的存储方案，都无法满足他们需求，不是性能问题，就是成本问题。

在接入酒店图片特征值这个业务后，我们首先担心的是空间浪费问题。我们知道，Ceph RGW是会对文件进行分片的，默认大小是4MB，对于图片特征值这种只有20～30KB 大小的文件，它实际占用空间到底是4MB还是文件的实际大小呢，根据我们的调研，对于小文件，Ceph RGW实际占用的空间是文件本身的大小再加上一些元数据所占用的空间。

在酒店图片特征值这个业务接入的过程中（灌数据），我们也遇到了一些问题，如下图右上角所示，我们发现存储后台机器的CPU  load 比较高，接近50，我们的机器是32核的。观察发现除了Ceph-osd 占用的CPU比较高之外，migration进程也占用了大量的CPU资源（如左下图所示），因此我们将Ceph-osd 进程与CPU核进行了绑定，但从反馈结果了解到，效果不明显。因此，最后我们让业务方更改了数据灌入策略，减少数据压入的线程数，CPU load 才恢复到正常。这个事情也给了我们一个警醒，要做好业务的隔离，以免某些业务会抢占大量的资源，影响其它业务的使用。

第二个场景是跨数据中心的持续交付：下图是跨数据中心的持续交付的流程架构图，其中与Ceph相关的部分在最下面的部分，App服务器上部署有Salt-agent服务，接受Salt-Master的命令从Ceph集群拉取应用包。因为携程作为一家大型的在线旅游互联网公司，数据中心也有多个，很多业务都部署在多个数据中心，为了提升部署成功率和速度，持续交付要求每个APP 服务器都从本IDC获取应用包。另一方面，为了简化持续交付打包系统的逻辑，打包系统仅会向一个IDC发送应用包。因此这就需要存储自己来同步这些包到不同的IDC。

提到跨数据中心的数据同步，我们首先会想到两种方案，一种是修改Ceph的Crushmap，另一种是Radosgw-agent。

Ceph的Crushmap决定了集群中的数据分布情况。假如我们配置Ceph集群数据存储3份，通过修改Crushmap，我们可以做到让每一份数据存放到指定的IDC、机架、服务器甚至硬盘上。假如我们需要将数据跨越两个IDC进行存储，并且每个IDC数据存储3份，我们可以配置pool数据存储6份，其中3份在IDC1，另外3份在IDC2中。这种方案从理论上来说是可行的，也是稳定和可靠的， 因为Crushmap是Ceph最基础的功能。但缺点：一：写延迟会很高，因为Ceph是强一致性的，它需要数据在写完6份之后才返回，跨IDC，网络延迟会比较大；二：对带宽要求很高，Ceph的写策略是先写主OSD，然后再由主OSD写其它的OSD，这样在两个IDC之间就会传送三份数据；三：本地访问，这个无法保证。这与我们的场景不符，所以我们首先否定了这个方案：

Radosgw-agent 这个方案是Ceph社区提供的方案，它可以变化的方式挺多，既可以在两个region之间同步， 也可以在一个region之内的两个zone之间同步。它们有什么区别呢？ Region之间只能同步元数据。 Region 之内的zone之间既可以同步元数据，也可以同步数据。

我们需要同步数据和元数据，因此我们选择的是region内两个zone之间进行数据同步。 这个方案的架构图是这样的：一个region中有两个zone，每个zone属于一个cluster，其中一个zone是master zone，另外一个是slave zone。master zone 和slave zone之间通过radosgw-agent 进行数据和元数据的同步。这里的master zone可以进行数据的读写，slave zone仅能进行数据的读。

这个方案有什么缺点呢？第一：不稳定，尤其是当正在同步的时候，slave zone 访问速度很慢，master zone也会crush掉；第二：这个方案的数据同步是基于zone的，也就是说需要同步整个集群的所有数据，这与我们的需求很不一致。作为一个开源的解决方案，有bug是正常的， 随着社区的发展，后续版本可能会解决，但同步粒度的问题，因为是这个方案设计之初就定下来了的，不可能很快调整。基于此，我们开发了自己的跨IDC数据同步方案—COS

COS设计之初是想作为一个平台来运行的，打算以后所有基于Ceph的开发都是基于它来进行，因为COS能获取到所有Ceph集群的信息。

COS中与跨IDC同步有关的模块有watcher， dispatcher，replicator。 watcher 负责监控原cluster中对象的变化，并将监控的结果通过rabbitmq 发送消息到dispatcher， dispatcher对消息进行处理，然后发送到指定的replicator， replicator解析消息，从原cluster 下载数据，上传到目的cluster。

COS 基于celery 框架进行开发，所有组件都是HA，并可以水平扩展。Celery 同步数据的粒度是Container，并且速率可控。

未来规划：

最后的这个图是我们云存储未来的一个规划，最下面的一层是携程分布在各个IDC的Ceph集群，在这些集群之上我们会做一个统一管理平台 Ceph-Manager，最上面一层是针对各个业务专门开发的一些组件，当前我们已经完成的有Data Sync。Database for QA、Picture Features、IT网盘和Ceph与OpenStack 的集成的组件我们正在规划中。

很经典，学习了~