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

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

DOC PATH reference/ceph/cephfs

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

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

MDS và CephFS

CephFS cung cấp filesystem POSIX. Data file nằm trong RADOS data pool; metadata namespace được MDS quản lý và lưu vào metadata pool.

MDS active xử lý metadata operations như lookup, mkdir, rename, inode/capabilities.
Standby MDS sẵn sàng takeover khi active MDS lỗi.
Client CephFS có thể là kernel client hoặc ceph-fuse.
CephX caps có thể giới hạn client theo fsname và quyền rw.

MDS không nằm trên data path của file contents sau khi client có layout/capability; dữ liệu file đi tới OSD.

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.

CephFS cung cấp filesystem phân tán với namespace chung. Metadata như inode, dentry và journal do MDS quản lý trong metadata pool; nội dung file nằm ở data pool và được client đọc/ghi trực tiếp tới OSD sau khi có thông tin cần thiết.

MDS, filesystem và HA

MDS trên metadata path, OSD trên data path

Khi client tra cứu đường dẫn, mở file hoặc đổi tên, MDS điều phối metadata và quyền cache. Khi đọc/ghi nội dung file, client giao tiếp trực tiếp với OSD theo layout đã nhận; MDS không chuyển tiếp toàn bộ nội dung file. Metadata pool thường dùng replication; data pool có thể dùng replication hoặc EC khi đáp ứng các điều kiện hỗ trợ ghi đè.

Thao tác	Thành phần nổi bật
`stat`, `readdir`, tạo/xóa/đổi tên file	MDS và metadata pool; cache trên client có thể giảm số request.
Đọc/ghi nội dung file	Client và OSD của data pool; MDS tham gia cấp metadata/layout/capability.
MDS failover	Standby tiếp quản rank và phát lại journal/cập nhật trạng thái; client có thể cần reconnect.

MDS daemon là một tiến trình; rank là vai trò logic mà daemon đảm nhiệm. max_mds quyết định số rank active cho một filesystem. Nhiều active rank có thể phân tán tải metadata nhờ dynamic subtree partitioning, tức chuyển quyền quản lý subtree/cache, không chuyển payload file giữa MDS. Standby/standby-replay phục vụ HA, không tự tăng thông lượng metadata khi chưa active. Xem Multi-MDS.

Filesystem and MDS HA

Dashboard: File > File systems > Create. Đặt Use existing pools=OFF để Volume workflow tạo metadata/data pools tự động. Nếu dùng existing pools, chuẩn bị đúng metadata/data pools theo yêu cầu của filesystem.

Metadata được lưu bền vững trong RADOS metadata pool; MDS xử lý metadata operations, không phải nơi duy nhất giữ dữ liệu metadata. File data nằm trong data pool.

ceph fs ls
ceph fs status <fs-name>
ceph fs get <fs-name>
ceph orch ps --daemon-type mds
ceph osd pool autoscale-status

Chọn hai placement hosts chưa đủ tạo HA nếu service Count=1. Ví dụ tại Administration > Services > mds.<fs-name> > Edit:

Tham số	Ví dụ HA	Ý nghĩa
Service Count	2	Số MDS processes.
`max_mds`	1	Số active metadata ranks mục tiêu.
`standby_count_wanted`	1	Standby redundancy mong muốn.
Role	1 active + 1 standby	Kiểm tra bằng `ceph fs status`, không chỉ process count.

PG mới có thể trải qua unknown/peering trước active+clean. Nếu state kéo dài, đọc health detail và tiến trình hội tụ thay vì coi mọi warning là tạm thời.

Client, capability và quyền truy cập

Capability và tính nhất quán cache

CephFS capability (cap) cấp cho client quyền cache/truy cập trạng thái inode trong giao thức MDS. Khi client khác cần thay đổi xung đột, MDS có thể recall cap; client phải flush và trả lại quyền tương ứng. Một client treo hoặc mạng chập chờn có thể giữ cap lâu, làm chậm tiến trình metadata hoặc failover.

Ba khái niệm cần phân biệt:

CephFS cap: cơ chế nhất quán/cache giữa MDS và client.
CephX cap: quyền xác thực/truy cập tài nguyên được cấp cho một Ceph client.
POSIX lock: khóa do ứng dụng/filesystem sử dụng để phối hợp truy cập file.

Các cơ chế này không thay thế nhau. Do client giữ cache, số liệu metadata và dung lượng có thể chưa phản ánh thay đổi mới nhất.

CephX and Kernel Mount

Administration > Ceph users dùng generic caps. ceph fs authorize phù hợp hơn để cấp quyền theo filesystem/path; chọn phạm vi nhỏ nhất đáp ứng workload.

ceph fs authorize <fs-name> client.<client-id> <authorized-path> rw

Lệnh mount dưới đây áp dụng cho client đã được cấp quyền root / của filesystem. Với client bị giới hạn subdirectory, dùng đúng authorized path trong device string.

mount -t ceph <client-id>@.<fs-name>=/ <mountpoint> \
  -o mon_addr=<mon-addresses>,secretfile=<secret-file>,_netdev
findmnt <mountpoint>
ceph fs status <fs-name>

<mon-addresses> là danh sách MON endpoints theo mount helper đang dùng. Secret file chỉ chứa key, quyền đọc hạn chế, ví dụ 0600; không lưu secret vào repository.

Trong device string, client ID không có prefix client.. Lặp prefix thành client.client.<id> có thể gây unauthorized/no MDS. Kernel client, gói ceph-common trên host và daemon/admin container là các lớp phần mềm có phiên bản riêng; xác định lớp bị lỗi trước khi thay đổi cluster.

Client Eviction and MDS Failover

Trước Evict, xác định đúng session, auth name, host và connection nonce. Eviction kết thúc MDS session và blocklist connection cũ, không thực hiện local unmount.

ceph fs status <fs-name>
ceph tell mds.<active-mds-id> client ls
ceph osd blocklist ls
findmnt <mountpoint>

Nếu mount vẫn hiện nhưng I/O trả Permission denied, dừng workload rồi unmount an toàn và mount lại để tạo session mới. Xác nhận connection nonce mới và đọc lại checksum; không gỡ blocklist cũ chỉ để bỏ qua nguyên nhân eviction.

Khi Active MDS dừng, standby được promote; filesystem có thể vẫn RW trong khi health cảnh báo thiếu standby. Khởi động lại daemon đã dừng và xác nhận 1 active + 1 standby.

Quota, layout và I/O

Quota và file layout

Quota max_bytes và max_files giới hạn mức sử dụng theo subtree, nhưng cơ chế kiểm tra phân tán và cache có thể khiến mức sử dụng tạm thời vượt ngưỡng. Tổng dung lượng file hiển thị trong namespace cũng có thể thấp hơn dung lượng vật lý đã dùng do snapshot, metadata, replication/EC và dữ liệu chưa được dọn. Quota không thay thế capacity planning cho cluster. Xem CephFS quotas.

File layout xác định data pool và cách file ánh xạ thành RADOS object. Thay layout trên thư mục thường áp dụng cho file/dữ liệu mới theo quy tắc kế thừa, không tự di chuyển dữ liệu đã có sang pool mới. Vì thế placement thực tế cần được kiểm tra ở mức file khi đổi layout. Xem CephFS file layouts.

File I/O, Usage and Quota

Kiểm tra write/read/checksum và persistence sau remount. Data pool STORED biểu diễn dữ liệu logic, còn raw USED có replication và overhead; metadata pool tăng riêng. Capacity hiển thị trên mỗi pool không phải dung lượng đã reserve riêng cho pool đó.

Dashboard: File > File systems > <fs-name> > Directories > <path>; đặt Max files/Max size, rồi kiểm tra trên mounted client:

getfattr -n ceph.quota.max_bytes <directory>
getfattr -n ceph.dir.rbytes <directory>

Directory quota áp dụng cho toàn bộ subtree. Khi vượt quota, write có thể ghi được một phần rồi trả Disk quota exceeded/EDQUOT; không mặc định failed write không để lại dữ liệu. Sau cleanup/Unset Max size, kiểm tra xattr, usage và checksum baseline.

Snapshot, subvolume và phục hồi

Snapshot và subvolume

Snapshot CephFS lưu trạng thái read-only của một cây thư mục tại thời điểm tạo; các block còn được snapshot tham chiếu không thể giải phóng ngay. Snapshot nằm trong cùng hệ thống storage, nên không phải bản backup độc lập khi cluster/pool gặp sự cố. Cần quiesce ứng dụng nếu yêu cầu tính nhất quán ở mức database hoặc giữa nhiều file.

Subvolume là ranh giới quản lý logic trong CephFS, hữu ích để cấp không gian và phân quyền cho workload. Nó không tạo một filesystem/cluster độc lập. Việc chọn đường dẫn subvolume, snapshot và nhóm subvolume cần thống nhất với mô hình client, quyền và phục hồi. Tham khảo CephFS volumes và subvolumes.

Directory Snapshot and Selective Restore

Tạo snapshot tại Directories > <path> > Snapshots > Create. Kernel client truy cập historical view qua .snap:

ls -la <directory>/.snap
sha256sum <directory>/.snap/<snapshot>/<file>
# Copy-back có thể ghi đè destination; xác nhận file đích trước
cp <directory>/.snap/<snapshot>/<file> <restore-destination>
sha256sum <restore-destination>

Selective copy-back khôi phục file cần thiết và giữ các file mới ở live directory. Sau restore, xóa snapshot bằng workflow quản lý rồi kiểm tra lại live data. Không mô tả thao tác này như RBD whole-image rollback.

Managed Subvolumes and Clones

Tạo Subvolume groups, sau đó Subvolume trong filesystem. Nếu Size để trống, kiểm tra bytes_quota để biết quota thực tế; mode/UID/GID và Isolated Namespace cần chọn theo client workload.

ceph fs subvolume getpath <fs-name> <subvolume> <group>
ceph fs subvolume info <fs-name> <subvolume> <group>
ceph fs subvolume snapshot ls <fs-name> <subvolume> <group>
ceph fs subvolume snapshot info <fs-name> <subvolume> <snapshot> <group>
ceph fs clone status <fs-name> <clone> --group_name <group>

getpath trả internal path có UUID dưới /volumes/...; không tự rename/move cấu trúc này. Trong info, xem state, bytes_quota, bytes_used, data_pool, pool_namespace, UID/GID và mode.

Dashboard snapshot menu có Clone và Remove. CephFS clone là asynchronous copy do Volume Manager quản lý; chờ complete, so sánh source/clone rồi mới sử dụng. Dữ liệu ghi thêm vào clone không thay đổi source. Không dùng RBD flatten cho CephFS clone.

Trước khi xóa source snapshot, kiểm tra pending clones. Chỉ dọn clone/snapshot thử nghiệm đã xác định không còn consumer và không thuộc chính sách lưu giữ; kiểm tra source sau thay đổi.

Snapshot Schedule

Trong Snapshot schedules, bật module bắt buộc snap_schedule rồi tạo schedule và retention. Ví dụ mỗi giờ (1h), giữ 2 snapshot gần nhất; chọn chu kỳ và retention theo RPO.

ceph mgr module ls
ceph fs snap-schedule status <path> --fs <fs-name>

Đối chiếu active, schedule, retention, start/timezone, created_count, pruned_count. active chỉ phản ánh cấu hình. Cần thấy snapshot được tạo đúng lịch, created_count tăng và pruning đúng retention; số đếm bằng 0 chưa chứng minh automation đã hoạt động.