rgw中 各个池的作用(更新中)

Last updated on 3 months ago

*背景*

这里主要介绍 与rgw 相关的pool ,对象网关使用几个池来满足其各种存储需求( radosgw-admin zone get 可以看到,如下图) , 这里从 zone get 里展示出来的 各种pool 出发,介绍下各个pool的功能,以及里面包含了什么

img

池的命名规则

首先我们用 rados lspool 看这个集群有那些 pool ,发现带有rgw 字眼的的只有三个,而我们用 zone get 发现是有个很多个;

img

(至于 et_uos_master_zone 则是这zone 名称)

以gc_pool 为例

img

字面意思是 gc_pool 对应的池 是 et_uos_master_zone.rgw.log:gc

而我们 查看的池子的时候 发现只有 et_uos_master_zone.rgw.log 池

img

这里是为了复用一个池,使一个池具有多个功能,ceph 使用了命名空间来分割这些池,我们可以用 命令 rados ls -p et_uos_master_zone.rgw.meta –all 可以看池有那些命名空间 如果你知道有那些 命名空间也可以直接用-N 指定 rados ls -p et_uos_master_zone.rgw.log -N gc

imgimg

*各个池的用途*

*.rgw.root*

这池用来存储realm,period,zonegroup,zone的信息,下面逐个介绍

img

realms_names.expondata

  • radosgw-admin realm create –rgw-realm= <realms_name** **> 创建 realm 实例

  • 内容时 是realm 的 ID

  • 命名方式: realms_names.<****realms_name** **>

default.realm

  • 创建 realm的时候,如果添加 –default 参数,创建流程上 会创建一个 默认的 realm

radosgw-admin realm create –rgw-realm=expondata –default

  • 内容同 realms_names.expondata 一样都是保存 realm ID

realms.655e14cb-a61b-469f-be4f-abe21280ef7f

创建 realm 的时候生成

  • 命名方式: realms.

  • 内容是 realm 的元数据信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
[root@7c31c0c6784c build]# rados -p .rgw.root get realms.7d94f248-98c1-49f7-8567-9ba01a19794c realms.7d94f248-98c1-49f7-8567-9ba01a19794c

[root@7c31c0c6784c build]# ceph-dencoder import realms.7d94f248-98c1-49f7-8567-9ba01a19794c type RGWRealm decode dump_json

{

// Realm ID

"id": "7d94f248-98c1-49f7-8567-9ba01a19794c",

// Realm Name

"name": "expondata",

//period ID, period 对象是记录了 当前realm 的状态信息

"current_period": "30dcf503-df25-479e-8f27-d0f64a7d9d39",

// period 版本号

"epoch": 1

}



[root@7c31c0c6784c build]#

realms.655e14cb-a61b-469f-be4f-abe21280ef7f.control

  • 创建 realm 的时候生成, 该对象提供 watch-notify 机制,realm 信息变更的时候 通知其他节点的客户端

periods.52470633-db3c-4205-86b6-bef9830c63bf.1

  • 创建 realm 的时候生成

  • 命名方式: realms..eponch

  • 内容是 period的元数据信息(当时 realm 的状态信息,包含了 )

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
[root@node85 tmp]#  ceph-dencoder import periods.4734ae69-b34e-406b-bdb2-8bb07545560d.1  type RGWPeriod decode dump_json

{

//perio ID

"id": "4734ae69-b34e-406b-bdb2-8bb07545560d",

// 可以理解为一个版本号,每次状态变更都会+1

"epoch": 1,



"predecessor_uuid": "aa7f8da8-d147-4870-9dba-1c035b12b5e0",

"sync_status": [],

//描述 zonegroup 和 zone 状态信息

"period_map": {

"id": "4734ae69-b34e-406b-bdb2-8bb07545560d",

"zonegroups": [

{

"id": "3dd507a4-288e-45de-a4ac-2287172a1ea1",

"name": "et_uos_master_zonegroup_name",

"api_name": "et_uos_master_zonegroup_name",

"is_master": "true",

"endpoints": [],

"hostnames": [],

"hostnames_s3website": [],

"master_zone": "60293779-abc2-430f-b0dd-fa301fa90702",

"zones": [

​ {

"id": "60293779-abc2-430f-b0dd-fa301fa90702",

"name": "et_uos_master_zone",

"endpoints": [],

"log_meta": "false",

"log_data": "false",

"bucket_index_max_shards": 0,

"read_only": "false",

"tier_type": "",

"sync_from_all": "true",

"sync_from": [],

"redirect_zone": ""

​ }

​ ],

"placement_targets": [

​ {

"name": "policy",

"tags": [],

"storage_classes": [

"STANDARD"

​ ],

"data_force_encrypt": "false"

​ }

​ ],

"default_placement": "policy",

"realm_id": "d6689a75-f22e-4f4a-aa66-45c0c15f420a"

​ }

​ ],

"short_zone_ids": [

​ {

"key": "60293779-abc2-430f-b0dd-fa301fa90702",

"val": 520533588

​ }

​ ]

},

"master_zonegroup": "3dd507a4-288e-45de-a4ac-2287172a1ea1",

"master_zone": "60293779-abc2-430f-b0dd-fa301fa90702",

"period_config": {

"bucket_quota": {

"enabled": false,

"check_on_raw": false,

"max_size": -1,

"max_size_kb": 0,

"max_objects": -1

​ },

"user_quota": {

"enabled": false,

"check_on_raw": false,

"max_size": -1,

"max_size_kb": 0,

"max_objects": -1

​ }

},

"realm_id": "d6689a75-f22e-4f4a-aa66-45c0c15f420a",

"realm_name": "et_uos_master_realm",

"realm_epoch": 2

}



[root@node85 tmp]#

periods.502c06f3-700a-4484-a813-fd928841dbea.latest_epoch

  • 创建 realm 的时候生成

  • 里面存放 的最新period epcoh(每次 realm 信息变更都会递增)

  • 命名方式: realms..latest_epoch

  • 该对象的后缀 latest_epoch 可由参数 rgw_period_latest_epoch_info_oid 指定

period_config.0cce92dc-0cba-44d2-ae34-673d3f787093

  • period_config.

  • 存放桶和用户的配额参数

zonegroups_names.expondata

  • 用命令 radosgw-admin zonegroup create 创建zonegroup 则会生成该对象

  • 保存 zonegroup的id,并且对象名字是以 zonegroups_names.

zonegroup_info.38e50b67-8655-4094-b632-1e97c1100439

  • 创建zonegroup 时生成的,用来保存 zonegroup 信息
  • *保存了 zonegroup 的元数据信息,对象命名规则**: zonegroup .
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
//获取对象信息

[root@7c31c0c6784c build]# rados get -p .rgw.root zonegroups_names.expondata zonegroup_info.38e50b67-8655-4094-b632-1e97c1100439 zonegroup_info.38e50b67-8655-4094-b632-1e97c1100439

//解码

[root@7c31c0c6784c build]# ceph-dencoder import zonegroup_info.38e50b67-8655-4094-b632-1e97c1100439 type RGWZoneGroup decode dump_json

{



"id": "38e50b67-8655-4094-b632-1e97c1100439",

"name": "expondata_rui",

"api_name": "expondata_rui",

"is_master": "true",

"endpoints": [],

"hostnames": [],

"hostnames_s3website": [],

"master_zone": "",

"zones": [],

"placement_targets": [],

"default_placement": "",

"realm_id": "2dbb2f6b-06ea-44bc-b66b-d18c46205746"

}

zone_names.et_uos_master_zone

  • 用命令 radosgw-admin zone create 创建zone 则会生成该对象

  • 保存 zone 的id,并且对象名字是以 zone_names.

zone_info.60293779-abc2-430f-b0dd-fa301fa90702

  • 创建zone 时生成的,用来保存 zone 信息
  • 保存了 zone 的元数据信息,对象命名规则**: **zone_info.

*domain_root*

“domain_root”: “et_uos_master_zone.rgw.meta:root”
当我们创建了一个桶后,et_uos_master_zone.rgw.meta:root 多了 两个对象

img

*命名规则:*

.bucket.meta.hrp:adbdbd21-2aab-49c8-8682-51ab72ff20e2.4224.1

  • .bucket.meta.[bucket_name]:[桶id]
  • 桶id 构成:[全局唯一的实例id].[num] 其中num在当前RGW实例中单调递增

HRP:

-{bucket name}

*包含内容以及作用*

.bucket.meta.hrp:adbdbd21-2aab-49c8-8682-51ab72ff20e2.4224.1

用 rados 命令导出来(是看不了的,还需要 用 ceph-dump 解析下)

rados get -p expondata.rgw.meta -N root .bucket.meta.HRP:da7eeaa4-fbfc-4254-8a0b-bcff352f32c7.4210.1 HRP

这里内容是ceph 代码里面的一个类decode 而成(至于为什么知道 是这个类,只有看代码知道)
从下面内容可以 看到该信息是记录 桶的元数据信息

展开源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
[root@7c31c0c6784c build]#  ceph-dencoder import HRP type RGWBucketInfo  decode dump_json

{

"bucket": {

"name": "HRP", //

"marker": "da7eeaa4-fbfc-4254-8a0b-bcff352f32c7.4210.1",

"bucket_id": "da7eeaa4-fbfc-4254-8a0b-bcff352f32c7.4210.1",

"tenant": "", //租户



//明确指定那个改桶数据数据要放在那个池子

"explicit_placement": {

"data_pool": "",

"data_extra_pool": "",

"index_pool": ""

​ }

},

"creation_time": "2023-08-11 06:47:15.151663Z",

//桶是由那个用户创建的

"owner": "testid",



//该falg 与桶的状态有关系

​ BUCKET_SUSPENDED = 0x1,

BUCKET_VERSIONED = 0x2,

BUCKET_VERSIONS_SUSPENDED = 0x4,

BUCKET_DATASYNC_DISABLED = 0X8,

BUCKET_MFA_ENABLED = 0X10,

BUCKET_OBJ_LOCK_ENABLED = 0X20,

BUCKET_WORM_ENABLED = 0X40, //worm功能开启标识

"flags": 0,



//所属的 zongroup

"zonegroup": "bc1df498-d35f-41db-84bd-0c60407058c3",

"placement_rule": "default-placement/STANDARD",

//桶信息现在驻留在实例特定的对象中,即 .bucket.meta.HRP:...



"has_instance_obj": "true",



//桶的quota

"quota": {

"enabled": false,

"check_on_raw": false,

"max_size": -1,

"max_size_kb": 0,

"max_objects": -1

},



//回源规则

"redirection_rules": [],





//桶的分片

"num_shards": 0,

"bi_shard_hash_type": 0,



"requester_pays": "false",

"has_website": "false",

"swift_versioning": "false",

"swift_ver_location": "",

"index_type": 0,

"mdsearch_config": [],

"reshard_status": 0,

"new_bucket_instance_id": "",

"merge_flag": 1,



// 桶策略

"policy_rule": {

"policy_id": "",

"policy_info": [],

"ctime": "0.000000"

},



"obj_lock": {

"enabled": "true",

"rule_exist": "false",

"rule": {

"defaultRetention": {

"mode": "",

"days": 0,

"years": 0

​ }

​ }

},

"version": 7,

"redirect_mon": "false",

"tagsearch_config": []

}



[root@7c31c0c6784c build]#

HRP

rados get -p expondata.rgw.meta -N root HRP hrp_bucket

*gc_pool*

“gc_pool”: “expondata.rgw.log:gc”

在删除桶里的对象时,数据并不是马上清除,而是过了一段时间才删除,等待时间 默认为 2h( 由参数 rgw_gc_obj_min_wait 限定),待删除的对象信息就存放在gc_pool的 对象里面

可以看到 gc 池中有32个对象,称为 gc shard ,这样可以为rgw 提供并发删除

img

*命名规则*

gc.0

· gc.[shardnumber]

shard number 由 参数 rgw_gc_max_objs 控制,默认是32个,所以你能看到 gc的obj数量

*包含内容以及作用*

看下 gc对象有什么数据,下图可见 size为0
img

从一个桶里删除数据后,待删除信息都会持久话到底层 ,我们可以用 radosgw-admin gc list –include-all

展开源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
//上传 对象

[root@node85 09cf5f5d-a79d-4a6e-8e04-135ba48a3b18]# s3cmd put ceph.log.20230807-22-1691416861.gz s3://hrp

upload: 'ceph.log.20230807-22-1691416861.gz' -> 's3://hrp/ceph.log.20230807-22-1691416861.gz' [1 of 1]

10835114 of 10835114 100% in 0s 24.47 MB/s done

[root@node85 09cf5f5d-a79d-4a6e-8e04-135ba48a3b18]# s3cmd ls s3://hrp/ceph.log.20230807-22-1691416861.gz

2023-08-14 11:51 10835114 s3://hrp/ceph.log.20230807-22-1691416861.gz



[root@node85 09cf5f5d-a79d-4a6e-8e04-135ba48a3b18]# radosgw-admin gc list --include-all

[]

//删除 刚才上传的文件

[root@node85 09cf5f5d-a79d-4a6e-8e04-135ba48a3b18]# s3cmd del s3://hrp/ceph.log.20230807-22-1691416861.gz

delete: 's3://hrp/ceph.log.20230807-22-1691416861.gz'



//通过 radosgw-admin gc list 命令查看 gc 信息

[root@node85 09cf5f5d-a79d-4a6e-8e04-135ba48a3b18]# radosgw-admin gc list --include-all

[

{

"tag": "60293779-abc2-430f-b0dd-fa301fa90702.1515771.585\u0000",



//删除时间

"time": "2023-08-14 21:52:43.0.116715s",

// 需要删除的底层对象 由 pool 和 集群唯一 oid

"objs": [

​ {

"pool": "c0a1606f-867c-45db-b41e-4b41d64e0972",

"oid": "60293779-abc2-430f-b0dd-fa301fa90702.78088.1__shadow_ceph.log.20230807-22-1691416861.gz.fXZygoPuf13I95dswoRcwI0o8dndqfZ_0",

"key": "",

"instance": ""

​ },

​ {

"pool": "c0a1606f-867c-45db-b41e-4b41d64e0972",

"oid": "60293779-abc2-430f-b0dd-fa301fa90702.78088.1__shadow_ceph.log.20230807-22-1691416861.gz.fXZygoPuf13I95dswoRcwI0o8dndqfZ_1",

"key": "",

"instance": ""

​ },

​ {

"pool": "c0a1606f-867c-45db-b41e-4b41d64e0972",

"oid": "60293779-abc2-430f-b0dd-fa301fa90702.78088.1__shadow_ceph.log.20230807-22-1691416861.gz.fXZygoPuf13I95dswoRcwI0o8dndqfZ_2",

"key": "",

"instance": ""

​ }

​ ]

}

]

//验证下 刚才删除的桶里的数据,再底层是否存在 ( 从上面gc 信息可以知道 对象的oid和pool)

1
2
3
4
5
[root@node85 09cf5f5d-a79d-4a6e-8e04-135ba48a3b18]# rados stat -p c0a1606f-867c-45db-b41e-4b41d64e0972  60293779-abc2-430f-b0dd-fa301fa90702.78088.1__shadow_ceph.log.20230807-22-1691416861.gz.fXZygoPuf13I95dswoRcwI0o8dndqfZ_0

c0a1606f-867c-45db-b41e-4b41d64e0972/60293779-abc2-430f-b0dd-fa301fa90702.78088.1__shadow_ceph.log.20230807-22-1691416861.gz.fXZygoPuf13I95dswoRcwI0o8dndqfZ_0 mtime 2023-08-14 19:51:58.000000, size 4194304


这些数据持久化到哪里呢?
gc数据 持久化到对象的omap中 ,每条gc信息 都以kv值性质 存放在 rocksdb中,( 这也说明了 为什么 对象存储批量删除数据,omap 数据会增大

下图是 刚才删除对象 信息, 可以看到 value 包含了包含了 刚才删除的数据

img

*control_pool** *

在RGW上启动时候, 在control pool创建若干个对象(默认是8个,由 (rgw_num_control_oids 控制 ) 用于参与 watch-notify 机制;

RGW使用 control pool 下的对象在运行在同一个zone 中的不同RGW进程之间发送消息;这些消息包括元数据缓存失效信息
这些信息在 元数据被修改时 被发送(例如用户或桶信息)。控制对象的数量越多,这些消息的并发性就越好,但代价是资源利用率更高。

// 场景

*命名规则*

· notify.[shardnumber]
shardnumber 由 参数 rgw_num_control_oids 控制 默认为8

·

*包含内容以及作用*

notify 对象再 control池,共有八个obj

img

可以通过 rados listwatchers 观察到notify obj的监听客户端

img

举个例子:

85节点上 用rados watch 命令 监听一个 notify对象

86节点上 用rados notify 命令 往一个 notify对象 发消息

img

*lc_pool*

img

img

*log_pool*

*intent_log_pool*

*usage_log_pool*

*reshard_pool*

*user_keys_pool*

*user_email_pool*

*user_swift_pool*

* **user_uid_pool*

* **otp_pool*