腾讯云存储专家深度解读基于Ceph对象存储的混合云机制

背景

毫无疑问，乘着云计算发展的东风，Ceph已是当今最火热的软件定义存储开源项目。以下图所示，它在同一底层平台之上能够对外提供三种存储接口，分别是文件存储、对象存储以及块存储，本文主要关注的是对象存储即radosgw。

基于Ceph可方便快捷地搭建安全性好、可用性高、扩展性好的私有化存储平台。私有化存储平台虽然以其安全性的优点受到愈来愈多的关注，但私有化存储平台也存在诸多弊端。

例如在以下场景中，某跨国公司须要在国外访问本地的业务数据，咱们该如何支持这种远距离的数据访问需求呢。若是仅仅是在私有化环境下，无非如下两种解决方案：

直接跨地域去访问本地数据中心中的数据，毫无疑问，这种解决方案会带来较高的访问延迟

在国外自建数据中心，不断将本地的数据异步复制到远程数据中心，这种解决方案的缺点是成本过高

在这种场景下，单纯的私有云存储平台并不能很好的解决的上面的问题。可是，经过采用混合云解决方案却能较好地知足上述需求。对于前文所述远距离数据访问的场景，咱们彻底能借助公有云在远程的数据中心节点做为存储点，将本地数据中心的数据异步复制到公有云，再经过终端直接访问公有云中的数据，这种方式在综合成本和快捷性方面具有较大优点，适合这种远距离的数据访问需求。

发展示状：RGW Cloud Sync发展历程

基于Ceph对象存储的混合云机制是对Ceph生态的良好补充， 基于此，社区将在Mimic这个版本上发布RGW Cloud Sync特性，初步支持将RGW中的数据导出到支持s3协议的公有云对象存储平台，好比咱们测试中使用的腾讯云COS，同Mulsite中的其余插件同样，RGW Cloud Sync这个特性也是作成了一个全新的同步插件（目前称之为aws sync module），能兼容支持S3协议。RGW Cloud Sync特性的总体发展历程以下：

Suse公司贡献了初始版本，这个版本仅支持简单上传Red Hat在这个初始版本之上实现了完整语义的支持，好比multipart上传、删除等，考虑到同步大文件的时候可能会形成内存爆炸的问题，还实现了流式上传

对于Ceph社区即将在M版本发布的这个公有云同步特性，腾讯云存储团队也在不断关注并进行了实际落地测试使用，并根据其中存在的问题进行了反馈及开发。在实际测试过程当中，咱们搭建了以下所示的运行环境：

其中，Cloud Zone内部包含一个公有云同步插件，它被配置为只读zone，用以将Rgw Zone中写入的数据跨地域同步至腾讯云公有云对象存储平台COS之上。顺利实现将数据从RGW中同步备份至公有云平台，而且支持自由定制来实现将数据导入至不一样云端路径，同时咱们还完善了同步状态显示功能，能较快监测到同步过程当中发生的错误以及当前落后的数据等。

核心机制 Multisite

RGW Cloud Sync这个特性本质上是基于Multisite之上的一个全新的同步插件（aws sync module）。首先来看Multisite的一些核心机制。Multisite是RGW中数据远程备份的一种解决方案，本质上来讲它是一种基于日志的异步复制策略，下图为一个Multisite的示意图。

Multisite中主要有如下基本概念：

Zone：存在于一个独立的Ceph集群，由一组rgw提供服务，对应一组后台的poolZonegroup：包含至少一个Zone，Zone之间同步数据和元数据Realm：一个独立的命名空间，包含至少一个Zonegroup，Zonegroup之间同步元数据

下面来看Multisite中的一些工做机制，分别是Data Sync、Async Framework、Sync Plugin这三部分。其中Data Sync部分主要分析Multisite中的数据同步流程，Async Framework部分会介绍Multisite中的协程框架，Sync Plugin部分会介绍Multisite中的一些同步插件。

Data Sync

Data Sync用以将一个Zonegroup内的数据进行备份，一个Zone内写入的数据会最终同步到Zonegroup内全部Zone上，一个完整的Data Sync流程包含以下三步：

Init：将远程的source zone与local zone创建日志分片对应关系，即将远程的datalog映射到本地，后续经过datalog就知道有没有数据须要更新Build Full Sync Map：获取远程bucket的元信息并创建映射关系来记录bucket的同步状态，若是配置multisite的时候source zone是没有数据的，则这步会直接跳过Data Sync：开始object数据的同步，经过RGW api来获取source zone的datalog并消费对应的bilog来同步数据

下面以一个bucket中数据的增量同步来阐述Data Sync的工做机制。了解RGW的人都应该知道，一个bucket实例至少包含一个bucket shard，Data Sync是以bucket shard为单位来同步的，每一个bucket shard有一个datalog shard 及bilog shard与之对应。在创建完对应关系及进行彻底量同步以后，本地Zone会记录Sourcezone每一个datalog 分片对应的sync_marker。此后local zone会按期将sync_marker与远程datalog的max_marker比对，若仍有数据未同步，则经过rgw消费datalog entry，datalog entry中记录了对应的bucket shard，消费bucket shard对应的bilog则可进行数据同步。以下面这个图所示，远程的datalog是以 gw_data_chang_log_entry这样一种格式来存储日志的，咱们可发现，每条datalog entry中包含rgw_data_change这样一个域，而rgw_data_change中包括的key这个域则是bucket shard的名字，以后就能够找到与之对应的bilog shard，从而消费bilog来进行增量同步。而全量同步其实就是没有开始这个sync_marker,直接从头开始消费datalog来进行数据同步。

Async Framework

RGW中使用的异步执行框架是基于boost::asio::coroutine这个库来开发的，它是一个stackless coroutine，和常见的协程技术不一样，Async Framework没有使用ucontext技术来保存当前堆栈信息来支持协程，而是使用宏的技巧来达到相似效果，它经过 reenter/yield/fork 几个伪关键字（宏）来实现协程。

RGWCoroutine是RGW中定义的关于协程的抽象类，它自己也是boost::asio::coroutine 的子类，它是用于描述一个任务流的，包含一个待实现的隐式状态机。RGWCoroutine能够call其余RGWCoroutine，也能够spawn一个并行的RGWCoroutine。RGWCoroutine 类会包含一个 RGWCoroutinesStack成员，使用call调用其余RGWCoroutine的时候会将其对应的任务流都存储在堆栈上，直到全部任务流完成以后控制权才会回到调用者处。然而，spawn一个新的RGWCoroutine时候会生成一个新的任务栈来存储任务流，它不会阻塞当前正在执行的任务流。当一个协程须要执行一个异步IO操做的时候，它会标记自身为阻塞状态，而这个IO事件会在任务管理器处注册，一旦IO完成后任务管理器会解锁当前堆栈，从而恢复这个协程的控制。下图为一个简单的协程使用例子，实现了一个有预约周期的请求处理器。

Sync Plugin

前文所述的数据同步过程是将数据从一个ceph zone同步到另外一ceph zone，咱们彻底能够将过程抽象出来，使数据同步变得更加通用，方便添加不一样的sync module来实现将数据迁移到不一样的目的地。由于上层消费datalog的逻辑都是一致的，只有最后一步上层数据到目的地这步是不同的，所以咱们只需实现数据同步和删除的相关接口就可实现不一样的同步插件，每一个插件在RGW中都被称为一个sync module，目前Ceph中有如下四个sync module：

rgw：默认sync module，用以在ceph zone之间同步数据log：用于获取object的扩展属性并进行打印elasticsearch：用于将数据的元信息同步至ES以支持一些搜索请求aws：Mimic版本发布，用于导出RGW中的数据到支持S3协议的对象存储平台 RGW Cloud Sync Streaming process

前文讲到Suse公司贡献了RGW Cloud Sync的初始版本，以下图所示，它的一个同步流程逻辑上来讲主要分为三步，第一经过aws sync module经过http connection将远程的object拉取过来装载至内存中，以后将这个object put到云端，以后云端会返回一个put result。

对于小文件来讲，这个流程是没问题的，可是若是这个object比较大的状况，所有load到内存中就有问题了，所以Red Hat在此基础之上支持了Streaming process。本质上是使用了一个新的协程，这里称之为pipe CR，它采用相似管道的机制，同时保持两个http connection，一个用于拉取远程object，一个用于上传object，且这两个过程是并行的，这样能够有效防止内存爆炸，具体以下图所示。

Multipart upload

Multipart upload是在Streaming process基础之上用以支持大文件的分片上传。它的总体流程以下：

Json config

公有云存储环境相对来讲比较复杂，须要更加复杂的配置来支持aws sync module的使用，所以Red Hat在这个插件上支持了json config。

相对其余插件来讲主要增长了三个配置项，分别是host_style, acl_mapping,target_path，其中host_style是配置域名的使用格式，acl_mapping 是配置acl信息的同步方式，target_path是配置元数据在目的处的存放点。以下图所示为一个实际使用的配置，它表示配置了aws zone，采用path-style这种域名格式，target_path是rgw加其所在zonegroup的名字并加上它的user_id，以后是它的bucket名字，最终这个object在云端的路径就是target_path加上object名字。

后续工做

根据社区的规划，关于RGW Cloud Sync方面的后续工做主要有如下四项：

同步状态显示的优化，好比显示落后的datalog、bucket、object等，同时将一些同步过程当中发生的错误上报至Monitor

数据的反向同步，即支持将公有云的数据同步至RGW

支持将RGW的数据导入更多的公有云平台，而不是仅仅支持S3协议的平台

在此基础之上以RGW为桥梁来实现不一样云平台之间的数据同步