3. 常見 PG 故障處理
3.1 PG 無法達到 CLEAN 狀態(tài)
創(chuàng)建一個新集群后镶骗，PG 的狀態(tài)一直處于 active ， active + remapped 或 active + degraded 狀態(tài)巩那， 而無法達到 active + clean 狀態(tài) ，那很可能是你的配置有問題此蜈。
你可能需要檢查下集群中有關(guān) Pool 、 PG 和 CRUSH 的配置項裆赵，做以適當?shù)恼{(diào)整战授。
一般來說，你的集群中需要多于 1 個 OSD份帐，并且存儲池的 size 要大于 1 副本废境。
單節(jié)點集群
有時候筒繁，我們需要搭建一個單節(jié)點的 Ceph 實驗環(huán)境毡咏。此時，在開始創(chuàng)建 monitor 和 OSD 之前堵泽，你需要把 Ceph 配置文件中的 osd crush chooseleaf type 選項從默認值 1 （表示 host 或 node）修改為 0 （表示 osd）。這樣做是告訴 Ceph 允許把數(shù)據(jù)的不同副本分布到同一 host 的 OSDs 上箩退。
OSD 個數(shù)小于副本數(shù)
如果你已經(jīng)啟動了 2 個 OSD戴涝，它們都處于 up 和 in 的狀態(tài)钻蔑，但 PG 仍未達到 active + clean 狀態(tài)咪笑，那可能是給 osd pool default size 設置了一個大于 2 的值。
如果你想要在 active + degraded 狀態(tài)（ 2 副本）操作你的集群映跟，可以設置 osd pool default min size 為 2 努隙，這樣你就可以對處于 active + degraded 的對象寫入數(shù)據(jù)辜昵。然后你還可以把 osd pool default size 的值改為 2 堪置，這樣集群就可以達到 active + clean 狀態(tài)了。
另外岭洲，修改參數(shù) osd pool default size/min_size后盾剩，只會對后面新建的 pool 起作用碑诉。如果想修改已存在的 pool 的 size/min_size 进栽，可用下面的命令：
ceph osd pool set <poolname> size|min_size <val>
注意： 你可以在運行時修改參數(shù)值恭垦。如果是在 Ceph 配置文件中進行的修改，你可能需要重啟集群唠帝。
POOL SIZE = 1
如果你設置了 osd pool default size 的值為 1 ，那你就僅有對象的單份拷貝贴铜。OSD 依賴于其他 OSD 告訴自己應該保存哪些對象绍坝。如果第一個 OSD 持有對象的拷貝苔悦，并且沒有第二份拷貝玖详，那么也就沒有第二個 OSD 去告訴第一個 OSD 它應該保管那份拷貝。對于每一個映射到第一個 OSD 上的 PG （參考 ceph pg dump 的輸出）拗踢，你可以強制第一個 OSD 關(guān)注它應該保存的 PGs ：
ceph pg force_create_pg <pgid>
CRUSH MAP 錯誤
PG 達不到 clean 狀態(tài)的另一個可能的原因就是集群的 CRUSH Map 有錯誤向臀，導致 PG 不能映射到正確的地方。
3.2 卡住的 PGs
有失敗發(fā)生后砂缩，PG 會進入“degraded”（降級）或“peering”（連接建立中）狀態(tài)庵芭，這種情況時有發(fā)生雀监。通常這些狀態(tài)意味著正常的失敗恢復正在進行。然而好乐，如果一個 PG 長時間處于這些狀態(tài)中的某個蔚万，就意味著有更大的問題临庇。因此 monitor 在 PG 卡 （ stuck ） 在非最優(yōu)狀態(tài)時會告警昵慌。我們具體檢查：
-
inactive（不活躍）—— PG 長時間不是active（即它不能提供讀寫服務了）斋攀； -
unclean（不干凈）—— PG 長時間不是clean（例如它未能從前面的失敗完全恢復）淳蔼； -
stale（不新鮮）—— PG 狀態(tài)沒有被ceph-osd更新裁眯，表明存儲這個 PG 的所有節(jié)點可能都down了俯画。
你可以用下列命令顯式地列出卡住的 PGs：
ceph pg dump_stuck stale
ceph pg dump_stuck inactive
ceph pg dump_stuck unclean
卡在 stale 狀態(tài)的 PG 通過重啟 ceph-osd 進程通臣璐梗可以修復猜憎；卡在 inactive 狀態(tài)的 PG 通常是互聯(lián)問題（參見 PG 掛了 —— 互聯(lián)失敗 ）胰柑；卡在 unclean 狀態(tài)的 PG 通常是由于某些原因阻止了恢復的完成柬讨，像未找到的對象（參見 未找到的對象 ）袍啡。
3.3 PG 掛了 —— 互聯(lián)失敗
在某些情況下境输， ceph-osd 互聯(lián)進程會遇到問題嗅剖，阻值 PG 達到活躍信粮、可用的狀態(tài)。例如莲绰， ceph health 也許顯示：
ceph health detail
HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down
...
pg 0.5 is down+peering
pg 1.4 is down+peering
...
osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
可以查詢到 PG 為何被標記為 down ：
ceph pg 0.5 query
{ "state": "down+peering",
...
"recovery_state": [
{ "name": "Started\/Primary\/Peering\/GetInfo",
"enter_time": "2012-03-06 14:40:16.169679",
"requested_info_from": []},
{ "name": "Started\/Primary\/Peering",
"enter_time": "2012-03-06 14:40:16.169659",
"probing_osds": [
0,
1],
"blocked": "peering is blocked due to down osds",
"down_osds_we_would_probe": [
1],
"peering_blocked_by": [
{ "osd": 1,
"current_lost_at": 0,
"comment": "starting or marking this osd lost may let us proceed"}]},
{ "name": "Started",
"enter_time": "2012-03-06 14:40:16.169513"}
]
}
recovery_state 段告訴我們互聯(lián)過程因 ceph-osd 進程掛了而被阻塞，本例是 osd.1 掛了辞友，啟動這個進程應該就可以恢復称龙。
或者，如果 osd.1 發(fā)生了災難性的失敵杖帷（如硬盤損壞）咳蔚，我們可以告訴集群它丟失（ lost ）了搔驼，讓集群盡力完成副本拷貝。
重要： 集群不能保證其它數(shù)據(jù)副本是一致且最新的糯耍，就會很危險温技！
讓 Ceph 無論如何都繼續(xù)：
ceph osd lost 1
恢復將繼續(xù)進行扭粱。
3.4 未找到的對象
某幾種失敗相組合焊刹，可能導致 Ceph 抱怨有找不到（ unfound ）的對象：
ceph health detail
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
pg 2.4 is active+degraded, 78 unfound
這意味著存儲集群知道一些對象（或者存在對象的較新副本）存在虐块，卻沒有找到它們的副本。下例展示了這種情況是如何發(fā)生的霜旧，一個 PG 的數(shù)據(jù)存儲在 ceph-osd 1 和 2 上：
- 1 掛了
- 2 獨自處理一些寫動作
- 1 起來了
- 1 和 2 重新互聯(lián)挂据， 1 上面丟失的對象加入隊列準備恢復
- 新對象還未拷貝完， 2 掛了
這時掷倔， 1 知道這些對象存在勒葱，但是活著的 ceph-osd 都沒有這些副本凛虽。這種情況下凯旋，讀寫這些對象的 IO 就會被阻塞钉迷，集群只能指望 down 掉的節(jié)點盡早恢復篷牌。這樣處理是假設比直接給用戶返回一個 IO 錯誤要好一些枷颊。
首先，你應該確認哪些對象找不到了：
ceph pg 2.4 list_missing [starting offset, in json]
{ "offset": { "oid": "",
"key": "",
"snapid": 0,
"hash": 0,
"max": 0},
"num_missing": 0,
"num_unfound": 0,
"objects": [
{ "oid": "object 1",
"key": "",
"hash": 0,
"max": 0 },
...
],
"more": 0}
如果在一次查詢里列出的對象太多信卡， more 這個字段將為 true 傍菇，你就可以查詢更多丢习。
其次淮悼，你可以找出哪些 OSD 上探測到、或可能包含數(shù)據(jù)：
ceph pg 2.4 query
"recovery_state": [
{ "name": "Started\/Primary\/Active",
"enter_time": "2012-03-06 15:15:46.713212",
"might_have_unfound": [
{ "osd": 1,
"status": "osd is down"}]},
本例中见擦，集群知道 osd.1 可能有數(shù)據(jù)鲤屡，但它掛了（ down ）。所有可能的狀態(tài)有：
- 已經(jīng)探測到了
- 在查詢
- OSD 掛了
- 尚未查詢
有時候集群要花一些時間來查詢可能的位置卢未。
還有一種可能性尝丐，對象存在于其它位置卻未被列出衡奥。例如矮固，集群里的一個 ceph-osd 停止且被剔出集群档址，然后集群完全恢復了守伸；后來一系列的失敗導致了未找到的對象尼摹，它也不會覺得早已死亡的 ceph-osd 上仍可能包含這些對象蠢涝。（這種情況幾乎不太可能發(fā)生）和二。
如果所有可能的位置都查詢過了但仍有對象丟失耳胎，那就得放棄丟失的對象了惯吕。這仍可能是罕見的失敗組合導致的，集群在寫操作恢復后怕午，未能得知寫入是否已執(zhí)行废登。以下命令把未找到的（ unfound ）對象標記為丟失（ lost ）。
ceph pg 2.5 mark_unfound_lost revert|delete
上述最后一個參數(shù)告訴集群應如何處理丟失的對象诗轻。
-
delete選項將導致完全刪除它們钳宪。 -
revert選項（糾刪碼存儲池不可用）會回滾到前一個版本或者（如果它是新對象的話）刪除它。要慎用，它可能迷惑那些期望對象存在的應用程序吏颖。
3.5 無家可歸的 PG
擁有 PG 拷貝的 OSD 可能會全部失敗搔体，這種情況下半醉，那一部分的對象存儲不可用呆奕， monitor 也就不會收到那些 PG 的狀態(tài)更新了。為檢測這種情況姆泻，monitor 會把任何主 OSD 失敗的 PG 標記為 stale （不新鮮），例如：
ceph health
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
可以找出哪些 PG 是 stale 狀態(tài)，和存儲這些歸置組的最新 OSD 瓣赂，命令如下：
ceph health detail
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
...
pg 2.5 is stuck stale+active+remapped, last acting [2,0]
...
osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080
osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539
osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
如果想使 PG 2.5 重新上線穆碎，例如方面，上面的輸出告訴我們它最后由 osd.0 和 osd.2 管理褂策，重啟這些 ceph-osd 將恢復之（可以假定還有其它的很多 PG 也會進行恢復 ）。
3.6 只有幾個 OSD 接收數(shù)據(jù)
如果你的集群有很多節(jié)點，但只有其中幾個接收數(shù)據(jù)，檢查下存儲池里的 PG 數(shù)量纫塌。因為 PG 是映射到多個 OSD 的，較少的 PG 將不能均衡地分布于整個集群抗悍。試著創(chuàng)建個新存儲池赏壹，設置 PG 數(shù)量是 OSD 數(shù)量的若干倍蝌借。更詳細的信息可以參考 Ceph 官方文檔 —— Placement Groups 凝化。
3.7 不能寫入數(shù)據(jù)
如果你的集群已啟動瞧哟，但一些 OSD 沒起來，導致不能寫入數(shù)據(jù)傍衡，確認下運行的 OSD 數(shù)量滿足 PG 要求的最低 OSD 數(shù)。如果不能滿足， Ceph 就不會允許你寫入數(shù)據(jù)被辑，因為 Ceph 不能保證復制能如愿進行俄删。這個最低 OSD 個數(shù)是由參數(shù) osd pool default min size 限定的。
3.8 PG 不一致
如果收到 active + clean + inconsistent 這樣的狀態(tài)抓艳，很可能是由于在對 PG 做擦洗（ scrubbing ）時發(fā)生了錯誤片任。如果是由于磁盤錯誤導致的不一致，請檢查磁盤棱诱，如果磁盤有損壞，可能需要將這個磁盤對應的 OSD 踢出集群靡菇，然后進行更換。生產(chǎn)環(huán)境中遇到過不一致的問題，就是由于磁盤壞道導致的。
當集群中出現(xiàn) PG 不一致的問題時畜伐，執(zhí)行 ceph -s 命令會出現(xiàn)下面的信息：
root@mon:~# ceph -s
cluster 614e77b4-c997-490a-a3f9-e89aa0274da3
health HEALTH_ERR
1 pgs inconsistent
1 scrub errors
monmap e5: 1 mons at {osd1=10.95.2.43:6789/0}
election epoch 796, quorum 0 osd1
osdmap e1079: 3 osds: 3 up, 3 in
flags sortbitwise
pgmap v312153: 384 pgs, 6 pools, 1148 MB data, 311 objects
3604 MB used, 73154 MB / 76759 MB avail
383 active+clean
1 active+clean+inconsistent
1慎框、查找處于 inconsistent 狀態(tài)的問題 PG ：
root@mon:~# ceph health detail
HEALTH_ERR 1 pgs inconsistent; 1 scrub errors
pg 9.14 is active+clean+inconsistent, acting [1,2,0]
1 scrub errors
這個有問題的 PG 分布在 osd.1 、 osd.2 和 osd.0 上，其中 osd.1 是主 OSD梧税。
2刨秆、去主 OSD（ osd.1 ）的日志中查找不一致的具體對象 。
root@osd0:~# grep -Hn 'ERR' /var/log/ceph/ceph-osd.1.log
/var/log/ceph/ceph-osd.1.log:30:2016-11-10 13:49:07.848804 7f628c5e6700 -1 log_channel(cluster) log [ERR] : 9.14 shard 0: soid 9:29b4ad99:::rbd_data.1349f035c101d9.0000000000000001:head missing attr _
/var/log/ceph/ceph-osd.1.log:31:2016-11-10 13:49:07.849803 7f628c5e6700 -1 log_channel(cluster) log [ERR] : 9.14 scrub 0 missing, 1 inconsistent objects
/var/log/ceph/ceph-osd.1.log:32:2016-11-10 13:49:07.849824 7f628c5e6700 -1 log_channel(cluster) log [ERR] : 9.14 scrub 1 errors
從日志中可以知道褪贵，是 rbd_data.1349f035c101d9.0000000000000001 這個對象的屬性 _ 丟失了冯乘，所以在 scrub 的過程中產(chǎn)生了 error 喷好。
3效览、執(zhí)行 ceph pg repair 命令修復問題 PG 瘦锹。
root@mon:~# ceph pg repair 9.14
instructing pg 9.14 on osd.1 to repair
4听绳、檢查 Ceph 集群是否恢復到 HEALTH_OK 狀態(tài)祝辣。
root@mon:~# ceph -s
cluster 614e77b4-c997-490a-a3f9-e89aa0274da3
health HEALTH_OK
monmap e5: 1 mons at {osd1=10.95.2.43:6789/0}
election epoch 796, quorum 0 osd1
osdmap e1079: 3 osds: 3 up, 3 in
flags sortbitwise
pgmap v312171: 384 pgs, 6 pools, 1148 MB data, 311 objects
3604 MB used, 73154 MB / 76759 MB avail
384 active+clean
osd.1 的日志里也提示修復成功：
2016-11-10 14:04:31.732640 7f628c5e6700 0 log_channel(cluster) log [INF] : 9.14 repair starts
2016-11-10 14:04:31.827951 7f628edeb700 -1 log_channel(cluster) log [ERR] : 9.14 shard 0: soid 9:29b4ad99:::rbd_data.1349f035c101d9.0000000000000001:head missing attr _
2016-11-10 14:04:31.828117 7f628edeb700 -1 log_channel(cluster) log [ERR] : 9.14 repair 0 missing, 1 inconsistent objects
2016-11-10 14:04:31.828273 7f628edeb700 -1 log_channel(cluster) log [ERR] : 9.14 repair 1 errors, 1 fixed
如果經(jīng)過前面的步驟攻谁，Ceph 仍沒有達到 HEALTH_OK 狀態(tài)垦搬，可以嘗試用下面這種方式進行修復米绕。
1非驮、停掉不一致的 object 所屬的 osd 雏赦。
stop ceph-osd id=xxx
2、刷新該 osd 的日志芙扎。
ceph-osd -i xx --flush-journal
3圈浇、將不一致的 object 移除剖踊。
mv /var/lib/ceph/osd/ceph-{osd-id}/current/{pg.id}_head/ rbd\\udata.xxx /home
4、重新啟動該 osd 供常。
start ceph-osd id=xx
5、重新執(zhí)行修復命令图张。
ceph pg repair {pg_id}
6柄错、檢查 Ceph 集群是否恢復到 HEALTH_OK 狀態(tài)。
3.9 Too Many/Few PGs per OSD
有時候，我們在 ceph -s 的輸出中可以看到如下的告警信息：
root@node241:~# ceph -s
cluster 3b37db44-f401-4409-b3bb-75585d21adfe
health HEALTH_WARN
too many PGs per OSD (652 > max 300)
monmap e1: 1 mons at {node241=192.168.2.41:6789/0}
election epoch 1, quorum 0 node241
osdmap e408: 5 osds: 5 up, 5 in
pgmap v23049: 1088 pgs, 16 pools, 256 MB data, 2889 objects
6100 MB used, 473 GB / 479 GB avail
1088 active+clean
這是因為集群 OSD 數(shù)量較少蔓同，測試過程中建立了多個存儲池则北，每個存儲池都要建立一些 PGs 尚揣。而目前 Ceph 配置的默認值是每 OSD 上最多有 300 個 PGs 方篮。在測試環(huán)境中巾表，為了快速解決這個問題姜凄，可以調(diào)大集群的關(guān)于此選項的告警閥值。方法如下：
在 monitor 節(jié)點的 ceph.conf 配置文件中添加:
[global]
.......
mon_pg_warn_max_per_osd = 1000
然后重啟 monitor 進程溃槐。
或者直接用 tell 命令在運行時更改參數(shù)的值而不用重啟服務：
ceph tell mon.* injectargs '--mon_pg_warn_max_per_osd 1000'
而另一種情況匣砖， too few PGs per OSD （16 < min 20） 這樣的告警信息則往往出現(xiàn)在集群剛剛建立起來，除了默認的 rbd 存儲池昏滴，還沒建立自己的存儲池猴鲫，再加上 OSD 個數(shù)較多，就會出現(xiàn)這個提示信息谣殊。這通常不是什么問題拂共，也無需修改配置項，在建立了自己的存儲池后姻几，這個告警信息就會消失宜狐。
