優化:
PG Number
PG和PGP數量一定要根據OSD的數量進行調整，計算公式如下，但是最后算出的結果一定要接近或者等於一個2的指數。調整PGP不會引起PG內的對象的分裂，但是會引起PG的分布的變動三、總結PG是指定存儲池存儲對象的目錄有多少個，PGP是存儲池PG的OSD分布組合個數PG的增加會引起PG內的數據進行分裂，分裂到相同的OSD上新生成的PG當中PGP的增加會引起部分PG的分布進行變化，但是不會引起PG內對象的變動
Total PGs = (Total_number_of_OSD * 100) / max_replication_count
結算的結果往上取靠近2的N次方的值。比如總共OSD數量是160，復制份數3，pool數量也是3，那么按上述公式計算出的結果是1777.7。取跟它接近的2的N次方是2048，那么每個pool分配的PG數量就是2048。
在更改pool的PG數量時，需同時更改PGP的數量。PGP是為了管理placement而存在的專門的PG，它和PG的數量應該保持一致。如果你增加pool的pg_num，就需要同時增加pgp_num，保持它們大小一致，這樣集群才能正常rebalancing。下面介紹如何修改pg_num和pgp_num。
（1）檢查rbd這個pool里已存在的PG和PGP數量：
$ ceph osd pool get rbd pg_num
pg_num: 128 $ ceph osd pool get rbd pgp_num pgp_num: 128
（2）檢查pool的復制size，執行如下命令：
$ ceph osd dump |grep size|grep rbd pool 2 'rbd' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 128 pgp_num 128 last_change 45 flags hashpspool stripe_width 0
（3）使用上述公式，根據OSD數量、復制size、pool的數量，計算出新的PG數量，假設是256.
（4）變更rbd的pg_num和pgp_num為256：
$ ceph osd pool set rbd pg_num 256 $ ceph osd pool set rbd pgp_num 256
（5）如果有其他pool，同步調整它們的pg_num和pgp_num，以使負載更加均衡。
ceph - pg 常見狀態
pg ( placement group ) 是數據存儲的重要單位
在使用 ceph 的時候, pg 會經常發生狀態的變化, 參考下面例子
當創建池的時候, 將會創建相應的 pg, 那么可以看到 pg creating 狀態當部分 pg 創建成功后, 將會發現 pg 會進入 peering 狀態當所有 pg peering 完成后, 將可見到狀態變成 active+clean
常見的 pg 狀態
creating (創建中)
PG 正在被創建, 通常當存儲池正在卑創建或增加一個存儲池的 PG 數量時, PG 會呈現這個狀態Down (失效)
PG 處於失效狀態, PG 應該處於離線狀態repair(修復)
PG 正在被檢查, 被發現的任何不一致都將盡可能被修復.peering (等待互聯)
當 ceph peering pg, ceph 將會把 pg 副本協定導入 osd, 當 ceph 完成 peering, 意味着 osd 同意當前 PG 狀態, 並允許寫入PG 處於 peering 過程中, peering 由主 osd 發起的使存放 PG 副本的所有 OSD 就 PG 的所有對象和元素數據的狀態達成一致的過程, peering 過程完成后, 主 OSD 就可以接受客戶端寫請求.Active (活動)
當 ceph 完成 peering 過程, pg 將會變成 active, active 狀態意味着 pg 中的數據變得可用, 主 pg 將可執行讀寫操作PG 是活動的, 意味着 PG 中的數據可以被讀寫, 對該 PG 的操作請求都講會被處理. Clean (干凈)
當 pg 顯示 clean 狀態, 主 osd 與副本 osd 成功同步並且沒有異步復制, ceph 在 pg 中所有對象具有正確的副本數量
PG 中的所有對象都已經卑復制了規定的副本數量. Replay (重做)
某 OSD 崩潰后, PG 正在等待客戶端重新發起操作Degraded (降級)
當客戶端寫對象到主 osd, 主 OSD 會把數據寫復制到對應復制 OSD, 在主 OSD 把對象寫入存儲后, PG 會顯示為 degraded 狀態, 直到主 osd 從復制 OSD 中接收到創建副本對象完成信息PG 處於 active+degraded 原因是因為 OSD 是處於活躍, 但並沒有完成所有的對象副本寫入, 假如 OSD DOWN, CEPH 標記每個 PG 分配到這個相關 OSD 的
狀態為 degraded, 當 OSD 重新上線, OSD 將會重新恢復,
假如 OSD DOWN 並且 degraded 狀態持續, CEPH 會標記 DOWN OSD, 並會對集群遷移相關 OSD 的數據, 對應時間由 mon osd down out interval 參數決定
PG 可以被北極為 degraded, 因為 ceph 在對應 PG 中無法找到一個或者多個相關的對象, 你不可以讀寫 unfound 對象, 你仍然可以訪問標記為 degraded PG 的其他數據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 准備好了就可以對外提供服務REMAPPED (重映射)
當 pg 改變, 數據從舊的 osd 遷移到新的 osd, 新的主 osd 應該請求將會花費一段時間, 在這段時間內, 將會繼續向舊主 osd 請求服務, 直到
PG 遷移完成, 當數據遷移完成, mapping 將會使用新的 OSD 響應主 OSD 服務
當 PG 的 action set 變化后, 數據將會從舊 acting set 遷移到新 action set, 新主 OSD 需要過一段時間后才能提供服務, 因此它會讓老的主 OSD 繼續提供服務, 知道 PG 遷移完成, 數據遷移完成后, PG map 將會使用新 acting set 中的主 OSDSTALE (舊)
當 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 定義超時時間