Reference // Tra cứu kỹ thuậtceph

Ceph — RBD: cơ chế và vận hành

DOC PATH reference/ceph/rbd

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

Mô hình hoạt động, cấu hình, lệnh và kiểm tra RBD 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.

Mô hình hoạt động và điều kiện áp dụng

RBD

RBD (RADOS Block Device) biểu diễn một virtual block device dưới dạng tập object trong RADOS. RBD được dùng phổ biến cho VM disks, Cinder volumes và Glance images.

Thin provisioning: chỉ object đã ghi mới tiêu thụ capacity.
Snapshot: point-in-time metadata view.
Clone/layering: child image tham chiếu parent snapshot, tiết kiệm dung lượng.
Exclusive-lock, object-map, fast-diff hỗ trợ hiệu năng và quản lý snapshot/clone.
Client có thể dùng kernel rbd hoặc librbd.

Khái niệm	Ý nghĩa
Image	Block device logic.
Object size/order	Kích thước chunk RADOS của image.
Snapshot	Trạng thái read-only của image tại thời điểm tạo.
Clone	Child image dùng copy-on-write dựa trên snapshot.
Flatten	Loại bỏ phụ thuộc vào parent bằng cách sao chép dữ liệu cần thiết.

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 Block Device (RBD) cung cấp block device cho VM, container hoặc server; dữ liệu của image được chia thành nhiều RADOS object trong pool. RBD không tạo một disk vật lý riêng cho mỗi image.

Tạo image và kết nối client

RBD image và đường I/O

Image có kích thước logic là dung lượng thiết bị mà guest nhìn thấy. Với thin provisioning, dung lượng raw mới tăng khi object thực sự được ghi hoặc được giữ bởi snapshot; kích thước logic không phải số byte đang chiếm trên cluster. Kích thước RADOS object và kích thước một request I/O của guest cũng là hai đại lượng khác nhau.

Guest filesystem → block request → RBD client → RADOS object/PG → OSD. Client tra cluster map để tìm PG/acting set. Ghi vào replicated pool được primary OSD phối hợp với replica; đọc mặc định hướng tới primary khi dữ liệu không được cache phía client.

Chính sách rbd_read_from_replica_policy có thể là default, balance hoặc localize: đọc theo primary, chọn replica để phân tải, hoặc ưu tiên replica gần client theo CRUSH. Chính sách chỉ đổi nguồn đọc, không đổi primary của PG và không thay yêu cầu đồng bộ của ghi. Tham khảo RBD configuration reference.

Các feature của image

Feature	Tác dụng	Ranh giới
`exclusive-lock`	Điều phối quyền ghi độc quyền cần cho một số feature phụ thuộc.	Không phải CephX, khóa file trong guest hay bảo đảm đã flush dữ liệu.
`object-map`	Theo dõi object nào tồn tại để một số thao tác không phải quét toàn image.	Metadata tăng và có quan hệ phụ thuộc feature.
`fast-diff`	Tận dụng object-map để xác định object thay đổi giữa các snapshot nhanh hơn.	Không đồng nghĩa incremental backup đã được tạo hoặc xác minh.

Feature phải được hỗ trợ đồng bộ bởi client và các hệ thống tích hợp (ví dụ hypervisor) trước khi bật. Xem RBD image features.

Image, Mapping and Filesystem

RBD cung cấp block device trên RADOS. Filesystem truy cập /dev/rbdX; image được chia thành RADOS objects và phân phối xuống OSD qua PG/CRUSH.

Tạo pool riêng với application Block (RBD).
Vào Block > Images > Create, chọn pool, image name và size. Ví dụ: format 2, image 1 GiB, object size 4 MiB.
Kiểm tra image và kernel client trước khi map. Feature set cần phù hợp với client đang dùng.

rbd ls -p <pool>
rbd info <pool>/<image>
rbd pool stats <pool>

# Trên client host
modprobe rbd
rbd device list
rbd device map <pool>/<image>
rbd status <pool>/<image>

rbd status cho biết watchers/client connections, không phải replica count. Nếu một image xuất hiện qua nhiều device, có thể đã bị map nhiều lần. Xác định mapping không được sử dụng, unmount nếu cần rồi unmap mapping thừa trước khi tiếp tục.

Chỉ tạo filesystem trên image mới, chưa có dữ liệu đã xác nhận:

wipefs -n <mapped-device>
blkid -p <mapped-device>
# Chỉ chạy mkfs sau khi xác nhận device/image trống
mkfs.ext4 <mapped-device>
mount -t ext4 <mapped-device> <mountpoint>
findmnt <mountpoint>
df -hT <mountpoint>

Không format lại chỉ vì lsblk -f chưa hiện FSTYPE; đối chiếu blkid -p, file -sL và findmnt. Kiểm tra persistence bằng write/checksum → sync → unmount/unmap → map/mount lại → checksum. Không dùng hai mapping của cùng một filesystem như hai disk độc lập.

Dung lượng, discard và resize

Discard và thu hồi dung lượng

Xóa file trong guest thường chỉ đổi metadata filesystem. Để RBD giải phóng object/extent không còn dùng, tín hiệu TRIM/discard phải đi xuyên suốt guest → virtual disk/hypervisor → RBD → OSD. Ghi các byte zero không phải lúc nào cũng tương đương discard. Snapshot hoặc clone còn tham chiếu dữ liệu cũ có thể giữ raw capacity dù discard đã tới RBD.

Khi xem dung lượng, tách ba góc nhìn: filesystem còn trống trong guest, object/extent RBD đang được cấp phát và raw space trên cluster (còn bị nhân theo replication/EC và tính cả metadata). Dung lượng tăng bất thường không thể kết luận chỉ từ một con số.

Thin Provisioning and Accounting

rbd du <pool>/<image>
ceph df detail

Metric	Ý nghĩa
Provisioned	Kích thước logic image, chưa đồng nghĩa dung lượng đã cấp phát
`rbd du` USED	Dung lượng cấp phát theo object; gồm ảnh hưởng của filesystem và dữ liệu ghi
Pool STORED	Lượng dữ liệu logic lưu trong pool
Pool raw USED	Dung lượng vật lý, gồm replication và overhead

Image 1 GiB với object size 4 MiB có không gian địa chỉ cho 256 objects, nhưng tạo image không cấp phát ngay cả 256 data object. Sparse objects, metadata, snapshot và clone khiến rbd du không bằng ceph df nhân một hệ số cố định.

Resize and Trash Lifecycle

Tăng image ở Dashboard trước, sau đó tăng filesystem theo đúng loại filesystem. Ví dụ dưới đây dành cho ext4, không áp dụng lệnh resize2fs cho XFS:

rbd info <pool>/<image>
rbd resize --size <new-size-MiB> <pool>/<image>
lsblk <mapped-device>
resize2fs <mapped-device>
df -hT <mountpoint>

Tăng kích thước image không tự mở rộng ext4; filesystem chỉ sử dụng phần mới sau bước resize phù hợp. Kiểm tra checksum sau thay đổi; tăng provisioned size không đồng nghĩa cấp phát toàn bộ dung lượng mới.

Move to Trash bỏ image khỏi active namespace nhưng còn khả năng Restore. Trạng thái Expired nghĩa đủ điều kiện purge/delete, không có nghĩa dữ liệu đã bị xóa.

rbd ls -p <pool>
rbd trash ls -p <pool>

Trước khi xóa vĩnh viễn, kiểm tra mapping/watchers, snapshot/clone dependency và đúng image ID trong Trash. Sau Restore, xác nhận ID/size/checksum; sau khi xóa vĩnh viễn, xác nhận active list, trash list và kết quả rbd info đúng dự kiến.

Snapshot, rollback và clone

Snapshot, clone và flatten

Snapshot lưu trạng thái của image ở mức block tại thời điểm tạo. Các lần ghi sau đó dùng cơ chế copy-on-write; dữ liệu cũ có thể tiếp tục chiếm dung lượng dù guest đã xóa file. Snapshot ở lớp block không tự bảo đảm tính nhất quán của database/application: guest cần flush/quiesce theo yêu cầu của ứng dụng.

Clone tạo child image dựa trên snapshot của parent image. Clone format v1 yêu cầu snapshot được bảo vệ; format v2 có thể clone từ snapshot không được bảo vệ, tùy khả năng của client. Khi đọc block chưa thay đổi, clone có thể phải đọc từ parent; chuỗi clone nhiều tầng có thể tăng chi phí đọc và làm phức tạp việc quản lý vòng đời dữ liệu. Flatten sao chép phần dữ liệu kế thừa sang clone để loại bỏ phụ thuộc vào parent của image hiện tại, đổi lại cần thời gian, I/O và dung lượng bổ sung. Snapshot của clone có thể còn phụ thuộc vào parent nếu không dùng deep-flatten. Xóa snapshot có thể kích hoạt snaptrim bất đồng bộ; raw capacity đã sử dụng không nhất thiết giảm ngay. Xem clone format và deep-flatten.

Snapshot/clone hữu ích cho khởi tạo nhanh và điểm khôi phục ngắn hạn, nhưng không thay backup độc lập hay DR. Nếu parent, pool hoặc cluster cùng gặp sự cố, bản snapshot nội bộ cũng bị ảnh hưởng.

Snapshot and Rollback

Dashboard: Block > Images > <image> > Snapshots > Create.

Quiesce ứng dụng, sync và unmount theo yêu cầu của filesystem để tạo snapshot nhất quán.
Tạo snapshot, ghi checksum của dữ liệu baseline.
Khi cần rollback, dừng I/O và unmount/unmap theo client workflow trước khi chọn Rollback.
Mount lại và xác nhận cả file cần phục hồi lẫn các thay đổi sau snapshot.

rbd snap ls <pool>/<image>
rbd snap create <pool>/<image>@<snapshot>
# Rollback thay toàn bộ block state của image
rbd snap rollback <pool>/<image>@<snapshot>

Đây là whole-image block rollback: toàn image quay về snapshot, kể cả việc mất file mới sau snapshot. Khác với selective file restore của CephFS, cần backup dữ liệu mới hợp lệ trước khi rollback.

Clone, Copy-on-Write and Flatten

Quy trình clone truyền thống: Protect parent snapshot → Clone → kiểm tra → Flatten khi cần bỏ dependency.

rbd snap protect <pool>/<image>@<snapshot>
rbd clone <pool>/<image>@<snapshot> <pool>/<clone>
rbd info <pool>/<clone>
rbd children <pool>/<image>@<snapshot>
rbd du <pool>/<clone>

Clone ban đầu có thể USED=0 B nhưng đọc được dữ liệu parent. Ghi vào clone tạo object riêng; source vẫn giữ checksum cũ. Mount read-write cũng có thể tăng allocation do filesystem journal.

rbd flatten <pool>/<clone>
rbd info <pool>/<clone>
rbd children <pool>/<image>@<snapshot>

Kết quả mong đợi sau flatten: không còn parent/overlap dependency; source và clone đọc đúng dữ liệu. Flatten cần thêm dung lượng để tách dữ liệu còn phụ thuộc parent. Chỉ Unprotect/Delete snapshot sau khi không còn child dependency; kiểm tra lại clone sau cleanup.

Cache, flush và durability

RBD client có thể dùng write-through, write-back hoặc write-around tùy cấu hình và tính năng. Write-back và write-around có thể xác nhận ghi trước khi dữ liệu được ghi xuống OSD, vì vậy flush/FUA và trình tự đồng bộ của guest quyết định thời điểm ứng dụng có thể coi dữ liệu đã được lưu bền vững (durability). Cần phân biệt:

Sự kiện	Ý nghĩa
Ứng dụng đã ghi vào page cache của guest	Chưa chứng minh byte đã xuống RBD client hoặc OSD.
RBD client đã nhận dữ liệu vào cache	Chưa nhất thiết là dữ liệu đã bền vững trên cluster.
Flush hoàn tất theo cam kết của client/device	Là điểm đồng bộ để ứng dụng đánh giá durability, với điều kiện toàn bộ stack thực hiện đúng flush.

Persistent write log, khi được hỗ trợ và cấu hình, thay đổi cách cache tồn tại qua một số sự cố nhưng không đồng nghĩa với việc dữ liệu đã có đủ replica bền vững trong OSD. Xem RBD cache options.