Đến nội dung chính
Infra Notes
DOCS / UTF-8
Reference // Tra cứu kỹ thuậtceph

Ceph — RGW/S3: cơ chế và vận hành

DOC PATH reference/ceph/rgw

Doc Type
Reference
Technology
ceph
Status
Active
Version
20.2.x
Tags
CephRGWStorage

Mô hình hoạt động, cấu hình, lệnh và kiểm tra RGW/S3 trên Ceph. Đọc theo thứ tự các chương hoặc chọn mục cần tra cứu trong mục lục.

RGW cung cấp REST API tương thích S3/Swift phía trên RADOS. RGW quản lý user, access/secret keys, bucket metadata, bucket index và object data.

  • RGW có thể scale-out bằng cách thêm daemon.
  • Nhiều RGW daemon không tự tạo một endpoint HA duy nhất; production thường dùng load balancer/ingress/VIP.
  • Bucket data, bucket index, metadata và control/log dùng các pool khác nhau.
  • Quota có thể áp dụng ở user hoặc bucket.

Lệnh Ceph chạy trong admin environment của Ceph Tentacle 20.2.3; lệnh mount, filesystem và kernel chạy trên client. Đối chiếu inventory và quyền trước khi thay đổi dữ liệu.

RADOS Gateway (RGW) nhận yêu cầu object storage qua HTTP/S3 hoặc Swift, xử lý xác thực và metadata, rồi lưu nội dung trong các RADOS pool. S3 object là khái niệm API; một object lớn hoặc multipart upload không nhất thiết tương ứng đúng một RADOS object.

S3 client → load balancer/VIP → RGW → RADOS → OSD. Gateway xử lý HTTP request, bucket/object metadata và gọi RADOS; MON cung cấp cluster map/quorum, không chuyển tiếp payload. S3 access key của user và CephX identity dùng nội bộ giữa gateway với cluster thuộc hai lớp xác thực khác nhau. Quyền truy cập S3 API không đồng nghĩa với quyền truy cập trực tiếp RADOS.

RGW dùng các pool cho metadata, bucket index và payload. Với object đủ lớn, dữ liệu có thể gồm head và nhiều tail RADOS object; multipart upload còn chia dữ liệu thành các part riêng. Vì vậy số S3 object, số RADOS object và raw bytes đo các đại lượng khác nhau. Tham khảo cấu trúc bucket index.

RGW cung cấp S3/Swift HTTP API trên RADOS: xử lý auth, metadata, bucket index và placement. Bucket không tương đương một pool, và một S3 object không nhất thiết là một RADOS object cùng tên. RGW không phụ thuộc MDS.

Mô hình single-site có thể dùng default zonegroup/default zone. Không có Multi-Site Sync chưa phải lỗi nếu kiến trúc không yêu cầu multisite.

Backend pools có vai trò riêng: .rgw.root, default.rgw.meta, .log, .control, .buckets.index, .buckets.data, .buckets.non-ec. Không xóa chúng khi chỉ cleanup bucket/user.

Dashboard Administration > Services > Create:

Field Cấu hình cần xác định
Type / Service rgw, tên service riêng.
Realm / Zonegroup / Zone Theo kiến trúc single-site hoặc multisite; đối chiếu zone thực tế.
Unmanaged OFF để cephadm quản lý lifecycle.
Placement / Count Host chạy gateway và số daemon; một daemon tạo endpoint đơn lẻ.
Port / SSL Ví dụ nội bộ dùng HTTP 7226; chọn cổng và TLS theo mạng triển khai.
Terminal window
ceph orch ls --service_type rgw
ceph orch ps --daemon-type rgw --refresh
curl -i http://<rgw-host>:<rgw-port>/

HTTP 200/S3 XML từ unsigned root request chỉ chứng minh endpoint có phản hồi. Xác nhận S3 request bằng credential hợp lệ và PUT/GET thực tế. Gateway host không quyết định nơi tất cả object được lưu: CRUSH vẫn phân phối dữ liệu trên OSD.

Một gateway là endpoint SPOF dù RADOS còn HA. Dùng ít nhất hai gateway trên các host khác nhau cùng endpoint/load balancer có failover trước maintenance có yêu cầu duy trì dịch vụ liên tục.

Dashboard: Object > User management > Users > Create. Xác định User ID, Maximum buckets, Suspended, System user và S3 key theo quyền ứng dụng; không cấp System user khi không cần.

Terminal window
radosgw-admin user info --uid=<s3-user>
s3cmd -c <s3-config-file> ls

user info có thể chứa keys; không đưa nguyên output vào log/report công khai. Client config phải trỏ đúng endpoint, dùng quyền 0600; các ví dụ dùng s3cmd cho CRUD và boto3 cho VersionId/multipart.

Key rotation: Create S3 Key → cập nhật client → test S3 access/PUT/GET → thu hồi key cũ → test lại. Không xóa key cũ trước khi workload đã chuyển thành công.

Bucket index theo dõi danh sách object và trạng thái để hỗ trợ LIST, versioning và các thao tác quản lý. Index được lưu qua OMAP; quá nhiều object nhỏ có thể làm tăng tải metadata, RocksDB, CPU và độ trễ LIST dù tổng dung lượng payload chưa lớn. Sharding chia index của một bucket thành nhiều shard; resharding thay số shard để tránh hotspot hoặc lãng phí tài nguyên. Cơ chế tự động điều chỉnh phụ thuộc phiên bản và chế độ triển khai; kiểm tra cấu hình resharding đang áp dụng cho bucket. Xem Dynamic bucket index resharding.

GET một object chủ yếu đi theo metadata lookup và data path của object đó; LIST bucket lớn lại phụ thuộc index. Tối ưu throughput payload và tối ưu thao tác liệt kê có thể cần hai cách quan sát khác nhau.

Dashboard: Object > Buckets > Create. Chọn owner, ACL/policy, placement, Versioning/Object Lock/encryption theo workload. Đối chiếu quyền owner và named placement rule thực tế, ví dụ default-placement.

Terminal window
radosgw-admin bucket stats --bucket=<bucket>
s3cmd -c <s3-config-file> ls s3://<bucket>/
s3cmd -c <s3-config-file> put <source-file> s3://<bucket>/<test-key>
s3cmd -c <s3-config-file> get s3://<bucket>/<test-key> <readback-file>
sha256sum <source-file> <readback-file>
cmp <source-file> <readback-file>

explicit_placement rỗng có thể có nghĩa đang dùng named placement rule; không chứng minh thiếu backend pool. num_shards là bucket index shards, không phải replica/OSD count. Chỉ xóa test key sau validation và xử lý đúng Versioning state.

Luồng multipart với boto3: create_multipart_upload → upload_part → list_parts → complete_multipart_upload. Lưu UploadId, PartNumber và ETag từng part; bước hoàn tất gửi danh sách part theo thứ tự.

Ví dụ chia file 12 MiB thành các part 5 + 5 + 2 MiB. Sau khi hoàn tất upload, đối chiếu size và checksum của file tải lại với file gốc. ETag dạng ...-3 không phải checksum toàn file. Khi upload bỏ dở, kiểm kê bằng list_multipart_uploads và abort đúng UploadId nếu không tiếp tục.

Metric Cách đọc
ceph_rgw_req Counter tổng request; cần rate/delta để ra requests/sec.
ceph_rgw_failed_req Counter failed/aborted; không tự chỉ ra nguyên nhân.
ceph_rgw_qlen Queue length tại thời điểm scrape.
Latency sum/count Dùng delta trên cùng time window để tính trung bình; chú ý counter reset.

MGR :9283 và ceph-exporter :9926 cung cấp các nhóm metrics khác nhau trong cấu hình lab. Cache hit/miss counters không mặc định bằng object GET cache-hit ratio.

Khi bật versioning, ghi lại cùng key có thể giữ phiên bản cũ. DELETE không chỉ định version có thể tạo delete marker, khiến key không xuất hiện trong truy vấn thông thường nhưng dữ liệu cũ vẫn tồn tại. Muốn thu hồi dung lượng, cần chính sách xóa version phù hợp. Lifecycle có thể xử lý hết hạn version hiện tại/cũ, xóa delete marker và dọn multipart upload chưa hoàn tất; các tác vụ này chạy nền nên raw capacity đã sử dụng không giảm ngay. Xem S3 bucket operations.

Versioning giúp khôi phục một số lỗi ghi đè/xóa, nhưng không phải immutable backup hay DR: cùng bucket/cluster, cùng quyền quản trị hoặc chính sách lifecycle vẫn có thể ảnh hưởng các phiên bản. Multipart upload bỏ dở cũng có thể chiếm dung lượng cho đến khi được hoàn tất hoặc dọn.

Quota RGW thường giới hạn max_size hoặc max_objects ở phạm vi user/bucket theo cấu hình. Đây là giới hạn mức dùng logic, không phải rate limit request và cũng không tương đương raw capacity sau replication/EC. Số liệu quota có thể cập nhật trễ; phải để headroom ở tầng OSD.

Bật Versioning tại Object > Buckets > <bucket> > Edit; kiểm tra bằng bucket stats.

Thao tác khi Versioning enabled Kết quả
PUT V1 rồi PUT V2 cùng key Giữ hai versions; GET thường trả V2.
GET với VersionId của V1 Đọc version cũ.
DELETE không kèm VersionId Tạo Delete Marker; GET thường coi key là đã xóa.
Xóa đúng Delete Marker bằng VersionId Version dữ liệu trước đó trở lại current.

list_object_versions của S3 API phải kiểm kê cả Versions và DeleteMarkers, kể cả pagination. Object tạo trước khi bật Versioning có thể mang VersionId null. Danh sách object thông thường không cho biết toàn bộ lịch sử đang chiếm dung lượng.

Trong phiên bản Dashboard này, tra quota tại Edit User:

Setting Phạm vi
Bucket quota Áp dụng giới hạn cho từng bucket của user.
User quota Tổng usage qua các bucket thuộc user.
Maximum buckets Số bucket user được tạo.

Khi vượt quota, PUT có thể gửi payload đến 100% rồi trả 403 QuotaExceeded; object không được commit. Kiểm tra final response và listing, không dùng progress bar làm tiêu chí thành công.

Terminal window
radosgw-admin user stats --uid=<s3-user> --sync-stats
radosgw-admin bucket stats --bucket=<bucket>

Stats cập nhật bất đồng bộ nên Dashboard có thể chưa phản ánh object vẫn đọc được qua S3. Đồng bộ rồi refresh trước khi kết luận mất dữ liệu. size_actual phản ánh RGW accounting granularity, không phải toàn bộ raw bytes sau replication/BlueStore overhead.

  1. Dừng workload test; kiểm kê mọi version, Delete Marker và incomplete multipart upload.
  2. Xóa đúng các versions/markers của bucket test, abort các upload không dùng; kiểm tra lại kết quả, bao gồm pagination.
  3. Xóa bucket rỗng, rồi S3 user/key không còn consumer.
  4. Xóa credential/test files không cần giữ; refresh Dashboard và kiểm tra health.
Terminal window
radosgw-admin bucket list
radosgw-admin user list
ceph -s

Dọn dữ liệu thử nghiệm không đồng nghĩa gỡ RGW service hoặc backend pools. Không xóa thành phần hạ tầng khi chỉ cần dọn bucket/user không còn sử dụng.

Multisite tổ chức theo Realm → Zonegroup → Zone; các zone thường gắn với các cluster/site khác nhau. Thay đổi metadata và dữ liệu được đồng bộ bất đồng bộ giữa các zone. ACK của request ở zone cục bộ không cam kết object đã đọc được hoặc đã được lưu bền vững ở zone từ xa, nên RPO/RTO không tự bằng 0. Metadata master điều phối metadata; vai trò này không có nghĩa chỉ một zone được phép ghi dữ liệu. Xem RGW multisite.

HA gateway phải xét đủ ba lớp:

Lớp Điều phải còn hoạt động
Frontend VIP/load balancer, DNS/TLS và health check điều hướng tới endpoint hoạt động bình thường.
Gateway Nhiều RGW instance đủ năng lực, cùng nhìn được metadata và data pool phù hợp.
Storage MON quorum, PG/OSD còn phục vụ I/O và capacity để ghi.

Nhiều RGW instance không loại bỏ single point of failure ở load balancer hoặc pool. Multisite failover còn cần đánh giá độ trễ đồng bộ, vai trò metadata master, chuyển traffic và cô lập site cũ để tránh dữ liệu phân kỳ do ghi ở cả hai site; chỉ đổi DNS chưa đủ. Trạng thái xử lý request cục bộ và trạng thái đồng bộ giữa các zone cần được theo dõi riêng.