Ceph 中的 PG 狀態詳解

Creating

Peering

Activating

Active

Backfilling

Backfill-toofull

Backfill-wait

Incomplete

Inconsistent

Peered

Recovering

Recovering-wait

Remapped

Scrubbing

Unactive

Unclean

Stale

Undersized

Down

 

 

Creating

含義：PG正在建立

引發緣由：建立pool的時候，根據指定的pg數量進行建立pg時出現的狀態，正常狀態

後果：無

解決方案：無需解決，正常狀態之一

 

 

Peering

含義：PG之間進行互聯，就其中的對象和元數據狀態達成一致

引發緣由：當pg被creating以後，會進行互聯，存儲歸置組副本的 OSD 之間就其中的對象和元數據狀態達成一致。

後果：無

解決方案：無需解決，正常狀態之一

 

 

Activating

含義：pg在完成peering過程後，會對以前的結果進行固化，等待全部pg同步，嘗試進入active狀態

引發緣由：pg進入active前的準備狀態

後果：若是長期卡在該狀態，會影響該PG沒法讀寫，進而影響整個pool可用性

解決方案：

停掉PG所在全部OSD

用ceph-object-tool進行pg數據備份

用ceph-object-tool在主PG上刪除空的pg（不要手動刪除）

再次使用ceph-object-tool導入數據

手動給該pg目錄賦ceph權限

最後重啓osd

 

 

Active

含義：pg是活躍態，能夠進行讀寫操做

引發緣由：正常狀態

後果：無

解決方案：無需解決，正常狀態之一

 

 

Backfilling

含義：回填狀態

引發緣由：這種狀況通常是因爲osd的離線（超過5分鐘沒有心跳回應），ceph找尋新的osd來替換所進行的全量數據拷貝。

後果：出現這個狀態通常都是肯定有osd掛掉或者離線了

解決方案：多數狀況下ceph會自動完成數據回填，若是沒法完成回填，就會進入backfill-toofull狀態

 

 

Backfill-toofull

含義：backfilling掛起狀態

引發緣由：一般是由於osd容量不足以回填丟失的osd引發

後果：形成pool沒法寫入，讀寫卡死。

解決方案：

須要檢查osd容量，是否有嚴重不平衡現象，將超量osd數據手動疏散（reweight），若是是集羣nearful現象，應該儘快物理擴容

緊急擴容方式（治標不治本，最好的方法仍是擴展osd數量和容量）

暫停osd讀寫：

ceph osd pause

通知mon和osd修改full閾值

ceph tell mon.* injectargs "--mon-osd-full-ratio 0.96"

ceph tell osd.* injectargs "--mon-osd-full-ratio 0.96"

通知PG修改full閾值：

ceph pg set_full_ratio 0.96

解除osd禁止讀寫：

ceph osd unpause

 

 

Backfill-wait

含義：PG正在等待開始回填操做。

引發緣由：OSD離線形成（未親自捕獲該狀態，多是太快了沒看到）

後果：接下來理論來說pg會進入backfilling狀態進行數據回填

解決方案：正常的回填必經狀態，無需特殊關注

 

 

Incomplete

含義：peering過程當中發現沒法就數據狀態達成一致

引發緣由：pg在選擇權威日誌的時候，權威日誌無法完成，或者權威日誌完成後和本地日誌對比邏輯不正常

後果：一般會致使pg沒法建立，卡在creating+incomplete狀態，進而致使pool沒法使用

解決方案：

首先確認osd_allow_recovery_below_min_size爲true，還有副本數量是否合理，crushmap配置的選取osd數量是否與pool一致，若是都正常，嘗試執行如下恢復流程

停掉全部incomplete的PG對應的每個osd

使用ceph-object-tool對osd進行mark complete

而後重啓osd

 

 

Inconsistent

含義：其實就是副本數據不一致的意思

引發緣由：某個副本數據未知緣由丟失

後果：副本數據不一致致使安全性降低

解決方案：

使用ceph pg repair工具進行數據修復，通常狀況下均可以恢復正常，若是沒法恢復

把三副本的osd的osd_max_scrubs都先調大,再次使用使用ceph pg repair工具進行數據修復，最後再將osd_max_scrubs調回1

 

 

Peered

含義：搜索中，指的是PG找不到足夠的副原本進行讀寫操做（連min_size都沒法知足的狀況下）

引發緣由：多個osd掛掉，形成當前活躍osd副本數<min_size，讀寫功能鎖死

後果：pg沒法使用，甚至pool沒法進行常規io

解決方案：

集羣健康狀態下，osd掛掉超過5分鐘會自動remapped修復該狀態，想要快速修復該狀態方法有二：

1 嘗試啓動副本osd，從新加入集羣，peered會自動消失

2 主動out掉失聯的osd，ceph會自動進入修復狀態

 

 

Recovering

含義：恢復中

引發緣由：當某 OSD 掛了（ down ）時，其內的歸置組會落後於別的歸置組副本；此 OSD 重生（ up ）時，歸置組內容必須更新到當前狀態；

後果：恢復並不是老是這些小事，由於一次硬件失敗可能牽連多個 OSD 。好比一個機櫃或房間的網絡交換機失敗了，這會致使多個主機上的 OSD 落後於集羣的當前狀態，故障恢復後每個 OSD 都必須恢復。

解決方案：集羣出現這個狀態，說明PG正在自動恢復，等它恢復完成就行了。

 

 

Recovering-wait

含義：等待 Recovery 資源預留

引發緣由：PG正在等待恢復。

後果：理論來說pg會進入recovering狀態進行數據恢復

解決方案：正常的恢復狀態。

 

 

Remapped

含義：從新映射態

引發緣由：當Acting集合裏面的PG組合發生變化時，數據從舊的集合遷移到新的集合中。這段時間可能比較久，新集合的主OSD在遷移完以前不能響應請求。因此新主OSD會要求舊主OSD繼續服務指導PG遷移完成。一旦數據遷移完成，新主OSD就會生效接受請求。

後果：若是沒法從新映射，數據就沒法進行遷移，會形成數據的丟失。

解決方案：

在 OSD 掛掉或者在擴容的時候PG 上的OSD會按照Crush算法從新分配PG 所屬的osd編號。而且會把 PG Remap到別的OSD上去。

Remapped狀態時，PG當前Acting Set與Up Set不一致。

客戶端IO能夠正常讀寫。

 

 

Scrubbing

含義：清理中

引發緣由：pg正在作不一致性校驗。

後果：會形成IO性能降低

解決方案：能夠根據實際環境需求，關閉該功能或者下降自檢頻率。

 

 

Unactive

含義：非活躍態,PG 不能處理讀寫請求

引發緣由：PG 很長時間沒有顯示爲 acitve 狀態, (不可執行讀寫請求), PG 不能夠執行讀寫,

後果：PG 不能夠執行讀寫

解決方案：等待 OSD 更新數據到最新的備份狀態

 

 

Unclean

含義：非乾淨態,PG 不能從上一個失敗中恢復

引發緣由：歸置組裏有些對象的副本數未達到指望次數，它們應該在恢復中；

後果：數據安全性降低

解決方案：一般都要執行恢復操做

 

 

Stale

含義：爲刷新態，pg沒有被任何osd更新

引發緣由：極可能是osd掛掉引發的，通常狀況下跟隨peering狀態一塊兒出現

模擬：手動停掉一個osd，systemctl stop ceph-osd@0，查看ceph -s 會發如今短期內（peering以前），pg會進入stale+clean+active的特殊狀態

後果：警告標誌，每每表明着osd出現異常，或者某節點斷網。

解決方案：通常狀況下只須要等待peering完成便可。

 

 

Undersized

含義：副本數太小

引發緣由：該PG的副本數量小於存儲池所配置的副本數量。一般是因爲一個osd服務down了，出現此狀態。

後果：下降數據可用性

解決方案：調整PG所在池的副本數 osd pool default min size =1 ，不建議調整。等osd服務起來就行了

 

 

Down

含義：失效

引發緣由：歸置組的權威副本OSD宕機，必須等待其開機，或者被標記爲lost才能繼續

後果：這個時候該 PG 不能提供客戶端 IO 讀寫， IO 會掛起夯住

解決方案：將OSD服務起來。