摘要: 當CRUSH分配安置組的OSD，它主要盯在泳池副本的數量和分配安置組到OSDS，每個副本都會被分配到不同的OSD等。例如，如果池需要三個副本放置組，CRUSH可能將他們分配到 osd.1 osd.2和osd.3。CRUSH其實是一個僞隨機分配，它考慮CRUSH圖中設置的故障域，所以你很少會看到在一個大集羣中，佈置組被分配到最近的鄰居的OSD。我們指到設定的OSD應包含代理設置一個特定的安置組的副本
當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 配置)。