Ceph Object Storage Deep Dive Series. Part 2

Đi sâu vào Ceph RGW: Data Path, Sharding và cơ chế quản lý tự động ¶

Giới thiệu ¶

Ở phần đầu tiên của loạt deep dive này, chúng ta đã mổ xẻ đường đi hiệu năng cao của một request bên trong Ceph RGW. Chúng ta đã đi qua các frontend stateless, những RADOS pool nền tảng, và bucket index đầy quan trọng — qua đó thấy được cách dynamic sharding mở ra khả năng mở rộng gần như vô hạn cho việc liệt kê object trong một bucket duy nhất.

Chúng ta đã hiểu cách RGW định vị và liệt kê object hiệu quả ở quy mô lớn. Giờ thì hãy chuyển trọng tâm từ index sang chính bản thân các object và hệ thống rộng hơn đang quản lý chúng. Trong phần deep dive thứ hai này, chúng ta sẽ khám phá control plane thông qua việc xem xét RGW metadata layout. Sau đó, ta sẽ tìm hiểu S3 object được lưu trữ vật lý ra sao thông qua mô hình dữ liệu head/tail, và khép lại bằng cái nhìn về những tiến trình nền tối quan trọng — Garbage Collection và Lifecycle Management — thứ tự động hóa việc quản trị dữ liệu.

RGW Metadata Layout: Bản thiết kế của Control Plane ¶

Giống như dữ liệu của một S3 object được tổ chức tỉ mỉ trên RADOS, toàn bộ state của hệ thống RGW — user, bucket và các policy — cũng được lưu bền vững trong những RADOS pool dành riêng. Thiết kế này chính là nền tảng cho bản chất stateless của các RGW daemon: mọi thông tin control plane đều nằm trong cluster, chứ không nằm trên gateway. Phần metadata này chủ yếu được đặt trong .rgw.meta pool, trong khi các log vận hành cho những tiến trình như garbage collection và lifecycle management thì nằm ở pool .rgw.log.

Các metadata object này được lưu ở định dạng binary nội bộ. Vì vậy, việc dùng công cụ dòng lệnh radosgw-admin để quản trị và tương tác là điều bắt buộc. Tiện ích này giải mã đáng tin cậy các bản ghi binary thành JSON mà con người đọc được, đồng thời đảm bảo mọi thay đổi đều được thực hiện một cách an toàn.

Lưu ý: Tuyệt đối không được sửa trực tiếp các object trong pool .rgw.meta bằng công cụ rados.

Các nhóm Metadata chính ¶

Pool .rgw.meta dùng RADOS namespace để phân tách các loại thông tin khác nhau ở mức logic. Khi truy vấn metadata, bạn sẽ gặp một số category ở cấp cao nhất:

user: Lưu các bản ghi S3 user, bao gồm access key, capability, quota sử dụng và thông tin liên hệ như email.
bucket: Bản ghi bucket ở mức tên gọi cấp cao. Nó chứa những thông tin thiết yếu như owner của bucket, placement policy (bucket thuộc zone nào) và nhiều flag khác nhau.
bucket.instance: Đại diện cho instance vật lý, cụ thể của một bucket. Bản ghi này theo dõi ID duy nhất của bucket, số shard của index, trạng thái versioning và thời điểm tạo. Một tên bucket có thể có nhiều instance trong suốt vòng đời của nó, chẳng hạn khi bị xóa rồi tạo lại.
roles: Chứa các định nghĩa STS (Security Token Service) và IAM role, được policy evaluation engine dùng để cấp credential tạm thời.
group: Định nghĩa các user group, có thể dùng cho các thao tác quản trị hoặc quản lý policy.
topic: Lưu cấu hình cho S3 bucket event notification.
otp: Giữ credential one-time password phục vụ multi-factor authentication.
account: Dùng cho Swift account metadata nếu Swift API được bật.

Xem xét Metadata bằng radosgw-admin ¶

Công cụ `radosgw-admin cung cấp cách an toàn và có cấu trúc để khám phá dữ liệu control plane này. Trước hết, bạn có thể liệt kê tất cả metadata category hiện có:

$ radosgw-admin metadata list
[
    "user",
    "bucket",
    "bucket.instance",
    "roles",
    ...
]
$ radosgw-admin metadata list account
[
    "RGW42603947660038067",
    "RGW46950437120753278",
    "RGW40572530565246530",
    "RGW66892093834478914",
    "RGW63384910224424377",
    "RGW94705908964376531",
    "RGW25531238860968914"
]

Tiếp theo, liệt kê các key cụ thể bên trong một category, ví dụ bucket hoặc bucket.instance:

# List all bucket names
$ radosgw-admin metadata list bucket | grep bucket1
   "bucket1",

# List all concrete bucket instances
$ radosgw-admin metadata list bucket.instance | grep bucket1
"bucket1:7fb0a3df-9553-4a76-938d-d23711e67677.34162.1",

Cuối cùng, đây là ví dụ lấy về và giải mã một bản ghi cụ thể thông qua key của nó. Đưa output qua jq sẽ giúp định dạng JSON dễ đọc hơn:

# Get bucket metadata by its name
$ radosgw-admin metadata get bucket:bucket1 | jq .

# Get a user record by their UID
$ radosgw-admin metadata get user:my-user-id | jq .

Cũng cần nhắc rằng radosgw-admin giúp cuộc sống của chúng ta dễ thở hơn nhiều nhờ các tham số CLI chuyên biệt để tương tác trực tiếp với đám metadata này. Ví dụ: radosgw-admin user, radosgw-admin account, radosgw-admin bucket, v.v.

Kết nối Metadata với mức sử dụng thực tế ¶

Để nối liền khoảng cách giữa metadata trừu tượng và mức sử dụng ngoài đời thực, radosgw-admin cung cấp các lệnh tổng hợp thông tin này:

# Get detailed stats for a bucket, including its shard count, object count, and size
$ radosgw-admin bucket stats --bucket <BUCKET_NAME> | jq .

# Get the complete metadata for a single object as RGW sees it
$ radosgw-admin object stat --bucket <BUCKET_NAME> --object <OBJECT_KEY> | jq .

Lệnh object stat này rất tiện, vì nó cho bạn thấy manifest, thông tin placement và toàn bộ system attribute của một S3 object cụ thể — tức là một bức tranh đầy đủ dưới góc nhìn của gateway.

RGW Data Layout: Mô hình Head/Tail Object ¶

Một S3 object ở mức logic thường được cấu thành từ nhiều RADOS object vật lý. RGW sử dụng mô hình head/tail object linh hoạt, cho phép tối ưu cho nhiều kích thước file khác nhau cũng như các thao tác phức tạp như MultiPart Upload (MPU).

RADOS object chính gắn với bất kỳ S3 object nào được gọi là head object. Tên RADOS object của nó thường được tạo bằng cách ghép marker nội bộ của bucket với key của object, ngăn cách bởi dấu gạch dưới, ví dụ <bucket_marker>_<object_key>. Head object phục vụ hai mục đích chính. Thứ nhất, nó là nơi lưu trữ chính thống cho toàn bộ metadata ở mức object, bao gồm ACL, HTTP content type, ETag và mọi metadata do người dùng tự định nghĩa. Thông tin này được lưu hiệu quả dưới dạng RADOS extended attribute (xattr) trên head object. Thứ hai, với các object nhỏ (mặc định là những object có kích thước tối đa bằng giá trị cấu hình được rgw_max_chunk_size), toàn bộ payload dữ liệu của S3 object sẽ được lưu thẳng vào phần data của head object. Đây là một tối ưu hiệu năng rất quan trọng, vì nó cho phép ghi cả dữ liệu lẫn metadata đi kèm vào cluster trong một thao tác RADOS duy nhất mang tính nguyên tử, giảm thiểu I/O amplification và độ trễ cho các workload nhiều file nhỏ.

Với những object vượt quá kích thước lưu inline này, phần data payload của head object sẽ được dùng để chứa một manifest. Manifest là một cấu trúc metadata mô tả phần dữ liệu còn lại của object được bố trí vật lý ra sao trên cluster. Nó chứa danh sách có thứ tự các RADOS object khác — gọi là tail object — nơi giữ những chunk dữ liệu còn lại. Mỗi entry trong manifest chỉ rõ tên của một tail object, kích thước của nó, và offset logic của nó bên trong toàn bộ S3 object.

Nếu kích thước object vượt quá rgw_max_chunk_size (mặc định: 4MB), dữ liệu sẽ được stripe trên nhiều RADOS object: một head object (chỉ chứa metadata/manifest) và một hoặc nhiều tail object (giữ phần dữ liệu chính).

Ta có thể lấy giá trị striping size mặc định — thứ quyết định khi nào dữ liệu bị chia nhỏ:

$ ceph config get mon rgw_obj_stripe_size
4194304

Output này xác nhận RGW object stripe size mặc định là 4.194.304 byte (4MB).

Sự tương tác giữa part size do client quy định và striping size nội bộ của RGW (rgw_obj_stripe_size) có thể tạo ra những tail object với tên gọi rất đặc trưng. Nếu client upload một part (ví dụ 5 MiB) lớn hơn RGW stripe size (ví dụ 4 MiB), RGW sẽ tự động stripe part đó ra nhiều RADOS object. Chẳng hạn, nó có thể tạo một object 4 MiB với tiền tố __multipart nếu dùng MPU, và một object 1 MiB với tiền tố __shadow để giữ phần dư còn lại. Đây đơn giản chỉ là các tail object có tên theo một quy ước nhất định, và cả hai đều được tham chiếu chính xác trong manifest cuối cùng.

Ở đây, ta quan sát head object của một file lớn:

$ aws --endpoint=http://ceph-node02:8080 s3 cp awscliv2.zip s3://bucket1/bigfile
$ aws --endpoint=http://ceph-node02:8080 s3 ls s3://bucket1/bigfile
2022-12-20 15:10:16   20971520 bigfile
$ rados -p default.rgw.buckets.data ls | grep bigfile$
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1_bigfile

Đây chính là head object của bigfile. Nó chứa metadata xattr của object, trong đó có user.rgw.manifest — thứ liệt kê vị trí của toàn bộ tail object.

Head object lưu metadata của nó một cách hiệu quả dưới dạng extended attribute:

$ rados -p default.rgw.buckets.data listxattr 7fb0a3df-9553-4a76-938d-d23711e67677.34162.1_bigfile
user.rgw.acl
user.rgw.content_type
user.rgw.etag
user.rgw.idtag
user.rgw.manifest
user.rgw.pg_ver
user.rgw.source_zone
user.rgw.tail_tag
user.rgw.x-amz-content-sha256
user.rgw.x-amz-date

Danh sách extended attribute (xattr) ở trên xác nhận rằng head object lưu giữ những metadata quan trọng của object, đáng chú ý nhất là user.rgw.manifest, mô tả cách payload dữ liệu của object lớn được chia ra thành các tail object.

Lệnh radosgw-admin object stat có thể cho ta thấy phần striping/parts trong manifest của object thông qua RGW metadata:

$ radosgw-admin object stat --bucket BUCKET --object OBJECT | jq .

Các tail object trong ví dụ của chúng ta:

# rados -p default.rgw.buckets.data ls | grep shadow_bigfile
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_bigfile.2~E_PYNwiBq0la0EuZcCOY30KgmRrf1pV.1_1
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_bigfile.2~E_PYNwiBq0la0EuZcCOY30KgmRrf1pV.2_1

Các tail object thường giữ những chunk dữ liệu 4MB:

default.rgw.buckets.data/7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_bigfile.2_E_PYNwiBq0la0EuZcCOY30KgmRrf1pV.1_1 mtime 2022-12-20T15:10:16.000000-0500, size 4194304

S3 Multipart Upload: Một thao tác Atomic Commit ¶

Tính năng S3 Multipart Upload (MPU) được thiết kế để upload các object lớn một cách hiệu quả, bằng cách chia chúng thành nhiều phần nhỏ có thể upload độc lập và song song. RGW hiện thực điều này rất khéo léo dưới dạng một thao tác commit thuần metadata.

Quy trình gồm ba bước chính:

Multipart Upload Initiation: Gửi một request để lấy về một Upload ID duy nhất.
Parts Upload: Từng part được upload lên bằng cách dùng cả Upload ID lẫn một Part ID riêng. Mỗi part được lưu như một RADOS object tạm thời, tách biệt. Nếu kích thước một part vượt quá RGW stripe size (mặc định 4MB), nó sẽ được chia nhỏ ở bên trong.
Multipart Upload Completion (Atomic Commit): Khi toàn bộ part đã được upload, client gửi request hoàn tất. RGW tránh việc copy dữ liệu tốn kém. Thay vào đó, nó tạo head object cuối cùng và điền vào manifest nội bộ của head object các con trỏ tới những RADOS object tạm cấu thành các part. Kết quả là thao tác hoàn tất diễn ra gần như tức thì.

Thiết kế này khiến việc hoàn tất upload một object lớn gần như tức thời dưới góc nhìn của cluster. Trong trường hợp này, bản thân head object không chứa dữ liệu người dùng nào cả — đó là lý do các công cụ ở mức thấp sẽ báo kích thước của nó là 0 byte; payload của nó là manifest, không phải nội dung object.

Cấu trúc MPU trong RADOS ¶

Khi một file được upload theo từng chunk (ví dụ chunk 5MB) trong khi RGW stripe width là 4 MiB, RGW sẽ tự lo phần chia nhỏ bên trong: nó lấy 4 MiB đầu để tạo một RADOS object "multipart", và 1 MiB còn lại để tạo một RADOS tail object "shadow".

Hãy cùng kiểm chứng bằng một ví dụ. Ta sẽ đặt chunk size phía client là 5 MiB, rồi upload một file 20 MiB:

$ aws configure set default.s3.multipart_chunksize 5MB
$ aws --endpoint=http://ceph-node02:8080 s3 cp text.txt s3://bucket1/5chuncks

Ta gửi các chunk 5 MiB tới RGW, trong khi RGW có stripe width là 4 MiB, nghĩa là RGW sẽ lấy 4 MiB đầu tiên để tạo một RADOS object "multipart", rồi tạo tiếp một RADOS tail object "shadow" 1 MiB.

$ rados -p default.rgw.buckets.data ls | grep 5chuncks
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.2_1
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__multipart_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.2
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.3_1
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.4_1
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__multipart_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.4
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.1_1
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__multipart_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.3
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1_5chuncks
7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__multipart_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.1

Output cho thấy các thành phần được tạo ra, bao gồm head object cuối cùng (..._5chuncks), cùng với nhiều object multipart và shadow tương ứng với các part đã bị stripe.

Việc kiểm tra kích thước của những object này minh họa rõ logic chia nhỏ của RGW: RADOS object multipart phần đầu có kích thước 4 MiB, còn RADOS object phần đuôi (shadow) là 1 MiB.

# Check the size of the main 4MB chunk
$ rados -p default.rgw.buckets.data stat 7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__multipart_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.2
default.rgw.buckets.data/7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__multipart_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.2 mtime 2022-12-21T03:07:49.000000-0500, size 4194304

# Check the size of the remaining 1MB chunk
$ rados -p default.rgw.buckets.data stat 7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.2_1
default.rgw.buckets.data/7fb0a3df-9553-4a76-938d-d23711e67677.34162.1__shadow_5chuncks.2_r3yyxqL2hYs5DW32L9UXR3uawF4VEKL.2_1 mtime 2022-12-21T03:07:49.000000-0500, size 1048576

Các part này không hề được ghép lại hay gộp lại trong RADOS: đây chính là trạng thái cuối cùng của chúng.

Cuối cùng, head RADOS object của S3 object đã hoàn tất chỉ chứa metadata manifest, và đó là lý do nó báo kích thước bằng 0 byte ở mức RADOS:

$ rados -p default.rgw.buckets.data stat 7fb0a3df-9553-4a76-938d-d23711e67677.34162.1_5chuncks
default.rgw.buckets.data/7fb0a3df-9553-4a76-938d-d23711e67677.34162.1_5chuncks mtime 2022-12-21T03:07:49.000000-0500, size 0

Thông tin chi tiết hơn về Multipart Upload có thể xem tại AWS Multipart Upload.

Garbage Collector (GC) bất đồng bộ ¶

Khi client xóa S3 object hoặc ghi đè lên chúng, các RADOS object bên dưới không bị xóa ngay lập tức. Chức năng chính của thao tác xóa object là cập nhật bucket index (hoặc đặt một delete marker nếu versioning đang bật). Một khi S3 object đã bị gỡ khỏi index, các RADOS object bên dưới nó trên thực tế trở thành "mồ côi".

Những RADOS object mồ côi này sau đó được đưa vào hàng đợi Garbage Collection (GC). Garbage Collector là một tiến trình nền tối quan trọng trong RGW, chịu trách nhiệm thu hồi bất đồng bộ phần dung lượng lưu trữ mà các object đã xóa đang chiếm giữ. Thiết kế này đảm bảo các request DELETE từ client trả về nhanh chóng mà không phải chờ quá trình xóa dữ liệu vật lý vốn rất chậm.

Với những workload có tốc độ churn object cao (tạo và xóa liên tục), tiến trình GC có thể bị tụt lại phía sau, khiến dung lượng có thể thu hồi bị dồn ứ. Để xử lý, quản trị viên có thể tinh chỉnh một số tham số quan trọng nhằm khiến GC hoạt động quyết liệt hơn:

rgw_gc_obj_min_wait: Khoảng thời gian tối thiểu trước khi một object đã xóa đủ điều kiện được thu hồi. Giảm giá trị này (mặc định là 2 giờ) sẽ đẩy nhanh tốc độ thu hồi dung lượng.
rgw_gc_max_concurrent_io: Số thao tác RADOS delete song song mà một GC thread có thể phát ra. Tăng giá trị này lên so với mặc định 10 cho phép GC xử lý nhiều object cùng lúc hơn, đổi lại là mức I/O nền trên cluster cao hơn.
rgw_gc_processor_period: Khoảng thời gian giữa các chu kỳ xử lý GC. Giá trị càng thấp thì GC thread chạy càng thường xuyên.
rgw_gc_max_trim_chunk: Số lượng log entry được xử lý trong một batch.

Ta có thể dùng các lệnh dưới đây để liệt kê tất cả object đang được xếp lịch xóa:

$ radosgw-admin gc list
$ radosgw-admin gc list --include-all

Mặc định, Ceph chờ 2 giờ giữa các chu kỳ GC. Để chạy tiến trình xóa của GC một cách thủ công, hãy chạy:

$ radosgw-admin gc process --include-all

Lệnh này có thể được thực thi để ép Garbage Collector xử lý phần tồn đọng của nó một cách thủ công, giúp thu hồi dung lượng nhanh chóng mà không phải chờ tới lần chạy theo lịch tiếp theo.

Lưu ý: Option rgw_gc_max_objs KHÔNG BAO GIỜ nên bị thay đổi khỏi giá trị mặc định trên một cluster đang chạy. Giá trị này chỉ nên được điều chỉnh (nếu thật sự cần) trước khi triển khai các RGW.

Cũng lưu ý thêm: radosgw-admin có thể nhận tham số --bypass-gc để xóa ngay phần storage bên dưới, nhưng chúng tôi khuyến cáo mạnh mẽ là không nên dùng option này.

Những hệ thống có mức churn S3 object rất cao cũng có thể thấy hữu ích khi triển khai một nhóm RGW daemon riêng chỉ chuyên xử lý các sự kiện GC, đồng thời tắt GC ở nhóm RGW phục vụ client.

Lifecycle (LC) Management ¶

Engine Lifecycle (LC) Management tự động hóa việc quản lý dữ liệu dựa trên các policy do người dùng định nghĩa và áp lên bucket. Những policy này gồm các rule kích hoạt hành động dựa trên tuổi của object hoặc các tiêu chí khác. Các hành động thường gặp gồm Expiration — xóa object, và Transition — chuyển object sang một storage class khác. Lifecycle Transition có thể được định nghĩa giữa các storage class (Tier) bất kỳ bên trong một cluster, hoặc tới các endpoint bên ngoài tương thích S3 như AWS, IBM Cloud hay các S3 Tape endpoint:

Bạn có thể tinh chỉnh S3 Lifecycle expiration trong RGW bằng các filter chi tiết:

Phân biệt phiên bản object Current và Noncurrent
Xóa các delete marker (ExpiredObjectDeleteMarker)
Tự động hủy các multipart upload còn dang dở (AbortIncompleteMultipartUpload)
Giới hạn số phiên bản cũ được giữ lại thông qua NewerNoncurrentVersions
Khoanh vùng rule theo kích thước object bằng ObjectSizeGreaterThan và ObjectSizeLessThan

Những filter này, kết hợp với việc dùng S3 Tag, có thể được phối hợp với nhau để kiểm soát hành vi dọn dẹp ở quy mô lớn với độ chi tiết cực kỳ cao.

Engine LC được hiện thực dưới dạng một tập các worker process đa luồng. Các worker này định kỳ quét bucket index trên toàn cluster. Với mỗi object gặp phải, chúng đánh giá các thuộc tính của object đó so với lifecycle policy của bucket. Nếu điều kiện của một rule được thỏa mãn, hành động tương ứng sẽ được thực thi. Hành động Expiration về bản chất kích hoạt một thao tác delete tiêu chuẩn: gỡ index entry của object và đưa dữ liệu của nó vào hàng đợi GC. Hành động Transition bao gồm việc copy dữ liệu của object sang storage pool đích (có thể nằm trên một tầng media khác, hoặc thậm chí là một cloud tier từ xa), rồi cập nhật metadata của object để phản ánh vị trí mới. Để scale trên các cluster lớn, mức độ song song của LC engine có thể tinh chỉnh:

rgw_lc_max_worker: Điều khiển số worker thread chính, vốn xử lý song song nhiều bucket index shard. Nên tăng giá trị này với những cluster có số lượng bucket cực lớn.
rgw_lc_max_wp_worker: Định nghĩa số sub-thread trong pool của mỗi worker, xử lý song song các object bên trong cùng một shard. Nên tăng giá trị này với những cluster chỉ có vài bucket nhưng mỗi bucket chứa cực kỳ nhiều S3 object.

Dưới đây là lệnh radosgw-admin liệt kê các LC job đã được cấu hình trong cluster:

$ radosgw-admin lc list | jq .
[
  {
    "bucket": ":ingest:fcabdf4a-86f2-452f-a13f-e0902685c655.47553.1",
    "shard": "lc.0",
    "started": "Sat, 11 Oct 2025 11:20:59 GMT",
    "status": "COMPLETE"
  },
  {
    "bucket": ":tierbucket:fcabdf4a-86f2-452f-a13f-e0902685c655.323278.10",
    "shard": "lc.3",
    "started": "Sat, 11 Oct 2025 11:20:56 GMT",
    "status": "COMPLETE"
  },

Ta có thể lấy thông tin cho một bucket cụ thể bằng câu lệnh dạng sau. Rule trong ví dụ này dùng object tag với cặp k/v processed:true làm filter để expire những object cũ hơn một ngày.

$ # radosgw-admin lc get --bucket ingest
{
    "prefix_map": {
        "": {
            "status": true,
            "dm_expiration": false,
            "expiration": 1,
            "noncur_expiration": 0,
            "mp_expiration": 0,
            "obj_tags": {
                "tagset": {
                    "processed": "true"
                }
            },
            "transitions": {},
            "noncur_transitions": {}
        }
    },
    "rule_map": [
        {
            "id": "Delete objects that are older than 24 hours",
            "rule": {
                "id": "Delete objects that are older than 24 hours",
                "prefix": "",
                "status": "Enabled",
                "expiration": {
                    "days": "1",
                    "date": ""
                },
                "noncur_expiration": {
                    "days": "",
                    "date": ""
                },
                "mp_expiration": {
                    "days": "",
                    "date": ""
                },
                "filter": {
                    "prefix": "",
                    "obj_tags": {
                        "tagset": {
                            "processed": "true"
                        }
                    }
                },
                "transitions": {},
                "noncur_transitions": {},
                "dm_expiration": false
            }
        }
    ]
}

Kết luận: Hé lộ phòng máy ¶

Qua loạt deep dive hai phần này, chúng ta đã đi hết những trụ cột kiến trúc cốt lõi của Ceph RGW. Từ các frontend hiệu năng cao và cơ chế tinh vi của bucket index sharding, tới mô hình bố trí dữ liệu head/tail đầy tinh tế và các tiến trình nền tự động — giờ đây bạn đã có một hiểu biết đầy đủ, xuyên suốt từ đầu tới cuối về cách RGW đạt được khả năng mở rộng và tính linh hoạt đáng nể của mình.

Hiểu được cấu tạo của cỗ máy mới chỉ là bước đầu tiên. Để thực sự làm chủ Ceph RGW, chúng ta còn phải học cách tinh chỉnh, bảo mật và vận hành nó trong những môi trường thực tế phức tạp.

Chuyến khám phá kiến trúc này chính là nền móng cho loạt bài đang tiếp diễn của chúng tôi về việc làm chủ Ceph RGW.

Nhóm tác giả xin cảm ơn IBM đã hỗ trợ cộng đồng bằng cách dành thời gian cho chúng tôi thực hiện những bài viết này.

Personal Ops Runbook

Infra Notes