ceph rgw故障处理

前言

这里想总结下，平时遇到的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了。