ceph pg 常見狀態

2021-08-18 14:49:45 字數 4669 閱讀 6306

參考:

ceph - pg 常見狀態 說明

pg ( placement group ) 是資料儲存的重要單位 

在使用 ceph 的時候, pg 會經常發生狀態的變化, 參考下面例子

1. 當建立池的時候, 將會建立相應的 pg, 那麼可以看到 pg creating 狀態

2. 當部分 pg 建立成功後, 將會發現 pg 會進入 peering 狀態

3. 當所有 pg peering 完成後,  將可見到狀態變成 active+clean

常見的 pg 狀態

creating (建立中)

pg 正在被建立, 通常當儲存池正在卑建立或增加乙個儲存池的 pg 數量時, pg 會呈現這個狀態

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 (乾淨)

1 當 pg 顯示 clean 狀態, 主 osd 與副本 osd 成功同步並且沒有非同步複製, ceph 在 pg 中所有物件具有正確的副本數量

2 pg 中的所有物件都已經卑複製了規定的副本數量. 

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 都必須執行恢復

ceph 提供一定數量的設定在新服務請求與恢復 pg 中資料物件時的資源平衡,  

osd recovery delay start 設定允許 osd 重啟, re-peer 並在啟動 恢復之前處理一些回應請求,  

osd recovery threads 設定了恢復過程中線程限制 (預設 1 ) 

osd recovery thread timeout 設定執行緒超時, 因為可能出現多個 osd 故障, 重啟後在 re-peer 過程中可能出現汙染

osd recovery max active 設定限制對乙個 osd 從故障後, 恢復請求併發數量

osd recovery max chunk 限制恢復時的資料 chunk 大小, 預防網路堵塞

pg 正在遷移或者同步物件及其副本, 乙個 osd 停止服務(down), 其內容將會落後與 pg 內的其他副本, 這時 pg 將會進入 recoverying 狀態, 該 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 準備好了就可以對外提供服務

當 pg 改變, 資料從舊的 osd 遷移到新的 osd, 新的主 osd 應該請求將會花費一段時間, 在這段時間內, 將會繼續向舊主 osd 請求服務, 直到

當 pg 的 action set 變化後, 資料將會從舊 acting set 遷移到新 action set, 新主 osd 需要過一段時間後才能提供服務, 因此它會讓老的主 osd 繼續提供服務, 知道 pg 遷移完成, 資料遷移完成後, pg map 將會使用新 acting set 中的主 osd 

參考例子

[root@hh-yun-ceph-cinder015-128055 ~]# 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 常見狀態

pg placement group 是資料儲存的重要單位 在使用 ceph 的時候,pg 會經常發生狀態的變化,參考下面例子 當建立池的時候,將會建立相應的 pg,那麼可以看到 pg creating 狀態 當部分 pg 建立成功後,將會發現 pg 會進入 peering 狀態 當所有 pg pe...

常見狀態碼

一些常見的狀態碼為 200 伺服器成功返回網頁 404 請求的網頁不存在 503 伺服器超時 1xx 臨時響應 表示臨時響應並需要請求者繼續執行操作的狀態碼。100 繼續 請求者應當繼續提出請求。伺服器返回此 表示已收到請求的第一部分,正在等待其餘部分。101 切換協議 請求者已要求伺服器切換協議,...

常見狀態碼

http狀態碼 status 伺服器返回的http請求響應狀態。常見狀態碼 200 表示請求成功 看不到,控制台才會看見 202 請求被接受但處理未完成 302 重定向,後台可以看到 304 看不到,控制台才會看見 不是錯誤,就是當前訪問的是以前的資訊,沒跟新。直接清除瀏覽器快取 就ok了 例如 f...