ceph-mon卡死故障分析处理

zphj19872024-04-302024-04-30

问题现象

ceph -s命令无返回了，查看mon的日志输出内容如下

globalid

看到的现象是 failed to assign global_id

然后尝试预分配更多的 global_id

mon_globalid_prealloc=1111110000

这个地方调整后，只是延缓了id的无法分配，没有解决问题，这个地方并不是消息id的问题，而是mon此时出现了问题，无法去正常的回收和响应消息，从而耗尽了id，出现了上面的现象，出现问题以后，mon实际无法响应请求了

把mon的进程直接放到前台运行

/usr/bin/ceph-mon -f --cluster ceph --id MYMON1 --setuser ceph --setgroup ceph
tcmalloc: large alloc 1073741824 bytes == 0x5568d6ac6000 @  0x7fb651ad24ef 0x7fb651af1bd6 0x556892b6c049 0x556892b6c08b 0x556892b6c940 0x7fb64f4e36f6 0x7fb64f4e7e66 0x7fb64f4debb5 0x556892b7a87d 0x556892ba9ba8 0x556892badb35 0x556892baefef 0x556892bdc6c6 0x556892bd8c86 0x7fb6531d8d69 0x7fb6532861ed 0x7fb64fd9dea5 0x7fb64ec60b0d
tcmalloc: large alloc 2147483648 bytes == 0x556916b3e000 @  0x7fb651ad24ef 0x7fb651af1bd6 0x556892b6c049 0x556892b6c08b 0x556892b6c940 0x7fb64f4e36f6 0x7fb64f4e7e66 0x7fb64f4debb5 0x556892b7a87d 0x556892ba9ba8 0x556892badb35 0x556892baefef 0x556892bdc6c6 0x556892bd8c86 0x7fb6531d8d69 0x7fb6532861ed 0x7fb64fd9dea5 0x7fb64ec60b0d
tcmalloc: large alloc 4294967296 bytes == 0x556996b3e000 @  0x7fb651ad24ef 0x7fb651af1bd6 0x556892b6c049 0x556892b6c08b 0x556892b6c940 0x7fb64f4e36f6 0x7fb64f4e7e66 0x7fb64f4debb5 0x556892b7a87d 0x556892ba9ba8 0x556892badb35 0x556892baefef 0x556892bdc6c6 0x556892bd8c86 0x7fb6531d8d69 0x7fb6532861ed 0x7fb64fd9dea5 0x7fb64ec60b0d
tcmalloc: large alloc 8589934592 bytes == (nil) @  0x7fb651ad24ef 0x7fb651af1bd6 0x556892b6c049 0x556892b6c08b 0x556892b6c940 0x7fb64f4e36f6 0x7fb64f4e7e66 0x7fb64f4debb5 0x556892b7a87d 0x556892ba9ba8 0x556892badb35 0x556892baefef 0x556892bdc6c6 0x556892bd8c86 0x7fb6531d8d69 0x7fb6532861ed 0x7fb64fd9dea5 0x7fb64ec60b0d

可以看到一直在大量的使用内存，这个地方会出现需要tcmalloc: large alloc 8589934592 bytes很大的问题

可以看到cpu占用很高，内存占用很多

mon的现象就是上面的持续的100%的情况，但是实际没做什么

临时恢复的方法

通过增加一个这个参数进行了问题的绕过

mon_sync_max_payload_size=4096

mon恢复了正常
这个在mon出现消息异常的时候，能够解决一些问题，这个地方我们继续分析相关的问题

问题定位

故障的原因是在响应ceph -s的时候产生了数百万个=的打印，这个纯属一个bug

https://tracker.ceph.com/issues/50587

这个issue里面比较清楚，并且15版本里面本身就完整的去掉了这一块，所以15版本没有问题，只有这个14版本有这个问题

https://github.com/ceph/ceph/blob/v14.2.11/src/mon/Monitor.cc
    auto& pem = mgrstatmon()->get_progress_events();
    if (!pem.empty()) {
      ss << "\n \n  progress:\n";
      for (auto& i : pem) {
	ss << "    " << i.second.message << "\n";
	ss << "      [";
	unsigned j;
	for (j = 0; j < (unsigned)(i.second.progress * 30.0); ++j) {
	  ss << '=';
	}
	for (; j < 30; ++j) {
	  ss << '.';
	}
	ss << "]\n";
      }
    }
    ss << "\n ";
  }

就是这块代码的问题

社区相关的pr已经解决了

https://github.com/ceph/ceph/pull/41098

按这样修改以后进行验证

这个问题触发的情况是在osd出现频繁的上下线或者out以后，计算里面的状态值里面有问题，然后执行ceph -s的时候就触发了大量的内存分配的情况了

这个问题拿的社区版本的14.2.11 复现出来了这个问题，这个复现需要使用异常的mon的数据进行复现，按照上面的在14.2.11上面进行修改后，重新打包rpm，进行复测

可以看到14.2.22版本确认已经解决了这个问题了

出现问题后可以采用两个方式验证这个问题是否解决

1、直接用14.2.11进行pr的修改，验证是否解决
2、不改代码，直接用官方的14.2.22，验证是否解决，升级是不是有其它问题（启动看看有没有问题）

这个需要看根据实际项目来看是原包升级还是整体升级，原版本改动小一点，回退也方便

离线mon数据的加载复现方法

准备了一台虚拟机，主机名和ip都设置为跟现场一样的，ceph版本也安装一样的版本，把mon的目录拷贝到虚拟机的环境里面

进行单mon的处理

[root@lab103 ~]#ceph-mon -i MYMON1 --extract-monmap /tmp/monmap
[root@lab103 ~]#monmaptool --rm  MYMON2 /tmp/monmap
[root@lab103 ~]#monmaptool --rm  MYMON3 /tmp/monmap
[root@lab103 ~]#ceph-mon -i  MYMON1  --inject-monmap /tmp/monmap

mon数据的属性问题

一般上面就可以了，但是这个有个版本的属性不匹配，需要多做下面的操作

[root@lab103 ~]#monmaptool /tmp/monmap --feature-list parseable
monmaptool: monmap file /tmp/monmap
monmap:persistent:[kraken(1),luminous(2),mimic(4),osdmap-prune(8),nautilus(16),unknown(128)]
monmap:optional:[none]
monmap:required:[kraken(1),luminous(2),mimic(4),osdmap-prune(8),nautilus(16),unknown(128)]
available:supported:[kraken(1),luminous(2),mimic(4),osdmap-prune(8),nautilus(16)]
available:persistent:[kraken(1),luminous(2),mimic(4),osdmap-prune(8),nautilus(16)]

关闭相关的属性

[root@lab103 ~]#monmaptool /tmp/monmap --feature-unset 128 --persistent
[root@lab103 ~]#monmaptool /tmp/monmap --feature-list parseable
monmaptool: monmap file /tmp/monmap
monmap:persistent:[kraken(1),luminous(2),mimic(4),osdmap-prune(8),nautilus(16)]
monmap:optional:[none]
monmap:required:[kraken(1),luminous(2),mimic(4),osdmap-prune(8),nautilus(16)]
available:supported:[kraken(1),luminous(2),mimic(4),osdmap-prune(8),nautilus(16)]
available:persistent:[kraken(1),luminous(2),mimic(4),osdmap-prune(8),nautilus(16)]