
Tổng quan về OSD và PG
Ceph là một hệ thống lưu trữ phân tán, được thiết kế để cung cấp hiệu suất cao, độ tin cậy cao và không có điểm chết đơn lẻ. Điều này có nghĩa là nếu một phần của hệ thống gặp sự cố, Ceph vẫn có thể tiếp tục phục vụ yêu cầu dữ liệu, ngay cả khi nó đang hoạt động trong chế độ “degraded” (giảm chất lượng).
Ceph sử dụng một cơ chế gọi là “data placement” để đảm bảo rằng dữ liệu không bị ràng buộc trực tiếp với các OSD (Object Storage Daemons) cụ thể. Điều này giúp Ceph linh hoạt hơn trong việc xử lý sự cố và phục hồi từ chúng.
Khi gặp sự cố, bạn đừng quá lo lắng vì Ceph có khả năng tự sửa chữa. Thay vào đó, bạn nên theo dõi các OSD và placement groups của mình, sau đó bắt đầu xử lý sự cố. Mặc dù Ceph có khả năng tự sửa chữa, nhưng nếu vấn đề vẫn tiếp tục, việc giám sát OSD và placement groups sẽ giúp bạn xác định vấn đề.

Giám sát OSD
Các trạng thái trong OSD
OSD (Object Storage Daemons) là các thành phần chịu trách nhiệm lưu trữ và truy xuất dữ liệu. Mỗi OSD có thể ở trong hai trạng thái chính: “in” (đang hoạt động) hoặc “out” (không hoạt động) và “up” (đang chạy và có thể truy cập được) hoặc “down” (không chạy và không thể truy cập được).
Vì vậy, một OSD có thể ở trạng thái “up” nhưng không phục vụ dữ liệu (nghĩa là “out of service”), hoặc nó có thể ở trạng thái “up” và đang phục vụ dữ liệu (nghĩa là “in service”).
Nếu một OSD ở trạng thái “out”, CRUSH (thuật toán phân bổ dữ liệu của Ceph) sẽ không gán placement groups cho nó. Nếu một OSD ở trạng thái “down”, nó cũng sẽ ở trạng thái “out”.

Việc kiểm tra xem OSD có đang hoạt động hay không rất quan trọng của việc giám sát chúng. Bất cứ khi nào cluster đang hoạt động thì tất cả các OSD trong cluster cũng nên ở trạng thái đang hoạt động. Để xem tất cả OSD của cluster có đang hoạt động hay không, bạn có thể chạy lệnh sau:
ceph osd statEpoch là một số nguyên dùng để đánh dấu phiên bản của map (bản đồ) của cluster. Mỗi khi có sự thay đổi trong cấu trúc của cluster (như thêm hoặc xóa một OSD, thay đổi trạng thái của một OSD, v.v.), Ceph sẽ tạo ra một bản đồ mới của cluster và tăng epoch lên một đơn vị.
shell> ceph osd stat
32 osds: 32 up (since 10w), 32 in (since 11w); epoch: e9392Ví dụ trường hợp này “epoch: e9392” có nghĩa là bản đồ hiện tại của cluster là phiên bản thứ 9392. Điều này cho thấy đã có 9392 thay đổi đã được thực hiện trên cluster kể từ khi nó được khởi tạo.
Điều này giúp người quản lý hệ thống theo dõi sự tiến triển và thay đổi của cluster theo thời gian.
Nếu số lượng OSD (Object Storage Daemons) trong cluster lớn hơn số lượng OSD đang hoạt động, bạn có thể chạy lệnh ceph osd tree để xác định các daemon ceph-osd không đang chạy:
shell> ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
-1 111.77881 root default
-3 27.94470 host pve01
0 ssd 3.49309 osd.0 up 1.00000 1.00000
1 ssd 3.49309 osd.1 down 0 0
2 ssd 3.49309 osd.2 up 1.00000 1.00000
3 ssd 3.49309 osd.3 up 1.00000 1.00000
4 ssd 3.49309 osd.4 up 1.00000 1.00000
5 ssd 3.49309 osd.5 up 1.00000 1.00000
6 ssd 3.49309 osd.6 up 1.00000 1.00000
7 ssd 3.49309 osd.7 up 1.00000 1.00000
-5 27.94470 host pve02
8 ssd 3.49309 osd.8 up 1.00000 1.00000
9 ssd 3.49309 osd.9 up 1.00000 1.00000
10 ssd 3.49309 osd.10 up 1.00000 1.00000
11 ssd 3.49309 osd.11 up 1.00000 1.00000
12 ssd 3.49309 osd.12 up 1.00000 1.00000
13 ssd 3.49309 osd.13 up 1.00000 1.00000
14 ssd 3.49309 osd.14 up 1.00000 1.00000
15 ssd 3.49309 osd.15 up 1.00000 1.00000
-7 27.94470 host pve03
16 ssd 3.49309 osd.16 up 1.00000 1.00000
17 ssd 3.49309 osd.17 up 1.00000 1.00000
18 ssd 3.49309 osd.18 up 1.00000 1.00000
19 ssd 3.49309 osd.19 up 1.00000 1.00000
20 ssd 3.49309 osd.20 up 1.00000 1.00000
21 ssd 3.49309 osd.21 up 1.00000 1.00000
22 ssd 3.49309 osd.22 up 1.00000 1.00000
23 ssd 3.49309 osd.23 up 1.00000 1.00000
-9 27.94470 host pve04
24 ssd 3.49309 osd.24 up 1.00000 1.00000
25 ssd 3.49309 osd.25 up 1.00000 1.00000
26 ssd 3.49309 osd.26 up 1.00000 1.00000
27 ssd 3.49309 osd.27 up 1.00000 1.00000
28 ssd 3.49309 osd.28 up 1.00000 1.00000
29 ssd 3.49309 osd.29 up 1.00000 1.00000
30 ssd 3.49309 osd.30 up 1.00000 1.00000
31 ssd 3.49309 osd.31 up 1.00000 1.0000Lệnh này sẽ hiển thị cấu trúc cây của cluster, bao gồm tất cả các OSD và trạng thái của chúng. Điều này giúp bạn xác định vị trí vật lý của các OSD cụ thể, có thể hỗ trợ bạn trong việc khắc phục sự cố của cluster.
Giám sát PG
Thuật toán CRUSH trong Ceph
CRUSH (Controlled Replication Under Scalable Hashing) là thuật toán mà Ceph sử dụng để xác định cách phân bổ và sao chép dữ liệu trong cluster. Khi CRUSH gán một Placement Group (PG) cho các OSD (Object Storage Daemons), nó sẽ xác định số lượng bản sao của PG cần thiết cho pool và sau đó gán mỗi bản sao cho một OSD khác nhau.
Ví dụ, nếu pool yêu cầu ba bản sao của một PG, CRUSH có thể gán chúng riêng lẻ cho osd.1, osd.2 và osd.3. CRUSH tìm kiếm một vị trí ngẫu nhiên mà cũng đồng thời xem xét các failure domains mà bạn đã đặt trong bản đồ CRUSH của mình; vì lý do này, PGs hiếm khi được gán cho các OSD liền kề trong một cluster lớn.
Failure domains là một khái niệm quan trọng liên quan đến cách dữ liệu được phân phối và sao lưu trong cluster. Một failure domain có thể được hiểu là một nhóm các OSD (Object Storage Daemons) mà nếu một sự cố xảy ra, tất cả các OSD trong nhóm đó có thể bị ảnh hưởng.
Ví dụ, nếu bạn đặt một rack chứa nhiều OSD làm một failure domain, điều đó có nghĩa là Ceph sẽ cố gắng không đặt nhiều bản sao của cùng một dữ liệu trên các OSD nằm trong cùng một rack. Điều này giúp ngăn ngừa mất mát dữ liệu nếu toàn bộ rack gặp sự cố.
Up set và Acting Set trong Ceph
Acting set được xác định bởi Ceph OSD daemon, Acting set là tập hợp các OSD mà một object hoặc một phần của object hiện đang được lưu trữ. Acting set giúp Ceph xác định nơi để đọc dữ liệu hiện có, đảm bảo rằng dữ liệu luôn sẵn sàng cho các yêu cầu đọc.

UP set được xác định bởi CRUSH map, UP set là tập hợp các OSD mà một object hoặc một phần của object sẽ được lưu trữ. UP set giúp Ceph xác định nơi để ghi dữ liệu mới, đảm bảo rằng dữ liệu được phân phối đều và hiệu quả trên tất cả các OSD.
Việc xác định UP set và Acting set được thực hiện tự động bởi thuật toán CRUSH và Ceph OSD daemon, không cần phải cấu hình thủ công.
Mỗi Placement Group (PG) trong Ceph sẽ có một Up Set và một Acting Set riêng của nó.
Bạn có thể sử dụng lệnh ceph pg dump để xem thông tin về tất cả các PG trong cluster, bao gồm cả Acting Set cho mỗi PG.
Để xem OSD nào nằm trong Acting Set và Up Set cho một PG cụ thể, hãy chạy lệnh sau:
shell> ceph pg map 2.7f
osdmap e9392 pg 2.7f (2.7f) -> up [22,13,31] acting [22,13,31]Vì UP set và Acting set giống nhau, điều này cho thấy hệ thống Ceph của bạn đang hoạt động bình thường và không có OSD nào bị hỏng hoặc đang di chuyển dữ liệu.
Lưu ý:
- Nếu Up Set và Acting Set không khớp, điều này có thể cho thấy rằng cụm đang cân bằng lại chính nó hoặc có vấn đề với cụm.
- Trực tiếp từ Ceph, bạn không thể xem được danh sách các object cụ thể đang được quản lý bởi một Placement Group (PG) cụ thể. Ceph không cung cấp công cụ hoặc lệnh để truy vấn trực tiếp thông tin này.
Giám sát trạng thái PG
Nếu bạn chạy các lệnh ceph health, ceph -s, hoặc ceph -w, bạn có thể nhận thấy rằng cụm không luôn hiển thị HEALTH OK. Sau khi kiểm tra xem các OSD có đang chạy hay không, bạn cũng nên kiểm tra trạng thái của PG. Có một số tình huống liên quan đến PG-peering mà cụm sẽ KHÔNG hiển thị HEALTH OK là bình thường và dự kiến:
- Bạn vừa tạo một pool và các PG chưa peering.
- Các PG đang phục hồi.
- Bạn vừa thêm một OSD vào hoặc loại bỏ một OSD khỏi cụm.
- Bạn vừa sửa đổi bản đồ CRUSH của mình và các PG của bạn đang di chuyển.
- Có dữ liệu không nhất quán trong các bản sao khác nhau của một PG.
- Ceph đang scrub các bản sao của một PG.
- Ceph không có đủ dung lượng lưu trữ để hoàn thành các hoạt động backfilling.
Nếu một trong những tình huống này khiến Ceph hiển thị HEALTH WARN, bạn đừng quá lo lắng vì nhiều trường hợp, cụm sẽ phục hồi tự động. Tuy nhiên, trong một số trường hợp, bạn có thể cần phải kiểm tra thủ công. Một khía cạnh quan trọng của việc giám sát PG là kiểm tra trạng thái của chúng là Active/clean: tức là, quan trọng là đảm bảo rằng, khi cụm đang hoạt động, tất cả các PG đều active và (ưu tiên) clean. Để xem trạng thái của mỗi PG, hãy chạy lệnh sau:
shell> ceph pg stat
161 pgs: 161 active+clean; 4.3 TiB data, 13 TiB used, 99 TiB / 112 TiB avail; 5.6 MiB/s rd, 1.7 MiB/s wr, 559 op/sCác trạng thái PG phổ biến

CREATING
Khi pool được tạo, Ceph sẽ tạo tất cả các PGs cho pool đó. Trong quá trình này, Ceph sẽ hiển thị trạng thái ‘creating’ cho mỗi PG. Điều này chỉ đơn giản là nghĩa là PG đang được tạo.
PEERING
Khi một Placement Group (PG) trong Ceph đồng bộ, các OSD (Object Storage Daemons) lưu trữ các bản sao của dữ liệu của nó đồng thuận về trạng thái của dữ liệu và metadata trong PG đó. Điều này có nghĩa là tất cả các OSD đều đồng ý về trạng thái hiện tại của PG, bao gồm cả dữ liệu và metadata.
ACTIVE
Trạng thái “active” của một Placement Group (PG) trong Ceph có nghĩa là PG đó đang hoạt động và sẵn sàng để nhận dữ liệu.
CLEAN
Trạng thái “clean” của một Placement Group (PG) trong Ceph có nghĩa là tất cả các OSD (Object Storage Daemons) chứa dữ liệu và metadata của PG đó đã hoàn thành quá trình peering thành công và không có bản sao nào lạc hậu.
DEGRADED
Trạng thái hạ cấp (Degraded State): Một PG chuyển vào trạng thái Degraded State khi không phải tất cả các bản sao của một đối tượng đều được cập nhật. Điều này có thể xảy ra, ví dụ khi một client ghi một đối tượng vào OSD chính và OSD chính chịu trách nhiệm sao chép đối tượng đó vào các OSD phụ. PG sẽ ở trong trạng thái Degraded State cho đến khi OSD chính nhận được xác nhận từ các OSD phụ rằng họ đã tạo thành công các bản sao của đối tượng.
Trạng thái active+degraded: Một PG có thể ở trong trạng thái active+degraded nếu một OSD đang hoạt động nhưng không giữ tất cả các đối tượng của PG. Nếu một OSD gặp sự cố, Ceph sẽ đánh dấu mỗi PG được gán cho OSD là Degraded State. Các PG phải thực hiện peering lại khi OSD trở lại online. Tuy nhiên, một client vẫn có thể ghi một đối tượng mới vào một PG Degraded State nếu nó đang hoạt động.
Remapping: Nếu một OSD gặp sự cố và trạng thái Degraded State kéo dài, Ceph có thể đánh dấu OSD loại bỏ OSD này khỏi cụm và remap dữ liệu từ OSD gặp sự cố đến OSD khác. Thời gian giữa việc được đánh dấu gặp sự cố và được đánh dấu loại bỏ OSD này khỏi cụm được xác định bởi mon_osd_down_out_interval, mặc định là 600 giây.
Đối tượng bị thiếu (Missing Objects): Một PG cũng có thể ở trong trạng thái Degraded State nếu có một hoặc nhiều đối tượng mà Ceph mong đợi tìm thấy trong PG nhưng không thể tìm thấy. Mặc dù bạn không thể đọc hoặc ghi vào các đối tượng bị thiếu, bạn vẫn có thể truy cập tất cả các đối tượng khác trong PG Degraded State. Trong trường hợp một đối tượng bị thiếu, Ceph sẽ không tự động tạo ra một đối tượng mới ở OSD khác. Thay vào đó, Ceph sẽ cố gắng khôi phục đối tượng bị thiếu từ các bản sao khác (nếu có) hoặc từ lịch sử ghi dữ liệu (nếu có).
RECOVERING
Khi một OSD gặp sự cố, dữ liệu trên đó có thể bị cũ so với các bản sao khác trong PG. Khi OSD hoạt động trở lại, nội dung của PG cần được cập nhật để phản ánh trạng thái hiện tại của cụm. Trong thời gian này, OSD có thể ở trong trạng thái đang phục hồi.
BACKFILLING
Khi một OSD mới được thêm vào cụm, hệ thống CRUSH sẽ phân chia lại PGs từ các OSD hiện có sang OSD mới. Điều này có thể tạo ra áp lực lớn cho OSD mới, vì nó phải chấp nhận nhiều PGs ngay lập tức. Quá trình “backfill” cho phép việc này diễn ra một cách từ từ, giúp giảm áp lực cho OSD mới.
REMAPPED
Khi tập hợp các OSD phục vụ một PG thay đổi, dữ liệu cần được di chuyển từ tập hợp OSD cũ sang tập hợp OSD mới. Điều này có thể mất một thời gian nhất định.
STALE
Ceph sử dụng cơ chế “heartbeat” để kiểm tra xem các host và daemons có đang hoạt động hay không. Tuy nhiên, trong một số trường hợp, các daemons ceph-osd có thể rơi vào trạng thái “bị kẹt”, nơi mà chúng không thể gửi các báo cáo thống kê kịp thời. Điều này có thể xảy ra do một số lỗi mạng tạm thời.
Xác định sự cố PG
Một PG cũng có thể ở trong trạng thái “degraded” vì có một hoặc nhiều đối tượng mà Ceph mong đợi tìm thấy trong PG nhưng Ceph không thể tìm thấy. Mặc dù bạn không thể đọc hoặc ghi vào các đối tượng không tìm thấy, bạn vẫn có thể truy cập tất cả các đối tượng khác trong PG “degraded”.
Để xác định PGs bị kẹt, hãy chạy lệnh sau:
ceph pg dump_stuck [unclean|inactive|stale|undersized|degraded]Tìm vị trí của Object
Để lưu trữ dữ liệu đối tượng trong Ceph Object Store, một client Ceph phải:
- Đặt tên cho đối tượng
- Chỉ định một pool
Đây là quy trình mà Ceph sử dụng để xác định vị trí lưu trữ của một đối tượng trong hệ thống:
- Client Ceph lấy bản đồ cluster mới nhất: Bản đồ cluster chứa thông tin về cấu trúc và trạng thái của cụm Ceph, bao gồm các OSD, các pool và các PG.
- Thuật toán CRUSH tính toán cách ánh xạ đối tượng đến một PG: CRUSH (Controlled Replication Under Scalable Hashing) là thuật toán mà Ceph sử dụng để xác định vị trí lưu trữ của mỗi đối tượng. CRUSH nhận vào tên đối tượng và tên pool và trả về ID của PG mà đối tượng nên được lưu trữ.
- Thuật toán CRUSH tính toán cách gán động PG đến một OSD: Sau khi xác định được PG, CRUSH tiếp tục xác định OSD nào sẽ chứa PG đó.
Để tìm vị trí của một đối tượng chỉ với tên đối tượng và tên pool, bạn có thể chạy một lệnh có dạng sau:
ceph osd map {poolname} {object-name} [namespace]Ceph sẽ xuất ra vị trí của đối tượng. Ví dụ:
shell> ceph osd map data test-object-1
osdmap e537 pool 'data' (1) object 'test-object-1' -> pg 1.d1743484 (1.4) -> up ([0,1], p0) acting ([0,1], p0)
