ceph recovery 진행시 특정 osd weight down

Every 2.0s: ceph -s Wed May 11 10:24:17 2016

cluster 9d3a1d48-ae9e-40b6-8986-424536ae5149
health HEALTH_ok
..
..
..
(이하 생략)

Every 2.0s: ceph osd tree Wed May 11 10:23:49 2016

ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 108.21393 root default
-2 32.73798 host cloudv-osd-D
6 16.36899 osd.6 up 1.00000 1.00000
5 16.36899 osd.5 up 1.00000 1.00000
-3 26.36899 host cloudv-osd-C
3 16.36899 osd.3 down 0 1.00000
4 16.36899 osd.4 up 1.00000 1.00000
-4 32.73798 host cloudv-osd-B
2 16.36899 osd.2 up 1.00000 1.00000
1 16.36899 osd.1 up 1.00000 1.00000
-5 16.36899 host cloudv-osd-A
0 16.36899 osd.0 up 1.00000 1.00000
7 0 osd.7 up 1.00000 1.00000

위 출력값중 확인할 사항 osd.7 의 weight 값이 ‘0’

osd7은 다른 osd와 마찬가지로 초기 구성 이후 추가된 osd 이다. ( osd.3 4 5 6 모두 동일 방법으로 추가됨.)

[mon log]
2016-05-11 10:32:00.717514 7f05171d4700 0 mon.mon-2@2(peon) e2 handle_command mon_command({“prefix”: “osd crush reweight”, “name”: “osd.7”, “weight”: 13.5} v 0) v1
2016-05-11 10:32:00.717621 7f05171d4700 0 log_channel(audit) log [INF] : from=’client.? 115.68.200.218:0/2803634566′ entity=’client.admin’ cmd=[{“prefix”: “osd crush reweight”, “name”: “osd.7”, “weight”: 13.5}]: dispatch

osd.3의 미확인 down으로 제거하지는 않고 ( osd.3제거시 osd.4도 autodown되기 때문 ) reweight 시킴.

3 16.36899 osd.3 down 0 1.00000
->
3 10.5 osd.3 down 0 1.00000

Every 2.0s: ceph -s Wed May 11 10:27:47 2016

cluster 9d3a1d48-ae9e-40b6-8986-424536ae5149
health HEALTH_WARN

[recovery] 진행.

같은 방법으로 osd.7 reweight
# ceph osd crush reweight osd.7 13.5
Error ENOENT: device ‘osd.7’ does not appear in the crush map

해당 내용은 특정 osd의 문제로 인해 같은 호스트내에 있는 다른 osd.id도 다운시킨 상황이다.
이것은 오류가 아닌 ceph운영중 하나로 같은 호스트내에 서로 다른 osd.id1~2중 일부가 문제라 해도 ceph는 두 osd를 같은 오류로 판단 후 down시킨다.
즉 recovery가 완료되고 문제시된 osd.id를 교체 하면 나머지 osd.id2도 정상으로 돌아온다.
이 부분에 대해 자세히 서술된 문서가 있지 않아 한참 애먹었던 것 같다.
만약 테스트중이라면 생성된 pool을 removet시킨 수 문제시된 osd.id의 문제만 해결해준뒤 다시 osd start해보길 바란다.