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

Ceph — Vận hành cluster, capacity và hiệu năng

DOC PATH reference/ceph/operations

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

Dashboard, health, monitoring, capacity, hiệu năng và thiết kế production cho 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.

Phạm vi và health baseline

Environment and Conventions

Phạm vi phiên bản: Ceph Tentacle 20.2.3, Ubuntu Server 24.04 LTS, cephadm và Podman. Tên menu bên dưới khớp Dashboard của phiên bản này; phiên bản khác có thể thay đổi vị trí hoặc tùy chọn.

Thay <host>, <pool>, <image>, <fs-name>, endpoint và device bằng inventory thực tế. Dung lượng, số PG và placement trong ví dụ cần được điều chỉnh theo workload, không phải cấu hình mặc định cho mọi cluster.
Các lệnh ceph, rados, rbd, radosgw-admin chạy trong admin environment phù hợp. Nếu host thiếu CLI, dùng cephadm shell -- <command>.
Lệnh mount, umount, kiểm tra kernel module và filesystem chạy trên client host. File của host không tự xuất hiện bên trong cephadm container.
Cluster Installation chứa bootstrap/provisioning; Failure Recovery & HA chứa maintenance, failover và OSD replacement.

Dashboard and Cluster State

Daily Baseline

Dashboard: Overview, Cluster > Hosts, Cluster > Monitors, Cluster > Physical disks.

ceph -s
ceph health detail
ceph orch host ls
ceph orch ps
ceph mon stat
ceph quorum_status -f json-pretty
ceph mgr stat
ceph osd tree
ceph df detail

Quan sát	Cách hiểu đúng
Host `Available`	Host có thể được quản lý; không có nghĩa mọi disk còn trống.
Device `AVAILABLE=No`	Bình thường nếu device đã thuộc OSD/BlueStore; không zap chỉ để đổi thành Yes.
Hai MGR `running`	Chỉ một Active MGR; daemon còn lại Standby.
MON rank / leader	Rank là định danh trong MON map, không đồng nghĩa leader hiện tại.
OSD `up/in`	Daemon liên lạc được và OSD thuộc tập được xét cho placement.
`HEALTH_OK`	Ceph đạt health baseline; vẫn có thể có infrastructure alert ngoài health subsystem.

Host inventory dùng Management/SSH address; MON Public address là đường mạng khác. Khi một host bị báo Offline, kiểm tra management/SSH riêng với MON quorum và OSD connectivity.

Monitoring and Endpoints

Nếu bootstrap dùng --skip-monitoring-stack, cần triển khai monitoring stack riêng. Administration > Manager modules cho biết module state; ceph mgr services cho biết endpoint đang active.

Component	Cổng trong cấu hình ví dụ	Validation
Prometheus	`9095`	Targets thực tế phải `UP`.
Alertmanager	`9093`, `9094`	Alert routing và peer connectivity.
Grafana	`3000`	Dashboard truy cập được từ browser của user.
MGR prometheus module	`9283`	Endpoint có thể chuyển khi MGR failover.
node-exporter	`9100`	Metrics host trên cả ba node.
ceph-exporter	`9926`	Daemon performance counters trên các host.

ceph mgr services
ceph mgr module ls
ceph orch ls
ceph config get mgr mgr/prometheus/exclude_perf_counters

Daemon running chưa chứng minh scrape thành công: mở Prometheus Targets và kiểm tra từng MGR/exporter. Với exclude_perf_counters=true, MGR vẫn cung cấp service/pool metadata, còn daemon performance counters được thu qua ceph-exporter.

Nếu backend Grafana URL resolve được trong cluster nhưng browser không resolve hostname, đặt frontend URL có DNS/routing phù hợp với browser:

ceph dashboard set-grafana-frontend-api-url https://<grafana-browser-host>:3000

Alerts, Logs and API Audit

Observability > Alerts: khi gặp CephNodeDiskspaceWarning, đối chiếu actual usage, inode và tốc độ tăng dung lượng trước khi thay đổi storage:

df -hT /
df -ih /
du -xh --max-depth=1 /var
podman system df

Cảnh báo dự báo disk đầy dựa trên tốc độ tăng có thể xuất hiện khi mức sử dụng còn thấp. Kiểm tra biểu thức alert, khoảng thời gian và thay đổi workload như pull image; phân biệt dự báo với việc disk đã đầy.

Observability > Logs có ba lớp:

Cluster Logs: health/PG events; dòng [DBG] pgmap không mặc định là lỗi.
Audit Logs: cả lệnh quản trị và lệnh nội bộ do MGR/orchestrator phát ra.
Daemon Logs: tích hợp Daemon Logs của phiên bản Dashboard này cần backend thu thập log phù hợp. Khi chưa có stack này, đọc log trên daemon host qua cephadm/journald.

Bật Dashboard API audit để ghi user/path/method, giữ payload logging tắt:

ceph dashboard set-audit-api-enabled true
ceph dashboard set-audit-api-log-payload false
ceph dashboard get-audit-api-enabled
ceph dashboard get-audit-api-log-payload

Kết quả mong đợi: Audit Logs xuất hiện [DASHBOARD] cùng user, path và method; không cần ghi request payload chứa secret.

RBAC, CephX and Telemetry

Dashboard user tạo ở Settings > User management > Users/Roles. Ba identity sau không thay thế nhau:

Identity	Dùng cho
Dashboard user / RBAC	Login và quyền thao tác Dashboard/API.
CephX client	Xác thực client/service với MON, OSD, MDS qua key/caps.
RGW/S3 user	Access key / secret key cho request S3 tới RGW.

Các built-in role để đối chiếu quyền gồm administrator, read-only, cluster-manager, pool-manager, block-manager, cephfs-manager, rgw-manager. Chọn role theo chức năng; kiểm tra bằng session riêng. User read-only xem được Overview/Services nhưng truy cập User management bị Access Denied. Menu vẫn hiện không chứng minh user được phép thực hiện API action.

ceph telemetry status

Telemetry là cơ chế gửi dữ liệu ra ngoài, khác local Prometheus/Grafana. Module loaded hoặc channel đã cấu hình không có nghĩa đã bật cơ chế gửi dữ liệu; kiểm tra enabled và chính sách chia sẻ thông tin trước khi bật telemetry.

Failure domain và bảo vệ dữ liệu

HA trong Ceph phụ thuộc vào nhiều cơ chế độc lập: MON quorum, CRUSH placement, số replica/chunk khả dụng của PG, dịch vụ MDS/RGW và phần cứng/mạng bên dưới. Một trạng thái tổng quan của cluster không đủ để bảo đảm mọi workload đều đọc/ghi được.

Failure domain và tính sẵn sàng

Failure domain có thể là disk, host, rack, nguồn/PDU, switch hoặc site. CRUSH rule chỉ bảo vệ đúng ranh giới được mô hình hóa: nếu ba host dùng chung một switch, ba replica trên ba host vẫn có thể mất kết nối cùng lúc. Device class, weight và topology phải khớp hạ tầng vật lý; số replica/chunk không tự chuyển thành số host hoặc site chịu lỗi được.

Lớp	Cơ chế	Điều chưa được bảo đảm
MON	Đa số thành viên giữ quorum để thống nhất map/trạng thái. Với 3 MON, thường cần 2.	Có quorum không có nghĩa mọi PG đủ `min_size` hay client còn đường tới OSD.
OSD/PG	Replica hoặc EC chunk phân bố qua failure domain; peering/recovery khôi phục redundancy.	PG còn `active` không nhất thiết đã `clean`; recovery cần OSD đích phù hợp và dung lượng.
MGR	Active/standby duy trì quản lý, metrics và module.	MGR không thay MON quorum hoặc OSD data path.
CephFS	MDS active rank và standby/standby-replay cho metadata.	MDS HA không khắc phục tình trạng data pool thiếu OSD hoặc client mất mạng.
RGW	Nhiều gateway sau frontend có HA, dựa trên RADOS.	Nhiều RGW không bảo vệ trước lỗi load balancer đơn lẻ hoặc cluster đầy.

Khi xảy ra network partition, phía có đa số MON có thể tiếp tục cập nhật cluster map; phía thiểu số không có quyền tự tạo map mới. Quorum và min_size là hai điều kiện khác nhau: quorum thuộc control plane, còn min_size quy định ngưỡng để PG phục vụ I/O. Mạng không ổn định có thể gây election, remap và recovery lặp lại ngay cả khi không có disk hỏng. osd down cũng có thể do daemon, host, mạng hoặc disk; trạng thái này chưa xác định được nguyên nhân.

Backup và DR không đồng nghĩa HA

Replica/EC bảo vệ trước lỗi thành phần trong failure domain đã thiết kế; chúng không bảo vệ đầy đủ trước xóa nhầm, lỗi ứng dụng, ransomware hay sai cấu hình được đồng bộ. Snapshot giúp khôi phục trạng thái trước đó nhưng thường nằm trong cùng cluster. Backup cần bản sao độc lập, chính sách giữ phiên bản và kiểm thử restore. Multisite bất đồng bộ có RPO khác 0; failover còn phụ thuộc trạng thái đồng bộ, điều hướng client và quy trình cô lập site cũ. HA, backup và DR xử lý các nhóm rủi ro khác nhau.

Capacity và phân bố dữ liệu

PG, dung lượng và hiệu năng

PG Autoscaler

PG autoscaler ước lượng số PG phù hợp theo capacity share, target ratio/size và số OSD. Quá nhiều PG làm tăng memory/CPU/peering overhead; quá ít PG có thể phân bố dữ liệu kém.

Không chữa TOO_MANY_PGS bằng cách chỉ tăng mon_max_pg_per_osd nếu nguyên nhân là design/pool count.
Các pool rất nhỏ có thể cần pg_num_max để tránh autoscaler mở rộng vô ích trong lab đặc biệt.
Sau khi xóa lab pools, PG count giảm mạnh là bình thường.

Capacity

Raw capacity khác usable capacity. Với replication size=3, 45 GiB raw về lý thuyết chỉ cho khoảng 15 GiB logical trước overhead/nearfull policy, nếu toàn bộ workload dùng size=3.

Performance

Latency phụ thuộc disk, network, queueing, replication, CPU và workload.
Recovery/backfill có thể cạnh tranh tài nguyên với client I/O.
HDD OSD thường bị IOPS-bound; NVMe/SSD có latency thấp hơn.
BlueStore DB/WAL placement có thể ảnh hưởng performance trong production.

Dung lượng hiệu dụng và headroom

Chính sách	Ước lượng trần lý thuyết từ raw capacity
Replication `size = n`	`raw / n`
EC `k+m`	`raw × k / (k+m)`

Các công thức trên chỉ ước lượng dung lượng payload khi dữ liệu phân bố đều, chưa trừ metadata, filesystem overhead, pool khác và dung lượng trống cho self-healing. min_size không phải hệ số tính dung lượng. Trong vận hành, giới hạn sử dụng thực tế thấp hơn vì cần headroom cho tăng trưởng dữ liệu, thêm hoặc thay OSD, backfill và chênh lệch placement.

OSD đầy nhất có thể chạm ngưỡng nearfull/backfillfull/full trước khi mức trung bình toàn cluster cao. Khi không còn nơi đặt replica/chunk thay thế, cluster có thể không phục hồi được redundancy dù vẫn còn raw bytes rải rác. Capacity planning phải xét từng pool, CRUSH rule, device class và failure domain, không chỉ phép chia tổng TB.

PG autoscaler và balancer

Quá nhiều PG làm tăng metadata và chi phí peering; quá ít PG có thể khiến dữ liệu và tải phân bố không đều. PG autoscaler ước lượng số PG mục tiêu theo pool và mức sử dụng; thay PG count có thể phát sinh di chuyển dữ liệu. Balancer điều chỉnh placement (chẳng hạn qua upmap) để giảm chênh lệch giữa các OSD. Hai công cụ giải quyết hai vấn đề có liên quan nhưng khác nhau.

Số PG bằng nhau không đồng nghĩa số byte, số request hay số primary read bằng nhau. Thêm OSD, đổi weight/device class hoặc đổi CRUSH rule có thể gây remap/backfill, dùng cùng tài nguyên với client. Nhiều pool rất nhỏ vẫn có thể tạo tổng PG lớn. Không dùng một con số PG “chuẩn” cho mọi cluster; hãy đối chiếu số OSD, pool, payload và trạng thái hiện tại. Tham khảo PG concepts.

Hiệu năng và giám sát

Mô hình hiệu năng

Ba thước đo chính là IOPS, throughput và latency. Chúng phụ thuộc kích thước I/O, random/sequential, tỷ lệ đọc/ghi, concurrency, số client, cache và trạng thái recovery. Một tác vụ ghi nhỏ ngẫu nhiên trên replicated/EC pool có profile khác xa đọc tuần tự object lớn; EC partial write có thể tạo thêm I/O/tính toán.

Bottleneck có thể nằm ở client/guest, RGW/MDS, mạng, CPU xử lý mã hóa/checksum, OSD queue, BlueStore/RocksDB hoặc disk. block.db trên SSD hỗ trợ xử lý metadata của OSD nhưng không thay đổi đặc tính của HDD chứa payload. Khi recovery/backfill chạy, disk và network còn phải phục vụ tác vụ nền. Tài nguyên bị bão hòa thường làm p95/p99 latency tăng mạnh trước khi throughput trung bình cho thấy dấu hiệu bất thường.

Khi so sánh benchmark, giữ cùng điều kiện đọc/ghi, block/object size, random/sequential, concurrency, client count, cache warm/cold, pool policy và trạng thái healthy/recovering. Đọc kết quả theo từng lớp: thiết bị → RADOS → RBD/CephFS/RGW → ứng dụng. Một hot object, PG hoặc acting set có thể chậm dù trung bình cluster tốt; slow ops là triệu chứng cần lần theo đường I/O, không phải root cause tự thân.

Giám sát

Các metric dưới đây là ví dụ phục vụ giám sát. Đối chiếu metric thực tế do exporter/module của cluster cung cấp trước khi viết query hoặc alert.

Metric/Signal	Ý nghĩa vận hành
ceph_health_status / health detail	Tổng quan health và warning chính.
ceph_pg_clean	Số PG clean.
ceph_pg_degraded	PG thiếu replica.
ceph_pg_recovering	PG đang recovery.
recovering_bytes_per_sec	Recovery throughput.
OSD latency / perf	Commit/apply latency và device responsiveness.
OSD up/in count	Phát hiện daemon/failure domain mất.
MON quorum	Control plane consensus.
MGR active/standby	Management availability.
Capacity / nearfull/full	Rủi ro dừng write khi đạt ratio ngưỡng.

Dashboard hữu ích cho overview và thao tác vận hành; CLI và Prometheus cần thiết khi cần state chi tiết, historical metric hoặc automation.

Thiết kế production

Ít nhất 3 MON trên failure domains độc lập.
MGR ít nhất 2 để có standby.
OSD capacity phải đủ để vẫn giữ redundancy khi mất host/disk.
Không thiết kế cluster vừa đủ size=3 trên đúng 3 OSD nếu production cần khả năng rebuild khi một OSD mất.
Failure domain nên là host/rack phù hợp topology thật.
Dùng NIC redundancy/bonding và switch redundancy nếu SLA yêu cầu.
Không để cluster chạy sát full; nearfull/backfillfull/full ratio là safety mechanism.
Theo dõi recovery time objective: có đủ bandwidth và spare capacity để rebuild trong thời gian chấp nhận được.
Tách workload theo pool/CRUSH rule/device class khi cần isolation.
Quản lý firmware, SMART/device health, time synchronization và MTU nhất quán.
Backup config/key và ghi quy trình thay thế thành runbook.

Lệnh và tài liệu tra cứu

Lệnh tra cứu

Chạy trên host quản trị có cephadm và quyền truy cập cluster. --refresh yêu cầu cập nhật inventory; safe-to-destroy chỉ kiểm tra điều kiện an toàn, không xóa OSD. Không công khai output chứa inventory hoặc thông tin tài khoản.

Mục đích	Lệnh
Cluster health	`cephadm shell -- ceph -s`
Health detail	`cephadm shell -- ceph health detail`
OSD tree	`cephadm shell -- ceph osd tree`
OSD stat	`cephadm shell -- ceph osd stat`
PG stat	`cephadm shell -- ceph pg stat`
Pool list	`cephadm shell -- ceph osd pool ls`
Orchestrator services	`cephadm shell -- ceph orch ls`
Daemon state	`cephadm shell -- ceph orch ps --refresh`
Hosts	`cephadm shell -- ceph orch host ls`
Devices	`cephadm shell -- ceph orch device ls --wide`
MON quorum	`cephadm shell -- ceph quorum_status -f json-pretty`
MGR state	`cephadm shell -- ceph mgr stat`
CRUSH mapping	`cephadm shell -- ceph osd map <pool> <object>`
Safe destroy	`cephadm shell -- ceph osd safe-to-destroy <id>`
OSD metadata	`cephadm shell -- ceph osd metadata <id>`
RBD list	`cephadm shell -- rbd ls -p <pool>`
CephFS status	`cephadm shell -- ceph fs status <fsname>`
RGW users	`cephadm shell -- radosgw-admin user list`

Tài liệu chính thức

Đối chiếu cú pháp khi sử dụng: RBD CLI — Tentacle và Snapshot Scheduling — Tentacle.