ceph中最常用的命令就是ceph -s。
我們通過ceph -s中顯示的結果如下：
但是有時侯也會有這種情況：
那么下面這些PG的狀態都是什么意思呢？
ceph -s 能夠非常直觀看到pg的狀態，pg是數據存儲的重要單位，在使用ceph的時候，pg會經常發生狀態的變化，參考下面例子。 1. 當創建 pool 的時候，將會創建相應的 pg，那么可以看到pg creating狀態。 2. 當部分 pg 創建成功后，將會發現 pg 會進入到 peering 狀態。 3. 當所有 pg peering 完成后，將可見到狀態變成 active+clean。
常見的PG狀態：
常見的pg狀態： creating ：創建中 down ：PG處於失效狀態，PG處於離線狀態 repair （修復）：PG正在被檢查，被發現的任何不一致都將盡可能的被修復。 peering（等待互聯）： 1. 當ceph peering pg, ceph 將會把 pg 副本協定導入 osd, 當 ceph 完成 peering, 意味着 osd 同意當前 PG 狀態, 並允許寫入 2. PG處於 peering 過程中, peering 由主 osd 發起的使存放 PG 副本的所有 OSD 就 PG 的所有對象和元素數據的狀態達成一致的過程, peering 過程完成后, 主 OSD 就可以接受客戶端寫請求. active： 1. 當 ceph 完成 peering 過程, pg 將會變成 active, active 狀態意味着 pg 中的數據變得可用, 主 pg 將可執行讀寫操作 2. PG 是活動的, 意味着 PG 中的數據可以被讀寫, 對該 PG 的操作請求都講會被處理. clean: 干凈態。PG當前不存在待修復的對象， Acting Set和Up Set內容一致，並且大小等於存儲池的副本數 replay（重做）：某OSD崩潰后，PG正在等待客戶端重新發起操作。 degraded（降級）： 1. 當客戶端寫對象到主 osd, 主 OSD 會把數據寫復制到對應復制 OSD, 在主 OSD 把對象寫入存儲后, PG 會顯示為 degraded 狀態, 直到主 osd 從復制 OSD 中接收到創建副本對象完成信息 2. PG 處於 active+degraded 原因是因為 OSD 是處於活躍, 但並沒有完成所有的對象副本寫入, 假如 OSD DOWN, CEPH 標記每個 PG 分配到這個相關 OSD 的 狀態為 degraded, 當 OSD 重新上線, OSD 將會重新恢復, 3. 假如 OSD DOWN 並且 degraded 狀態持續, CEPH 會標記 DOWN OSD, 並會對集群遷移相關 OSD 的數據, 對應時間由 mon osd down out interval 參數決定 4. PG 可以被北極為 degraded, 因為 ceph 在對應 PG 中無法找到一個或者多個相關的對象, 你不可以讀寫 unfound 對象, 你仍然可以訪問標記為 degraded PG 的其他數據 5. PG 中部分對象的副本數量未達到規定的數量 inconsistent（不一致）：PG副本出現不一致, 對象大小不正確或者恢復借宿后某個副本出現對象丟失現象 recoverying（恢復中）： ceph 設備故障容忍在一定范圍的軟件與硬件問題, 當 OSD 變 DOWN, 那么包含該 OSD 的 PG 副本都會有問題, 當 OSD 恢復, OSD 對應的 PG 將會更新 並反映出當前狀態, 在一段時間周期后, OSD 將會恢復 recoverying 狀態 recovery 並非永遠都有效, 因為硬件故障可能會導致多個 OSD 故障, 例如, 網絡交換機故障, 可以導致集群中的多個主機及主機包含的 OSD 故障 當網絡恢復之后, 每個 OSD 都必須執行恢復 back filling（回填）： 當新 OSD 加入集群, CRUSH 將會為集群新添加的 OSD 重新分配 PG, 強制新的 OSD 接受重新分配的 PG 並把一定數量的負載轉移到新 OSD 中,back filling OSD 會在后台處理, 當 backfilling 完成, 新的 OSD 完成后, 將開始對請求進行服務 在 backfill 操作期間, 你可以看到多種狀態, backfill_wait 表示 backfill 操作掛起, 但 backfill 操作還沒有開始 ( PG 正在等待開始回填操作 ) backfill 表示 backfill 操作正在執行 backfill_too_full 表示在請求 backfill 操作, 由於存儲能力問題, 但不可以完成, ceph 提供設定管理裝載重新分配 PG 關聯到新的 OSD osd_max_backfills 設定最大數量並發 backfills 到一個 OSD, 默認 10 osd backfill full ratio 當 osd 達到負載, 允許 OSD 拒絕 backfill 請求, 默認 85%, 假如 OSD 拒絕 backfill 請求, osd backfill retry interval 將會生效, 默認 10 秒后重試 osd backfill scan min , osd backfill scan max 管理檢測時間間隔 一個新 OSD 加入集群后, CRUSH 會把集群先有的一部分 PG 分配給他, 該過程稱為回填, 回填進程完成后, 新 OSD 准備好了就可以對外提供服務。 remapped（重映射）： 當 pg 改變, 數據從舊的 osd 遷移到新的 osd, 新的主 osd 應該請求將會花費一段時間, 在這段時間內, 將會繼續向舊主 osd 請求服務, 直到 PG 遷移完成, 當數據遷移完成, mapping 將會使用新的 OSD 響應主 OSD 服務 當 PG 的 action set 變化后, 數據將會從舊 acting set 遷移到新 action set, 新主 OSD 需要過一段時間后才能提供服務, 因此它會讓老的主 OSD 繼續提供服務, 知道 PG 遷移完成, 數據遷移完成后, PG map 將會使用新 acting set 中的主 OSD 例如： [root@ ~]# ceph osd map volumes rbd_id.volume-1421625f-a9a2-41d0-8023-4cec54b33a57 osdmap e5276 pool 'volumes' (1) object 'rbd_id.volume-1421625f-a9a2-41d0-8023-4cec54b33a57' -> pg 1.2cdd8028 (1.28) -> up ([32,26,41], p32) acting ([32,26,41], p32) stale（舊）： 當 ceph 使用 heartbeat 確認主機與進程是否運行, ceph osd daemon 可能由於網絡臨時故障, 獲得一個卡住狀態 (stuck state) 沒有得到心跳回應 默認, osd daemon 會每 0.5 秒報告 PG, up 狀態, 啟動與故障分析, 假如 PG 中主 OSD 因為故障沒有回應 monitor 或者其他 OSD 報告 主 osd down, 那么 monitor 將會標記 PG stale, 當你重啟集群, 通常會看到 stale 狀態, 直到 peering 處理完成, 在集群運行一段時候, 看到 stale 狀態, 表示主 osd PG DOWN 或者沒有主 osd 沒有報告 PG 信息到 monitor 中 PG 處於未知狀態, monitors 在 PG map 改變后還沒有收到過 PG 的更新, 啟用一個集群后, 常常會看到主 peering 過程結束前 PG 處於該狀態。 scrubbing（清理中）： PG 在做不一至性校驗
有問題的PG： inactive ：PG 很長時間沒有顯示為 acitve 狀態, (不可執行讀寫請求), PG 不可以執行讀寫, 因為等待 OSD 更新數據到最新的備份狀態 unclean：PG 很長時間都不是 clean 狀態 (不可以完成之前恢復的操作), PG 包含對象沒有完成相應的復制副本數量, 通常都要執行恢復操作。 stale：PG 狀態很長時間沒有被 ceph-osd 更新過, 標識存儲在該 GP 中的節點顯示為 DOWN, PG 處於 unknown 狀態, 因為 OSD 沒有報告 monitor 由 mon osd report timeout 定義超時時間
ceph pg 常見問題處理：
案例1:
1. 檢查集群狀態發現有pg inconsistent
通過ceph health detail查看具體的PG id。
$ ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent
pg 3.0 is active+clean+inconsistent, acting [34,23,1]
通過上面輸出可以看到當前PG3.0處於inconsistent，並且它的三副本分別在osd.34,osd.23,osd.1。
2. 修復PG 3.0
$ ceph pg repair 3.0
instructing pg 3.0 on osd.34 to repair
#查看集群監控狀態
$ ceph health detail
HEALTH_ERR 1 scrub errors; Possible data damage: 1 pg inconsistent, 1 pg repair
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent, 1 pg repair
pg 3.0 is active+clean+scrubbing+deep+inconsistent+repair, acting [34,23,1]
#集群監控狀態已恢復正常
$ ceph health detail
HEALTH_OK
3. 根據以往經驗，pg出現inconsistent很有可能是對應的osd磁盤上有邏輯壞道，可以去查看osd [34,23,1]的磁盤，查看對應節點上的dmesg日志。
dimes -T |grep -I err
案例2: osd掛了
當osd短暫掛掉的時候，因為集群內還存在着兩個副本，是可以正常寫入的，但是 osd.34 內的數據並沒有得到更新，過了一會osd.34上線了，這個時候osd.34的數據是陳舊的，就通過其他的OSD 向 osd.34 進行數據的恢復，使其數據為最新的，而這個恢復的過程中，PG的狀態會從inconsistent ->recover -> clean,最終恢復正常。 這是集群故障自愈一種場景。