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

Ceph — Tổng quan và kiến trúc

DOC PATH reference/ceph/theory

Doc Type: Reference
Technology: ceph
Status: Active
Tags: CephStorageRADOSRBDCephFSRGW

Kiến trúc Ceph, control plane, network, CephX và tích hợp OpenStack. Đọc theo thứ tự các chương hoặc chọn mục cần tra cứu trong mục lục.

Phạm vi và mô hình hệ thống

Phạm vi và quy ước

Phạm vi: Ceph Tentacle 20.2.x và cephadm. Các mục dưới đây giải thích cơ chế và điều kiện áp dụng; cấu hình cluster được trình bày trong bài triển khai.

Ceph là gì?

Ceph là một nền tảng distributed storage được thiết kế để cung cấp đồng thời ba mô hình truy cập dữ liệu: block, file và object trên cùng một nền RADOS. Thay vì phụ thuộc vào một storage controller trung tâm, Ceph phân phối dữ liệu và metadata trên nhiều node, nhiều disk và nhiều failure domain.

Scale-out: mở rộng bằng cách thêm host hoặc OSD thay vì nâng cấp một storage array duy nhất.
Self-healing: khi replica bị mất, Ceph tự xác định bản sao còn tốt và tái tạo dữ liệu.
No central data path: client có thể giao tiếp trực tiếp với OSD sau khi biết cluster map; MON không nằm trên data path.
Software-defined storage: phần cứng phổ thông có thể được tổ chức thành storage cluster.
Unified storage: RBD, CephFS và RGW cùng dùng RADOS nhưng cung cấp các giao diện khác nhau.

System Scope

Sơ đồ mô tả hạ tầng Ceph gồm ba MON, active/standby MGR và ba BlueStore OSD. CephFS/RGW là các dịch vụ bổ sung, nằm ngoài phạm vi sơ đồ này. Hostname ceph-01..03 và OSD ID xác định vị trí trong sơ đồ; đối chiếu với inventory trước khi thao tác.

Topology

Layer	Responsibility
MON quorum	Paxos consensus và cluster maps; giữ số MON lẻ để duy trì majority.
MGR	Dashboard, modules và orchestration; chỉ một daemon giữ Active role.
OSD	Lưu RADOS objects; CRUSH phân phối replica theo host failure domain.
Public Network	Client ↔ MON/OSD, Dashboard và API.
Cluster Network	OSD replication, recovery, backfill và heartbeat.
Observability	Prometheus, Grafana, Alertmanager và exporters là monitoring layer bổ sung.

Operational Notes

Flow 3 thể hiện luồng quản lý qua cephadm; client I/O không đi qua MGR. Tách network ở mức logic chỉ cải thiện bandwidth khi hạ tầng bên dưới đủ độc lập.
Dùng ceph quorum_status và ceph mgr stat để kiểm tra quorum/role; process running chưa đủ xác nhận HA.
Lab có ba OSD, replica size 3 và không có spare: khi mất một host, I/O có thể tiếp tục nhưng redundancy giảm. Chờ recovery hoàn tất và safe-to-destroy trả PASS trước khi xóa OSD cũ.

Thành phần và control plane

Thành phần

Daemon/Layer	Vai trò	Có nằm trên data path?
MON (Monitor)	Giữ cluster maps, quorum, membership, auth state.	Không đối với data I/O bình thường
MGR (Manager)	Metrics, Dashboard, modules, management API.	Không trực tiếp
OSD	Lưu object, replication/recovery, peering, scrub.	Có - là data path chính
MDS	Metadata cho CephFS: directory, inode, namespace.	Chỉ CephFS metadata path
RGW	Gateway HTTP/S3/Swift, chuyển object API thành RADOS operations.	Có cho client object
RADOS	Nền distributed object store của toàn Ceph.	Có
RBD	Block interface trên RADOS.	Có qua librados/librbd
CephFS	POSIX filesystem trên RADOS.	Có

Một client Ceph thường kết nối MON để lấy cluster map và xác thực. Sau đó client tính toán placement và giao tiếp trực tiếp với OSD. Điều này giúp MON không trở thành bottleneck dữ liệu.

MON, Quorum và Paxos

MON duy trì authoritative cluster state thông qua các map như monmap, osdmap, mgrmap, mdsmap và auth state. MON dùng quorum để đảm bảo consistency.

3 MON cho phép mất 1 MON mà vẫn còn majority 2/3.
5 MON cho phép mất 2 MON nhưng tăng overhead; thường 3 hoặc 5 là hợp lý.
MON không lưu user data payload của RBD/CephFS/RGW.
Mất quorum thường làm cluster không thể cập nhật map và client operations sẽ bị ảnh hưởng nghiêm trọng.

Ba MON còn giữ majority khi mất một MON. Khả năng phục vụ dữ liệu cần kiểm tra thêm OSD và PG, không suy ra chỉ từ MON quorum.

MGR và Dashboard

MGR bổ sung management/telemetry cho MON. Một MGR active chạy modules, các MGR khác standby.

Dashboard module cung cấp Web UI/API.
Prometheus module xuất metric cho monitoring.
Balancer, autoscaler và nhiều module quản trị dựa trên MGR.
MGR failover không đồng nghĩa daemon process kia bị stop; process có thể vẫn running nhưng role chuyển active/standby.

Network và bảo mật

Mạng

Ceph có thể tách public network và cluster network để giảm contention giữa client I/O và backend replication/recovery.

Network	Traffic điển hình	CIDR mẫu
Public network	Client ↔ MON, client ↔ OSD, daemon front-side.	`<ceph-public-cidr>`
Cluster network	OSD replication, recovery/backfill, backend heartbeat.	`<ceph-cluster-cidr>`
Management	SSH/cephadm/OS management.	`<management-cidr>`

Tách network giúp recovery traffic không bóp nghẹt client I/O.
Production cần xét MTU, bandwidth, redundancy, NIC bonding, switch design.
Một public network không nên bị nhầm với OpenStack public/external network; tên gọi là theo Ceph.

CephX và bảo mật

CephX là cơ chế authentication/authorization nội bộ của Ceph. Một entity có key và capabilities cho MON, OSD, MDS, MGR.

Ví dụ entity và quyền truy cập (không chứa key):

[client.example]
  caps mon = 'allow r'
  caps osd = 'allow rw pool=example'

Nguyên tắc least privilege: chỉ cấp pool/fs và action cần thiết.
OpenStack integration nên dùng keyring/client riêng cho Glance/Cinder/Nova.
CephX không thay thế encryption-at-rest hoặc TLS cho mọi use case; đây là auth/capability layer.
Keyring phải được bảo vệ bằng filesystem permissions và secret management phù hợp.

Quản lý bằng cephadm

cephadm và Orchestrator

cephadm triển khai Ceph daemons dưới dạng container và quản lý lifecycle thông qua orchestrator.

Service spec mô tả desired state: placement, count, network/port, device filters.
ceph orch ps hiển thị daemon state; ceph orch ls hiển thị service-level desired/current state.
Host inventory và device inventory được cephadm refresh định kỳ.
Service spec là declarative; thay spec có thể khiến cephadm deploy/remove/reconcile daemon để đạt trạng thái mong muốn.

Tích hợp OpenStack

OpenStack

Trong OpenStack, Ceph thường đóng vai trò backend RBD cho nhiều service.

OpenStack service	Ceph use case thường gặp
Glance	Lưu VM images trong RBD pool images.
Cinder	Lưu block volumes trong RBD pool volumes.
Nova	Ephemeral/root disks có thể dùng RBD pool vms; hỗ trợ copy-on-write từ Glance.
Cinder Backup	Có thể dùng pool backups nếu thiết kế.

Mỗi service nên có CephX client/caps phù hợp.
Không nên dùng lại pool lab cũ; tạo pool OpenStack riêng và gắn application rbd.
Kolla-Ansible có thể cấu hình external Ceph; cần cung cấp ceph.conf/keyrings vào đúng container/config path.
Live migration thuận lợi khi compute nodes cùng truy cập shared RBD storage.

Thuật ngữ và lộ trình đọc

Thuật ngữ

Thuật ngữ	Giải thích
Acting set	Tập OSD đang thực sự phục vụ PG ở thời điểm hiện tại.
Up set	Tập OSD mà CRUSH/OSD map hiện muốn PG sử dụng.
Backfill	Copy dữ liệu quy mô lớn để thỏa placement mới.
CephX	Authentication + capabilities nội bộ Ceph.
CRUSH	Thuật toán deterministic placement theo topology/weight/rule.
Degraded	PG/object thiếu một hoặc nhiều replica/chunk.
Failure domain	Đơn vị hỏng cần tách replica: OSD, host, rack, …
MDS	Metadata Server cho CephFS.
MGR	Manager daemon, modules/Dashboard/metrics.
MON	Monitor, quorum và authoritative maps.
OSD	Daemon lưu object và thực hiện replication/recovery.
PG	Placement Group, đơn vị logic giữa object và OSD.
RADOS	Distributed object store lõi của Ceph.
RBD	Block storage interface trên RADOS.
RGW	Object gateway tương thích S3/Swift.
Scrub	Kiểm tra consistency object/metadata giữa replica.
Undersized	PG có ít replica hiện hữu hơn pool size.

Đọc tiếp theo chủ đề

RADOS và data path — object/PG/CRUSH, luồng đọc ghi, peering, recovery và BlueStore.
RBD và block storage — image, cache, snapshot/clone và discard.
CephFS và file storage — MDS, capability, snapshot, subvolume và quota.
RGW và object storage — bucket index, versioning, lifecycle và multisite.
Độ tin cậy và hiệu năng — failure domain, headroom, PG balancing và bottleneck.

Kết luận

Cách hiểu Ceph hiệu quả nhất là đi từ RADOS: object thuộc pool, được hash vào PG, rồi CRUSH/OSDMap xác định placement; MON giữ cluster state, MGR cung cấp chức năng quản lý, OSD thực hiện data plane, còn RBD/CephFS/RGW cung cấp block/file/object storage trên RADOS. Khi một thành phần hỏng, khả năng duy trì I/O phụ thuộc quorum, min_size và trạng thái PG; Ceph khôi phục redundancy khi có đủ capacity và failure domain phù hợp.

Điểm cần nhớ khi học và vận hành Ceph

RADOS là lõi; RBD, CephFS và RGW chỉ là các giao diện khác nhau phía trên RADOS.
MON giữ cluster state và quorum, nhưng không nằm trên data path của I/O bình thường.
OSD là thành phần chính của data plane: lưu object, replication, recovery, scrub và peering.
Lần theo object -> PG -> CRUSH/OSDMap, rồi đối chiếu up set và acting set để hiểu placement.
UP/DOWN và IN/OUT là hai trạng thái khác nhau; đừng dùng thay thế lẫn nhau.
Degraded không đồng nghĩa Recovering: có thể thiếu replica nhưng chưa có nơi để rebuild.
size quyết định số replica mong muốn; min_size quyết định ngưỡng tối thiểu để tiếp tục I/O.
HA phải đánh giá theo từng service: MON quorum, MGR role, OSD redundancy, RGW endpoint, MDS standby.
Trước khi thay/xóa OSD, luôn kiểm tra durability và dùng safe-to-destroy làm safety gate.
Khi tích hợp OpenStack, tạo pool và CephX client riêng cho workload; không tái sử dụng pool lab cũ.