본문 바로가기
Ceph

Radosgw Object 저장과 삭제 과정

raodsgw로 구성된 오브젝트 서비스에서 client 가 파일을 업로드 시 어떻게 ceph rados에 object로 저장되는 과정을 이야기하고자 한다.

how to upload object

테스트를 위하여 cy-zone-a 이름의 zone을 생성하여 해당이름의 pool들이 생성된 것을 확인할 수 있다. 지금은 버킷이나 오브젝트가 업로드된 것이 아닌 초기 상태이기 때문에 오브젝트가 없이 나온다.

# ceph osd pool ls
device_health_metrics
.rgw.root
cy-zone-a.rgw.log
cy-zone-a.rgw.control
cy-zone-a.rgw.meta
cy-zone-a.rgw.buckets.index
cy-zone-a.rgw.buckets.non-ec
cy-zone-a.rgw.buckets.data
 
# rados df
POOL_NAME                        USED  OBJECTS  CLONES  COPIES  MISSING_ON_PRIMARY  UNFOUND  DEGRADED  RD_OPS       RD  WR_OPS       WR  USED COMPR  UNDER COMPR
.rgw.root                     2.8 MiB       16       0      48                   0        0         0     231  231 KiB      46   30 KiB         0 B          0 B
cy-zone-a.rgw.buckets.data        0 B        0       0       0                   0        0         0       0      0 B       0      0 B         0 B          0 B
cy-zone-a.rgw.buckets.index       0 B        0       0       0                   0        0         0       0      0 B       0      0 B         0 B          0 B
cy-zone-a.rgw.buckets.non-ec      0 B        0       0       0                   0        0         0       0      0 B       0      0 B         0 B          0 B
cy-zone-a.rgw.control             0 B        8       0      24                   0        0         0       0      0 B       0      0 B         0 B          0 B
cy-zone-a.rgw.log             6.2 MiB      464       0    1392                   0        0         0    4096  3.6 MiB    3609  874 KiB         0 B          0 B
cy-zone-a.rgw.meta            768 KiB        4       0      12                   0        0         0       0      0 B       6    4 KiB         0 B          0 B

s3cmd 명령을 이용하여 "test" 이름의 버킷을 생성한다.

# s3cmd mb s3://test
Bucket 's3://test/' created

버킷을 생성후 해당  zone의 index pool에 11개의 오브젝특가 3벌 복제된것을 확인할 수 있다.

POOL_NAME                        USED  OBJECTS  CLONES  COPIES  MISSING_ON_PRIMARY  UNFOUND  DEGRADED  RD_OPS       RD  WR_OPS       WR  USED COMPR  UNDER COMPR
cy-zone-a.rgw.buckets.index       0 B        0       0       0                   0        0         0       0      0 B       0      0 B         0 B          0 B
(버킷 생성후)
cy-zone-a.rgw.buckets.index       0 B       11       0      33                   0        0         0       0      0 B      11      0 B         0 B          0 B

해당 test이름의 버킷을 보면 11 개의 shard로  "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1" 아이디로 구성된것을 확인할 수 있으며, rados 명령을 통하여 해당 rados object를 확인할 수 있다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin bucket  stats --bucket=test
{
    "bucket": "test",
    "num_shards": 11,
...
    "id": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1",
...
}
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.index
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.4
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.7
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.3
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.9
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.8
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.1
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.0
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.6
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.10
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.5
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.1.2
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.index | wc -l
11

1m 파일을 생성후 s3 client 를 이용해서 파일을 업로드를 하면 bucket.data pool 에 해당 object 가 [ Bucket ID+ Object Name ] 의 형태로 pool에 저장 되는것을 확인할 수 있다.

# fallocate -l 1M 1m.file
# s3cmd put  1m.file --acl-public s3://test/1m.file
upload: '1m.file' -> 's3://test/1m.file'  [1 of 1]
 1048576 of 1048576   100% in    0s    14.46 MB/s  done
# rados ls -p cy-zone-a.rgw.buckets.data
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_1m.file

5m 파일도 비슷하게 bueckt.data pool에 생성되는것을 확인 할 수 있다.

root@cy01-ceph231:/home/rook-1.5.6/cluster/examples/kubernetes/ceph# fallocate -l 5M 5m.f
ile
root@cy01-ceph231:/home/rook-1.5.6/cluster/examples/kubernetes/ceph# s3cmd put  5m.file -
-acl-public s3://test/5m.file
upload: '5m.file' -> 's3://test/5m.file'  [1 of 1]
 5242880 of 5242880   100% in    0s    34.48 MB/s  done
Public URL of the object is: http://test.rgw15.cyuucloud.xyz/5m.file
root@cy01-ceph231:/home/rook-1.5.6/cluster/examples/kubernetes/ceph#
 
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_5m.file
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_1m.file
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_.gYoRrJlB0wiZkn0PcqyEx6LdZDK-PHJ_1

multi-part upload(MPU)- 만일 큰 사이즈의 오브젝트는 어떻게 업로드 될까. 50M 사이즈의 파일을 생성 후 업로드를 하면 client 상으로 4번이 나눠져서 업로드되는것을 확인 할 수 있으며, 실제 pool에는 shadow파일과 multipart 파일로 나줘져서 생성된것을 볼수 있다. 4번이 나눠진것을 client 설정상으로 15m 를 multipart의 chunk로 설정되었기 때문에 client 입장에서 15m 씩 나눠서 업로드를 하게 된다.

root@cy01-ceph231:/home/rook-1.5.6/cluster/examples/kubernetes/ceph# fallocate -l 50M 50m
.file
root@cy01-ceph231:/home/rook-1.5.6/cluster/examples/kubernetes/ceph# s3cmd put  50m.file
--acl-public s3://test/50m.file
upload: '50m.file' -> 's3://test/50m.file'  [part 1 of 4, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    66.62 MB/s  done
upload: '50m.file' -> 's3://test/50m.file'  [part 2 of 4, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    70.49 MB/s  done
upload: '50m.file' -> 's3://test/50m.file'  [part 3 of 4, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    70.41 MB/s  done
upload: '50m.file' -> 's3://test/50m.file'  [part 4 of 4, 5MB] [1 of 1]
 5242880 of 5242880   100% in    0s    48.50 MB/s  done
Public URL of the object is: http://test.rgw15.cyuucloud.xyz/50m.file
 
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data  | grep 50m
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.4_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.4
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_2
 
root@cy01-ceph231:/home/rook-1.5.6/cluster/examples/kubernetes/ceph# cat ~/.s3cfg | grep multi
enable_multipart = True
multipart_chunk_size_mb = 15
multipart_max_chunks = 10000

shadow 오브젝트의 전체 사이즈와 multipart 오브젝트의 사이즈를 모두 합하면 실제 업로드 하였던 파일의 용량과 동일하다라는것을 확인할 수 있다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data  | grep shadow_50m.file | awk '{print "radosgw-admin object stat --object="$1 " |grep size"}' | sh
    "size": 4194304,
    "size": 3145728,
    "size": 3145728,
    "size": 1048576,
    "size": 3145728,
    "size": 4194304,
    "size": 4194304,
    "size": 4194304,
    "size": 4194304,
    "size": 4194304,
 
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data  | grep shadow_50m.file | awk '{print "radosgw-admin object stat --object="$1 "| jq .size " }' | sh |  awk '{sum += $1} END {print sum}'
35651584
 
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data  | grep multipart_50m.file | awk '{print "radosgw-admin object stat --object="$1 "
|grep size"}' | sh
    "size": 4194304,
    "size": 4194304,
    "size": 4194304,
    "size": 4194304,
 
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data  | grep multipart_50m.file | awk '{print "radosgw-admin object stat --object="$1 "| jq .size " }' | sh |  awk '{sum += $1} END {print sum}'
16777216
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# expr 35651584 + 16777216
52428800
root@cy01-ceph231:/home/rook-1.5.6/cluster/examples/kubernetes/ceph# ls -al 50m.file
-rw-r--r-- 1 root root 52428800 Mar  3 04:17 50m.file

그렇다면 4194304으로 나눠서 저장되는 이유는 무엇일까

radosgw 의 여러 설정중 "rgw_max_chunk_size" 설정 값이 있다. 해당 값은  RadosGW에서 RADOS 클러스터로 보내는 단일 IO의 크기이며 응용 프로그램 개체가 여러 RADOS 개체로 분할 될 때 첫 번째 개체 (head_obj)의 크기도 결정하기도 한다.

아래와 같이 "rgw_max_chunk_size" 값이 4194304 으로 설정 되어 있기 때문에 object는 radosgw 에서 rados 로 객체를 전달 한다. 그래서 위에서 1m 크기의 오브젝트를 업로드시에는 단일 오브젝트로 rados상으로 확인이 가능했던것이다. 

그에 비하여 50m 크기의 오브젝트는  첫번째 오브젝트가 rgw_max_chunk_size  크기의 오브젝트로 rados에 객체로 저장되고 나머지 는 rgw_obj_stripe_size 크기만큼 slice 되어 저장 된다.

즉,  아래 설정으로 4194304 보다 작은 개체 파일은 기본 RADOS에 하나의 개체 만 있지만 , 해당 크기보다  큰 개체 파일은 여러 개체 저장소로 분할된다. 참고로 rgw_obj_stripe_size 옵션은  Object Gateway 개체에 대한 개체 스트라이프의 크기로.기본값은 4m 이며 최대 20m 까지 설정 가능 하다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin --show-config  |grep rgw_max_chunk_size
rgw_max_chunk_size = 4194304
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin --show-config  |grep rgw_obj_stripe_size
rgw_obj_stripe_size = 4194304

shadow ,multipart 파일이 아닌 "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file" 을 확인 해보자. radosgw-admin 으로 확인 하면  용량이 52428800 즉 업로드 한 파일의 용량과 동일한것을 볼수 있지만, rados 명령으로 확인하면 크기가 0 이다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin object stat --object=bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file| jq .size
52428800
 
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados stat -p cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file
cy-zone-a.rgw.buckets.data/bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file mtime 2021-03-03T04:17:39.000000+0000, size 0

그이유는 radosgw-admin 으로 응답 받은 사이즈는 multipart 로 나줘진 오브젝트에서 begin_iter에서 end_iter 까지의 프리픽스의 오브젝트 사이즈를 모두 합친 실제 값인것이다.

즉, mulitipart 로 구성시 해당 파일이름의 오브젝트는 실제 데이터가 없이 나눠진 오브젝트의 정보만 출력 해주는 것이다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin object stat --object=bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file| jq .manifest.begin_iter.location.obj.key
{
  "name": "50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1",
  "instance": "",
  "ns": "multipart"
}
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin object stat --object=bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file| jq .manifest.end_iter.location.obj.key
{
  "name": "50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.5",
  "instance": "",
  "ns": "multipart"
}

해당 정보는 오브젝트에 데이터가 있는것이 아닌 getxattr 지시자로 manifest 파일을 확인할수 있으며 해당 manifest를 ceph-dencoder 명령으로 json 형태로 decode 하여 확인한 결과를 radosgw-admin 명령에서 stat 으로 전달 하는것을 확인할 수 있다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados -p cy-zone-a.rgw.buckets.data getxattr  bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file user.rgw.manifest  > user.rgw.manifest
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# ceph-dencoder type RGWObjManifest import user.rgw.manifest   decode dump_json
{
    "objs": [],
    "obj_size": 52428800,
    "explicit_objs": "false",
    "head_size": 0,
    "max_head_size": 0,
    "prefix": "50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q",
    "rules": [
        {
            "key": 0,
            "val": {
                "start_part_num": 1,
                "start_ofs": 0,
                "part_size": 15728640,
                "stripe_max_size": 4194304,
                "override_prefix": ""
            }
        },
        {
            "key": 47185920,
            "val": {
                "start_part_num": 4,
                "start_ofs": 47185920,
                "part_size": 5242880,
                "stripe_max_size": 4194304,
                "override_prefix": ""
            }
        }
    ],
...
    },
   "begin_iter": {
        "part_ofs": 0,
        "stripe_ofs": 0,
        "ofs": 0,
        "stripe_size": 4194304,
        "cur_part_id": 1,
        "cur_stripe": 0,
        "cur_override_prefix": "",
        "location": {
            "placement_rule": "default-placement",
            "obj": {
                "bucket": {
                    "name": "test",
                    "marker": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2",
                    "bucket_id": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2",
                    "tenant": "",
...
                "key": {
                    "name": "50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1",
                    "instance": "",
                    "ns": "multipart"
                }
...
    },
    "end_iter": {
        "part_ofs": 52428800,
        "stripe_ofs": 52428800,
        "ofs": 52428800,
...
            "placement_rule": "default-placement",
            "obj": {
                "bucket": {
                    "name": "test",
                    "marker": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2",
                    "bucket_id": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2",
                    "tenant": "",
...
                },
                "key": {
                    "name": "50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.5",
                    "instance": "",
                    "ns": "multipart"
                }
            },
            "raw_obj": {
                "pool": "",
                "oid": "",
                "loc": ""
            },
            "is_raw": false
        }
    }
}

그렇다면 shadow 오브젝트와 multipart  오브젝트는 어떻게 구성 되는지 확인해봐야 한다.

우선 처음에 업로드시 "multipart_chunk_size_mb" 옵션이 15m 으로 설정된 s3 client 에서 50m 파일을 15+15+15+5 이렇게 4번 나눠서 전송했던것을 기억해야 한다.

upload: '50m.file' -> 's3://test/50m.file'  [part 1 of 4, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    66.62 MB/s  done
upload: '50m.file' -> 's3://test/50m.file'  [part 2 of 4, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    70.49 MB/s  done
upload: '50m.file' -> 's3://test/50m.file'  [part 3 of 4, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    70.41 MB/s  done
upload: '50m.file' -> 's3://test/50m.file'  [part 4 of 4, 5MB] [1 of 1]
 5242880 of 5242880   100% in    0s    48.50 MB/s  done
Public URL of the object is: http://test.rgw15.cyuucloud.xyz/50m.file
# cat ~/.s3cfg | grep multi
enable_multipart = True
multipart_chunk_size_mb = 15
multipart_max_chunks = 10000

오브젝트 이름의 파일의 radosgw-admin 상으로  begin_iter.location.obj.key 의 프리픽스가 "50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1" 이름의 프리픽스라는것을 확인 할수 있다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin object stat --object=bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_50m.file| jq .manifest.begin_iter.location.obj.key
{
  "name": "50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1",
  "instance": "",
  "ns": "multipart"
}

아래와 같이 해당 프리픽스로 3개의 shadow파일과 3개의 multipart 파일 1개가 구성된것을 볼수 있다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]#  rados ls -p cy-zone-a.rgw.buckets.data | grep 50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1

각 오브젝트의 크기는 1개의 multipart  오브젝트가 4194304 이며 2개의 shadow 오브젝트가  4194304  이고 마지막 shadow 오브젝트가 3145728 이라는 사이즈를 확인할 수 있다.

모두 합치면 4194304+4194304+4194304+3145728  = 15728640 이라는  값을 확인할 수 있다. 

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data | grep 50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1| awk '{print "rados stat -p cy-zone-a.rgw.buckets.data "  $1}' | sh
cy-zone-a.rgw.buckets.data/bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_3 mtime 2021-03-03T04:17:38.000000+0000, size 3145728
cy-zone-a.rgw.buckets.data/bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_1 mtime 2021-03-03T04:17:38.000000+0000, size 4194304
cy-zone-a.rgw.buckets.data/bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_2 mtime 2021-03-03T04:17:38.000000+0000, size 4194304
cy-zone-a.rgw.buckets.data/bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1 mtime 2021-03-03T04:17:38.000000+0000, size 4194304

즉,  client 에서 multipart 로 업로드된 첫번째 오브젝트의 크기와 동일 하다.  radoswgw 로 업로드된 15728640 크기의 오브젝트가 radoswgw 에서 rados 로 업로드시 rgw_max_chunk_size 사이즈에 의하여 multipart 이름의 오브젝트가 해당 사이즈 만큼 나눠져서 업로드 되며 나머지 용량에 대하여 rgw_obj_stripe_size 사이즈 만큼 나눠서 보내고 남은 용량은 rgw_obj_stripe_size 보다 작은 사이즈로 업로드 된것을 알수 있다.

upload: '50m.file' -> 's3://test/50m.file'  [part 1 of 4, 15MB] [1 of 1]
 15728640 of 15728640   100% in    0s    66.62 MB/s  done

정리 하면 아래와 같이 client 가 s3cmd로 rados 오브젝트로 업로드 하는 과정을 정리 할 수 있다.

마지막으로 해당 rados object가 어떤 pg에 osd로 저장되고 있는지 확인해본다.

"ceph osd map" 명령으로 어떤 pg 의 osd 로 저장 되어 있고 어떤 primary osd 인지도 확인이 가능 하다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data | grep 50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q | awk '{print "ceph osd map cy-zone-a.rgw.buckets.data " $1}'
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_1
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_3
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_3
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.4_1
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.4
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_3
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_1
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_1
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_2
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_2
ceph osd map cy-zone-a.rgw.buckets.data bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_2
 
 
 
[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# rados ls -p cy-zone-a.rgw.buckets.data | grep 50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q | awk '{print "ceph o
sd map cy-zone-a.rgw.buckets.data " $1}' | sh
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3' -> pg 29.62194280 (29.0) -> up ([1,0,2], p1) acting ([1,0,2], p1)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_1' -> pg 29.86383a6c (29.c) -> up ([1,2,0], p1) acting ([1,2,0], p1)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_3' -> pg 29.7e692d7c (29.1c) -> up ([2,0,1], p2) acting ([2,0,1], p2)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_3' -> pg 29.39ca3d46 (29.6) -> up ([0,1,2], p0) acting ([0,1,2], p0)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.4_1' -> pg 29.91799056 (29.16) -> up ([2,1,0], p2) acting ([2,1,0], p2)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.4' -> pg 29.6182cdce (29.e) -> up ([0,2,1], p0) acting ([0,2,1], p0)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_3' -> pg 29.a63745e9 (29.9) -> up ([2,0,1], p2) acting ([2,0,1], p2)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_1' -> pg 29.5cbed9b9 (29.19) -> up ([1,2,0], p1) acting ([1,2,0], p1)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2' -> pg 29.618d4bcd (29.d) -> up ([2,1,0], p2) acting ([2,1,0], p2)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_1' -> pg 29.5a071bd (29.1d) -> up ([1,0,2], p1) acting ([1,0,2], p1)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_2' -> pg 29.1a513fbb (29.1b) -> up ([0,2,1], p0) acting ([0,2,1], p0)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1' -> pg 29.617ec407 (29.7) -> up ([2,1,0], p2) acting ([2,1,0], p2)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_2' -> pg 29.8254e397 (29.17) -> up ([1,2,0], p1) acting ([1,2,0], p1)
osdmap e667 pool 'cy-zone-a.rgw.buckets.data' (29) object 'bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_2' -> pg 29.6e8583cf (29.f) -> up ([0,1,2], p0) acting ([0,1,2], p0)

그렇다면 rgw 에서는 어떻게 object 가 있고 object가 어떤 pool 에 있고 또 어떠한 정보를 가지고 있는지 이러한 정보는 어디에 저장 될까 ?

RGW에서 저장된 Object의 Metadata는  bucket index pool 에  bucket index 형태로 Key-Value 맵 형태로 저장 된다.

맵 자체는 각 RADOS 객체와 연관된 omap에 보관되며 각 omap의 키는 객체의 이름이며 값은 해당 Object의 일부 기본 메타 데이터 (버킷을 나열 할 때 표시되는 메타 데이터)를 보유한다. 또한 각 omap에는 헤더가 있으며 해당 헤더에 일부 버킷 계정 메타 데이터 (객체 수, 총 크기 등)를 보관한다.

Bucket Index의  Rados Object 이름은 ".dir. <marker>"이며 marker는 Bucket 마다 고유하게 나타나는 프리픽스 같은 아이디 이다.

만일   Index가 Sharding 된 경우 각 Shard는 Marker 뒤에 Shard Index를 추가한다. 아래는 11개로 구성된 index shard 가 maker+shard 번호 로 구성된것을 볼수 있다.

#  radosgw-admin bucket stats --bucket=test
{
    "bucket": "test",
    "num_shards": 11, <<---------11개로 shard구성
    "tenant": "",
    "zonegroup": "8bb31efb-cd50-4796-82a8-e2f964c0701c",
    "placement_rule": "default-placement",
    "explicit_placement": {
        "data_pool": "",
        "data_extra_pool": "",
        "index_pool": ""
    },
    "id": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2",
    "marker": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2",   <<-----test 이름의 bucket 의 marker
    "index_type": "Normal",
    "owner": "cy-realm-system-user",
    "ver": "0#7,1#1,2#2,3#1,4#9,5#1,6#1,7#2,8#1,9#1,10#1",
    "master_ver": "0#0,1#0,2#0,3#0,4#0,5#0,6#0,7#0,8#0,9#0,10#0",
    "mtime": "2021-03-03T04:14:56.266183Z",
    "creation_time": "2021-03-03T04:14:56.256979Z",
    "max_marker": "0#,1#,2#,3#,4#,5#,6#,7#,8#,9#,10#",
    "usage": {
        "rgw.main": {
            "size": 6291456,
...
 
 
# rados ls -p cy-zone-a.rgw.buckets.index | grep bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2.9
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2.8
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2.2
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2.5
...
.dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2.1
 
# rados ls -p cy-zone-a.rgw.buckets.index | grep bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2 | wc -l
11

listomapkeys  지시자를 rados 명령으로 확인하면 해당 index shard 에 저장된 rgw object의 key 정보를 알 수 있다.

listomapvals 지시자로 확인 하면 해당 key 의 value를 확인할 수 있는데 261 byte 사이즈의 16진수 덤프 내용을 확인 할 수 있다.

해당내용으로 보면 "5m.file" 이라는 rgw object 이름과 rgw object의 etag 명 owner와  display owner이름 정보 및 tag 그리고 Standard라는 placement 정보 등을 확인할 수 있다.

다양한 정보중 etag 정보가 있다. 이는 객체의 MD5Sum이며 S3 호환성에 사용된다. (즉 생성 될 때 각 개체에 대해 MD5Sum을 계산)

물론 테스트한 결과에서 16진수 덤프가 표현 안된 부분도 동일 버킷 정보에 있을것으로 보인다.

#  rados -p rados -p   cy-zone-a.rgw.buckets.index  listomapkeys .dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2.2 indexfile
5m.file
#  rados -p rados -p   cy-zone-a.rgw.buckets.index  listomapvals .dir.bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2.2 indexfile
5m.file
value (261 bytes) :
00000000  08 03 ff 00 00 00 07 00  00 00 35 6d 2e 66 69 6c  |..........5m.fil|
00000010  65 06 00 00 00 00 00 00  00 01 07 03 93 00 00 00  |e...............|
00000020  01 00 00 50 00 00 00 00  00 b4 0d 3f 60 36 2a 04  |...P.......?`6*.|
00000030  33 20 00 00 00 35 66 33  36 33 65 30 65 35 38 61  |3 ...5f363e0e58a|
00000040  39 35 66 30 36 63 62 65  39 62 62 63 36 36 32 63  |95f06cbe9bbc662c|
00000050  35 64 66 62 36 14 00 00  00 63 79 2d 72 65 61 6c  |5dfb6....cy-real|
00000060  6d 2d 73 79 73 74 65 6d  2d 75 73 65 72 0d 00 00  |m-system-user...|
00000070  00 63 79 2d 72 65 61 6c  6d 2e 75 73 65 72 18 00  |.cy-realm.user..|
00000080  00 00 61 70 70 6c 69 63  61 74 69 6f 6e 2f 6f 63  |..application/oc|
00000090  74 65 74 2d 73 74 72 65  61 6d 00 00 50 00 00 00  |tet-stream..P...|
000000a0  00 00 00 00 00 00 08 00  00 00 53 54 41 4e 44 41  |..........STANDA|
000000b0  52 44 00 00 00 00 00 00  00 00 00 01 01 02 00 00  |RD..............|
000000c0  00 1d 06 01 2f 00 00 00  62 63 61 33 37 66 63 36  |..../...bca37fc6|
000000d0  2d 36 36 37 61 2d 34 33  64 36 2d 39 36 38 39 2d  |-667a-43d6-9689-|
000000e0  33 38 39 38 63 66 39 38  62 62 66 66 2e 31 34 38  |3898cf98bbff.148|
000000f0  36 33 37 2e 36 30 35 00  00 00 00 00 00 00 00 00  |637.605.........|
00000100  00 00 00 00 00                                    |.....|
00000105
 
# radosgw-admin bucket list --bucket=test
[
 ...
    {
        "name": "5m.file",      <--- bucket index
        "instance": "",
        "ver": {
            "pool": 29,
            "epoch": 6
        },
        "locator": "",
        "exists": "true",
        "meta": {
            "category": 1,
            "size": 5242880,
            "mtime": "2021-03-03T04:16:52.855910Z",
            "etag": "5f363e0e58a95f06cbe9bbc662c5dfb6",  <--- bucket index
            "storage_class": "STANDARD",  <--- bucket index
            "owner": "cy-realm-system-user",  <--- bucket index
            "owner_display_name": "cy-realm.user",  <--- bucket index
            "content_type": "application/octet-stream",  <--- bucket index
            "accounted_size": 5242880,
            "user_data": "",
            "appendable": "false"
        },
        "tag": "bca37fc6-667a-43d6-9689-3898cf98bbff.148637.605",  <--- bucket index
        "flags": 0,
        "pending_map": [],
        "versioned_epoch": 0
    }

 

how to delete object

이제 업로드된 파일을 삭제해본다.

root@cy01-ceph231:~# s3cmd rm  s3://test/50m.file
delete: 's3://test/50m.file'

파일을 삭제 했지만 bucket.data pool에서는 업로드된 파일명의 오브젝트는 삭제되었지만 shadow,multipart 오브젝트가 남아 있는것을 볼수 있다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]#  rados ls -p cy-zone-a.rgw.buckets.data
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_5m.file
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.4_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.4
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2_1m.file
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.2_2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_.gYoRrJlB0wiZkn0PcqyEx6LdZDK-PHJ_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.3_2

RGW는 새로운 Object와 덮어 쓴 Object에 대한 Storage로 바로 할당 하며 , Multipart ,Shadow Object 업로드에 대하여 Storage를 사용한다.

RGW가 Bucket Index에서 Object를 삭제한 후 Storage에 삭제된 개체에 사용된 스토리지 공간을 정리한다.

또한 Multipart 업로드가 완료된 후 또는 구성 가능한 시간 동안 업로드가 비활성 상태가 되거나 완료되지 못한 경우 Multipart 업로드와 관련된 데이터를 삭제하게 된다.

이러한 삭제된 Objcet 데이터를 삭제하는 프로세스를  Garbage Collection(GC)라고 한다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin gc list --include-all
[
    {
        "tag": "bca37fc6-667a-43d6-9689-3898cf98bbff.148637.617\u0000",
        "time": "2021-03-03T10:35:55.598149+0000",
        "objs": [
            {
                "pool": "cy-zone-a.rgw.buckets.data",
                "oid": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1",
                "key": "",
                "instance": ""
            },
            {
                "pool": "cy-zone-a.rgw.buckets.data",
                "oid": "bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_50m.file.2~Uf7o7m01c0AHiTSS80LRhmlqSb_g24Q.1_1",
                "key": "",
                "instance": ""
            },
...

GC는  구성하는 방법에 따라 로드가 적은 시간 동안 또는 연속적으로 실행될 수 있는 백그라운드 작업이다. 기본적으로 Ceph Object Gateway는 GC 작업을 지속적으로 수행한다.

GC 작업은 Ceph Object Gateway 작업의 일반적인 부분이며, 특히 객체 삭제 작업의 경우 GC에 적합한 개체가 대부분 존재한다.

일부 워크로드는 GC 작업 속도를 일시적으로 또는 영구적으로 초과할 수 있다.

이는 특히 많은 개체가 짧은 시간 동안 저장되었다가 삭제되는 삭제 집약적인 워크로드의 경우에 해당된다.

이러한 워크로드 유형의 경우 관리자는 다음과 같은 구성 매개 변수를 사용하여 다른 작업에 비해 GC 작업의 우선 순위를 높일 수 있다.

우선 기본 설정된 GC와 관련된 설정은 아래와 같이 확인할 수 있다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]# radosgw-admin --show-config | grep rgw_gc_
rgw_gc_max_concurrent_io = 10
rgw_gc_max_deferred = 50
rgw_gc_max_deferred_entries_size = 3072
rgw_gc_max_objs = 32
rgw_gc_max_queue_size = 134213632
rgw_gc_max_trim_chunk = 16
rgw_gc_obj_min_wait = 7200
rgw_gc_processor_max_time = 3600
rgw_gc_processor_period = 3600
  • rgw_gc_obj_min_wait 는 삭제 된 Object의 데이터를 제거하기 전에 최소 초 동안 대기한다.
    기본적으로 2 시간으로 설정된다. 과중한 워크로드 삭제에서이 설정은 스토리지를 너무 많이 사용하거나 제거 할 삭제 된 개체를 많이 남길 수 있는 경우 해당 설정을 더 짧은 시간 간격으로 줄이는 것이 좋다.
  • rgw_gc_processor_period 는 GC주기 런타임으로  GC 스레드의 연속 실행 시작 사이의 시간으로 두 개의 연속 GC 처리주기 시작 사이의 최대 시간으로 볼수 있다.
    GC 실행이이 기간보다 오래 걸리는 경우RGW는 GC주기를 다시 실행하기 전에 기다리지 않는다
  • rgw_gc_max_concurrent_io 는 게이트웨이 GC스레드가 삭제 된 데이터를 제거 할 때 사용할 최대 동시 IO 작업 수를 지정한다.
    과중한 워크로드 삭제에서이 설정을 더 많은 수의 동시 IO 작업으로 늘리는 것이 좋다.
  • rgw_gc_max_trim_chunk 는 단일 작업으로 GC 로그에서 제거 할 최대 키 수를 지정한다. 무거운 작업을 삭제하는 경우 각 GC 작업 중에 더 많은 개체가 제거되도록 최대 키 수를 늘리는 것이 좋다.
  • rgw_gc_max_objs는 한 GC 처리주기에서 GC로 처리 할 수있는 최대 Object 수이다. 기본값은 32이다.

위 기본 설정을 바탕으로 2시간 이후 다시 오브젝트를 확인하면 파일이 삭제 된것을 볼수 있다.

[root@rook-ceph-tools-7bf6744b9c-mxgd8 /]#  rados ls -p cy-zone-a.rgw.buckets.data | grep 50m | wc -l
0

만일 GC 프로세스를 강제로 실행할 경우 아래와 같이 진행하면 현재 GC 리스트에 있는 Object에 대하여 정리 하게 된다.

# radosgw-admin gc process --include-all

하지만 업로드중간에 잘못된 Object나 버그 등으로 GC로 처리가 안되서 정리가 안된 Object가 있을수 있다. 이러한 경우를 Orpahns 로 불린다.

Orphans는 연관된 후 남겨지는 RADOS Objcet로 있으며, 이러한 Object는 사용하지 않고 Ceph 클러스터의 공간을 불필요하게  소모한다.

rgw-orphan-list 명령을 사용하면 해당 pool 에 Orpahns 된 상태의 Rados Object를 확인할 수 있다.  해당 output 파일을 확인 하여 rados 명령으로 삭제 하여 정리할 수 있다.

# rgw-orphan-list
Available pools:
    device_health_metrics
    .rgw.root
    cy-zone-a.rgw.log
    cy-zone-a.rgw.control
    cy-zone-a.rgw.meta
    cy-zone-a.rgw.buckets.index
    cy-zone-a.rgw.buckets.non-ec
    cy-zone-a.rgw.buckets.data
Which pool do you want to search for orphans? cy-zone-a.rgw.buckets.data
Pool is "cy-zone-a.rgw.buckets.data".
Note: output files produced will be tagged with the current timestamp -- 20210304051316.
running 'rados ls' at Thu Mar  4 05:13:22 UTC 2021
running 'radosgw-admin bucket radoslist' at Thu Mar  4 05:13:22 UTC 2021
computing delta at Thu Mar  4 05:13:23 UTC 2021
8 potential orphans found out of a possible 12 (66%).  <<----출력된 결과
The results can be found in './orphan-list-20210304051316.out'.
    Intermediate files are './rados-20210304051316.intermediate' and './radosgw-admin-20210304051316.intermediate'.
***
*** WARNING: This is EXPERIMENTAL code and the results should be used
***          only with CAUTION!
***
Done at Thu Mar  4 05:13:23 UTC 2021.
 
 
# cat ./orphan-list-20210304051316.out
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_30m-2.2~ZiqOqxcHq2BAOM9FL2DUXtr8Qj5dpCM.1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__multipart_30m-2.2~ZiqOqxcHq2BAOM9FL2DUXtr8Qj5dpCM.2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_30m-2.2~ZiqOqxcHq2BAOM9FL2DUXtr8Qj5dpCM.1_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_30m-2.2~ZiqOqxcHq2BAOM9FL2DUXtr8Qj5dpCM.1_2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_30m-2.2~ZiqOqxcHq2BAOM9FL2DUXtr8Qj5dpCM.1_3
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_30m-2.2~ZiqOqxcHq2BAOM9FL2DUXtr8Qj5dpCM.2_1
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_30m-2.2~ZiqOqxcHq2BAOM9FL2DUXtr8Qj5dpCM.2_2
bca37fc6-667a-43d6-9689-3898cf98bbff.128805.2__shadow_30m-2.2~ZiqOqxcHq2BAOM9FL2DUXtr8Qj5dpCM.2_3

 

참고사이트

allthenodes.wordpress.com/2016/01/29/how-indexes-work-in-ceph-rados-gateway/

access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/ceph_object_gateway_for_production/assembly-configuring-a-cluster-rgw-adv

bean-li.github.io/how-s3-data-store-in-ceph/

levelup.gitconnected.com/ceph-what-is-multipart-upload-omap-and-resharding-b72d339c939f

www.redhat.com/en/blog/ceph-rgw-dynamic-bucket-sharding-performance-investigation-and-guidance

www.programmersought.com/article/6322527394/

반응형

'Ceph' 카테고리의 다른 글

Ceph Pacific 버전의 Multi-site 구성 동기화 과정  (0) 2022.03.07
Rook Oeperator 환경의 RGW MultiSite 구성  (1) 2021.03.07
Ceph zabbix plugin  (0) 2018.05.18