携程网的Ceph实践之路

今天分享的内容分为两部分，前面一部分为携程网Ceph的具体实践讲解，后面一部分为携程工程师在Ceph中国社区针对Ceph应用的一系列问答

携程网的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之间就会传送三份数据；

三：本地访问，这个无法保证。这与我们的场景不符，所以我们首先否定了这个方案：

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之间就会传送三份数据；

三：本地访问，这个无法保证。这与我们的场景不符，所以我们首先否定了这个方案：

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 的集成的组件我们正在规划中。

Ceph中国社区分享：Ceph在Ctrip携程的应用

Ceph中国首次进行的线上分享活动第一期我们邀请到的是携程工程师刘俊。

Hi，大家好，我叫刘俊，来自携程。 很高兴认识大家，今天我要跟大家分享的是Ceph在Ctrip(携程)的应用。 欢迎大家提问。

今天我要给大家分享的有如下部分：

首先，我先介绍一下Ceph在携程的现状：

之前只是介绍了环境信息，如PPT所述。

下面我介绍一下Ceph在我们公司的部署情况：

我们公司总共部署了四套Ceph集群，分别在不同的IDC。

他们的部署结构都相同。

下面我给出一个集群的部署结构图：

我解释一下：

每个集群三台机器，每台机器12块硬盘。每块硬盘3T，所有机器部署模块完全相同。

这是为了运维的方便，以简化运维。

在Ceph前端我们部署了一个RGW集群。并采用DNS进行HA，后面我会对HA进行更详细的介绍。

这是我们曾经考虑和调研过的HA方式。其中后面三种可以归于一类。

在这后面三种中，我们选择了LVS+KEEPALIVE进行了DEMO。

下面我给出我的调研结果。

关于DNS轮询的优缺点请看PPT。

待会关于这几部分的问题，欢迎大家跟我探讨。

考虑到我们的使用场景，我们最终选用了DNS。

HA就先分享到这里。下面我再分享一下携程对Ceph运维所做的工作。

我会分为四个部分进行介绍。

第一部分：权限控制

也即用户管理。包括命名空间和权限部分。

下面我给出我们的结论；

因为我们采用的是Swift接口，使用的是Swift账号。

第二部分是关于监控。

监控这块我们采用的是Zabbix方案。下面我给出一个截图：

第三部分，我讲讲我们怎么收集Ceph日志

我们采用的方案是，ELK Logstash。下面我给出相关的截图：

第四部分，我讲讲Ceph的可视化。Ceph有多种可视化方案。

我们最终选择的是，Ceph Calamari。因为它正统。

接着，我给大家分享一下，Ctrip是如何测试Ceph性能的。

对象存储不同于文件系统和块存储，基准测试工具不是很多，多是不开源的。我在腾讯就使用过一种，但因为未开源，最终没有采用。

最终我们采用的是Intel的Cosbench。

下面是Cosbench测试出来的部分截图：

使用下来感觉，Cosbench还是很不错的，可以自定义测试项，图表均可自动化生成。

最后一部分，我给大家分享一下，我们在跨IDC数据同步方面的一些经验。

这块我们花的时间最多，当前也还在进行中。Ceph官方有他自己的跨IDC数据同步方案及Multi Region

这个方案我们也调研过，但感觉有如下问题：

1. 不太稳定，当数据同步的时候，会严重影响MasterRegion的性能。

甚至会崩溃，不够灵活。

2.不够灵活

必须同步所有的数据。并且无法控制同步策略。

基本是如上两点原因。跨IDC的数据同步，也可以采用修改，crushmap来实现。但因为性能，很少人这么使用。、

为此我们开发了自己的跨IDC同步方案。下面我给出该方案的架构图。

以上就是我今天的分享。准备不是很充分，欢迎大家拍板砖。

互动问答环节

==============================

问题1：我想问下，logstash收集起来的日志怎么用呢？

答案：首先是过滤和定位问题的所在

问题2：

我有几个问题，第一，携程只使用Swift接口，那为什么不直接使用Swift？第二，ssd做raid1是用来做journal还是用来装系统？raid1为了可靠性？第三，集群里头主要存什么类型的数据？关心的性能指标是什么？是否能分享你们心目中的QoS。第四，日志收集了什么内容，是性能数据(perf count er)还是osd的log。

答: 第一，目前是只使用Swift接口，后续会把RBD加进来.

第二，都用，我们使用的是raid10.

第三，目前存放的有：软件包、静态图片以及图片特征值，后续会支持openstack image。我们关注的主要指标是延迟.

第四，日志目前主要收集的是log，收集日志的目的是为了当分布式系统出了问题的时候，方便定位.

问题3：请问携程做的主要是对象存储，是吗？

答：主要是对象存储

问题4：你们是否对rgw-agent进行了定制？主要是那些方面的定制？

答：我们不是定制，是完全自己设计了一套自己的同步方案。

问题5：同步是至什么，在什么时候同步啊？

答：可以通过策略进行控制。目前第一版本支持的是实时同步

问题6：如何用ssd加速集群性能的 ？效果明显不？

答：存放日志以加速性能

问题7：你们的机器上四块ssd坐了raid10？

答：四块SSD做了raid10

问题8：存储的是小文件还是大文件？

答：目前主要是小文件

问题9：您好，我想问一下数据同步问题，您使用Swift接口，是因为您调研过S3接口不能用吗？因为我使用s3数据同步时出现问题，架构是一个region，两个zone包含两个集群，问题如下（网上的log，跟我问题一样）： (env)root at ceph-rgw41:~/myproject# ./radosgw-agent -ccluster-data-sync.conf -q

region map is: {u'us': [u'us-west', u'us-east']}

ERROR:radosgw_agent.worker:failed to sync object new-east-bucket/new-east.json:state is error

ERROR:radosgw_agent.worker:failed to sync objectnew-east-bucket/new-east.json: state is error

ERROR:radosgw_agent.worker:failed to sync objectnew-east-bucket/new-east.json: state is error

答：不是，S3我也成功使用过，但配置起来比较复杂。使用Swift主要是因为前期我们调研过Swift对象存储，并且使用过程中也没有发现S3可以支持而Swift不能支持的功能。

问题10：跨机房同步你们是异步的吗？可以基于用户还是bucket同步？

答：是的，都可以

问题11：对象存储能提高速度不?

答：SSD主要是用来存放日志的，当然对提升性能也是有帮助的，目前我们还没对性能进行优化。

问题12：RGW服务器的配置是如何？

答：RGW是部署在Ceph集群的机器上面的，具体配置见前面图片。

问题13：你们存储小文件的时候，数据量大概多少，同步会有问题吗？每个小文件实际占用空间呢？

答：对象存储相对什么能提高速度呢？这个速度不至于，我们带宽可达100M。小文件从几K到500M以内。

问题14：你们是用httpd还是CivetWeb？civetweb配置https有办法么？

答：CivetWeb，我们没有使用https

问题15：数据同步是基于文件还是cephobj？

答：数据同步我们调用的上层Swift接口。

问题16：性能如何

答：性能能满足我们的需求；

问题17：存储的数据到达什么量级了？

答：存储的数据可参见前面图片；

问题18：跨DC的数据同步是主备模式吗？还是主主模式

答：可以说主备模式。

问题19：4块盘做raid10，为什么要这么做，硬raid？放日志还是做cache？

答：是硬Raid,做日志。

问题20：为什么要做跨机房同步？想解决什么问题？

答：为了解决本地访问的问题；

问题21：同步的时候是在同步object吗？还是用了其他什么办法？

答：有几个层面的Object，我们是调用Swift接口来同步的。

问题22：ctrip自研的rgw-agent如何实现增量同步？也是基于data log，md log和bi log？

答：这是具体实现问题，有多种策略。以后我们可以私下多讨论下。

问题23：radosgw 原生的方案也是实时同步、会影响主radosgw的性能，你们不是异步同步，为什么主的没影响性能呢？

答：我们有多种同步策略，可以根据需要调整。

问题24：貌似用的swiftclient？对s3的接口支持到什么程度了？另外支持断点续传吗？

答：Swiftclient是我们使用的一种方式，S3接口尚未具体测试，官网可查阅相关文档。暂不支持断点续传。

问题25：几k的文件在集群中实际占用空间是这个文件大小还是分配object大小？（加入object比该文件大）

答：应该是Object大小。

✦ ✦ ✦ ✦ ✦ ✦ ✦ ✦

作者： fc013 原文：http://www.aboutyun.com/thread-16670-1-1.html

喜欢我们的会点赞，爱我们的会分享！

架构师之旅

TravelWithFrame

企业级架构、系统开发架构、Web架构、大规模分布式、高可用高性能架构研究探讨、结合互联网应用技术的动态扩展架构，讨论各类中间件如ActiveMq，Zookeeper，Dubbo，Kafka，OpenStack，GlusterFs，Ceph，SpringCloud，Nginx，关注java、C++、python、node.js、shell、plsql等开发语言，敢于探索，关注最新IT资讯。

可以加我微信号 ：tiandaomaster 注明-架构师之旅

（关注ID：TravelWithFrame）

（如有侵权，请联系我们删除）