Logo

Personal Ops Runbook

Personal runbook covering infrastructure operations for Cloud, Kubernetes, OpenStack, and Ceph environments. Includes deployment and teardown procedures, node management, cluster monitoring setup, and incident response workflows compiled from day-to-day operational work. Intended strictly for personal reference — configurations and scripts are environment-specific and not guaranteed to work as-is elsewhere.

1. Tổng quan

Ceph là hệ thống lưu trữ phân tán (distributed storage) có khả năng mở rộng rất lớn, cung cấp nhiều lớp dịch vụ (block, object, file). Thành phần Ceph OSD (Object Storage Daemon) chịu trách nhiệm chính trong việc ghi, đọc, nhân bản và phục hồi dữ liệu.

Khác với cơ chế I/O thông thường của Linux (dựa vào page cache trong kernel), Ceph tự xây dựng hệ thống cache riêng trong user-space để kiểm soát hiệu năng, độ bền và tính nhất quán dữ liệu.

Bài viết này phân tích chi tiết cách Ceph OSD quản lý cache, cơ chế ghi – đọc, và lý do vì sao nó không dựa vào page cache của kernel.

2. Cơ chế ghi dữ liệu thông thường trong Linux

Khi một tiến trình ghi vào file, dữ liệu sẽ đi qua VFS (Virtual File System) và page cache:

Ứng dụng → VFS → Page Cache (RAM) → Disk (sau vài giây hoặc fsync)
  • Dữ liệu ban đầu ghi vào RAM (page cache) → đánh dấu “dirty”.
  • Kernel tự động flush xuống disk sau vài giây (theo cấu hình dirty_writeback_centisecs).
  • Việc này giúp tăng tốc độ ghi, nhưng không đảm bảo dữ liệu an toàn tuyệt đối nếu mất điện.

Cơ chế này hoạt động tốt cho hệ thống đơn giản, nhưng không phù hợp với hệ thống lưu trữ quy mô lớn như Ceph.

3. Vì sao Ceph không dùng page cache của kernel

Ceph phải xử lý hàng trăm nghìn request I/O mỗi giây và quản lý dữ liệu ở mức petabyte. Việc dựa vào page cache kernel sẽ gây ra các vấn đề:

  1. Không kiểm soát được bộ nhớ: Kernel tự quyết định cache/flush, Ceph không thể dự đoán.
  2. Double buffering: Dữ liệu bị giữ cả ở page cache và cache của Ceph → tốn RAM vô ích.
  3. Không đảm bảo tính nhất quán: Kernel cache không biết về các replica hay quorum của Ceph.
  4. Không ổn định hiệu năng: Khi kernel tự flush, latency có thể tăng đột ngột.

Do đó, Ceph chọn cách bỏ qua page cache bằng cách sử dụng O_DIRECT hoặc AIO (Asynchronous I/O) — dữ liệu đi thẳng giữa process và disk.

4. Cấu trúc cache trong Ceph OSD (BlueStore)

Ceph hiện sử dụng BlueStore làm backend mặc định. BlueStore lưu trữ dữ liệu trực tiếp trên thiết bị block mà không cần filesystem trung gian như ext4/xfs.

Các tầng cache chính của BlueStore:

Thành phần Loại dữ liệu cache Nơi lưu Vai trò
BlueStore Onode Cache Metadata về object (extent map, size, checksum) RAM Giúp truy xuất nhanh cấu trúc dữ liệu object.
RocksDB Cache (block cache, memtable) Metadata dạng key-value (omap, index) RAM Tăng tốc truy vấn nội bộ.
Write Buffer / Deferred Write Dữ liệu mới ghi RAM → SSD (journal/WAL) Đảm bảo tốc độ ghi và tính bền vững.
BlueFS Cache Metadata của BlueFS (filesystem riêng dùng cho RocksDB) RAM Giúp truy cập nhanh vào các file cấu hình nội bộ.

Ceph cho phép giới hạn dung lượng RAM dùng cho cache thông qua các tham số:

bluestore_cache_size = 3G
bluestore_cache_size_hdd = 1G
bluestore_cache_size_ssd = 4G

5. Quy trình ghi dữ liệu trong Ceph OSD

Sơ đồ luồng ghi dữ liệu (write path):

Client → OSD → (Write Buffer - RAM) → WAL/DB (SSD) → Main Store (Disk)
  1. Dữ liệu đến OSD → ghi tạm vào bộ đệm (RAM).
  2. Dữ liệu được ghi xuống WAL (Write-Ahead Log) trên SSD để đảm bảo an toàn.
  3. Sau khi ghi thành công, OSD trả ACK cho client.
  4. Thread background sẽ flush dữ liệu từ WAL sang vùng lưu chính (Main Store).

Ceph OSD tự điều phối các bước này, không để kernel can thiệp.

6. Quy trình đọc dữ liệu trong Ceph OSD

Sơ đồ luồng đọc dữ liệu (read path):

Client → OSD
           ↳ Cache hit (RAM) → Trả ngay
           ↳ Cache miss → Đọc từ disk (O_DIRECT)
  1. Khi có yêu cầu đọc, OSD kiểm tra cache nội bộ.
  2. Nếu dữ liệu đã có trong RAM → trả kết quả tức thì.
  3. Nếu chưa có → đọc trực tiếp từ disk bằng O_DIRECT → có thể lưu lại một phần nhỏ vào cache cho lần đọc sau.

Như vậy, Ceph chỉ cache metadata và dữ liệu “nóng”, không cache toàn bộ như page cache kernel.

7. So sánh giữa cơ chế cache của Ceph và kernel

Đặc điểm Page Cache (Kernel) Ceph OSD Cache (User-space)
Vị trí quản lý Kernel space User space (OSD process)
Loại dữ liệu cache Mọi file hệ thống Metadata, data nóng, log
Ghi xuống disk Kernel tự flush theo thời gian Ceph quyết định, gần real-time
Dung lượng RAM Không giới hạn cụ thể Giới hạn cấu hình (bluestore_cache_size)
Kiểm soát consistency Kernel không biết replica Ceph đảm bảo replica/quorum
Giao tiếp I/O VFS + page cache O_DIRECT / AIO

8. Ví dụ thực tế

Ví dụ 1: Khi Ceph OSD nhận 10.000 request ghi mỗi giây:

  • Mỗi request được gom (batched) và ghi vào WAL nhanh trên SSD.
  • Dữ liệu trong RAM chỉ tạm thời giữ vài trăm MB.
  • Thread background liên tục flush WAL → Main Store → Disk.

Ví dụ 2: Khi client đọc 1 object “nóng” nhiều lần:

  • Lần đầu đọc từ disk (O_DIRECT).
  • Lần sau được phục vụ từ cache nội bộ OSD → tốc độ nhanh gấp nhiều lần.

9. Lời khuyên

  1. Khi triển khai Ceph OSD:

  2. Nên cấu hình bluestore_cache_size phù hợp với dung lượng RAM.

  3. Nếu OSD dùng HDD, nên có WAL/DB trên SSD để giảm latency.
  4. Không nên để kernel page cache can thiệp — Ceph đã quản lý I/O trực tiếp.
  5. Giám sát chỉ số cache hit ratio (ceph daemon osd.X perf dump | grep cache) để tối ưu hiệu năng.
  6. Nếu RAM hạn chế, giảm cache size để tránh OOM.

10. Kết luận

Ceph OSD không sử dụng page cache của kernel mà tự xây dựng cơ chế cache riêng trong user-space. Điều này giúp:

  • Kiểm soát chính xác bộ nhớ, flush và đồng bộ dữ liệu.
  • Đảm bảo tính bền vững và nhất quán trong môi trường phân tán.
  • Tối ưu hiệu năng đọc/ghi với dung lượng RAM có giới hạn.

Tóm lại, Ceph OSD vẫn “ghi vào RAM trước” nhưng trong phạm vi cache do chính nó quản lý, không để kernel tự quyết như hệ thống file thông thường.

© Copyright Infra Notes contributors. Last updated on September 07, 2026.