Ceph中的Placement Group狀態有哪些

這篇文章主要為大家展示了“Ceph中的Placement Group狀態有哪些”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“Ceph中的Placement Group狀態有哪些”這篇文章吧。

Placement Group（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可用性
解決方案：

1. 停掉PG所在所有OSD

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

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

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

5. 手動給該pg目錄賦ceph權限

6. 最后重啟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，查看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服務起來。

以上是“Ceph中的Placement Group狀態有哪些”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！