使用命令檢查ceph集群的監控狀態,得到
[root@node1 ~]# ceph -s
cluster c4898b1c-7ac1-406d-bb5d-d3c7980de438 health HEALTH_ERR 4 pgs inconsistent; 8 scrub errors; mds cluster is degraded; mds alpha is laggy monmap e5: 1 mons at {node1=172.17.44.22:6789/0}, election epoch 1, quorum 0 node1 osdmap e172: 3 osds: 2 up, 2 in pgmap v32874: 192 pgs: 188 active+clean, 4 active+clean+inconsistent; 216 MB data, 2517 MB used, 780 GB / 782 GB avail mdsmap e587: 1/1/1 up {0=alpha=up:replay(laggy or crashed)}
可以看到，ceph的監控狀態是錯誤的，所以當前ceph集群是不用用的。也主要是是pg沖突。我們運行命令來看是那些pg沖突。
[root@node1 ~]# ceph pg dump | grep inconsistent
dumped all in format plain
1.2d 2 0 0 0 4194350 680 680 active+clean+inconsistent 2014-09-16 17:22:26.262442 77'680 172:1149 [0,1] [0,1] 77'680 2014-09-16 15:34:54.801604 77'680 2014-09-15 15:34:51.375100
1.27 2 0 0 0 4194338 654 654 active+clean+inconsistent 2014-09-16 17:22:39.042809 77'654 172:1052 [0,1] [0,1] 77'654 2014-09-16 15:34:33.812579 77'654 2014-09-15 15:34:25.371366
1.13 1 0 0 0 66 118 118 active+clean+inconsistent 2014-09-16 17:22:33.648556 77'118 172:313 [1,0] [1,0] 77'118 2014-09-16 15:34:06.806975 77'118 2014-09-15 15:34:04.363863
1.b 2 0 0 0 4194766 797 797 active+clean+inconsistent 2014-09-16 17:22:37.363771 77'797 172:1255 [0,1] [0,1] 77'797 2014-09-16 15:33:52.856734 77'797 2014-09-15 15:33:42.365185
可以得到這幾個沖突的pg組,第一行是他的ID 根據官方提供的辦法,http://docs.ceph.com/docs/master/rados/troubleshooting/troubleshooting-pg/
ceph pg repair {placement-group-ID}
[root@node1 ~]# ceph pg repair 1.2d instructing pg 1.2d on osd.0 to repair [root@node1 ~]# ceph pg repair 1.27 instructing pg 1.27 on osd.0 to repair [root@node1 ~]# ceph pg repair 1.13 instructing pg 1.13 on osd.1 to repair [root@node1 ~]# ceph pg repair 1.b instructing pg 1.b on osd.0 to repair
然后檢查狀態:
[root@node1 ~]# ceph -s
cluster c4898b1c-7ac1-406d-bb5d-d3c7980de438 health HEALTH_ERR 1 pgs inconsistent; 2 scrub errors; mds cluster is degraded; mds alpha is laggy monmap e5: 1 mons at {node1=172.17.44.22:6789/0}, election epoch 1, quorum 0 node1 osdmap e172: 3 osds: 2 up, 2 in pgmap v32877: 192 pgs: 191 active+clean, 1 active+clean+inconsistent; 216 MB data, 2517 MB used, 780 GB / 782 GB avail mdsmap e595: 1/1/1 up {0=alpha=up:replay(laggy or crashed)}
可以看到現在還是錯誤，但是只有一個inconsistent了，實際上是因為網絡需要時間同步我們的數據。在次執行
[root@node1 ~]# ceph -s cluster c4898b1c-7ac1-406d-bb5d-d3c7980de438
health HEALTH_WARN mds cluster is degraded; mds alpha is laggy monmap e5: 1 mons at {node1=172.17.44.22:6789/0}, election epoch 1, quorum 0 node1 osdmap e172: 3 osds: 2 up, 2 in pgmap v32878: 192 pgs: 192 active+clean; 216 MB data, 2517 MB used, 780 GB / 782 GB avail mdsmap e596: 1/1/1 up {0=alpha=up:replay(laggy or crashed)}
可以看到現在的監控狀況也僅僅是一個warning了，而不是錯誤。
但是，我們看到3個osds中卻只有2個up(運行中),2個in(在集群中).osd是我們存儲pg的底層，而pg是對象集合，對象是文件小各個小部分集合，所以如果osd錯誤，則可以 肯定這個狀態更不正確。由於現在我們的環境是測試環境，我們可以使用將錯誤的osd存儲幾點先直接移除出當前集群環境，然后再加入。這中間會將錯誤的那個osd的數據移到正確的保留osd里對比，取舍，然后我們將這個錯誤的osd數據刪除，在添加進來。
1. 刪除osd
ceph osd out 2
我們是里的配置文件是:
[osd.2] host = node3 [osd.1] host = node2 [osd.0] host = node1
錯誤的是node3節點，所以參數out 后是2
ceph osd crush remove osd.2
ceph osd rm 6
到這一步運行會提示該節點上的osd正在運行。停止之。到對應節點刪除數據。
- rm -fr /data/osd.2/*
到這一步我們在看ceph的健康狀況:
cluster c4898b1c-7ac1-406d-bb5d-d3c7980de438
health HEALTH_OK
monmap e5: 1 mons at {node1=172.17.44.22:6789/0}, election epoch 1, quorum 0 node1
osdmap e217: 2 osds: 2 up, 2 in
pgmap v33222: 192 pgs: 192 active+clean; 216 MB data, 2519 MB used, 780 GB / 782 GB avail; 1769B/s wr, 0op/s
mdsmap e5954: 1/1/1 up {0=a=up:active}
可以看到只有2個osd節點了，而一般生產環境是需要3個的。我們將剛才移除的osd節點在添加進來。
2. 添加osd節點。
ceph osd create
返回一個數字2 獨立磁盤的掛在等工作我們這里就省去了，df -h也能看到該數據。
ceph-osd -i 2 --mkfs
在填加節點上執行
/etc/init.d/ceph start osd
在存儲節點上查看狀態
cluster c4898b1c-7ac1-406d-bb5d-d3c7980de438
health HEALTH_WARN 67 pgs peering; 67 pgs stuck inactive; 67 pgs stuck unclean
monmap e5: 1 mons at {node1=172.17.44.22:6789/0}, election epoch 1, quorum 0 node1
osdmap e225: 3 osds: 3 up, 3 in
pgmap v33340: 192 pgs: 125 active+clean, 67 peering; 125 MB data, 3552 MB used, 1170 GB / 1173 GB avail
mdsmap e5954: 1/1/1 up {0=a=up:active}
還是不正確？！別急，我們知道ceph是網絡傳輸分布式文件系統，而我們這個集群前面為了存儲存儲能力，有過1個多G的數據，等幾秒就能看到我們最終想看到的狀態:
[root@node1 ceph]# ceph -w
cluster c4898b1c-7ac1-406d-bb5d-d3c7980de438
health HEALTH_OK
monmap e5: 1 mons at {node1=172.17.44.22:6789/0}, election epoch 1, quorum 0 node1
osdmap e235: 3 osds: 3 up, 3 in
pgmap v33364: 192 pgs: 192 active+clean; 217 MB data, 3605 MB used, 1170 GB / 1173 GB avail; 1023B/s wr, 0op/s
mdsmap e5954: 1/1/1 up {0=a=up:active}