同事最近把jenkins里的openstack的压力测试跑起来了,压力测试的方案使用openstack项目中的tempest,
24*7循环跑testcase,早晨同事发现很多VMs状态是Error,看了一下nova-sechduler,因为资源不够导致没有host可用,因此得出一个结论:openstack存在资源泄露。
我们现在就要一起来探索一下openstack的资源调度和监控机制,找到问题解决疑惑,并且需要确认是否真的泄露。
首先看两段log,/var/log/nova/nova-compute.log和/var/log/nova/nova-scheduler.log。
1
| /var/log/nova/nova-compute.log (host: trystack-compute3) |
1
| nova.compute.resource_tracker [-] Hypervisor: free ram (MB): 23353 |
1
| nova.compute.resource_tracker [-] Hypervisor: free disk (GB): 4271 |
1
| nova.compute.resource_tracker [-] Hypervisor: free VCPUs: -43 |
1
| nova.compute.resource_tracker [-] Free ram (MB): -46683 |
1
| nova.compute.resource_tracker [-] Free disk (GB): -7332 |
1
| nova.compute.resource_tracker [-] Free VCPUS: -90 |
1
| nova.compute.resource_tracker [-] Compute_service record updated for trystack-compute3 |
1
| /var/log/nova/nova-scheduler.log (host: trystack-manager) |
1
| nova.openstack.common.rpc.amqp [-] received method 'update_service_capabilities' |
1
| nova.scheduler.host_manager [-] Received compute service update from trystack-compute2. |
1
| nova.scheduler.host_manager [-] Received compute service update from trystack-compute2. |
1
| nova.scheduler.host_manager [-] Received compute service update from trystack-compute2. |
openstack的资源监控机制是每个host自己负责将自己的资源使用情况实时的持久化到数据库里,启动VM的时候需要通过资源调度将VM路由到资源最合理的host上去,那么nova-compute与nova-scheduler是怎么交互的呢?nova-scheduler又是怎么获取每个host上的资源情况呢?
update available resource
首先看看nova-compute的update_available_resource这个定时任务(default:60S),我们看看他做了些什么事情。
- 定时执行update_available_resouce, 这是compute/resouce_tracker.py: ResouceTracker的一个方法
- resource_tracker.update_available_resource的逻辑:
- resource = libvirt_dirver.get_available_resource() 这个资源都是host的真实资源情况,还不包含instance中flavor的资源占用情况。
- nova-compute log 打印Hypervisor资源相关的信息
- purge_expired_claims这里我没仔细看
- 获取当前host上所有未删除的云主机
- 对resource进行资源扣除根据每个instance的flavor信息mem/disk
- 持久化resource信息到mysql
report driver status
再来看一个和nova-scheduler相关的_report_driver_status(60S),我们再看看他做了些什么事情。
- 检查时间间隔
- capabilities = libvirt_driver.get_host_stats (host的真实资源情况和一些系统参数)
- update self.last_capabilities = capabilities
- 另外一个periodic task发生,把capabilities的信息发送给nova-scheduler
- nova-scheduler服务接受这个rpc call之后cache住这个host的信息
- 当启动VM的时候nova-scheduler获取到所有的cached的host capabilities,并且通过mysql里的compute_node信息更新capabilities信息。
- 到此nova-scheduler终于和update_available_resource有了联系。
总起来说,这个逻辑真复杂,为什么不直接用mysql多加了一个rpc call意义在哪?最后还是要依赖于db里的compute_node信息?