Ceph Pacific 버전의 Multi-site 구성 동기화 과정

들어가기 전...

해당 분석은 Ceph Pacific 버전으로 진행된 Multi-site 간의 Log 기반의 동기화를 분석한 것으로 아직 rgw_default_data_log_backing fifo에 대한 정보가 부족하여 깊게는 확인하지 못하였다. (부족한 지식으로 작성한 것이기에 틀린 부분이 있다면 댓글 부탁드립니다 :) )
하지만, 확실한 것은 기존 rgw_default_data_log_backing omap의 방식 때보다 실제 Object 기반의 Omap 이 아닌 Pipe Fifo를 이용하였기에 중복 처리나, Large Omap과 같은 이슈에 대처하기 용이 해 진 것은 맞는 것 같다.
Master와 Slave의 구분은 Ceph에 아직 소스 코드상으로 Master Slave로 구분되어 있어서 동일하게 구분한 것이다.

또한 Sync Status 나 Marker에 대한 자세한 설명은 하지 않았다.

간략한 Ceph Multisite 동기화 과정

Object Service는 User가 CEPH RGW에 등록된 User 계정을 이용하여 Bucket (디렉토리 혹은 폴더) 에 들어간 Object (이미지, 문서, 영상 등...)을 Object Client( S3 cmd, API 등)을 이용 하여 업로드하거나 다운로드 가능한 서비이다.

CEPH RGW는 하나의 Web Server처럼 지정된 API를 통하여 업로드 다운로드가 가능하다.

CEPH RGW 내부적으로는 Bucket Index Pool , Data Pool , Meta Pool에 각각의 정보가 CEPH의 Object(이미지, 영상 등과 같은 Object 가 아닌 CEPH에서 인식하는 RADOS Object)로 저장된다.

Bucket Index Pool 에는 User 가 업로드/다운로드 시 사용되는 Bucket의 정보가 저장되어 사용된다.

Bucket Data Pool 에는 실제 이미지나, 영상, 텍스트 등과 같은 Object의 데이터가 저장되는 Pool이다.

Meta Pool 에는 사용자 계정이나 계정 정보 등 Metadata 가 저장되는 Pool이다.

이렇게 분산되어 있는 Pool을 CEPH RGW 가 API 요청에 따라 CEPH OBJECT를 조합/ 분리하여 업로드/다운로드를 웹서버와 비슷한 형태로 제공하게 된다.

Mutisite 설정을 활성화하여 DR(혹은 이중화 )를 구성시 CEPH RGW는 Log Pool을 생성하여 Bucket의 변화(생성, 삭제, 변경)에 대한 부분을 Bucket Index Log Object을 생상 하여 Log Pool에 생성 하고, Bucket Data 에 대한 변화(생성,삭제,변경)에 대한 부분을 Data Log Objcet 로 그리고, User 등과 같은 Metadata 에 대한 변화(생성,삭제,변경)에 대한 부분은 Metadata Log Objcet 로 Log Pool 에 생성한다.

Multi-site 구성시 하나의 Zone-group에 논리적으로 Slave Zone, Master Zone으로 나 지는데, Slave Zone에 있는 RGW 서비가 Master Zone 에 있는 RGW에 Log 파일에 변경사항을 REST를 이용하여 체크한다.

변경 사항이 있을 경우에 Slave Zone에서 변경사항을 Master Zone 에 있는 Log Pool 과 같이 Slave Zone 에 있는 Log Pool에 있는 Log Object를 업데이트한다.

Slave Zone에 있는 Log 파일이 업데이트 됨에 따라서 Log 파일에서 변경사항만 Marker 하여 Master Zone 에 있는 Metadata, Data, Bucket의 Objcet를 RGW로 다운로드하여 동기화한다.

Metadata Log Sync 과정

Metadata Sync 과정을 확인하기 위하여 Bucket을 raq002 이름으로 하나 생성 한다. Bucket 을 생성하더라도, Bucket Bucket.instnace 와 같은 Metadata 가 생성되기에 테스트를 진행한다.

root@cy02-test190:~# s3cmd mb s3://raq002
Bucket 's3://raq002/' created

Master Zone에서는 metadata pool에 root namespace로 Metadata Object 가 생성되었다.

총 2개의 Object 가 확인이 된다. 안에 내용은 우선 나중에 확인하기로 하고 해당 Namespace에 해당 Object 이름으로 있다는 것만 확인 하자.

sh-4.4$ rados -p zone-a.rgw.meta ls --all| \grep raq002
root    .bucket.meta.raq002:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.3
root    raq002

또한 log pool 에는 Metadata Object 가 생성됨에 따라 Log Object 가 생성되었다.

생성된 형식은 "meta.log. [PERIOD D]. [SHARD 번호] "형식으로 지금은 22c652d5-5 dfc-424e-9119-304721e8b7 cb라는 Period 가 가장 우선시되기에 해당 번호로 Shard Object 가 Log Pool에 생성된다.

sh-4.4$ rados -p zone-a.rgw.log ls | grep meta.log
meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.54
meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.16
meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.23
meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.17
meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.47
meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.6
meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.32
 
sh-4.4$ radosgw-admin period list
{
    "periods": [
        "22c652d5-5dfc-424e-9119-304721e8b7cb",
        "ae5ce14f-87aa-491f-ad4c-e975ffd2f9c7",
        "cd4d449d-515a-4421-aba3-54f98f57dd9b:staging"
    ]
}

shard의 번호는 hash 돼서 지정되는데 우선 날짜로 확인해서 16번 shard에 있는 것을 확인하고 omap key가 4개가 있는것을 확인할 수 있다.

sh-4.4$   rados -p zone-a.rgw.log listomapkeys meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.16
1_1646626637.491370_281779.1
1_1646626637.529577_281784.1
1_1646626637.545697_281785.1
1_1646626637.577451_281786.1
 
sh-4.4$ rados -p zone-a.rgw.log listomapvals meta.log.22c652d5-5dfc-424e-9119-304721e8b7cb.16
...
1_1646626637.577451_281786.1
value (140 bytes) :
00000000  02 01 86 00 00 00 06 00  00 00 62 75 63 6b 65 74  |..........bucket|
00000010  06 00 00 00 72 61 71 30  30 32 4d 87 25 62 40 36  |....raq002M.%b@6|
00000020  6b 22 46 00 00 00 01 01  40 00 00 00 01 01 0c 00  |k"F.....@.......|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 01 01  |................|
00000040  24 00 00 00 01 00 00 00  00 00 00 00 18 00 00 00  |$...............|
00000050  5f 46 56 42 32 78 4b 61  79 53 53 4b 41 62 76 58  |_FVB2xKaySSKAbvX|
00000060  75 47 4c 41 5a 41 79 59  04 00 00 00 1c 00 00 00  |uGLAZAyY........|
00000070  31 5f 31 36 34 36 36 32  36 36 33 37 2e 35 37 37  |1_1646626637.577|
00000080  34 35 31 5f 32 38 31 37  38 36 2e 31              |451_281786.1|
0000008c

mdlog list를 통하여 좀 더 직관적으로 json 형태로 확인할 수 있는데, Bucket 생성으로 인하여 Metadata Pool에 Write 된 Object의 이름을 확인할 수가 있다.

이는 section 별로 bucket과 bucket.intance section 인 것을 확인할 수 있다.

즉 , Slave에서는 이 Omap의 정보를 보고 동기화할 것이다.

sh-4.4$ radosgw-admin mdlog list --period=22c652d5-5dfc-424e-9119-304721e8b7cb  | grep 1_1646626637.577451_281786.1 -B 2 -A 17
  
        "section": "bucket",
        "name": "raq002",
...
         status": "write"
...
        "section": "bucket",
        "name": "raq002",
...
         "status": "complete"
   
        "section": "bucket.instance",
        "name": "raq002:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.3",
...
        "status": "write"
...
        "section": "bucket.instance",
        "name": "raq002:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.3",
...
      "status": "complete"
...

Omap의 정보를 가져오기 위하여 Slave에서는 주기적으로 Sync 되어 있는 Zonegroup과 Period 정보로 "http://[MASTER RGW]/admin/log? type=metadata&id=16&period=[PERIOD ID]&max-entries=100&&rgwx-zonegroup=[ZONE GROUP ID]" Master RGW로 요청을 보낸다.

이렇게 요청을 해서 앞서 Master에서 작성된 "listomapkeys meta.log.22c652d5-5 dfc-424e-9119-304721e8b7 cb.16" Log Object의 Omap을 확인하려 할 것이다.

debug 2022-03-07T04:17:31.231+0000 7f0d5d864700 15 rgw rados thread: generated auth header: AWS Z2hdJTJ2VVYxV3lQKkk=:MTBvH/pSHTgl5JG6lwWKjED/3QY=
debug 2022-03-07T04:17:31.231+0000 7f0d5d864700 20 sending request to http://10.20.2.150:80/admin/log?type=metadata&id=16&period=22c652d5-5dfc-424e-9119-304721e8b7cb&max-entries=100&&rgwx-zonegroup=a4568371-4806-4a18-8e3c-1cb7d8e1ce4e

Slave에서 Metadata Log(이하 Md Log)의 entri를 각 shard 별로 확인하는데 해당 로그에서는 16번 shard에 4개의 entri가 있는 것을 확인할 수 있다.

metadata log shard 에 entri 가 없는 경우 ---> debug 2022-03-07T04:17:31.239+0000 7f0d5d864700 20 rgw rados thread: cr:s=0x560d61682f00:op=0x560d61dd3500:24RGWCloneMetaLogCoroutine: operate()
 metadata log shard 에 entri 가 없는 경우 ---> debug 2022-03-07T04:17:31.239+0000 7f0d5d864700 20 rgw rados thread: operate: shard_id=4: receiving rest response
 metadata log shard 에 entri 가 없는 경우 ---> debug 2022-03-07T04:17:31.239+0000 7f0d5d864700 20 meta sync: remote mdlog, shard_id=4 num of shard entries: 0
...
 metadata log shard 에 entri 가 있는 경우 --->  debug 2022-03-07T04:17:31.243+0000 7f0d5d864700 20 meta sync: remote mdlog, shard_id=16 num of shard entries: 4
 metadata log shard 에 entri 가 있는 경우 ---> debug 2022-03-07T04:17:31.243+0000 7f0d5d864700 20 rgw rados thread: cr:s=0x560d61a32c80:op=0x560d61df7100:24RGWCloneMetaLogCoroutine: operate()
 metadata log shard 에 entri 가 있는 경우 ---> debug 2022-03-07T04:17:31.243+0000 7f0d5d864700 20 rgw rados thread: operate: shard_id=16: storing mdlog entries
 metadata log shard 에 entri 가 있는 경우 ---> debug 2022-03-07T04:17:31.243+0000 7f0d5d864700 20 meta sync: entry: name=raq002:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.3
 metadata log shard 에 entri 가 있는 경우 ---> debug 2022-03-07T04:17:31.243+0000 7f0d5d864700 20 meta sync: entry: name=raq002:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.3
 metadata log shard 에 entri 가 있는 경우 ---> debug 2022-03-07T04:17:31.243+0000 7f0d5d864700 20 meta sync: entry: name=raq002
 metadata log shard 에 entri 가 있는 경우 ---> debug 2022-03-07T04:17:31.243+0000 7f0d5d864700 20 meta sync: entry: name=raq002

이제 omap 정보를 확인한 Slave는 entry에 있는 Omap 정보로 Meta Pool에 있는 Object 2개를 동기화하게 되고 , 나중에 중복 제거를 위해서 mdlog.sync-status.shard 에 marker 내용 즉, 해당 Omap ID를 등록해서 중복을 방지한다.

mdlog.sync-status.shard [ SHARD 번호] 로 되어 있는 오브젝트에 정보를 등록 하는것 처럼 보였으나, 실제 빠른 처리를 위하여 Metadata 는 Cache 를 사용할 수 있는데, LRU cache 에 Omap 이 있던 Shard 번호의 mdlog.sync-status.shard[ SHARD번호] 정보와 Marker 정보를 Cache LRU에 등록하여 진행한다.

즉, 빠른 중복 처리를 위하여 해당 방법으로 사용된다.

debug 2022-03-07T04:17:31.247+0000 7f0d5d864700 20 meta sync: store_marker(): updating marker marker_oid=mdlog.sync-status.shard.16 marker=1_1646626637.491370_281779.1 realm_epoch=2
,,,
debug 2022-03-07T04:17:31.607+0000 7f0d5d864700 10 RGW-SYNC:meta:shard[16]:entry[bucket:raq002]: success
...
debug 2022-03-07T04:17:31.627+0000 7f0d5d864700 20 meta sync: store_marker(): updating marker marker_oid=mdlog.sync-status.shard.16 marker=1_1646626637.577451_281786.1 realm_epoch=2
...
 
debug 2022-03-07T04:17:31.635+0000 7f0d6a87e700 10 rgw async rados processor: cache put: name=zone-b.rgw.log++mdlog.sync-status.shard.16 info.flags=0x1
debug 2022-03-07T04:17:31.635+0000 7f0d6a87e700 10 rgw async rados processor: moving zone-b.rgw.log++mdlog.sync-status.shard.16 to cache LRU end
debug 2022-03-07T04:17:31.635+0000 7f0d6a87e700 10 rgw async rados processor: distributing notification oid=zone-b.rgw.control:notify.0 cni=[op: 0, obj: zone-b.rgw.log:mdlog.sync-status.shard.16, ofs0, ns]
...
debug 2022-03-07T04:17:31.635+0000 7f0d5d864700 10 RGW-SYNC:meta:shard[16]:entry[bucket.instance:raq002:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.3]: success

그래서 실제 해당 sync-sttatus에 Object를 확인하면 Marker 정보가 없는 것을 알 수 있다.

root@cy02-test194:~# rados -p zone-b.rgw.log listxattr mdlog.sync-status.shard.16
ceph.objclass.version
lock.sync_lock
 
root@cy02-test194:~# ceph-dencoder type rgw_meta_sync_marker dump_json import file
{
    "state": 0,
    "marker": "",
    "next_step_marker": "",
    "total_entries": 0,
    "pos": 0,
    "timestamp": "0.000000",
    "realm_epoch": 0
}

Data /Bucket-Index Log Sync 과정

rgw를 배포하고 나면 아래와 같은 pool을 확인할 수 있다.

root@cy02-test190:~#cephosdpoolls
device_health_metrics
.rgw.root
zone-a.rgw.log
zone-a.rgw.control
zone-a.rgw.buckets.index
zone-a.rgw.buckets.non-ec
zone-a.rgw.meta
zone-a.rgw.buckets.data
zone-a.rgw.otp

현재 master 쪽에는 총 4개의 버킷이 있는데 buckets.indexpool에 오브젝트를 확인하면 각 bucket 별로 11개의 bucketindex오브젝트를 가지며, 총 44개의 오브젝트가 있는 것을 확인 가능하다.

root@cy02-test190:~#rados-pzone-a.rgw.buckets.indexls|sort-n
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.0
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.1
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.10
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.2
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.3
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.4
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.5
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.6
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.7
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.8
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.1.9
...
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.0
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.1
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.10
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.2
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.3
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.4
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.5
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.6
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.7
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.8
.dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4.9
 
root@cy02-test190:~#rados-pzone-a.rgw.buckets.index ls|sort -n|wc-l
44
 
root@cy02-test190:~#rados-pzone-a.rgw.buckets.index ls|sort -n|grep .dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.20608.4|wc-l
11

log의 pool을 확인하면"data_log.NN"형태의 오브젝트가 있는 것을 확인할 수 있다.

"data_log"의 이름은"rgw data log obj prefix"이라는 ceph지시자에 있는 변수에 설정된 기본 prefix이름인"data_log"로설정되어있기 때문이다.

또한 숫자가 128개까지 있는 이유는"rgw data log num shards"이라는 ceph지시자에서 변수 설정된 기본값인 128이기 때문에 128개의 오브젝트가 shard로 구성되어있다.

root@cy02-test190:~#rados-pzone-a.rgw.logls--all|grep data_log|sort-n
...
data_log.117
data_log.118
data_log.119
data_log.12
data_log.120
data_log.121
data_log.122
data_log.123
data_log.124
data_log.125
data_log.126
...

0101.txt 파일을 raq003 버킷에 Put 한다.

root@cy02-test190:~# s3cmd put /etc/passwd s3://raq003/0101.txt
upload: '/etc/passwd' -> 's3://raq003/0101.txt'  [1 of 1]

Put 된 파일은 raq003 Bucket ID 인 81 dd7 c8 d-d1e5-4e6c-aa59-9d827 fec12c6.1750963.4를 프리픽스로 buckets.data pool에 81 dd7 c8 d-d1e5-4e6c-aa59-9d827 fec12c6.1750963.4_0101.txt 이름의 Object로 저장되어진다.

sh-4.4$ radosgw-admin bucket stats| grep raq003 -B 2 -A 15
[
    {
        "bucket": "raq003",
        "num_shards": 11
...
        },
        "id": "81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4",
        "marker": "81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4",
...
 
 
root@cy02-test190:~#  rados stat -p zone-a.rgw.buckets.data 81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4_0101.txt
zone-a.rgw.buckets.data/81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4_0101.txt mtime 2022-03-07T07:29:11.000000+0000, size 1760

Bucket Index나 Data 도 Metadata와 동일하게 각각의 Bucket Index Log와 Data Log를 남겨서 Slave에서 해당 Log를 확인하고 동기화를 하게 된다.

Master와 Slave에서는 각각 radosgw-admin 명령을 이용하여 각각의 Log정보를 확인할 수 있다.

아래는 Put 된 파일로 인하여 생성된 Bucket Index Log와 Data Log의 정보이다.

sh-4.4$ radosgw-admin  datalog list | grep 81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4 -A 2 -B 2
    {
        "entity_type": "bucket",
        "key": "raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8",
        "timestamp": "2022-03-07T07:29:11.473082Z"
    },
 
 
sh-4.4$ radosgw-admin  bilog list --bucket=raq003
[
    {
        "op_id": "8#00000000001.15.5",
        "op_tag": "81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750957.8237343014026175688",
        "op": "write",
        "object": "0101.txt",
        "instance": "",
        "state": "complete",
        "index_ver": 1,
        "timestamp": "2022-03-07T07:29:11.439973987Z",
        "ver": {
            "pool": 8,
            "epoch": 33
        },
        "bilog_flags": 0,
        "versioned": false,
        "owner": "",
        "owner_display_name": "",
        "zones_trace": [
            {
                "entry": "81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6:raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4"
            }
        ]
    }

data_log의 Omap을 확인하면 Omap을 확인할 수 없다.

sh-4.4$ rados -p zone-a.rgw.log listomapkeys 2022-03-07-07-81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4-raq003
sh-4.4$
 
sh-4.4$  rados -p zone-a.rgw.log listomapkeys data_log@G2.53
sh-4.4$  rados -p zone-a.rgw.log listomapkeys data_log@G2.53.zZDN2HW76jI.0
sh-4.4$

rgw_default_data_log_backing의 기본 설정이 omap 이 아닌 fifo로 변경되어서 omap을 확인할 수 없는 것이다.

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/4.2/html/release_notes/enhancements

https://github.com/ceph/ceph/pull/35548

Master Zone의 Log를 확인하면 Master에 Put 이 다 완료된 뒤 datalog_notify execute()를 실행하여 53번 Shard에 raq003:81 dd7 c8 d-d1e5-4e6c-aa59-9d827 fec12c6.1750963.4:8 key로 업데이트하여 wakeup_data_sync_shards를 수행한다.

datalog_notify execute(): read data: [{"key":53,"val":["raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8"]}]
debug 2022-03-07T07:29:27.644+0000 7f83f1749700 20 req 11531862842186089704 0.003999956s :datalog_notify execute(): updated shard=53
debug 2022-03-07T07:29:27.644+0000 7f83f1749700 20 req 11531862842186089704 0.003999956s :datalog_notify execute(): modified key=raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8
debug 2022-03-07T07:29:27.644+0000 7f83f1749700 20 wakeup_data_sync_shards: source_zone=d86a5791-a54d-4281-9b2d-dab4e1591d88, shard_ids={53=raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8}
debug 2022-03-07T07:29:27.644+0000 7f83f1749700  2 req 11531862842186089704 0.003999956s :datalog_notify completing

Slave에서는 "http://[ MASTER ZONE]:80/admin/log/? type=data&id=70&marker&extra-info=true&rgwx-zonegroup=[ZONE GROUP ID]" 형태로 Shard의 정보를 모두 확인 한뒤 53번 Shard 의 정보에 Log Entri 가 있는 것을 보고 해당 정보를 기반으로 동기화를 하게 된다.

debug 2022-03-07T07:29:27.379+0000 7f0d5c862700 20 sending request to http://10.20.2.150:80/admin/log/?type=data&id=70&marker&extra-info=true&rgwx-zonegroup=a4568371-4806-4a18-8e3c-1cb7d8e1ce4e
...
 
debug 2022-03-07T07:29:27.379+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]: shard_id=53 log_entry: G00000000000000000002@00000000000000000000:00000000000000000512:2022-03-07T07:29:11.483996+0000:raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8
...
debug 2022-03-07T07:29:27.379+0000 7f0d5c862700 4 data sync: starting sync on raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8 key=raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8 marker=G00000000000000000002@00000000000000000000:00000000000000000512 timestamp=2022-03-07T07:29:11.483996+0000
...
 debug 2022-03-07T07:29:27.403+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]:entry:bucket_sync_sources[target=:[]):source_bucket=:[]):source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6]:bucket[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8<-raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]: sync status for source bucket: 0
debug 2022-03-07T07:29:27.431+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]:entry:bucket_sync_sources[target=:[]):source_bucket=:[]):source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6]:bucket[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8<-raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:full_sync[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]: listing bucket for full sync
debug 2022-03-07T07:29:27.435+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]:entry:bucket_sync_sources[target=:[]):source_bucket=:[]):source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6]:bucket[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8<-raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:full_sync[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]: [full sync] syncing object: raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8/0101.txt
debug 2022-03-07T07:29:27.435+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]:entry:bucket_sync_sources[target=:[]):source_bucket=:[]):source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6]:bucket[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8<-raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:full_sync[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:entry[0101.txt]: bucket sync single entry (source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6) b=bucket sync single entry (source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6) b= log_entry=0101.txt op=0 op_state=1
debug 2022-03-07T07:29:27.435+0000 7f0d5c862700  5 RGW-SYNC:data:sync:shard[53]:entry:bucket_sync_sources[target=:[]):source_bucket=:[]):source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6]:bucket[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8<-raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:full_sync[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:entry[0101.txt]: bucket sync: sync obj: 81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6/:raq003[81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4])/0101.txt[0]
debug 2022-03-07T07:29:27.607+0000 7f0d5c862700 10 RGW-SYNC:data:sync:shard[53]:entry:bucket_sync_sources[target=:[]):source_bucket=:[]):source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6]:bucket[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8<-raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:full_sync[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:entry[0101.txt]: success
debug 2022-03-07T07:29:27.607+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]:entry:bucket_sync_sources[target=:[]):source_bucket=:[]):source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6]:bucket[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8<-raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:full_sync[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]: updating marker marker_oid=bucket.sync-status.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6:raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8 marker=0101.txt
debug 2022-03-07T07:29:27.627+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]:entry:bucket_sync_sources[target=:[]):source_bucket=:[]):source_zone=81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6]:bucket[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8<-raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]:inc_sync[raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8]: listing bilog for incremental sync00000000001.15.5
debug 2022-03-07T07:29:27.639+0000 7f0d5c862700 10 RGW-SYNC:data:sync:shard[53]:entry: sync finished on raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8 progress=2022-03-07T07:29:27.414131+0000  key=raq003:81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4:8 marker=G00000000000000000002@00000000000000000000:00000000000000000512 timestamp=2022-03-07T07:29:11.483996+0000 r=0
debug 2022-03-07T07:29:27.639+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]: updating marker marker_oid=datalog.sync-status.shard.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.53 marker=G00000000000000000002@00000000000000000000:00000000000000000512
debug 2022-03-07T07:29:27.699+0000 7f0d5c862700 20 RGW-SYNC:data:sync:shard[53]: shard_id=53 sync_marker= next_marker=G00000000000000000002@00000000000000000000:00000000000000000512 truncated=0
...

여기서 Slave 가 요청한 Key에 raq003:81 dd7 c8 d-d1e5-4e6c-aa59-9d827 fec12c6.1750963.4:8라는 정보가 있는데 이를 bucket index에서 omap을 확인하면 업로드된 0101.txt 파일의 omap과 Bucket Index의 업데이트된 정보의 Omap 인 0_00000000001.15.5를 확인할 수 있다.

각각의 omap value를 확인하면 아래와 같이 bi log 정보 해당 업로드된 Object의 정보를 같이 알 수 있다.

root@cy02-test190:~# rados  -p zone-a.rgw.buckets.index listomapkeys .dir.81dd7c8d-d1e5-4e6c-aa59-9d827fec12c6.1750963.4.8
0101.txt
0_00000000001.15.5
...
000000  80 30 5f 30 30 30 30 30  30 30 30 30 30 31 2e 31  |.0_00000000001.1|
00000010  35 2e 35                                          |5.5|
00000013
 
value (237 bytes) :
00000000  04 01 e7 00 00 00 10 00  00 00 30 30 30 30 30 30  |..........000000|  <--- bi log 정보
00000010  30 30 30 30 31 2e 31 35  2e 35 08 00 00 00 30 31  |00001.15.5....01|
00000020  30 31 2e 74 78 74 47 b4  25 62 63 78 39 1a 01 01  |01.txtG.%bcx9...|
00000030  02 00 00 00 08 21 40 00  00 00 38 31 64 64 37 63  |.....!@...81dd7c|
00000040  38 64 2d 64 31 65 35 2d  34 65 36 63 2d 61 61 35  |8d-d1e5-4e6c-aa5|
00000050  39 2d 39 64 38 32 37 66  65 63 31 32 63 36 2e 31  |9-9d827fec12c6.1|
00000060  37 35 30 39 35 37 2e 38  32 33 37 33 34 33 30 31  |750957.823734301|
00000070  34 30 32 36 31 37 35 36  38 38 00 01 01 00 00 00  |4026175688......|
00000080  00 00 00 00 00 00 00 00  00 00 00 01 00 00 00 5a  |...............Z|
00000090  00 00 00 38 31 64 64 37  63 38 64 2d 64 31 65 35  |...81dd7c8d-d1e5|
000000a0  2d 34 65 36 63 2d 61 61  35 39 2d 39 64 38 32 37  |-4e6c-aa59-9d827|
000000b0  66 65 63 31 32 63 36 3a  72 61 71 30 30 33 3a 38  |fec12c6:raq003:8|
000000c0  31 64 64 37 63 38 64 2d  64 31 65 35 2d 34 65 36  |1dd7c8d-d1e5-4e6|
000000d0  63 2d 61 61 35 39 2d 39  64 38 32 37 66 65 63 31  |c-aa59-9d827fec1|
000000e0  32 63 36 2e 31 37 35 30  39 36 33 2e 34           |2c6.1750963.4|
000000ed
...
 
00000000  08 03 f3 00 00 00 08 00  00 00 30 31 30 31 2e 74  |..........0101.t| <--- data log 정보 -파일명
00000010  78 74 21 00 00 00 00 00  00 00 01 07 03 75 00 00  |xt!..........u..|
00000020  00 01 e0 06 00 00 00 00  00 00 47 b4 25 62 63 78  |..........G.%bcx|
00000030  39 1a 20 00 00 00 65 66  31 31 34 64 34 64 65 36  |9. ...ef114d4de6|<--- 파일의 eTag
00000040  31 32 39 64 66 64 39 34  33 36 61 35 35 39 33 66  |129dfd9436a5593f|
00000050  33 31 35 32 63 65 03 00  00 00 61 61 61 0e 00 00  |3152ce....aaa...|
00000060  00 41 64 6d 69 6e 20 41  50 49 20 55 73 65 72 0a  |.Admin API User.|
00000070  00 00 00 74 65 78 74 2f  70 6c 61 69 6e e0 06 00  |...text/plain...|<--- 파일의 속성
00000080  00 00 00 00 00 00 00 00  00 08 00 00 00 53 54 41  |.............STA|<--- 파일의 Storage Class
00000090  4e 44 41 52 44 00 00 00  00 00 00 00 00 00 01 01  |NDARD...........|
000000a0  02 00 00 00 08 21 01 40  00 00 00 38 31 64 64 37  |.....!.@...81dd7|<--- 파일의 Tag
000000b0  63 38 64 2d 64 31 65 35  2d 34 65 36 63 2d 61 61  |c8d-d1e5-4e6c-aa|
000000c0  35 39 2d 39 64 38 32 37  66 65 63 31 32 63 36 2e  |59-9d827fec12c6.|
000000d0  31 37 35 30 39 35 37 2e  38 32 33 37 33 34 33 30  |1750957.82373430|
000000e0  31 34 30 32 36 31 37 35  36 38 38 00 00 00 00 00  |14026175688.....|
000000f0  00 00 00 00 00 00 00 00  00                       |.........|
000000f9

'Ceph' 카테고리의 다른 글

Rook Oeperator 환경의 RGW MultiSite 구성 (1)	2021.03.07
Radosgw Object 저장과 삭제 과정 (0)	2021.03.04
Ceph zabbix plugin (0)	2018.05.18

« 2025/01 »
일	월	화	수	목	금	토
			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