Ceph rgw bucket lifecycle

May 29, 2019 in CEPH
ceph lifecycle rgw
2 min read

一. lifecycle

lifecycle 是aws s3最早提供的一个bucket功能，lifecycle对 bucket内的object 起作用，需要设置在bucket中，aws s3的lifecycle主要有两个功能

1. 过期对象删除（Expiration）
2. 达到条件的对象进行转存，也就是数据迁移（Transition）

但是ceph的rgw目前只支持 过期对象删除这个功能见官网

二. lifecycle 的设置和获取

这里通过python中比较常用的 boto3 sdk 进行lifecycle的操作

设置bucket lifecycle 过期对象删除

import boto3
    
if __name__ == "__main__":
endpoint = "http://xxxxx:8000"
key = "xxx"
secret = "xxx"
dev_bucket = "data_bucket"
s3 = boto3.client('s3', aws_access_key_id=self.key
                           , aws_secret_access_key=self.secret
                           , endpoint_url=self.endpoint)
s3.put_bucket_lifecycle(
    Bucket=dev_bucket,
    LifecycleConfiguration={
        'Rules': [
            {
                'Expiration':       
                    {
                        'Days': 1   
                    },
                'ID': 's7sds8sd9f0s8', 
                'Status': 'Enabled',    
                'Prefix': ''          
            }
        ],
    })
# 打印lifecycle
print(s3cli.s3.get_bucket_lifecycle(Bucket=dev_bucket))

这里稍微解释下设置的字段含义

Expiration ：设置过期对象删除

Days: 过期时间，只能以天为单位

ID : 唯一的id

Prefix: 对象的前缀，空字符串表示对所有对象起作用

需要注意的是虽然boto3官方api 中 Expiration 还有其他字段比如 Date ， ExpiredObjectDeleteMarker 但是经过测试如果设置了这些字段将会设置失败。

lifecycle 执行时间段控制

[rgw]
# 运行时间
rgw_lifecycle_work_time = "00:00-24:00"     
# 时间间隔
rgw_lc_debug_interval = 10

修改完需要重启rgw

三. rgw lifecycle的基本工作原理

1. lifecycle 配置的存储

在lifecycle的配置信息保存在meta池中对象的 user.rgw.lc 属性中，这边以上面测试的 ‘data_bucket’ bucket为例

查找data_bucket 元数据对象

# bin/rados -p default.rgw.meta --namespace root ls | grep data_bucket
data_bucket
.bucket.meta.data_bucket:88f84179-aa08-4c53-bbb8-fc704a23e6fd.254107.1

.bucket.meta.data_bucket:88f84179-aa08-4c53-bbb8-fc704a23e6fd.254107.1 就是元数据对象

查看对象的属性

# bin/rados -p default.rgw.meta --namespace root listxattr .bucket.meta.data_bucket:88f84179-aa08-4c53-bbb8-fc704a23e6fd.254107.1
ceph.objclass.version
user.rgw.acl
user.rgw.lc

user.rgw.lc 就是存储lifecycle配置的属性

2. lc的工作流程

所有设置了lifecycle的bucket都会以 omap 的形式写入rgw log 池的命名空间为 lc 的对象中

查看 lc 对象

# rados -p default.rgw.log --namespace=lc ls
lc.6
lc.14
lc.29
lc.8
lc.10
lc.26
lc.22
lc.17
lc.27
lc.4
lc.11
lc.18
lc.20
lc.7
lc.2
lc.13
lc.16
lc.12
lc.30
lc.24
lc.9
lc.15
lc.19
lc.21
lc.23
lc.31
lc.25
lc.5
lc.3
lc.28
lc.1
lc.0

这个对象的多少由如下配置项决定

"rgw_lc_max_objs": "32"

分配的规则是 bucket hash后取模，比如上面 data_bucket 就存在对象 lc.16 的omap中

# rados -p default.rgw.log --namespace=lc listomapkeys lc.16
:data_bucket:88f84179-aa08-4c53-bbb8-fc704a23e6fd.254107.1

其中lc对象的omap header 中记录了当前omap的lifecycle遍历进度的marker。可以查看下

bin/rados -p default.rgw.log --namespace=lc getomapheader lc.16
header (76 bytes) :
00000000  01 01 46 00 00 00 40 0e  ee 5c 00 00 00 00 3a 00  |..F...@..\....:.|
00000010  00 00 3a 64 61 74 61 5f  62 75 63 6b 65 74 3a 38  |..:data_bucket:8|
00000020  38 66 38 34 31 37 39 2d  61 61 30 38 2d 34 63 35  |8f84179-aa08-4c5|
00000030  33 2d 62 62 62 38 2d 66  63 37 30 34 61 32 33 65  |3-bbb8-fc704a23e|
00000040  36 66 64 2e 32 35 34 31  30 37 2e 31              |6fd.254107.1|
0000004c

可以大概看到是哪个bucket

lifecycle 执行原理简单描述
- 执行进程线程选择一个lc对象，根据lc对象中omapheader信息选择需要执行lifecycle的下一个bucket
- 更新bucket的lc状态为 PROCESSING
- 更新header
- 开始遍历bucket中的所有对象，如果过期则删除
其中bucket 的lc 状态有四种分别是

状态含义

UNINITIAL 未初始化

PROCESSING 进行中

FAILED 失败

COMPLETE 完成

查看bucket lc的状态
```
# radosgw-admin lc list
[
    {
        "bucket": ":data_bucket:88f84179-aa08-4c53-bbb8-fc704a23e6fd.254107.1",
        "status": "COMPLETE"
    }
]
```
如果要手动启动process可执行
```
# bin/radosgw-admin lc process
```

状态	含义
UNINITIAL	未初始化
PROCESSING	进行中
FAILED	失败
COMPLETE	完成

四. 生产环境中遇到的问题

在生产环境中，有1500个bucket设置了lifecycle，每个bucket对象数在100万至1000万不等，遇到如下问题

bucket清理的时间不确定，根据lc的工作原理，可以知道，他是选择一个lc对象，然后开始当前lc对象上所有bucket的遍历，当数据量很大的时候，很大概率不能再指定的时间内，完成所有bucket遍历，例如笔者有个bucket 设置了过期时间为1天，但是在三天后才选择到这个bucket执行lc过程。
因为lifecycle的是整个个bucket的遍历，在使用过程中发现index pool的读取流量非常高，index osd cpu使用率是非lc 情况的三倍以上,下图峰值时间为lc工作时间，大量的lc是一个比较吃资源的