ceph运维大宝剑之osd暴毙引发的pg创建失败

2020-01-23

字数统计: 1.9k字 | 阅读时长≈ 7分

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：

今天一看关注的朋友忽然增多挺多的，甚是惊喜

博客暂时访问不了，关注的朋友还在增多，感谢大家的支持

今天更的大宝剑也是一次故障排查，不是很复杂的问题，本来不想写，但是同样的报错出现两次，觉得还是有必要记录一下

现象

这个问题出现过两次：

第一次，跑自动化初始化集群的脚本的时候，卡住在创建realm上，看了下集群状态，绝大部分的pg都有问题，大批osd间歇性暴毙，多次restart起来又挂掉

data:
  pools:   6 pools, 9472 pgs
  objects: 0 objects, 0 B
  usage:   4.6 TiB used, 18 PiB / 18 PiB avail
  pgs:     91.026% pgs unknown
           8.488% pgs not active
           8622 unkown
           804  creating+peering
           46   active_clean

第二次，也是在创建realm时卡住，不同的是本次仅有小部分pg not active，仅有两个节点的osd发生暴毙(集群有72个节点，18PB的环境)

相同点

都是建pool之后出问题，建pool前集群所有osd都up&in
暴毙的osd报错信息都一样

Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 41.1b53s8 has ref count of 2
Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 47.2e9s3 has ref count of 2
Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 41.997s1 has ref count of 2
Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 41.142ds7 has ref count of 2
Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 41.16das0 has ref count of 2
Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 41.beas3 has ref count of 2
Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 41.3bs8 has ref count of 2
Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 41.3bas4 has ref count of 2
Sep 26 10:49:54  ceph-osd: 2019-09-26 10:49:54.821 7f65bee08700 -1 osd.31 9943 pgid 47.172es8 has ref count of 2

排查

创建pool失败，pg长时间无法clean，判断可能与crushmap有关，导出map看了下，没有问题，ceph osd pool ls detail看了下，rule对得上，看起来跟crushmap关系不大

集群的public和cluster是用同一个bond接口，建池之前所有osd都是正常的，推测网络是没有问题的

osd日志级别调大，多次重启osd，类似pgid 47.172es8 has ref count of 2这种信息查了一圈，没有什么结果，47.172es8这个pgid也有问题，从名称上看，它是id为47的存储池的pg，可是172es8显然不是16进制的pg编号，所以这个报错信息也是奇奇怪怪的，根本不知道在说什么

在集群第一次出情况的时候，排查到这里，很难想到其他思路了，绝大部分pg是unkonw和peering状态，梳理一下pg创建过程，osd收到pg创建的相关信息后，开始创建，完成后，会进行pg之间的peer，只有peer也完成了，这个pg才能最终达到clean，现象上看一方面是pg的创建有问题，另外一方面，pg之间可能无法正常完成peer，可是crushmap确认过没有问题，那么可能是pg之间，或者说osd之间的通信有问题

因为确认过，osd在创建pool前全是up&in的，很容易让人排除掉是网络问题，事实上，在没有pool的情况下，osd之间并不会相互建立联系

osd的连接有这么几种：

与mon的连接，通过public进行通信，主要是心跳维系和必要的数据交互，例如osdmap，这个连接正常，会被mon认为这个osd是正常的
与client的连接，这个是在进行集群读写的时候才会产生，也是走的public
osd之间的连接，相同pool的osd会建立连接，用于心跳和副本数据复制，尤其是osd之间的心跳，确保任何一个pg在出现问题的时候能第一时间被感知到

回到环境看，mon看到所有osd都是up且in的，只能说明osd到mon的连接没有问题，但是osd之间有没有问题是不确定的！想到这，ansible立马搞起来，72台设备之间相互ping 3个包，检测一看，集群1-36号节点，与37-72号节点完全不通！啊～～～

由于集群规模较大，节点之间在集成的时候，被分成了两个vlan，这种情况看来是vlan之间的互通出问题了！这是非常不容易发现的一个点。

解决办法很简单，让集成的同事搞一下跨vlan转发，pg 30s左右就正常了。

第二次出现这个日志，第一时间当然是ansible搞起来，ping一波，节点都是通的！集群的所有osd也是正常的，出问题的节点仅有两个，是不是这两个节点有什么特别呢？

首先两个节点之间相互ping，没有问题，osd是刚重装完的，也不会有什么旧配置的问题，最大的怀疑在于，这个集群刚刚换完ip，mon更换完ip后已经重新起来，osd更换完ip也都全部起来了，还会有问题吗？

既然报错一样，大概率是一类问题：网络

打开ip a查看了一下节点的ip情况，看了一眼bond口的ip，好像没有什么不对

6: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 70:c7:f2:ad:32:d8 brd ff:ff:ff:ff:ff:ff
    inet 10.199.100.21/25 brd 10.199.24.127 scope global bond0
       valid_lft forever preferred_lft forever
    inet 10.100.100.21/25 brd 10.100.24.127 scope global bond0
       valid_lft forever preferred_lft forever
    inet6 fe80::72c7:f2ff:fead:32d8/64 scope link
       valid_lft forever preferred_lft forever

两个ip，掩码是25位，好像也没有什么不对劲啊，慢着，ceph.conf文件中的public network是啥？

1 2	[tanweijie@ceph-021 ~]$ cat /etc/ceph/ceph.conf \|grep public public_network = 10.0.0.0/8

我。。。。。

原来自动化部署的时候为了方便，使用了8位的掩码，节点修改完ip后，不知道遇到了什么情况，接口上原来的ip没有释放，同时新的ip也绑上去了，于是出现了bond接口有两个ip的情况，这种情况下，osd读入的public配置，发现系统有两个符合条件的ip，它哪里知道要用哪个ip呢？

解决办法还是那么简单，修改public network为16位掩码地址，就ok了，另外保险起见，手动重启了一下两个节点，让bond口只配置一个ip

总结

这次的问题，光看日志和集群信息，很难得到什么有价值的线索，在大规模集群中，往往一个细节的地方配置得有失误，就会引发一些奇特无比的现象，让人摸不着思路

本次大宝剑排查的问题，根据osd日志信息，查了一圈没有什么收获(没有用谷歌，梯子坏了，难受)，因此这边记录一下，方便其他朋友参考

本文作者： 奋斗的松鼠
本文链接： http://www.strugglesquirrel.com/2020/01/23/ceph运维大宝剑之osd暴毙引发的pg创建失败/
版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！