【Ceph】Ceph-RGW基本原理

原文：https://www.sohu.com/a/120065877_468741

背景

Ceph提供了三种存储类型：块存储、文件存储和对象存储，本文主要介绍对象存储的RGW基本原理和应用场景。

RGW

什么是对象存储？

对象存储(云存储)是面向对象/文件的、海量的互联网存储。对象存储里的对象是经过封装了的文件，在对象存储系统里，不能直接打开/修改文件，但可以像ftp一样上传文件，下载文件等。另外，对象存储没有像文件系统那样有一个很多层级的文件结构，而是只有一个“桶”的概念（也就是存储空间），“桶”里面全部都是对象，是一种非常扁平化的存储方式。其最大的特点就是它的对象名称就是一个域名地址，一旦对象被设置为“公开”，所有网民都可以访问到。对象存储最主流的使用场景，就是存储网站、移动app等互联网/移动互联网应用的静态内容（视频、图片、文件、软件安装包等等）。

什么是RGW？

RGW为Rados Gateway的缩写，ceph通过RGW为互联网云服务提供商提供对象存储服务。RGW在librados之上向应用提供访问ceph集群的RestAPI，支持Amazon S3和openstack swift两种接口。对RGW最直接的理解就是一个协议转换层，把从上层应用符合S3或Swift协议的请求转换成rados的请求，将数据保存在rados集群中。

几个内部基本概念

zone：包含多个RGW实例的一个逻辑概念。zone不能跨集群。同一个zone的数据保存在同一组pool中。

zonegroup：一个zonegroup如果包含1个或多个zone。如果一个zonegroup包含多个zone，必须指定一个zone作为master zone，用来处理bucket和用户的创建。一个集群可以创建多个zonegroup，一个zonegroup也可以跨多个集群。

realm：一个realm包含1个或多个zonegroup。如果realm包含多个zonegroup，必须指定一个zonegroup为master zonegroup，用来处理系统操作。一个系统中可以包含多个realm，多个realm之间资源完全隔离。

几个外部基本概念

user：对象存储的使用者，默认情况下，一个用户只能创建1000个存储桶。

bucket：存储桶，用来管理对象的容器。

object：对象，泛指一个文档、图片或视频文件等，尽管用户可以直接上传一个目录，但是ceph并不按目录层级结构保存对象， ceph所有的对象扁平化的保存在bucket中。

访问流程

下图展示了应用、RGW、ceph集群的关系：

应用通过RGW访问集群流程如下:

● S3或Swift 应用通过http协议发送请求到RGW。

● RGW从http请求中解析出s3或swift协议数据，调用librados接口，将对应的请求发送到rados集群中。

注：图中load balance非必须，只要在存在多个RGW做负荷分担时需要。

数据存储位置

对象存储涉及各种类型的数据，ceph将不同类型的数据存储在不同的pool中，RGW涉及的pool分为两大类:

● 保存集群数据的pool，比如用来保存realm信息，zonegroup信息，zone信息，使用哪个pool来保存哪个信息在配置文件中指定，默认保存在.rgw.zone中。

●保存跟单个zone相关数据的pool，在创建zone时指定，默认情况下，pool名以zone名+rgw+保存数据类型来命名，例如下面名为z1的zone默认pool如下：

注：RGW需要用到的这些pool最好在使用之前手动创建，如果不手动创建，RGW会在需要时自动创建。手动创建的好处是我们可以根据需要指定pool的PG数，crush规则等。

下面详细说明RGW涉及到的各个pool的作用：

domain_root：

保存bucket和bucket元数据。

control_pool：

在RGW上电时，在control pool创建若干个对象用于watch-notify，主要作用为当一个zone对应多个RGW，且cache使能时，保证数据的一致性，其基本原理为利用librados提供的对象watch-notify功能，当有数据更新时，通知其他RGW刷新cache，后面会有文档专门描述RGW cache。

gc_pool：

RGW中大文件数据一般在后台删除，该pool用于记录那些待删除的文件对象。

lc_pool：

保存对象生命周期执行状态。

log_pool：

各种log信息，如op log、数据同步log、过期对象等。

intent_log_pool：

目前没用。

usage_log_pool：

存储计量数据统计，比如上传文件多少次，下载多少次，遍历bucket多少次之类。

user_keys_pool：

存储用户AK和uid的对应关系，方便通过用户restful请求的ak找到用户id。

user_email_pool：

存储swift key和uid的对应关系。

user_swift_pool：

存储用户email和uid的对应关系。

user_uid_pool：

存储用户信息，和用户下bucket列表。

index_pool：

保存bucket中对象列表，index_pool可以配置多个，跟data_pool、data_extra_pool一起组成placement_pool，在创建bucket时指定数据保存到哪一组placement_pool中。

data_pool：

保存对象数据，data_pool可以有多个。

data_extra_pool：

Multipart upload过程中一些中间态的数据，会存在该pool上。这些数据可以帮助用户进行断点续传及垃圾数据回收。

应用场景

● 频繁IO的网盘。

● 有海量数据归档和备份需求的互联网应用企业

云备份的企业用户。

2.RGW的内部结构和处理流

以下是RGW的内部逻辑处理层级结构图：

HTTP 前端接收请求数据并保存在相应的数据结构中。
REST API 通用处理层从 HTTP 语义中解析出 S3 或 Swift 数据并进行一系列检查。
检查通过后，根据不同 API 操作请求执行不同的处理流程。
如需从 RADOS 集群中获取数据或者往 RADOS 集群中写入数据，则通过 RGW 与 RADOS 接口适配层调用 librados 接口将请求发送到 RADOS 集群中获取或写入相应数据。

二、RGW对外的的三类基础数据逻辑实体

RGW对外提供三种基础数据逻辑实体:

用户
存储桶
对象

1.用户

RGW兼容AWS S3和OpenStack Swift。RGW user对应S3 user，RGW user对应Swift Account，RGW subuser对应Swift user。
用户数据信息包含：

用户认证信息：S3(access key, secret key), Swift(secret key)
访问控制权限信息：包含操作访问权限（read、write、delete等）和访问控制列表ACL
用户配额信息：防止某些用户占用过多存储空间，根据用户付费情况配置存储空间。

2.存储桶(bucket)

存储桶是对象的容器，是为了方便管理和操作具有相同属性的一类对象而引入的一级管理单元。
存储桶信息包含：

基础信息：（保存在对应RADOS对象的数据部分）RGW关注的信息，包含bucket配额信息（最大对象数目或最大对象大小总和），bucket placement rule，bucket中的索引对象数目等等。
扩展信息：（保存在对应RADOS对象的扩展属性）对RGW透明的一些信息，如用户自定义的元数据信息。

对于bucket placement rule，

3.对象

RGW中的应用对象对应RADOS对象。应用对象上传分整体上传和分段上传，不同的上传方式应用对象对应RADOS对象的方式不同。
首先介绍三个概念：

rgw_max_chunk_size：分块大小，RGW下发至RADOS集群的单个IO的大小。
rgw_obj_stripe_size：条带大小，multipart除首对象外的分段其他大小
class RGWObjManifest：管理应用对象和RADOS对象的对应关系。

3.1 整体上传

应用对象大小小于等于分块大小：用户上传的一个对象只对应一个 RADOS 对象，该 RADOS 对象以应用对象名称命名，应用对象元数据也保存在该 RADOS 对象的扩展属性中。
应用对象大小大于分块大小：应用对象被分解成一个大小等于分块大小的首对象，多个大小等于条带大小的中间对象，和一个大小小于等于条带大小的尾对象。首对象以应用对象名称命名，在 RGW 中将该对象称为head_obj，该对象的数据部分保存了应用对象前 rgw_max_chunk_size 字节的数据，扩展属性部分保存了应用对象的元数据信息和manifest信息。中间对象和尾对象保存应用对象剩余的数据，对象名称为“shadow_” + “.” + “32bit 随机字符串” + “_” + “条带编号”，其中条带编号从1开始。

3.2 分段上传

RGW依照条带大小将应用对象的每一个分段分成多个RADOS对象，每个分段的第一个 RADOS 对象名称为：

“_multipart_” + “用户上传对象名称” + “分段上传ID” + “分段编号”
其余对象的名称为：
“_shadow_” + “用户上传对象名称” + “分段上传ID” + “分段编号” +  “_” + “条带编号”