本系列文章會深刻研究 Ceph 以及 Ceph 和 OpenStack 的集成：html
（1）安裝和部署linux
（2）Ceph RBD 接口和工具git
（3）Ceph 物理和邏輯結構github
（4）Ceph 的基礎數據結構算法
（6）QEMU-KVM 和 Ceph RBD 的 緩存機制總結安全
（7）Ceph 的基本操做和常見故障排除方法服務器
（8）關於Ceph PGs網絡
學以至用，本文將介紹 Ceph 集羣的一些基本操做和常見的故障排除方法。數據結構
0. 測試環境
將由 Virtulbox 管理的兩個虛機，分別是 ceph1 和 ceph2，做爲 OSD 服務器，其中，ceph1 同時做爲 MON 服務器。兩個節點上分別有兩個虛擬磁盤做爲 OSD 存儲磁盤，每一個大小爲 5G；還有一個虛擬磁盤做爲 Journal 磁盤，1G，分爲兩個區，作爲數據盤的日誌分區。從 ceph1 上使用 ceph-deploy 工具部署。pool 的 size 設置爲 2，min_size 也設置爲 2.
每一個機器配置兩個網卡，eth0 是 NAT 模式，使用 DHCP 方式獲取IP，用於虛機訪問外網；eth1 是 host-only 模式，配置靜態IP，用於主機訪問虛機，以及虛機之間的互訪。對Ceph 來講，eth0 用於安裝程序，eth1 用於 public 和 cluster network。
注意在宿主機上要設置防火牆容許 Virtualbox 訪問外網。我機器上安裝了 Symentac Endpoint Protection，不當心 block 了它的互聯網訪問，而後虛機也就沒法鏈接外網了，我在這裏花了很多時間折騰：
1. 修改 OSD CRUSH weight
1.1 問題描述
部署完成後，集羣處於 PG Degraded 狀態，經查 ceph health detail，發現 PG 的 acting OSD 只有 [0]，而不是兩個。查 osd tree，osd 日誌等，看不出明顯問題。
1.2 緣由分析
從文章 http://serverfault.com/questions/680492/after-initial-deployment-ceph-cluster-stays-in-activedegraded-state 受到啓發，個人 Ceph 集羣的 OSD 的 weight 都是 0！！
root@ceph1:/etc/ceph# ceph osd tree # id weight type name up/down reweight -1 0 root default -2 0 host ceph1 0 0 osd.0 up 1 2 0 osd.2 up 1 -3 0 host ceph2 1 0 osd.1 up 1 3 0 osd.3 up 1
咱們從上面 ceph osd tree 的結果裏面能夠看到這裏有兩個weight：weight 和 reweight。這篇文章 有詳細的分析。簡單來講：
- weight：即 osd crush weight，表示設備(device) 容量的相對值，好比若是1TB對應1.00，那麼 500MB 對應 0.50。bucket weight 是全部 item weight 之和，item weight 的變化會影響 bucket weight 的變化，也就是 osd.X 會影響host。 對於 straw bucket，若是 item weight 爲0，則 item straw 也爲0，當CRUSH 算法在 bucket 選擇 item 時，也就不太可能選中該 item。
- reweight：取值爲0~1。osd reweight 並不會影響 host。當 osd 被踢出集羣（out）時，osd weight 被設置0，加入集羣時，設置爲1。它會參與 CRUSH 建立 PG 的過程。CRUSH在選擇 OSD 時，若是發現 weight 爲0，就跳過該 OSD。
所以，問題的癥結就在於 osd crush weight 爲0。至於爲何會這樣，以及該值對 PG 分配的影響，有待進一步查明。
1.3 解決辦法：修改 osd crush weight
ceph osd crush reweight osd.0 1 ceph osd crush reweight osd.1 1 ceph osd crush reweight osd.2 1 ceph osd crush reweight osd.3 1
修改後，集羣就回到了 HEALTH_OK 狀態。
注意：修改 OSD 的 crush weight 會帶來部分 PG 之間的數據移動，這可能會影響集羣的性能，所以在生產環境中使用要當心。你能夠參考 這篇文章 來看數據移動的狀況。
2. 修改 CRUSH tunables（可調參數）
2.1 問題描述
將 osd.1 設置爲 out 後，集羣並無開始作 recovery，部分 PG 保持在 remapped 狀態：
root@ceph1:~# ceph -s cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71 health HEALTH_WARN 88 pgs stuck unclean monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1 osdmap e71: 4 osds: 4 up, 3 in pgmap v442: 256 pgs, 4 pools, 285 MB data, 8 objects 690 MB used, 14636 MB / 15326 MB avail 88 active+remapped 168 active+clean
2.2 緣由分析
（1）. 查看 ceph health detail
root@ceph1:~# ceph health detail HEALTH_WARN 88 pgs stuck unclean pg 1.23 is stuck unclean for 337.342290, current state active+remapped, last acting [0,1] pg 0.1f is stuck unclean for 336.838743, current state active+remapped, last acting [0,1] pg 1.1f is stuck unclean for 337.355851, current state active+remapped, last acting [0,1]
Remapped（重映射）：當 PG 的 acting set 變化後，數據將會從舊 acting set 遷移到新 action set。新主 OSD 須要過一段時間後才能提供服務。所以，它會讓老的主 OSD 繼續提供服務，直到 PG 遷移完成。數據遷移完成後，PG map 將使用新 acting set 中的主OSD。
以 PG 爲例，比較在 osd.1 out 先後的 PG map：
state state_stamp v reported up up_primary acting acting_primary active+clean 2016-06-03 00:31:44.220896 0'0 57:74 [0,1] 0 [0,1] 0 #osd.1 out 以前 active+remapped 2016-06-03 00:47:12.703537 0'0 71:109 [0] 0 [0,1] 0 #osd.1 out 以後
2.3 解決辦法
2.3.1 之一：將 crush tunables 設置爲 optimal
（2）從這篇文章中得到線索，這可能和 crush tunables 有關係。它的默認值應該是 legacy，運行下面的命令將其修改成 optimal 後，集羣狀態回到正常。
ceph osd crush tunables optimal
（3）繼續找緣由，Red Hat 這篇文章 給出了一些線索。
在新版本的Ceph 集羣中使用 legacy 值可能會有一些問題，包括：
- 當葉子bucket（每每是 host）所擁有的設備數目很小時，一些 PG 被映射到的 OSD 數目少於存儲池的size。這在 host 節點的 OSD 數目爲 1-3 時較爲常見。
- 大型集羣中，小部分的 PG 被映射到的 OSD 數目小於規定的數目。這在 CRUSH 層級結構中好幾層（好比 row，rack，host，osd 等）時比較常見。
- 當一些 OSD 被標記爲 out 時，從新分佈的數據會更多地在附近的 OSD 上而不是整個層級結構中。
而第一種狀況正是個人測試集羣所遇到的狀況，每一個 host 擁有的 OSD 數目在3個之內，而後部分 PG 所在的 OSD 數目較 replica 少一些。
關於 CRUSH tunables 的詳細信息，請閱讀有關文檔。請注意在生產環境操做時有必定的風險。
2.3.2 之二：將 OSD 的 reweight 修改成 0 而不是使用 out 命令
Ceph 官方的這篇文章 給出了另外一個思路。它認爲在主機數目很小的集羣中，當一個 OSD 被 out 後，部分 PG 限於 active+remapped 狀態是常常出現的。解決辦法是先運行 ceph osd in {osd-num} 將集羣狀態恢復到初始狀態，而後運行 ceph osd crush reweight osd.{osd-num} 0 來將這個 osd 的 crush weight 修改成 0，而後集羣會開始數據遷移。對小集羣來講，reweight 命令甚至更好些。
當集羣中 PG 限於 active + remapped 狀態時，能夠經過 reweight 命令來使得集羣恢復正常。當往集羣中新加入 OSD 時，爲了減小數據移動對集羣性能的影響，Ceph 官方建議逐漸地增長 OSD 的 crush weight，好比起始值爲0，先設置爲 0.2，等數據遷移結束，再設置爲 0.4，依此類推，逐漸增長爲 0.6,0.8 和 1 甚至更高。在要停用一個 OSD 時，建議採用相反操做，逐漸減小 OSD 的 crush weight 直至 0.
3. 修改 CRUSH ruleset
3.1 問題描述
繼續將跟 osd.1 在贊成個host 上的 osd.3 out，看看 Ceph 集羣能不能繼續恢復。Ceph 集羣中部分 PG 再次進入 remapped 狀態：
root@ceph1:~# ceph -s cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71 health HEALTH_WARN 256 pgs stuck unclean monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1 osdmap e77: 4 osds: 4 up, 2 in pgmap v480: 256 pgs, 4 pools, 285 MB data, 8 objects 625 MB used, 9592 MB / 10217 MB avail 256 active+remapped
運行 ceph pg 1.0 query 查看 PG 1.0 的狀態：
"recovery_state": [ { "name": "Started\/Primary\/Active", "enter_time": "2016-06-03 01:31:22.045434", "might_have_unfound": [], "recovery_progress": { "backfill_targets": [], "waiting_on_backfill": [], "last_backfill_started": "0\/\/0\/\/-1", "backfill_info": { "begin": "0\/\/0\/\/-1", "end": "0\/\/0\/\/-1", "objects": []}, "peer_backfill_info": [], "backfills_in_flight": [], "recovering": [], "pg_backend": { "pull_from_peer": [], "pushing": []}}, "scrub": { "scrubber.epoch_start": "0", "scrubber.active": 0, "scrubber.block_writes": 0, "scrubber.finalizing": 0, "scrubber.waiting_on": 0, "scrubber.waiting_on_whom": []}}, { "name": "Started", "enter_time": "2016-06-03 01:31:20.976290"}],
可見它已經開始 recovery 了，可是沒完成。
3.2 緣由分析
PG 的分佈和 CRUSH ruleset 有關。個人集羣當前只有一個默認的 ruleset：
root@ceph1:~# ceph osd crush rule dump [ { "rule_id": 0, "rule_name": "replicated_ruleset", "ruleset": 0, "type": 1, "min_size": 1, "max_size": 10, "steps": [ { "op": "take", "item": -1, "item_name": "default"}, { "op": "chooseleaf_firstn", "num": 0, "type": "host"}, { "op": "emit"}]}]
注意其 type 爲 「host」，也就是說 CRUSH 不會爲一個 PG 選擇在同一個 host 上的兩個 OSD。而個人環境中，目前只有 ceph1 上的兩個 OSD 是in 的，所以，CRUSH 沒法爲全部的 PG 從新選擇一個新的 OSD 來替代 osd.3.
3.3 解決辦法
按照如下步驟，將 CRUSH ruleset 的 type 由 「host」 修改成 「osd」，使得 CRUSH 爲 PG 選擇 OSD 時再也不侷限於不一樣的 host。
root@ceph1:~# ceph osd getcrushmap -o crushmap_compiled_file got crush map from osdmap epoch 77 root@ceph1:~# crushtool -d crushmap_compiled_file -o crushmap_decompiled_file root@ceph1:~# vi crushmap_decompiled_file
rule replicated_ruleset { ruleset 0 type replicated min_size 1 max_size 10 step take default step chooseleaf firstn 0 type osd #將 type 由 「host」 修改成 「osd」 step emit }
root@ceph1:~# crushtool -c crushmap_decompiled_file -o newcrushmap root@ceph1:~# ceph osd setcrushmap -i newcrushmap set crush map
以上命令執行完畢後，能夠看到 recovery 過程繼續進行，一段時間後，集羣恢復 OK 狀態。
root@ceph1:~# ceph -s cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71 health HEALTH_WARN 256 pgs stuck unclean monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1 osdmap e80: 4 osds: 4 up, 2 in pgmap v493: 256 pgs, 4 pools, 285 MB data, 8 objects 552 MB used, 9665 MB / 10217 MB avail 256 active+remapped root@ceph1:~# ceph -s cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71 health HEALTH_WARN 137 pgs stuck unclean monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1 osdmap e80: 4 osds: 4 up, 2 in pgmap v494: 256 pgs, 4 pools, 285 MB data, 8 objects 677 MB used, 9540 MB / 10217 MB avail 137 active+remapped 119 active+clean recovery io 34977 B/s, 0 objects/s root@ceph1:~# ceph -s cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71 health HEALTH_OK monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1 osdmap e80: 4 osds: 4 up, 2 in pgmap v495: 256 pgs, 4 pools, 285 MB data, 8 objects 679 MB used, 9538 MB / 10217 MB avail 256 active+clean recovery io 18499 kB/s, 0 objects/s
4. 將一個 OSD 移出集羣
（1）將該 osd 設置爲 out
root@ceph1:/home/s1# ceph osd out osd.1 marked out osd.1.
（2）集羣作 recovery
2016-06-03 01:54:21.596632 mon.0 [INF] osdmap e90: 4 osds: 4 up, 3 in 2016-06-03 01:54:21.608675 mon.0 [INF] pgmap v565: 256 pgs: 256 active+clean; 1422 MB data, 2833 MB used, 12493 MB / 15326 MB avail 2016-06-03 01:54:26.352909 mon.0 [INF] pgmap v566: 256 pgs: 1 active, 255 active+clean; 1422 MB data, 2979 MB used, 12347 MB / 15326 MB avail; 2/40 objects degraded (5.000%); 51033 B/s, 0 objects/s recovering 2016-06-03 01:54:28.624334 mon.0 [INF] pgmap v567: 256 pgs: 4 active, 252 active+clean; 1422 MB data, 3427 MB used, 11899 MB / 15326 MB avail; 8/40 objects degraded (20.000%); 51053 B/s, 0 objects/s recovering 2016-06-03 01:54:31.320973 mon.0 [INF] pgmap v568: 256 pgs: 3 active, 253 active+clean; 1422 MB data, 3539 MB used, 11787 MB / 15326 MB avail; 6/40 objects degraded (15.000%); 19414 kB/s, 0 objects/s recovering 2016-06-03 01:54:32.323443 mon.0 [INF] pgmap v569: 256 pgs: 256 active+clean; 1422 MB data, 3730 MB used, 11595 MB / 15326 MB avail; 77801 kB/s, 0 objects/s recovering ^[[A2016-06-03 01:56:10.949077 mon.0 [INF] pgmap v570: 256 pgs: 256 active+clean; 1422 MB data, 3730 MB used, 11595 MB / 15326 MB avail
（3）完成後，該 osd 的狀態仍是 up，表示它的服務還在運行。如今將其服務停掉。
root@ceph1:/home/s1# ssh ceph2 service ceph stop osd.1 /etc/init.d/ceph: osd.1 not found (/etc/ceph/ceph.conf defines , /var/lib/ceph defines )
該命令出錯，須要將 osd.1 加入 ceph.conf 中。在 ceph1 上的 ceph.conf 中添加：
[osd]
[osd.1]
host = ceph2
[osd.2]
host = ceph1
[osd.3]
host = ceph2
[osd.0]
host = ceph1
而後運行 ceph-deploy --overwrite-conf config push ceph2 將它拷貝到 ceph2 上。重啓全部的 osd 服務。詭異的事情出現了：
root@ceph1:/etc/ceph# ceph osd tree # id weight type name up/down reweight -1 4 root default -2 4 host ceph1 0 1 osd.0 up 1 2 1 osd.2 up 1 1 1 osd.1 up 0 3 1 osd.3 up 1 -3 0 host ceph2
osd.1 和 osd.3 跑到了 ceph1 節點上！查看 start 命令，它將 curshmap 中的 osd.1 的 host 修改成了 ceph2：
root@ceph1:/etc/ceph# /etc/init.d/ceph -a start osd === osd.1 === df: ‘/var/lib/ceph/osd/ceph-1/.’: No such file or directory create-or-move updating item name 'osd.1' weight 1 at location {host=ceph1,root=default} to crush map Starting Ceph osd.1 on ceph2... starting osd.1 at :/0 osd_data /var/lib/ceph/osd/ceph-1 /var/lib/ceph/osd/ceph-1/journal
從 這篇文章 能夠看出，這實際上是Ceph的一個 bug：make osd crush placement on startup handle multiple trees (e.g., ssd + sas)。該bug 在 OSD location reset after restart 中也有討論。目前 Ceph 沒有機制能夠確保 CRUSH map 結構不變，最簡單的辦法是在 ceph.conf 中 [OSD] 部分設置 osd crush update on start = false。
嘗試手工挪動 osd.1 和 osd.3：
root@ceph1:/etc/ceph# ceph osd crush remove osd.1 removed item id 1 name 'osd.1' from crush map root@ceph1:/etc/ceph# ceph osd crush remove osd.3 removed item id 3 name 'osd.3' from crush map
root@ceph1:/etc/ceph# ceph osd tree # id weight type name up/down reweight -1 2 root default -2 2 host ceph1 0 1 osd.0 up 1 2 1 osd.2 up 1 -3 0 host ceph2 1 0 osd.1 up 0 3 0 osd.3 up 1
root@ceph1:/etc/ceph# ceph osd crush set 1 1 root=default host=ceph2 Error ENOENT: unable to set item id 1 name 'osd.1' weight 1 at location {host=ceph2,root=default}: does not exist
該錯誤的緣由待查。索性直接修改 crush map，而後正確的結果就回來了：
root@ceph1:/etc/ceph# ceph osd tree # id weight type name up/down reweight -1 2 root default -2 2 host ceph1 0 1 osd.0 up 1 2 1 osd.2 up 1 -3 0 host ceph2 1 1 osd.1 up 0 3 1 osd.3 up 1
繼續運行命令 ssh ceph2 /etc/init.d/ceph stop osd.1 去中止 osd.1 的服務，可是沒法中止。聽說是由於用 ceph-deploy 部署的 OSD 的服務都無法中止。只能想辦法把進程殺掉了。
而後繼續執行：
root@ceph1:/etc/ceph# ceph osd crush remove osd.1 removed item id 1 name 'osd.1' from crush map root@ceph1:/etc/ceph# ceph auth del osd.1 updated
root@ceph1:/etc/init# ceph osd rm osd.1
removed osd.1
此時，osd tree 中再也沒有 osd.1 了：
root@ceph1:/etc/ceph# ceph osd tree # id weight type name up/down reweight -1 3 root default -2 2 host ceph1 0 1 osd.0 up 1 2 1 osd.2 up 1 -3 1 host ceph2 3 1 osd.3 up 1
5. 將一個 OSD 加入集羣
（1）將 /dev/sdb1 分區刪除
（2）清理磁盤：ceph-deploy disk zap ceph2:/dev/sdb
（3）建立 OSD：ceph-deploy osd create ceph2:sdb:/dev/sdd1
結果OSD就回來了：
root@ceph1:~# ceph-deploy osd create ceph2:sdb:/dev/sdd1c^C root@ceph1:~# ceph osd tree # id weight type name up/down reweight -1 2 root default -2 2 host ceph1 0 1 osd.0 up 1 2 1 osd.2 up 1 -3 0 host ceph2 4 0 osd.4 up 1 1 0 osd.1 up 1
其實將上面第四步和第五步合併在一塊兒，就是替換一個故障磁盤的過程。
6. 在特定 OSD 上建立存儲池
咱們假設 osd.0 和 osd.2 的磁盤是 SSD 磁盤，osd.1 和 osd.4 的磁盤是 SATA 磁盤。咱們將建立兩個pool：pool-ssd 和 pool-sata，並確保 pool-ssd 中的對象都保存在 osd.0 和 osd.2 上，pool-sata 中的對象都保存在 osd.1 和 osd.4 上。
（1）修改 CRUSH map
root@ceph1:~# ceph osd getcrushmap -o crushmapdump got crush map from osdmap epoch 124 root@ceph1:~# crushtool -d crushmapdump -o crushmapdump-decompiled root@ceph1:~# vi crushmapdump-decompiled
root@ceph1:~# crushtool -c crushmapdump-decompiled -o crushmapdump-compiled
root@ceph1:~# ceph osd setcrushmap -i crushmapdump-compiled
在 crushmapdump-decompiled 文件中添加以下內容：
root ssd { id -5 alg straw hash 0 item osd.0 weight 1 item osd.2 weight 1 }root sata {
id -6
alg straw
hash 0
item osd.1 weight 1
item osd.4 weight 1
}rules
...
rule ssd-pool {
ruleset 1
type replicated
min_size 1
max_size 10
step take ssd
step chooseleaf firstn 0 type osd
step emit
}rule sata-pool {
ruleset 2
type replicated
min_size 1
max_size 10
step take sata
step chooseleaf firstn 0 type osd
step emit
}
（2） ceph osd tree 以下：
root@ceph1:~# ceph osd tree # id weight type name up/down reweight -6 2 root sata 1 1 osd.1 up 1 4 1 osd.4 up 1 -5 2 root ssd 0 1 osd.0 up 1 2 1 osd.2 up 1 -1 2 root default -2 2 host ceph1 0 1 osd.0 up 1 2 1 osd.2 up 1 -3 0 host ceph2 4 0 osd.4 up 1 1 0 osd.1 up 1
（3）建立 ssd-pool，其默認的 ruleset 爲 0：
root@ceph1:~# ceph osd pool create ssd-pool 8 8 pool 'ssd-pool' created root@ceph1:~# ceph osd dump | grep -i ssd pool 4 'ssd-pool' replicated size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 8 pgp_num 8 last_change 126 flags hashpspool stripe_width 0
（4）修改 ssd-pool 的 ruleset 爲 ssd-pool 其id 爲 1：
root@ceph1:~# ceph osd pool set ssd-pool crush_ruleset 1 set pool 4 crush_ruleset to 1 root@ceph1:~# ceph osd dump | grep -i ssd pool 4 'ssd-pool' replicated size 2 min_size 1 crush_ruleset 1 object_hash rjenkins pg_num 8 pgp_num 8 last_change 128 flags hashpspool stripe_width 0
（5）相似地建立 sata-pool 並設置其 cursh ruleset 爲 sata-pool 其id 爲 2：
root@ceph1:~# ceph osd pool create sata-pool 8 8 pool 'sata-pool' created root@ceph1:~# ceph osd pool set sata-pool crush_ruleset 2 set pool 5 crush_ruleset to 2 root@ceph1:~# ceph osd dump | grep -i sata pool 5 'sata-pool' replicated size 2 min_size 1 crush_ruleset 2 object_hash rjenkins pg_num 8 pgp_num 8 last_change 131 flags hashpspool stripe_width 0
（6）分別放一個文件進這兩個pool：
root@ceph1:/home/s1# rados -p ssd-pool put root-id_rsa root-id_rsa root@ceph1:/home/s1# rados -p sata-pool put root-id_rsa root-id_rsa root@ceph1:/home/s1# rados -p ssd-pool ls root-id_rsa root@ceph1:/home/s1# rados -p sata-pool ls root-id_rsa
（7）查看對象所在的 OSD
root@ceph1:/home/s1# ceph osd map ssd-pool root-id_rsa osdmap e132 pool 'ssd-pool' (4) object 'root-id_rsa' -> pg 4.38e001ef (4.7) -> up ([2,0], p2) acting ([2,0], p2) root@ceph1:/home/s1# ceph osd map sata-pool root-id_rsa osdmap e132 pool 'sata-pool' (5) object 'root-id_rsa' -> pg 5.38e001ef (5.7) -> up ([4,1], p4) acting ([4,1], p4)
可見，兩個pool各自在ssd 和 sata 磁盤上。
7. rbd map 失敗：Input/output error
7.1 問題描述
先準備好機器，而後在Ceph集羣管理節點上運行 ceph-deploy install client 和 ceph-deploy admin client 來安裝和配置該節點。詳細過程能夠參考 Oracle 這篇文章。 注意第二個命令須要在 /etc/ceph 目錄下執行，不然，拷貝到 client 節點上的 ceph.conf 會不正確，運行 ceph -s 也會碰到錯誤 0 librados: client.admin authentication error (1) Operation not permitted。
而後執行下面的命令來建立一個卷並mount給該客戶端：
root@client:~# rbd create -p pool1 bd1 --size 100 root@client:~# rbd info --image bd1 -p pool1 rbd image 'bd1': size 102400 kB in 25 objects order 22 (4096 kB objects) block_name_prefix: rb.0.383a.2ae8944a format: 1 root@client:~# rbd map -p pool1 bd1rbd: add failed: (5) Input/output error
7.2 問題解決和緣由分析
從 這篇文章 中得到線索，須要修改 crushmap 中的
root@client:/home/s1# ceph osd getcrushmap -o crush got crush map from osdmap epoch 138 root@client:/home/s1# crushtool -i crush --set-chooseleaf_vary_r 0 -o crush.newroot@client:/home/s1# ceph osd setcrushmap -i crush.new set crush map root@client:/home/s1# rbd map -p pool1 bd1
初步看起來，這個問題和 linux 內核版本（個人內核版本是 1.13）以及 crush tunables 有關。在 3.15 以前的版本中，chooseleaf_vary_r 的值必須爲0。根本緣由須要進一步研究。
8. 修復 stale 狀態 PG
8.1 問題描述
root@client:/home/s1# ceph -s cluster 5ccdcb2d-961d-4dcb-a9ed-e8034c56cf71 health HEALTH_WARN 8 pgs stale; 8 pgs stuck stale monmap e2: 1 mons at {ceph1=192.168.56.102:6789/0}, election epoch 1, quorum 0 ceph1 osdmap e182: 4 osds: 4 up, 4 in pgmap v2569: 336 pgs, 8 pools, 5763 MB data, 1171 objects 13763 MB used, 6672 MB / 20435 MB avail 8 stale+active+clean 328 active+clean
學習一下 stale 狀態的概念：PG 的狀態沒有被 ceph-osd 上報給 MON，這意味着存放該 PG 的全部 OSD 都是down 的。MON 將主 OSD down 掉了的 PG 的狀態狀態設置爲 stale。
8.2 問題定位
（1）.找出哪些 PG 處於 stale 狀態
root@ceph1:~# ceph pg dump | grep stale dumped all in format plain 5.2 0 0 0 0 0 0 0 stale+active+clean 2016-06-03 03:50:07.049571 0'0 132:6 [4,1] 4 [4,1] 4 0'0 2016-06-03 03:49:50.301465 0'0 2016-06-03 03:49:50.301465 5.3 0 0 0 0 0 0 0 stale+active+clean 2016-06-03 03:50:07.034290 0'0 132:6 [4,1] 4 [4,1] 4 0'0 2016-06-03 03:49:50.302140 0'0 2016-06-03 03:49:50.302140
可是如今 OSD Tree 中再也不有 osd.1 和 osd.4，由於這兩個 OSD 的盤以前丟了！後來重作成了 osd.3 和 osd.5。這和上面的 stale 狀態的概念吻合。重作的時候 OSD磁盤的分區被刪除過，不知道數據是否還在。看來，丟失數據也是很容易的事情啊。看來，下次看到某個 OSD down 掉了時，首先應該作的是要將它從新 up 起來。
（2）修復不行
root@ceph1:~# ceph pg repair 5.2 Error EAGAIN: pg 5.2 primary osd.4 not up
（3）只能刪除它所屬於的 pool 了。注意 PG ID 的前半部分是 pool id，後半部分纔是 PG 本身的 id。
root@ceph1:~# ceph osd pool delete sata-pool sata-pool --yes-i-really-really-mean-it pool 'sata-pool' removed
其實這麼作也不對，由於一個 pool 有多個 PG，其中只有部分是 stale 狀態，所以在刪除以前要看清楚。這一步驟要十分當心！
（4）ceph -s 恢復正常。
9. 分離 public network 和 cluster network
9.1 分離的好處
（1）提升性能：消除副本建立、數據恢復和再平衡對 public network 的壓力；加強 OSD 心跳網絡的可靠性。
（2）安全性：使用一個完全與外網分離的內部網絡做爲 cluster network，能夠防止好比 DDOS 這樣的網絡攻擊。
更多信息，請參閱 NETWORK CONFIGURATION REFERENCE。
9.2 分離的方法
（1）配置網絡
給每一個 OSD 節點增長一塊網卡，它的鏈接方式爲 「內部網絡」；在虛機內配置靜態IP地址，網段爲 192.168.1.100/24 （其實用不了這麼大的網段）.
（2）在 ceph1 上修改 ceph.conf 文件
[global] ...public network = 192.168.56.100/24
cluster network = 192.168.1.100/24[mon]
[mon.ceph1] # MON 守護進程只在public network 內
host = ceph1
mon addr = 192.168.56.102:6789[osd]
osd journal size = 500
osd crush update on start = false[osd.3] #OSD 守護進程同時在 public 和 cluster network 上
host = ceph2
public addr = 192.168.56.103
cluster addr = 192.168.1.103[osd.0]
host = ceph1
public addr = 192.168.56.102
cluster addr = 192.168.1.102[osd.5]
host = ceph2
public addr = 192.168.56.103
cluster addr = 192.168.1.103[osd.2]
host = ceph1
public addr = 192.168.56.102
cluster addr = 192.168.1.102
（3）將新的 ceph.conf 分發到其它節點上，好比 ceph-deploy --overwrite-conf config push ceph2
（4）重啓全部 OSD 和 MON 守護進程
能夠在 osd 日誌中看到內部網絡IP地址被啓用了。
10. 啓用客戶端 rbd cache
10.1 步驟
編輯在客戶端的 ceph.conf 文件，添加下面的配置項
[client] rbd cache = true rbd cache writethrough until flush = true admin socket = /var/run/ceph/$cluster-$type.$id.$pid.$cctid.asok log file = /var/log/ceph/
啓動使用 librbd 的應用，好比 fio + rbd ioengine，而後從 client admin socket 中確認cache 被啓用了：
root@client:/var/run/ceph# ls ceph-client.admin.23789.140009021853536.asok root@client:/var/run/ceph# ceph --admin-daemon ceph-client.admin.23789.140009021853536.asok config show | grep rbd_cache "rbd_cache": "true", "rbd_cache_writethrough_until_flush": "false", "rbd_cache_size": "33554432", "rbd_cache_max_dirty": "25165824", "rbd_cache_target_dirty": "16777216", "rbd_cache_max_dirty_age": "1", "rbd_cache_max_dirty_object": "0", "rbd_cache_block_writes_upfront": "false",
注意rbd cache 只對 librbd 起做用，對 kernel rbd 不起做用。
[更多內容，未來會繼續添加]