Ceph问题解决操作和维护记录

1.1首先停止坏的osd和好的osd(因为执行ceph-objectstore-tool时需要停止osd)，然后执行导出和导入。

命令示例:84是好的osd，85是坏的OSD。

ceph-objectstore-tool-op get-OSD map-epoch 145039-data-path/data 1/ceph-OSD/-journal-path/var/log/ceph/ceph-84/journal-type file store-file OSD map 145039

ceph-objectstore-tool-op set-OSD map-epoch 145039-data-path/data 2/ceph-OSD/-journal-path/var/log/ceph/ceph-85/journal-type file store-file OSD map 145039

PS:其中145039是对应的版本号，data-path和journal-path填写各自对应osd的路径。

2.找到正确的纪元版本。

这应该通过报告错误的osd日志来查看。启动时，osd将加载一个正在执行的纪元版本A，缺失的纪元版本在它之前。然后在最近事件的转储中找到已经执行的epoch版本B和ecoch版本C。导入max(B，C)到A之间的所有版本(也可以导入一个版本开始观察，太麻烦)。在我的日志里，A = 145068，B = 145011，C=145012，所以我把145013放到1438。我的日志如下所示。

1，原因:

如果osdmap的两个osd版本相差太大(可能相差50左右)，会导致两个osd通信上报给错误的节点。如果偶尔出现错误节点，问题不大，因为一个osd操作卡住了，然后恢复最新版本的osdmap。如果osd日志一直报，说明osd同步osdmap有问题，会导致osd宕机，心跳超时(有可能)，甚至osd吃掉大量内存，导致服务器挂机。日志如下所示:

2.查看osd的OSD地图版本。

按命令查看:ceph守护进程osd.xx状态？-对应于——xx标记的osd编号

命令结果示例:

{

" cluster _ fsid ":" df 181181-2154-4816-a2b 7-D6 EAE 79980 FB "，

" OSD _ fsid ":" D5 edac 3-CEE 7-45e b-90df-e 381d 8684 DFB "，

“whoami”:15，

“状态”:“活动”，

“最旧_地图”:92570，

"最新_地图":158146，

" num_pgs": 2105

}

其中latest _ map表示osd的最新版本号。

3.检查集群的osdmap版本号。

命令:ceph -s

这里:最新版本号在178170。

4.确定osd版本是否有问题。

每隔一段时间执行几次命令ceph daemon osd.xx status，以检查osd版本号。正确的状态如下:

4.1.查询到的版本号始终与集群版本号一致。

4.2.它小于集群版本号，但它会不断增加，最终会达到集群版本号。

5.osd出现时不更新OSD地图的解决方案。

到目前为止，我还没有找到osd不更新osdmap的根本原因。我用过ceph daemon osd.xx？Dump_blocked_ops检查是否有阻塞的操作，解决阻塞，但是还是不行，即使返回no blocking，还是不更新。更新osd的可能方法:

1，把对应的osd出簇(osd或up)，过一段时间观察版本号(我就是这么回答的)。

2.重启osd

1，问题日志

2.解决方案:

1.检查服务器时间是否一致。

2.检查集群中的密匙环与本地osd中的密匙环是否一致:

使用命令:？

ceph？auth？List从mon获取所有osd密匙环，

cat/var/lib/ceph/osd/ceph-xx/key ring来获取本地OSD的密匙环。

3.删除验证，重新启动所有mon和osd，并修改ceph.conf中的以下参数，如下所示

授权群集必需=无

授权服务要求=无

授权客户端要求=无

1，问题日志

2.解决方法

1，检查服务器时间和服务器网络(我的不是问题)

2.一般心跳超时是由其他问题引起的。这里可以先增加心跳超时(我已经增加了心跳超时，解决其他问题后就没有心跳超时了)修改合作文件ceph.conf的参数

mon _ OSD _ report _ time out = 1800

文件存储操作线程自杀超时= 1800

文件存储操作线程超时= 600

osd_heartbeat_grace = 600

osd _ op _ thread _自杀_超时=1800

osd_op_thread_timeout=36000

这个配置可以先放在【全局】里，等问题解决后再移除，也可以根据实际情况自己调整参数。

1.检查日志以查看osd卡的位置。

日志调整级别:修改配置文件的ceph.conf参数，增加debug_osd=10(15/20)。该值越高，打印的数量越多。如果osd已经启动，并且您想要更改日志级别，您可以使用命令:ceph tell OSD。xx注入args-debug-osd5。

2.根据日志信息解决问题。

我卡在load_pgs上了，因为整个集群状态不对，pg很多，所以加载很慢。这时候就需要考虑服务器压力了，可以一个一个慢慢启动，不要一下子全部启动。

1，问题的原因

不完整状态表示无法选择权威日志或者通过choos_acting选择的动作不足以完成数据恢复(例如对于纠删码，存活副本数小于k)，导致peer无法正常完成。也就是说，pg元数据丢失，pg状态无法恢复。

2.解决问题

1.使用ceph-objectstore-tool工具来标记不完整的pg。

2、操作步骤:

操作前提:设置集群标志:noout nodown noup noin？PS:这里的目的是防止pg的分布发生变化。因为osd打开了，所以我只设置了noout nodown。

第一步:传递命令ceph pg dump _ stuck | grep complete >；Inincomplete.txt从集群中导出所有处于完成状态的pg。

第二步:通过第一步，我知道pg的两个osd在哪里，并阻止这两个osd。

第三步:用命令在两个osd上标记pg，命令如下

ceph-objectstore-tool-data-path/data 4/ceph-OSD/-journal-path/var/log/ceph/ceph-15/journal-type file store-pgid 9 . ea8-op mark-complete

ceph-objectstore-tool-data-path/data 8/ceph-OSD/-journal-path/var/log/ceph/ceph-91/journal-type file store-pgid 9 . ea8-op mark-complete

第四步:启动这两个osd(启动顺序无关)。

第五步:观察集群中是否有不完整的。

第六步:重复第二次及后续操作，直到不完整为止。

3.特殊说明

3.1，标记完成的过程可能会导致降级和错位簇的增加，这是正常的。

3.2.原因:因为我在阅卷的过程中错过了导入导出pg的步骤。我这里没有操作导入导出是因为pg数量有点多，导入导出会让两个osd停太久，我觉得还是让集群自己恢复比较好。

3.3.导入和导出pg命令:

ceph-objectstore-tool-data-path/data 3/ceph-OSD/-journal-path/var/log/ceph/ceph-2/journal-type file store-pgid 4.15 D5-op export-file/data 10/55/pg 4.15 D5

ceph-objectstore-tool-data-path/data 8/ceph-OSD/-journal-path/var/log/ceph/ceph-5/journal-type file store-pgid？4.15d5 - op导入-文件/数据10/55/pg4.15d5

选择一个osd作为主要OSD，另一个作为次要OSD，并将其中一个导入另一个pg。导入和导出时需要停止osd。以上是将4.15d5从osd.2导入OSD.5。

1.如果能重启pg对应的osd就最好了，问题自然就解决了。

2.如果osd对应的数据盘损坏或其他原因无法启动。

步骤1:删除这个osd和命令

ceph osd crush重新称重osd.xx 0

ceph osd out osd.xx

ceph osd碾压移除osd.xx

ceph osd rm osd.xx

ceph auth del osd.xx

？第二步:清理当前osd的硬盘或添加新硬盘。

第三步:用同样的号码启动一个新的osd。

？第四部分:重复上述操作，去掉所有有问题的osd。如果还有down，没关系，等待集群恢复处理(我刚启动了一个新的osd，pg处理了income plete+down。在我标记了Incomplept之后，down就自行消失了)。

1，原因

PG在这种状态下还没有？ceph-osd？更新，表示所有存储这个PG的节点可能是？下来？是的。带有PG副本的OSD可能都会失败。在这种情况下，对象存储的该部分不可用，并且监视器将不会接收到这些pg的状态更新，并且这些pg将被标记为陈旧的。

2.解决办法

第一种:OSD osd down后，可以正常，直接启动即可。

第二种类型:

1.使用命令ceph pg dump |grep stale来查找stale的pg。

2.使用命令ceph pg force _ create _ pg＄pg _ id，pg状态将更改为creating。

3.重新启动集群中的所有osd。

3.特殊说明

？我是第二种情况，然后按照上面的步骤。结果，所有osd启动都卡住了。我猜测可能的原因:当时我的force_create_pg的数量是3000，有点多，所以osd卡了很多，启动时间很长，可能几个小时。所以这个操作要谨慎，建议如下。

1，这个陈腐的pg终于处理完了。

2.不要一次有太多的force_create_pg。osd重启时，一次重启成功后，重启另一次。

这个比较简单，直接执行命令:ceph pg repair $pg_id repair。

说明集群中osd有问题，需要解决osd问题。我只是有三个osd问题。我省略了这三个osd，这两个状态很快就消失了。

1.发现的问题:ceph -s或mon进程死亡并看到日志。

2.原因

产生了大量的epoch，导致mon的store.db的数据迅速膨胀这是我的集群出现问题后才出现的。之前集群正常的时候我没有这种现象。不知道集群正常后会不会恢复正常。

3.解决办法

第一种:压缩数据，使用命令？ceph tell mon . ceph 163 compact？Ceph163是我的mon的名字。

第二种:使用ceph-mon？-我？主持人？-压缩启动紧凑。我这里用ceph163做主机，主机名。

注意:不管用哪一个，都要注意一点:压缩的时候硬盘会先膨胀后收缩，要留足空间。第二种方法的优点是可以修改ceph.conf中的参数mon _ data =/data 10/ceph 153使其生效。我后来的mon数据太大了，就更新了数据盘的路径:把对应的mon数据保存到另一个目录就行了。

第三种:集群正常时，尝试修改mon的配置参数(未验证，参数可降)。

mon_min_osdmap_epochs=500

mon_max_pgmap_epochs=500

mon_max_mdsmap_epochs=500

4.请特别注意:

？默认情况下，当mon所在的存储有5%空闲时，mon进程会自杀。

只需将对应的osd节点设置为out (osd进程依然存在)，它就会自动移除数据，删除对应数据盘的数据。当数据被删除时，通常关闭并删除osd。

命令:ceph osd out osd.xx

当服务器需要迁移，集群需要关闭时，先设置ceph osd set nodown？ceph osd set noup？ceph osd set noout？ceph osd设置nobackfill？Ceph osd set norecover保持集群不变，然后关闭每个osd、mon和rgw。

ceph osd设置no平衡

-禁止集群pg进行从属平衡。出现问题时，可以设置为故障排除。

ceph osd设置nobackfill

-严禁修复数据回填。出现问题时，我们暂时不想修复数据，可以和nobackfill一起使用。

ceph osd set norecover？

-严禁修复数据恢复。出现问题时，我们暂时不想修复数据，可以和nobackfill一起使用。

ceph osd设置nodown

-当集群中出现问题时，osd会上升和下降一段时间，您可以使用此命令禁用osd下降。

ceph osd set noup？

？-集群出现问题时，osd会一会儿上一会儿下，可以用这个命令禁止OSD上。

ceph osd set noout？

-禁止集群中的osd长时间自动下线并出局？

ceph OSD set no deep-scrub？

-取消使用相应的unset而不做进一步处理，如ceph osd unset noout。

ceph osd out osd.xx？将单个osd的状态设置为out。

osd.xx中的Ceph osd将单个osd的状态设置为in。

ceph osd down osd.xx？将单个osd的状态设置为关闭。

ceph tell osd.xx injectargs？-debug-osd20实时修改osd.xx的日志级别，无需重启osd。

ceph tell？mon.xx injectargs？- debug-mon？20?实时修改mon的日志级别，而无需重新启动mon。

ceph？告诉？osd。*?注射剂？-OSD _恢复_睡眠？1?单位二，最初设置为1，怕服务器有压力，观察后可以去掉设置为0。

ceph？告诉？osd。*?注射剂？- osd_max_backfills？1?调整恢复线程的数量，可根据实际情况进行调整。

ceph？告诉？osd。*?注射剂？- osd_recovery_op_priority？60?调整回收线的高度

ceph守护进程osd.xx状态？检查osd.xx的状态，主要看osdmap版本号。

Ceph pg转储查看所有pg信息。

Ceph pgdump _ stuck stall查看pg状态为stall的数据。

Ceph pg dump_stuck inactive查看pg状态为非活动的数据。

Ceph pgdump _ stuck不清楚的视图数据，pg状态为不干净。

Ceph -s查看集群。

Ceph osd树视图osd状态树

Ceph运行状况详细信息视图集群运行状况详细信息

Ceph pg pg_id查询以查看pg信息。

Ceph osd getmap -o osdmap.bin查看osdmap地图。

ceph-dencoder？类型？OSDMap？进口？osdmap_197？解码？Dump_json将osdmap导出为json格式。