Featured image of post openstack节点down机的一种可能

openstack节点down机的一种可能

openstack节点down机的一种可能性

问题现象

公司春节放假要求测试环境openstack停机,回来开机以后有节点就出问题。

[root@osm01 ~]# nova-manage service list

Binary Host Zone Status State Updated_At
nova-consoleauth osm01.devcenter.geo internal enabled :-) 2024/2/20 07:35:57
nova-scheduler osm01.devcenter.geo internal enabled :-) 2024/2/20 07:35:58
nova-conductor osm01.devcenter.geo internal enabled :-) 2024/2/20 07:35:57
nova-cert osm01.devcenter.geo internal enabled :-) 2024/2/20 07:35:57
nova-console osm01.devcenter.geo internal enabled :-) 2024/2/20 07:35:57
nova-compute osc01.devcenter.geo nova enabled :-) 2024/2/20 07:35:56
nova-compute osc02.devcenter.geo nova enabled XXX 2024/2/20 07:35:58

在下面这张图中(省略了其他大部分计算节点)我们可以看到有一个compute是Down的,这个时候的第一印象是Compute的挂掉了,上节点上看,检查的时会发现Compute并没有挂掉,nova-compute服务跑的好好的,查看service的日志也是一切正常,并且不管如何重启状态就是不变过来。

问题解决过程

偶然发现时间变了,master节点跟计算节点差了1分多钟,那是不是这个问题呢?

检查下配置:

1
2
3
$ cat /etc/nova/nova.conf | grep service_down_time
#service_down_time=60
service_down_time=60

这个配置显示我们的时间容差是60s,那一分多钟肯定是不行了。

在nova.servicegroup.drivers.db中有如下处理用于判断服务的状态是up还是down的。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
class DbDriver(base.Driver):
    def __init__(self, *args, **kwargs):
        self.service_down_time = CONF.service_down_time
...
    def is_up(self, service_ref):
        """Moved from nova.utils
        Check whether a service is up based on last heartbeat.
        """
        ...
        elapsed = timeutils.delta_seconds(last_heartbeat, timeutils.utcnow())
        is_up = abs(elapsed) <= self.service_down_time
        ...
...

从上可以看到,在默认的配置下,如果Compute比Controller慢了1分钟以上,那即使Controller能不断的收到Compute上报的信息。但还是会认为Compute是Down的。

既然这样就简单了,那我直接启用一个ntp服务器,再配置内网节点间时间同步就可以了(使用自带的chronyd即可)。

此处省略配置时间同步。。。。

再验证,发现节点都正常了。