ceph PG狀態的示例分析

這篇文章主要介紹ceph PG狀態的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

當CRUSH分配安置組的OSD，它主要盯在泳池副本的數量和分配安置組到OSDS，每個副本都會被分配到不同的OSD等。例如，如果池需要三個副本放置組，CRUSH可能將他們分配到 osd.1 osd.2和osd.3。CRUSH其實是一個偽隨機分配，它考慮CRUSH圖中設置的故障域，所以你很少會看到在一個大集群中，布置組被分配到最近的鄰居的OSD。我們指到設定的OSD應包含代理設置一個特定的安置組的副本。在某些情況下，代理設置OSD掛掉或以其他方式無法對安置組對象的服務請求。出現這種情況時，不要驚慌。常見的例子包括：

• 您正在添加或刪除OSD。然后，CRUSH重新分配安置組給其他的OSD從而改變組成的代理設置和“回填”的過程中的數據遷移。

• 一個OSD 被restared，現在恢復。

• 一個正在執行動作的OSD掛掉，或無法接收服務請求，另一個的OSD臨時使用其職責。

Ceph processes a client request using the Up Set, which is the set of OSDs that will actually handle the requests. In most cases, the Up Set and the Acting Set are virtually identical. When they are not, it may indicate that Ceph is migrating data, an OSD is recovering, or that there is a problem (i.e., Ceph usually echoes a “HEALTH WARN” state with a “stuck stale” message in such scenarios).

To retrieve a list of placement groups, execute:

Ceph的處理的客戶端請求，使用的Up Set，這是一組，將實際處理請求的OSD。在大多數情況下，Up Set和the Acting Set，實際上是相同的。當他們都不是這種情況時，它可能表明Ceph的數據遷移，OSD正在恢復，或者說是一個問題（即，通常Ceph響應消息“HEALTH WARN”與“stuck stale”的消息）。

要檢索布置組的列表，執行：

ceph pg dump

要查看它的OSD內的代理設置或最多設置安置組，執行：

ceph pg map {pg-num}

結果應該包括：osdmap的epoch（eNNN），安置組號碼（{PG-NUM}），處于Up Set的OSDS和處于the acting set的OSDS。

osdmap eNNN pg {pg-num} -> up [0,1,2] acting [0,1,2]

PG中OSD確定代碼主要為OSDMap::pg_to_osds、OSDMap::pg_to_up_acting_osds，在OSD.cc中創建、裝載PG時都有調用

1. Creating

創建存儲池時,它會創建指定數量的歸置組。ceph 在創建一或多個歸置組時會顯示 creating;創建完后,在其歸置組的 Acting Set 里的 OSD 將建立互聯;一旦互聯完成,歸置組狀態應該變為 active+clean,意思是ceph 客戶端可以向歸置組寫入數據了。

2. peering

ceph 為歸置組建立互聯時,會讓存儲歸置組副本的 OSD 之間就其中的對象和元數據狀態達成一致。ceph 完成了互聯,也就意味著存儲著歸置組的 OSD 就其當前狀態達成了一致。然而,互聯過程的完成并不能表明各副本都有了數據的最新版本。

3. active

ceph 完成互聯進程后,一歸置組就可變為 active。active 狀態通常意味著在主歸置組和副本中的數據都可以讀寫。

4. clean

某一歸置組處于 clean 狀態時,主 OSD 和副本 OSD 已成功互聯,并且沒有偏離的歸置組。ceph 已把歸置組中的對象復制了規定次數。

5. degraded

當客戶端向主 OSD 寫入數據時,由主 OSD 負責把副本寫入其余復制 OSD。主 OSD 把對象寫入復制 OSD 后,在沒收到成功完成的確認前,主 OSD 會一直停留在 degraded 狀態。
歸置組狀態可以是 active+degraded 狀態,原因在于一 OSD 即使沒所有對象也可以處于 active 狀態。如果一OSD 掛了,ceph 會把相關的歸置組都標記為 degraded;那個 OSD 重生后,它們必須重新互聯。然而,如果歸置組仍處于 active 狀態,即便它處于 degraded 狀態,客戶端還可以向其寫入新對象。
如果一 OSD 掛了,且 degraded 狀態持續,ceph 會把 down 的 OSD 標記為在集群外(out)、并把那些 down 掉的 OSD 上的數據重映射到其它 OSD。從標記為 down 到 out 的時間間隔由 mon osd down out interval 控制,默認是 300 秒。
歸置組也會被降級(degraded),因為歸置組找不到本應存在于歸置組中的一或多個對象,這時,你不能讀或寫找不到的對象,但仍能訪問其它位于降級歸置組中的對象。

6. recovering

ceph 被設計為可容錯,可抵御一定規模的軟、硬件問題。當某 OSD 掛了(down)時,其內容版本會落后于歸置組內的其它副本;它重生(up)時,歸置組內容必須更新,以反映當前狀態;在此期間,OSD 在recovering 狀態。
恢復并非總是這些小事,因為一次硬件失敗可能牽連多個 OSD。比如一個機柜的網絡交換機失敗了,這會導致多個主機落后于集群的當前狀態,問題解決后每一個 OSD 都必須恢復。
ceph 提供了很多選項來均衡資源競爭,如新服務請求、恢復數據對象和恢復歸置組到當前狀態。osd recovery delay start 選項允許一 OSD 在開始恢復進程前,先重啟、重建互聯、甚至處理一些重放請求;osd recovery threads 選項限制恢復進程的線程數,默認為 1 線程;osd recovery thread timeout 設置線程超時,因為多個OSD 可能交替失敗、重啟和重建互聯;osd recovery max active 選項限制一 OSD 最多同時接受多少請求,以防它壓力過大而不能正常服務;osd recovery max chunk 選項限制恢復數據塊尺寸,以防網絡擁塞。

7. back filling

有新 OSD 加入集群時,CRUSH 會把現有集群內的歸置組重分配給它。強制新 OSD 立即接受重分配的歸置組會使之過載,用歸置組回填可使這個過程在后臺開始。回填完成后,新 OSD 準備好時就可以對外服務了。

8. remapped

某一歸置組的 Acting Set 變更時,數據要從舊集合遷移到新的。主 OSD 要花費一些時間才能提供服務,所以它可以讓老的主 OSD 持續服務、直到歸置組遷移完。數據遷移完后,主 OSD 會映射到新 acting set。

9. stale

雖然 ceph 用心跳來保證主機和守護進程在運行,但是 ceph-osd 仍有可能進入 stuck 狀態,它們沒有按時報告其狀態(如網絡瞬斷)。默認,OSD 守護進程每半秒(0.5)會一次報告其歸置組、出流量、引導和失敗統計
狀態,此頻率高于心跳閥值。如果一歸置組的主 OSD 所在的 acting set 沒能向監視器報告、或者其它監視器已經報告了那個主 OSD 已 down,監視器們就會把此歸置組標記為 stale。啟動集群時,會經常看到 stale 狀態,直到互聯完成。集群運行一陣后,如果還能看到有歸置組位于 stale 狀態,就說明那些歸置組的主 OSD 掛了(down)、或沒在向監視器報告統計信息。
二、找出故障歸置組

一般來說,歸置組卡住時 ceph 的自修復功能往往無能為力,卡住的狀態細分為:

1. unclean

不干凈:歸置組里有些對象的復制數未達到期望次數,它們應該在恢復中。

2. inactive

不活躍:歸置組不能處理讀寫,因為它們在等著一個持有最新數據的 OSD 再次進入 up 狀態。

3. stale

發蔫:歸置組們處于一種未知狀態,因為存儲它們的 OSD 有一陣子沒向監視器報告了(由 mon osdreport timeout 配置)。

以上是“ceph PG狀態的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注億速云行業資訊頻道！