裸金属常见问题——hypervisor信息不匹配

Posted 2020-12-24 wangwei1

问题1：对接物理机，ironic node在nova的hypervisor中无法显示CPU、RAM等信息，全是0。

注：该ironic node是使用fake driver创建的。

 

相关概念：

在裸金属场景下，ironic node在nova侧的概念就是hypervisor，用于承载用户实例的一种资源。其实很好理解，对于虚拟化而言，nova-compute节点上起虚机作为实例，所以虚拟化场景下nova-compute节点就是hypervisor；而对于裸金属而言，由于每个ironic node是通过安装系统，为租户提供实例资源，所以，ironic node就应该作为hypervisor。

而在nova-compute的代码中，会周期性的调用ironic-api（通过ironicclient），获取裸金属节点信息，并转换为nova的hypervisor资源，用于发放实例。

 

解决：

分析日志与代码，得知，由于该ironic node是使用fake driver，所以电源状态无法同步，使用的是默认的None。
而nova在同步ironic node的时候，如果node的电源信息为错误的值，则将cpu、ram、disk等设置为0，代码如下：

    def _node_resource(self, node):
       ...
       elif self._node_resources_unavailable(node):
            # The node‘s current state is such that it should not present any
            # of its resources to Nova
            vcpus = 0
            memory_mb = 0
            local_gb = 0

    def _node_resources_unavailable(self, node_obj):
        """Determine whether the node‘s resources are in an acceptable state.

        Determines whether the node‘s resources should be presented
        to Nova for use based on the current power, provision and maintenance
        state. This is called after _node_resources_used, so any node that
        is not used and not in AVAILABLE should be considered in a ‘bad‘ state,
        and unavailable for scheduling. Returns True if unacceptable.
        """
        bad_power_states = [
            ironic_states.ERROR, ironic_states.NOSTATE]
        # keep NOSTATE around for compatibility
        good_provision_states = [
            ironic_states.AVAILABLE, ironic_states.NOSTATE]
        return (node_obj.maintenance or
                node_obj.power_state in bad_power_states or
                node_obj.provision_state not in good_provision_states)

所以，有如下情况的ironic node，其对应的hypervisor中的资源就是0了：

• node处于维护状态：maintenance=True
• node的电源状态异常：‘error’或者None
• node的provision状态不为available或者None
• node的properties中没有相应的硬件信息

对于创建的fake driver的ironic node，修改其电源状态即可：

ironic  node-set-power-state <uuid> on

 

问题2：hypervisor个数不同步问题：

ironic node有1120个，但是在nova 的hypervisor中只有526个，且ironic node与nova-compute都属于同一个dmz的az。

 

问题描述：

本环环境的问题目前有两个：
1、ironic node有1120个属于dmz域，相应的nova-compute节点也都属于dmz域，但是nova hypervisor-list 只能看到526个ironic node。
2、nova发放物理机实例的时候，nova scheduler对526个node进行过滤，但是可用的node却没有一个。

解决：
1）首先我们看一下环境上ironic node的分配情况：
属于dmz域的ironic node有1120个。
ironic node-list --az dmz | grep None | wc -l

其中：

enroll状态的node有241个：
    ironic node-list --az dmz | grep enroll | wc -l
manageable状态的node有878个：
    ironic node-list --az dmz | grep manageable | wc -l 
而available状态的node只有1个：
    ironic node-list --az dmz | grep available | wc -l

2）同步到nova数据库中的node只有526个，我们登录nova数据库，查看这些node的分布：

use nova；
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.101" and deleted=0;
0
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.102" and deleted=0;
0
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.103" and deleted=0;
114
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.104" and deleted=0;
0
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.131" and deleted=0;
0
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.132" and deleted=0;
72
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.133" and deleted=0;
0
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.134" and deleted=0;
75
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.137" and deleted=0;
85
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.138" and deleted=0;
98
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.139" and deleted=0;
82
select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where host_ip="10.193.102.140" and deleted=0;
0
Total: 526 == nova hypervisor-list

View Code

发现，12个nova-compute节点，其管理的ironic node并不满足哈希环的分布。有问题的节点为：

10.193.102.101、10.193.102.102、10.193.102.104、10.193.102.131、10.193.102.133、10.193.102.140
这4个节点。

3）尝试重启一个有问题节点的nova-compute服务；

ssh 10.193.102.101
systemctl restart openstack-nova-compute

   这时查看数据库中的数据，发现多了一些内容：

select hypervisor_hostname, deleted, host,hypervisor_type  from compute_nodes where deleted=0;

   而且数据在一直增长，直到617。

因此，认为nova hypervisor-list 与 ironic node不匹配的原因可能是这些节点上nova-compute服务的异常导致。
将其他有问题节点的nova-compute服务也依次重启，发现数据库中的hypervisor的个数在一直增长，最终和ironic 的 1120个node相等。

 

问题3：hypervisor显示的个数与数据库中的个数不匹配：

nova hypervisor-list结果显示为1000个。但是数据库中有1120个。

代码如下：

1 def get_limit_and_marker(request):
2     """Get limited parameter from request."""
3     params = get_pagination_params(request)
4     limit = CONF.api.max_limit
5     limit = min(limit, params.get(‘limit‘, limit))
6     marker = params.get(‘marker‘, None)
7 
8     return limit, marker

View Code

CONF.api.max_limix的默认值为：1000

 

 所以显示的hypervisor个数默认限制为1000个，如果想显示更多，修改对应的配置项即可。

 

 问题4：在有一次清空nova数据库然后重建数据库的时候，执行一次物理机发放，但是nova-scheduler调度不到主机，nova-conductor报错”No valid host found"。

  然后查看nova-compute的日志，发现一直在刷错误日志：

 

而且相应的nova-placement-api也一直在刷错误日志：

 

 

 

 

排查：

1. 通过执行 nova hypervisor-list 可以发现nova-compute已经从ironic获取到了节点信息。
2. 然后nova-compute调用nova-placement的API在nova-placement的数据库中添加相应的可用节点的数据，发现nova-placement返回409，则nova-compute则认为该数据可能已经被其他线程添加过了，所以不再创建数据，而是调用nova-placement的API去获取这些节点信息，但是nova-placement却返回404说找不到这条数据。
3. nova-placement获取hypervisor数据是从nova数据库中获取的，但是创建是在nova-placement的数据库，可能的原因就是清空了nova数据库中的信息，但是nova-placement的数据库中仍有残留数据，所以导致创建时候冲突，但是也获取不到数据。
4. nova-placement获取hypervisor是从nova的compute_nodes表中读取数据，nova-compute调用nova-placement的API创建hypervisor数据是在nova-placement的resource_providers表中。

所以，虽然清空了nova的数据库，但是placement数据库中的残留，影响到了nova-compute将hypervisor同步给placement，因此，placement的数据库的resource_providers表也要清空。