ceph PG故障排除

苏泽湛

　　配置组无法清空
　　有些情况下Ceph的配置组无法清空：
　　1. 只有一个OSD：如果你不是从quick start开始，只有一个OSD的话，你很可能会遇到问题。OSD会向监控上报其他的OSD，当需要拷贝数据的时候也需要和其他的OSD交互.如果你只有一个OSD，第二个OSD就不能检测到它的心跳数据。而且，如果你删除了一个OSD，只剩下一个OSD的时候，你也会遇到问题。第二个和第三个OSD会从另外的OSD那里得到配置组的数据，如果那个OSD缺失，这个过程就无法完成。因此，配置组一直保持在“stale”状态。

　　2. Pool>　　ceph pg force_create_pg
　　3. 3. CRUSH规则：另外一个配置组无法清空的情况是你的CRUSH 映射出现了错误。

　　一般来说，你应该在集群中运行多个OSD，pool>　　配置组不响应
　　在某个步骤执行失败的时候通常配置组会进入"degraged"或者"peering"状态。通常，这些状态表明，程序正在从错误中恢复。但是，当一个配置组一直保持在这种状态，也许预示着一个更大的问题。因此，监控系统会在配置组卡在某个状态的时候发出警告。尤其需要检查这些状态:
　　inactive - 配置组已经长时间处于非激活状态(比如，它一直无法处理读写请求)
　　unclean - 配置组长时间未被清理(比如，它没有完全从上一个错误中恢复)
　　stale - 配置组的状态没有被OSD更新过，意味着所有存储在该配置组的节点都down掉了
　　你可以用下面的方法列出不响应的配置组:
　　ceph pg dump_stuck stale
　　ceph pg dump_stuck inactive
　　ceph pg dump_stuck unclean
　　对于处在stale状态的配置组，通常让对应的OSD运行起来即可。对于处在inactive的配置组，通常是peer问题(参见配置组不可用-Peering Failure)。 对于处在unclena状态的配置组，通常是由于恢复过程被阻止，导致无法完成，比如对象为找到(参见对象缺失问题)
　　配置组不可用 - 同等操作失败
　　在特定情况下，ceph-OSD同等进程会出现问题，导致PG无法激活。比如ceph的检测系统会报告：
　　ceph health detail
　　HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down
　　...
　　pg 0.5 is down+peering
　　pg 1.4 is down+peering
　　...
　　osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
　　我们查询集群以确定PG不可用的准确原因是:
　　ceph pg 0.5 query
　　{ "state": "down+peering",
　　...
　　"recovery_state": [
　　{ "name": "Started\/Primary\/Peering\/GetInfo",
　　"enter_time": "2012-03-06 14:40:16.169679",
　　"requested_info_from": []},
　　{ "name": "Started\/Primary\/Peering",
　　"enter_time": "2012-03-06 14:40:16.169659",
　　"probing_osds": [
　　0,
　　1],
　　"blocked": "peering is blocked due to down osds",
　　"down_osds_we_would_probe": [
　　1],
　　"peering_blocked_by": [
　　{ "osd": 1,
　　"current_lost_at": 0,
　　"comment": "starting or marking this osd lost may let us proceed"}]},
　　{ "name": "Started",
　　"enter_time": "2012-03-06 14:40:16.169513"}
　　]
　　}
　　恢复状态告诉我们peer被阻塞，因为ceph-OSD进程未运行，尤其是OSD.1 。这种情况下，我们可以启动指定的OSD，问题就会得到解决。
　　另外，如果OSD.1出现比较严重的错误(比如磁盘错误)，我们可以通知集群OSD.1缺失，让其尽量从其它地方获取。
　　重要：当集群不能保证数据的其它拷贝持久和最新的，这种方法会带来较大的风险。
　　引导ceph继续运行:
　　ceph osd lost 1
　　会启动恢复。
　　对象缺失
　　当一些错误同时出现时，会出现对象缺失:
　　ceph health detail
　　HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
　　pg 2.4 is active+degraded, 78 unfound
　　这意味着存储集群知道一些对象(或者对象的拷贝)存在，但是没有发现它们的拷贝。下面是当PG的数据在ceph-OSD1和ceph-OSD2时的例子:
　　1. OSD1不可用
　　2. 只有OSD2处理写请求
　　3. OSD1启动
　　4. OSD1和OSD2重新通信，OSD1上缺失的对象进入恢复队列
　　5. 在新对象完成拷贝前，OSD2 down掉
　　现在OSD1知道这些对象存在，但是找不到其拷贝.这种情况下，对那些对象的请求会被阻塞，集群会认为down掉的节点会很快恢复;这时候会返回一个IO错误给用户。
　　首先，你能用下面的方法判断哪些对象找不到:
　　ceph pg 2.4 list_missing [starting offset, in json]
　　{ "offset": { "oid": "",
　　"key": "",
　　"snapid": 0,
　　"hash": 0,
　　"max": 0},
　　"num_missing": 0,
　　"num_unfound": 0,
　　"objects": [
　　{ "oid": "object 1",
　　"key": "",
　　"hash": 0,
　　"max": 0 },
　　...
　　],
　　"more": 0}
　　如果单次查询的列表过长，列表上会出现more，你可以继续查看剩下的列表.(最终命令行工具会隐藏它，但是暂时还未隐藏)
　　第二，你可以确定哪些OSD已经被探测或者包含数据:
　　ceph pg 2.4 query
　　"recovery_state": [
　　{ "name": "Started\/Primary\/Active",
　　"enter_time": "2012-03-06 15:15:46.713212",
　　"might_have_unfound": [
　　{ "osd": 1,
　　"status": "osd is down"}]},
　　在这种情况下，比如，集群知道OSD.1也许有数据，但是OSD.1 down掉了了。所有可能的状态包括:
　　* already probed
　　* querying
　　* osd is down
　　* not queried (yet)
　　有时，集群需要一些时间来查询可能的位置。
　　对象也可能存在未列出的位置上。比如，如果一个ceph-OSDS被停止，而且被移出了集群，集群恢复之后，再次出现错误的时候就会遇到对象找不到的情况，被移出的ceph-OSD未被考虑进来。(这种情况是我们不愿意看到的)
　　如果所有可能的位置都已经被查询，但是对象仍然找不到，你也许不得不放弃那些对象了。这种情况也会报出一些错误，让集群知道已经执行的写操作要在数据恢复之前进行。将"unfound"对象标记为"lost":
　　ceph pg 2.5 mark_unfound_lost revert
　　最后,我们需要明确集群是如何处理丢失的对象的。当前支持的选项是“revert”，将对象恢复到之前的版本或者(当有副本时)忽略它。使用这个功能的时候要小心，因为它也许会让使用它的程序产生错误。
　　配置组无归属
　　即使所有的OSD都有某个配置组的拷贝也可能会失败。如果是这种情况，对象存储的子集不可用，监控系统会收不到那个配置组的状态更新。为了检测到这种情况，监测系统会将主OSD失败的配置组标记为stale。比如:
　　ceph health
　　HEALTH_WARN 24 pgs stale; 3/300 in osds are down
　　你可以用下面的方式找出那些配置组是stale状态和上一次存储它们的是哪些OSD
　　ceph health detail
　　HEALTH_WARN 24 pgs stale; 3/300 in osds are down
　　...
　　pg 2.5 is stuck stale+active+remapped, last acting [2,0]
　　...
　　osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080
　　osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539
　　osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
　　如果我们想让配置组恢复到在线状态，比如，这告诉我们它之前是OSD.0和osd.2管理的。重启ceph-osd进程会让集群恢复这个配置组(其它也一样)
　　OSD接收仅少量的数据
　　如果你的集群有许多节点，只有部分能收到数据，检查你的资源池的配置组数量，因为配置组和OSD有映射关系，一小部分的配置组不会覆盖到你的整个集群。尝试创建一个新的资源池，保证配置组的数量是OSD数量的倍数。参加配置组章节。默认的配置组数量并没有效，你可以修改它。
　　无法写入数据
　　如果你的集群在运行状态中，但是一些OSD down掉了，你无法写入数据，检查一下，确保你的OSD是够用的。如果你OSD数量过少，ceph不会允许你写入数据，因为ceph无法保证能够拷贝你的数据。参见Pool，PG和CRUSH配置中的osd资源值的最小值。
　　pg 不一致问题

　　HEALTH_ERR 1 pgs inconsistent; 1 scrub errors 报不一致问题。先查看不一致pg>　　修复pg : ceph pg repair pgid