带你读《存储漫谈Ceph原理与实践》第三章接入层3.2对象存储RGW(五)-阿里云开发者社区

开发者社区> 人民邮电出版社> 正文

带你读《存储漫谈Ceph原理与实践》第三章接入层3.2对象存储RGW(五)

简介: 带你读《存储漫谈Ceph原理与实践》第三章接入层3.2对象存储RGW
+关注继续查看

3.2.5   元数据/数据同步

CephRGW的多数据中心(Multisite)机制用于实现多个 Ceph  对象存储集群之间的元数据、数据同步。

1.  元数据同步

 

(1)多数据中心简介

Ceph 的多数据中心有如下几个概念:Realm、ZoneGroup、Zone,如图 3-31所示。

 


 

 image.png

 

 

图 3-31 多数据中、示意

 

每个 Realm 都为一个独立的命名空间,桶名在所在命名空间内是唯一的,即一旦在某个 Realm下创建了桶A,则 A这个名字就被使用了,在该 Realm 下其他人就无法创建出名字为A的桶。

一个 Realm下可以有多个 ZoneGroup。顾名思义,每个ZoneGroup可以对应多个Zone,即 ZoneGroup是一组 Zone的集合,Zone之间同步数据和元数据。

 

通常一个 Zone为多台服务器组成的一个 Ceph集群,由一组 RGW 对外提供服务,一个集群上部署多个 RGW网关,以对请求进行负载均衡。

在一个 Realm下的多个 ZoneGroup中, 必须有一个 MasterZoneGroup,MasterZoneGroup中必须有一个 MasterZone,在 MasterZoneGroup下的 MasterZone中执行用户的创建、删除、修改操作会记录一些日志信息(MDlog),这些日志信息被克隆到其他 ZoneGroup下的 Zone中,其他Zone中的 RGW网关依照日志信息从 MasterZoneGroup 下的 MasterZone 中已配置的 endpoints 拉取元数据信息并执行相应操作。

在 Ceph的配置中有以下几个参数与多数据中心机制相关,分别为 rgw_realm、rgw_zonegroup、rgw_zone。一旦设置好这 3 个参数并启动 RGW网关,RGW就会默认到.rgw.root下寻找相应的 Realm、ZoneGroup、Zone 信息,如果无法找到则启动失败。用户也可以通过修改参数rgw_realm_root_pool、rgw_zonegroup_root_pool、rgw_zone_root_pool 的配置值,来告诉RGW网关到指定的存储池下读取 Realm、ZoneGroup、Zone 等信息。默认情况下,一个Realm下的不同ZoneGroup之间只会进行元数据同步,元数据包括

用户信息、bucket、bucket.instance信息。RGW实例在启动时,会启动 RGWMetaSync-

ProcessorThread 线程进行多数据中心元数据的同步服务。

一个新的ZoneGroup加入已存在的Realm 时,会执行全量同步,完成全量同步后就会进入增量同步阶段。在此阶段,新加入的 ZoneGroup下的Zone内的 RGW网关每隔 20s

通过 INCREMENTAL_INTERVAL参数配置到 MasterZoneGroup中拉取日志信息MDlog。在增量同步阶段,每隔 20s执行如下动作。

1)  查询请求带上 marker参数发送到MasterZoneGroup,查询是否有新增的MDlog,如果有,则拉取新增的MDlog到本地集群;

2)  读取保存在本集群的新增的 MDlog并处理,按照 MDlog记录信息发送读取元数据请求到 MasterZoneGroup;

3)保存从 MasterZoneGroup 读取到的元数据信息到本地集群;4)更新 marker参数。

(2) MDLog简介

Mdlog为 MasterZoneGroup上的RGW网关记录, 日志信息记录在 Log池下的meta.log.PERIOD.SHARD_ID对象的 OMAP上,shard_id默认为 0~31。

以下命令可查询第 0个 shard上的 omapkey,key为 1_开头,后面带记录 Log的时间戳。

 

#rados -p zgp2-z1.rgw.log listomapkeys meta.log.315d0473-9ff8-4828-83fd-96fdc36ed618.01_1598684563.695864_0.1

 

也可以使用radosgw-admin命令查看MDlog日志信息的状态,状态信息中有marker和 last_update的时间信息,marker记录上次同步的位置,last_update记录上次同步的时间。

 

#radosgw-admin mdlog status[

{

"marker": "1_1598768113.971442_11.1""last_update":"2020-08-3006:15:13.971442Z"

}

]

 

status信息保存在 Log池下的 RADOS 对象中,可通过如下命令进行查询。

 

 

#rados -p zgp2-z1.rgw.log lsmdlog.sync-status.shard.0mdlog.sync-status

 

当主数据中心没有元数据更新记录到MDlog时,以下是从主数据中心拉取 MDlog请求时没有新 MDlog返回的请求和响应。

 

GET/admin/log?type=metadata&id=0&period=315d0473-9ff8-4828-83fd-

96fdc36ed618&max-entries=100&marker=当前的 marker&rgwx-zonegroup=7085627f-27f8-

4779-9552-ebdd13c265e2HTTP/1.1

 

HTTP/1.1200 OK

Content-Length:44

 

{

"marker":""

"entries": []"truncated":false

}

 

当主数据中心有元数据更新记录到MDlog时,以下是从主数据中心拉取 MDlog请求时有新 MDlog返回的请求和响应。

 

GET/admin/log?type=metadata&id=0&period=315d0473-9ff8-4828-83fd-

96fdc36ed618&max-entries=100&marker当前的marker&rgwx-zonegroup=7085627f-27f8-

4779-9552-ebdd13c265e2HTTP/1.1

 

HTTP/1.1200 OK

Content-Length:598

 

{

"marker":"1_1598774754.303770_13.1"

"entries":[

{

 

...

}


"timestamp":"2020-08-3008:05:54.234410256Z"

"section":"user"

"data": {

"status": {

"status":"write"

 

如果从主数据中心拉取 MDlog请求时有新的 MDlog返回,发起拉取请求的 RGW则进入 MDlog的处理流程,即发送新的获取元数据请求到 MasterZoneGroup去拉取新的信息覆盖本地旧的元数据信息。如下为在MasterZoneGroup中创建一个用户后,非MasterZoneGroup向 MasterZoneGroup的网关发起的拉取用户信息的请求。

GET/admin/metadata/user/user001?key=user001&rgwx-zonegroup=abcHTTP/1.1

 

HTTP/1.1200 OK

Content-Length:713

 

{

"data": {


...


"default_storage_class": """keys": [

{



}

]

...

}


"access_key":""

"secret_key":""

"user":"user001"


 

拉取到新的用户信息写入本地集群后,更新marker参数,这样在下一个20s时带上该 Marker参数,就会只返回本Zone没有的 MDlog,对处理过的 MDlog就不会返回,从而实现了元数据的增量更新。

RGW 进程只有同时满足如下条件,才会进行MDlog的记录。

◆  rgw_zonegroup为 MasterZoneGroup。

◆  当前的ZoneGroup内的Zone个数多于1个或者当前Realm下的ZoneGroup多于1个。

(3)  示例:非主数据中心创建桶

用户信息在 MasterZoneGroup中创建后通过MDlog的方式同步到其他 ZoneGroup下所有的 Zone中,例如非 MasterZoneGroup下的某个RGW 网关接收到创建桶的请求,该 RGW网关会将请求转发到 MasterZoneGroup的网关处理。

 

voidRGWCreateBucket::execute()

{

...

if (!store->svc.zone->is_meta_master()) {JSONParserjp;

op_ret=forward_request_to_master(s NULLstore in_data&jp);

...

}

 

如果主数据中心创建失败例如主数据中心没有该用户,该用户在非MasterZoneGroup中创建,则创建桶失败。因此所有用户必须在MasterZoneGroup中创建,并通过 MDlog同步到其他数据中心,用户的修改和删除也必须在 MasterZoneGroup执行。如果 MasterZoneGroup成功返回转发创建桶的请求,则继续执行剩余的创建桶流程,将 bucketinfo保存到本数据中心的RADOS。MasterZoneGroup接收到该创建桶的请求后,其下的RGW也会执行 RGWCreateBucket::execute()。由于它是主数据中心,同时也会记录 MDlog,在元数据同步线程中 MDlog会克隆到其他ZoneGroup,所有的ZoneGroup下都会保存该 bucketinfo信息,例如 MasterZoneGroup为 beijing1,创建桶的请求发到ZoneGroup为beijing2的 RGW网关,这个请求会被beijing2 的RGW网关转发到 beijng1的RGW网关,同时 MDlog信息会被同步到beijing2、guangzhou1、hunan1等所有 ZoneGroup。在创建好桶之后,如果向这个桶上传数据,则需要将上传数据请求发到ZoneGroup为beijing2的 RGW网关。如果上传请求发到ZoneGroup 为guangzhou1的 RGW网关,guangzhou1的 RGW网关会返回301 状态码,表明请求所访问的桶不在本数据中心。

对于其他桶的元数据操作,大部分的请求会被转发到MasterZoneGroup,例如删除桶、设置桶的静态网站、设置桶的多版本控制、设置桶的桶策略、设置桶的   ACL、设置桶的生命周期规则、设置桶的跨域访问配置等。

2.  数据同步

 

Ceph 的数据同步是指在多数据中心不同Zone 之间同步用户上传的文件数据。

可以将实体数据的同步分为 个部分:记录日志、数据更新通知以及数据更新。下面分别介绍。

(1)记录日志

在对数据进行操作时比如上传、删除等操作,RGW会记录一些日志信息,为之后的实体数据同步服务。日志主要分两部分。

◆ bucketindexlog:在更新 bucketindex、设置 olh(objectlogicalhead,对象逻辑头)时会记录该日志,包含了对象、操作类型等信息;

◆  datalog:记录发生变化的 bucketshard 等信息。

在进行同步时,依据 datalog,可以知道哪些 bucketshard 发生了数据的变化。而通过bucketindexlog,则可以对对应的对象进行操作。比如,indexlog中记录的是add操作,就会从 SourceZone 获取具体的对象,如果是 remove 操作,就会把相应的对象删除。

(2)数据更新通知

与元数据同步类似,实体数据的同步同样拥有一个线程周期性地进行数据更新通知。

◆  初始化

实体数据的更新通知由 RGWDataNotifier线程负责。它的初始化以及启动都是在RGWRados的初始化函数中。

data_notifier = new RGWDataNotifier(this);data_notifier->start();

 

◆  运行

在被启动之后,每隔一段时间(由 rgw_md_notify_interval_msec配置,默认 200ms)

会进行数据更新通知,将记录在datalog中发生变化的 shard发送到其他 Zone。其他Zone在接收到更新通知后,会唤醒相应的数据同步线程。

(3)数据更新

为了与不同的 Zone进行实体数据的同步,RGW 会启动单独的同步线程。

◆  初始化

数据同步线程的初始化,同样在 RGW 的初始化中,数据同步线程可能会有多个。对于需要进行数据同步的Zone,都会启动一个线程来专门负责从该Zone 获取同步数据。

◆  运行

同步线程启动之后,会开始调用 RGWDataSyncProcessorThread的 process来对数据进行处理,其主要流程如下。

1)  从 RADOS中读取 datasyncstatus,以及各个 Logshard的 syncmarker。如果是第一次同步,RADOS 中还不存在这些信息,会先对 status 进行初始化。

2)  datasyncstatus共 有 3种 状 态, 即 StateInit、StateBuildingFullSyncMaps、StateSync。依据状态的不同,会执行不同的操作。

a)StateInit:该状态下,会执行一些同步的初始化操作,例如,往LogPool 中写入sync_status对象,从远端获取各个 Logshard的 syncmarker写入LogPool,将 sync_status设置为 StateBuildingFullSyncMaps等。

b)StateBuildingFullSyncMaps:该状态下,会从远端获取所有的 bucket 信息。之后,会以 bucket  shard为单位,将所有需要同步的bucketshard写入 OMAP中,并更新 Logshard的同步 marker,最后将状态置为StateSync。

c)StateSync:该状态即为正常的同步状态,在进行同步时,以 Logshard为单位,对每一个 Logshard进行数据同步操作。

3)  在对某个 Logshard进行数据同步时,依据Logshard的 syncmarker来判断执行全量还是增量同步。同样,在执行过一次全量同步后,之后执行的就是增量同步了。

4)  在每一个 Logshard中,包含了多个条目,每一个条目是一个bucketshard信息。对 Logshard的同步,实际上就是遍历并同步这些bucketshard。

5) 同步 bucketshard过程中有不同的状态。依据不同的状态,来依次执行初始化、全量同步以及增量同步。同样,初始化与全量同步只会执行一次,之后便是增量同步。为   了同步 bucketshard,RGW会从对端Zone的RGW获取该bucketshard的bucketindexlog,并依据这些 Log,最终决定是从远端获取实体对象,还是从本地删除对象,或者进行其他的操作,此时才会涉及真正的实体数据的操作。

(4)删除日志

如果不删除日志,则随着时间的增加,日志会越来越大。因此,RGW每隔一段时间都会删除已经同步完成的数据日志。间隔时间由rgw_sync_log_trim_interval确定,默认是1200s。在进行日志删除时,需要从各个 Zone获取数据同步状态信息,并根据这些信息, 判断出哪些日志已经被同步完成了,并将其从RADOS中删除。

(5)总结

从实体数据同步过程中可以看到涉及多种同步状态的判断。之所以有这么多的状态,   是因为 RGW 在进行数据同步时,将其在逻辑上分成了多个层级。我们可以将同步的层级分成如下4个层次。

1)Zone级别

该层级表示了与某个 Zone 的同步状态,表征该层级的同步状态由下面的结构给出。

struct rgw_data_sync_info {enum SyncState {StateInit = 0

StateBuildingFullSyncMaps=1

StateSync = 2

};

uint16_t state;uint32_tnum_shards;

rgw_data_sync_info():state((int)StateInit)num_shards(0){}

}

 

2)Logshard级别

记录数据变化时会将日志分成多个   Log,从而在数据量较大时,获得较好的性能。下面是表示 Logshard层级的同步状态结构。

struct rgw_data_sync_marker {enum SyncState {

FullSync = 0

IncrementalSync= 1

};

uint16_t state;stringmarker;

string next_step_marker;uint64_t total_entries;uint64_tpos;

real_timetimestamp;

rgw_data_sync_marker():state(FullSync)total_entries(0)pos(0){}

}

 

3)bucketshard级别

默认情况下,bucketshard大小为 0。但为了让单个容器可以承载更多的对象,不得不以牺牲 list对象的性能为代价,增大bucketshard的值。目前在线上环境中,该值通常都不配置为 0。因此,我们可以认为,每个bucket实际上都存在多个 shard,各自承载着部分对象。而在同步过程中,每一个 bucketshard都归属于某个 Logshard。对于logshard的同步,实际上就是对其下的各个 bucketshard进行同步。

4)对象级别

在每一个 bucketshard中都保存了很多对象, 同步 bucketshard,就是同步其下面的这些对象。该层级涉及对实体数据的操作,并且也是同步过程中的最底层(不考虑RADOS),没有专门的结构来保存同步信息。

3.  小结

 

因为 Multisite是一个Zone层面的功能处理机制,所以默认情况下是 Zone级的数据同步,即配置了Multisite之后,整个 Zone中的数据都会被同步处理。

整个Zone 层面的数据同步,操作粒度过于粗糙,在很多场景下都是非常不适用的。当前,CephRGW还支持通过bucketsyncenable/disable来启用/禁用存储桶级的数据同步,操作粒度更细,灵活度也更高。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
阿里云服务器怎么设置密码?怎么停机?怎么重启服务器?
如果在创建实例时没有设置密码,或者密码丢失,您可以在控制台上重新设置实例的登录密码。本文仅描述如何在 ECS 管理控制台上修改实例登录密码。
4074 0
带你读《存储漫谈Ceph原理与实践》第三章接入层3.2对象存储RGW(二)
《存储漫谈Ceph原理与实践》第三章接入层3.2对象存储RGW
14 0
Hive Tunning(二)优化存储
《Hive Tunning》读后小记第二篇——Hive Tunning(二)优化存储。
1426 0
iptables 状态策略 允许内网连接外网 拒绝外网主动连入内网 _ 笔记
4种状态 new established related invalid   NEW ( a连接b 在b没有回复前 都被称为NEW包)     ESTABLISHED ( a和b 连接成功 ...
591 0
阿里云服务器端口号设置
阿里云服务器初级使用者可能面临的问题之一. 使用tomcat或者其他服务器软件设置端口号后,比如 一些不是默认的, mysql的 3306, mssql的1433,有时候打不开网页, 原因是没有在ecs安全组去设置这个端口号. 解决: 点击ecs下网络和安全下的安全组 在弹出的安全组中,如果没有就新建安全组,然后点击配置规则 最后如上图点击添加...或快速创建.   have fun!  将编程看作是一门艺术,而不单单是个技术。
4510 0
带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(四)
带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD
22 0
带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(六)
带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD
15 0
带你读《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(二)
《存储漫谈Ceph原理与实践》第三章接入层3.1块存储 RBD(二)
31 0
472
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
文娱运维技术
立即下载
《SaaS模式云原生数据仓库应用场景实践》
立即下载
《看见新力量:二》电子书
立即下载