问题现象
Monitor维护这Ceph集群的信息,如果Monitor无法正常提供服务,那整个Ceph集群就不可访问。一般来说,在实际运行中,Ceph Monitor的个数是 2n + 1 ( n >= 0 )个,在线上至少3个,只要正常的节点数 >= n+1,Ceph的Paxos算法就能保证系统的正常运行。通常情况下两个以上Monitor节>点同时出现异常的几率是非常低的。所以,当Monitor节点出现异常时,不要惊慌,静下心来,一步步的进行处理。
排查思路
1、Mon进程是否在运行
首先需要确保的是Mon进程是正常运行的,如果进程都没有运行,肯定是会影响集群状况的。如果此时ceph -s
可以正常输出信息,可以通过此命令快速获取到集群的状态信息,命令如下:
$ ceph -s
cluster 9a0ef35c-691a-4c3c-b242-c5a57e43e08a
health HEALTH_WARN
1 mons down, quorum 0,2 node1,node3
monmap e3: 3 mons at {node1=192.168.1.10:6789/0,node2=192.168.1.11:6789/0,node3=192.168.1.12:6789/0}
election epoch 24, quorum 0,2 node1,node3
osdmap e123: 12 osds: 12 up, 12 in
flags sortbitwise,require_jewel_osds
pgmap v1079: 288 pgs, 9 pools, 1832 MB data, 1 objects
19095 MB used, 221 GB / 239 GB avail
288 active+clean
通过命令的执行结果可以看到,目前是有一个Mon宕掉,正常的mon是node1、node3,所以目前是node2节点上的Mon出现了异常。通常情况下 ceph -s
命令可以正常执行时,可以通过 ceph health detail
获取到更加详细的异常输出。命令输入信息如下:
$ ceph health detail
HEALTH_WARN 1 mons down, quorum 0,2 node1,node3
mon.node2 (rank 1) addr 192.168.1.11:6789/0 is down (out of quorum)
2、异常的Mon节点是否可以正常连接
通常情况下在做连接测试时,建议先核实一下防火墙的状态,确保防火墙没有对通信进行限制。这里提到的连接主要牵涉到两个方面,首先可以尝试通过ssh进行一下连接,确保Mon节点能够正常远程到。如果能够正常进行ssh,那么接下来可以使用 telnet
、 nc
等命令进行一下测试异常Mon节点的端口(如果有修改端口,以实际端口进行测试),比如现在要测试宕掉的node2节点的Mon端口,那>么可以执行以下命令
telnet node2 6789
3、ceph -s是否可以正常获取到集群信息
在第一项中提到使用 ceph -s
查看集群信息,以便了解具体是哪台主机出现异常。而实际操作过程中,ceph -s
命令阻塞,无法正常收到集群回复的情况。此时有可能是Monitor全部宕掉了,或者正常运行的Monitor数量并不足以形成quorum。这种情况下你就需要登录到集群中使用Monitor的管理套接字来进行查询了。
通过管理套接字,你可以使用Unix套接字文件直接与指定的守护进程交互。这个文件通常位于Monitor节点的run目录下,默认的配置路径是 /var/run/ceph/ceph-mon.ID.asok
,如果有对这个配置位置进行过手动更改,可以看一下ceph.conf文件中的配置路径,或者使用以下命令进行一下查询:
$ ceph-conf -name mon.node2 --show-config-value admin_socket
/var/run/ceph/ceph-client.admin.asok
这里有一点需要注意一下,只有在Mon节点运行时管理套接字才可以使用。如果Mon节点是正常关闭的,那么管理套接字文件也会被删除。如果Mon节点没有运行,但是管理套接字文件还是存在的,就说明Mon不是正常关闭的。总之,Mon没有运行的情况下,是无法使用管理套接字的。
要访问管理套接字,命令格式为:
ceph daemon mon.<id> <command>
例如:
ceph daemon mon.node1 mon_status
可以通过执行help命令来显示管理套接字支持的其他命令,如:ceph daemon mon.node1 help
,建议了解一下 config show
、 mon_status
、 quorum_status
命令,在排查Mon故障时非常有用。
mon_status 的输出结果如下:
{
"name": "node1",
"rank": 0,
"state": "leader",
"election_epoch": 28,
"quorum": [
0,
2
],
"outside_quorum": [],
"extra_probe_peers": [],
"sync_provider": [],
"monmap": {
"quorum": [
0,
2
],
"outside_quorum": [],
"extra_probe_peers": [],
"sync_provider": [],
"monmap": {
"epoch": 3,
"fsid": "9a0ef35c-691a-4c3c-b242-c5a57e43e08a",
"modified": "2018-07-20 12:01:29.580779",
"created": "2018-07-20 11:57:44.542507",
"mons": [
{
"rank": 0,
"name": "node1",
"addr": "192.168.1.10:6789\/0"
},
{
"rank": 1,
"name": "node2",
"addr": "192.168.1.11:6789\/0"
},
{
"rank": 2,
"name": "node3",
"addr": "192.168.1.12:6789\/0"
}
]
}
}
从上面的信息中可以看到,当前quorum之中主机为0和2,节点1并不在quorum内。从monmap信息可以查看到节点1对应的主机是node2,所以当前出现异常的Mon是node2。
4、查看异常节点的日志记录,根据日志信息进一步进行判断故障状况
通常情况下ceph的日志存放在 /var/log/ceph/
目录下,如果集群部署时有进行更改,要根据实际的存放路径进行查询。
结果验证
找到故障原因进行修复后,可以通过ceph -s
或 ceph health detail
确认集群状态为HEALTH_OK进行验证是否完成了修复。