前言
这里想总结下，平时遇到的ceph rgw相关的故障和对应的处理方法。方便下次遇到类似问题之后，能快速有效的找到解决方案。这里故障案例的来源我是会从各种渠道去收集的，比如：自身环境、官网、群友在群里反馈等等地方。
有时间会持续更新。
1、radosgw请求被卡住
现象
有时候radosgw的客户端（比如s3cmd），在和radosgw交互过程中出现卡顿，radosgw响应请求非常慢等状况。
分析
首先我们先检查下客户端和集群的网络有没有问题，如果没有问题。我们可以通过radosgw的守护进程的管理套接字来获取radosgw的内部相关信息。到radosgw实例所在节点上执行如下命令：
$ ceph daemon client.rgw.ceph03 objecter_requests
{ "ops": [
{ "tid": 1858,
"pg": "2.d2041a48",
"osd": 1,
"last_sent": "2012-03-08 14:56:37.949872",
"attempts": 1,
"object_id": "fatty_25647_object1857",
"object_locator": "@2",
"snapid": "head",
"snap_context": "0=[]",
"mtime": "2012-03-08 14:56:37.949813",
"osd_ops": [
"write 0~4096"]},
{ "tid": 1873,
"pg": "2.695e9f8e",
"osd": 1,
"last_sent": "2012-03-08 14:56:37.970615",
"attempts": 1,
"object_id": "fatty_25647_object1872",
"object_locator": "@2",
"snapid": "head",
"snap_context": "0=[]",
"mtime": "2012-03-08 14:56:37.970555",
"osd_ops": [
"write 0~4096"]}],
"linger_ops": [],
"pool_ops": [],
"pool_stat_ops": [],
"statfs_ops": []
}
上面命令输出里面的ops字段里面可以看到有两个请求，tid为1858和tid为1873的请求。我们拿tid为1858的请求举例说明，这个请求信息为
{ "tid": 1858,
"pg": "2.d2041a48",
"osd": 1,
"last_sent": "2012-03-08 14:56:37.949872",
"attempts": 1,
"object_id": "fatty_25647_object1857",
"object_locator": "@2",
"snapid": "head",
"snap_context": "0=[]",
"mtime": "2012-03-08 14:56:37.949813",
"osd_ops": [
"write 0~4096"]}
其中last_sent字段表示发送给rados请求的时间，如果这个时间和当前时间相差间隔比较大，说明这个发送给rados的请求，rados一直没有回应，导致radosgw无法回复客户端（s3cmd）请求，所以客户端s3cmd就会出现卡顿的情况。
好了，我们知道了原因，然后在继续看osd这个字段，它表示radosgw将这个请求发给了哪个osd，上面可以看到是发给了osd.1这个osd，pg是2.d2041a48，然后我们执行
$ ceph pg map 2.d2041a48
osdmap e9 pg 2.d2041a48 (2.0) -> up [1,0] acting [1,0]
可以看到，这个pg的主本是osd.1，副本是osd.0，然后我们到osd.1所在的节点，执行命令
$ ceph deamon osd.1 ops
{ "num_ops": 651,
"ops": [
{ "description": "osd_op(client.4124.0:1858 fatty_25647_object1857 [write 0~4096] 2.d2041a48)",
"received_at": "1331247573.344650",
"age": "25.606449",
"flag_point": "waiting for sub ops",
"client_info": { "client": "client.4124",
"tid": 1858}},
...
上面信息中找到tid为1858这个请求的相关信息，然后看到flag_point这个字段，waiting for sub ops表示在等待其他副本osd.0的回复。
现在我们知道了是因为osd.0没有回复消息给主本osd.1，从而导致整个io被卡住，因为osd.0没有回复消息的可能性非常多，所以就要根据实际的情况去排查osd.0为啥没有回复消息给主本osd.1了。