配置组无法清空有些情况下Ceph的配置组无法清空：1. 只有一个OSD：如果你不是从quick start开始，只有一个OSD的话，你很可能会遇到问题。OSD会向监控上报其他的OSD，当需要拷贝数据的时候也需要和其他的OSD交互.如果你只有一个OSD，第二个OSD就不能检测到它的心跳数据。而且，如果你删除了一个OSD，只剩下一个OSD的时候，你也会遇到问题。第二个和第三个OSD会从另外的OSD那里得到配置组的数据，如果那个OSD缺失，这个过程就无法完成。因此，配置组一直保持在“stale”状态。2. Pool Size = 1: 如果一个对象只有一个拷贝，其他的OSD无法告知该OSD它拥有哪些配置组。对于每个存在的OSD对应的配置组(参见ceph的pg dump)，你可以强制OSD检查它运行所需要的配置组。ceph pg force_create_pg 3. 3. CRUSH规则：另外一个配置组无法清空的情况是你的CRUSH 映射出现了错误。一般来说，你应该在集群中运行多个OSD，pool size也应该大于1配置组不响应在某个步骤执行失败的时候通常配置组会进入"degraged"或者"peering"状态。通常，这些状态表明，程序正在从错误中恢复。但是，当一个配置组一直保持在这种状态，也许预示着一个更大的问题。因此，监控系统会在配置组卡在某个状态的时候发出警告。尤其需要检查这些状态:    inactive - 配置组已经长时间处于非激活状态(比如，它一直无法处理读写请求)    unclean - 配置组长时间未被清理(比如，它没有完全从上一个错误中恢复)    stale - 配置组的状态没有被OSD更新过，意味着所有存储在该配置组的节点都down掉了你可以用下面的方法列出不响应的配置组:ceph pg dump_stuck staleceph pg dump_stuck inactiveceph pg dump_stuck unclean对于处在stale状态的配置组，通常让对应的OSD运行起来即可。对于处在inactive的配置组，通常是peer问题(参见配置组不可用-Peering Failure)。 对于处在unclena状态的配置组，通常是由于恢复过程被阻止，导致无法完成，比如对象为找到(参见对象缺失问题)配置组不可用 - 同等操作失败在特定情况下，ceph-OSD同等进程会出现问题，导致PG无法激活。比如ceph的检测系统会报告：ceph health detailHEALTH_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+peeringpg 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 detailHEALTH_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 healthHEALTH_WARN 24 pgs stale; 3/300 in osds are down你可以用下面的方式找出那些配置组是stale状态和上一次存储它们的是哪些OSDceph health detailHEALTH_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/11080osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539osd.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 id：  ceph health detail修复pg : ceph pg repair pgid