nova-compute源码结构分析

一 目录结构
Compute服务位于nova/compute
[root@localhost compute]# tree -L 1
.
├── api.py
├── build_results.py
├── cells_api.py
├── claims.py
├── flavors.py
├── __init__.py
├── __init__.pyc
├── instance_actions.py
├── manager.py
├── monitors
├── power_state.py
├── power_state.pyc
├── resource_tracker.py
├── rpcapi.py
├── stats.py
├── task_states.py
├── task_states.pyc
├── utils.py
├── utils.pyc
├── vm_states.py
└── vm_states.pyc
二 跟API相关的三个文件
rpcapi.py
这个文件包含了调用nova-compute服务RPC API的client端代码。该文件简化了client调用rpc api的代码。文件注释说明了该文件的作用。
"""
Client side of the compute RPC API.
"""
举例,nova-scheduler中即引用了该代码
#filter_scheduler.py
from nova.compute import rpcapi as compute_rpcapi
#scheduler在选定了一个计算节点后,通过RPC调用计算节点上的nova-compute服务来创建虚拟机。
            self.compute_rpcapi.run_instance(context,
                    instance=updated_instance,
                    host=weighed_host.obj.host,
                    request_spec=request_spec,
                    filter_properties=filter_properties,
                    requested_networks=requested_networks,
                    injected_files=injected_files,
                    admin_password=admin_password, is_first_time=is_first_time,
                    node=weighed_host.obj.nodename,
                    legacy_bdm_in_spec=legacy_bdm_in_spec)
api.py
compute中的本地调用api。每个服务会有一个api.py文件,这个文件提供了该服务的本地调用api接口。
查看api.py文件可以看到,该文件中的很多实现其实调用了compute的rpcapi.py。例如:
 
   def attach_interface(self, context, instance, network_id, port_id,
                         requested_ip):
        """Use hotplug to add an network adapter to an instance."""
        return self.compute_rpcapi.attach_interface(context,
            instance=instance, network_id=network_id, port_id=port_id,
            requested_ip=requested_ip)
从中可以看出,api.py应该是属于遗留代码(legacy code),不应该继续使用,保留是为了兼容以前的代码。
manager.py是nova-computer最为核心的代码,所有有关虚拟机生命周期管理的函数都在这个模块中,其中ComputerManager类用于执行接受到的RPC请求。把它理解为RPC调用的服务端。

三 资源管理模块
resource_tracker.py和claim.py实现资源管理。
nova-compute为每一个主机创建一个ResourceTracker类实例来跟踪它的资源。作为Openstack的资源管理器,Resource Tracker负责收集主机上的资源以及将资源的使用情况通知nova-scheduler,作为选择主机的依据。
每个主机上都有很多资源,最初,虚拟机的调度和创建,只关心CPU、内存、磁盘等资源。但是随着虚拟机管理越来越精细,特别是NFV(network Functions Virtualization,网络功能虚拟化)场景下,需要更为精细化的资源控制。但哪些资源需要跟踪刷新,哪些不需要,大家很难达成一致。
于是,社区针对Resource Tracker提供了扩展机制(ERT,Extensible Resource Tracker),每个人可以根据自己的需求创建插件实现特定资源的管理,ERT机制的实现位于resource目录,目前默认只有一个vcpu的实现。
monitors目录是UBS的实现,与ERT一起,它们都是Juno中加入的,但是在kilo中会被删除或替换。

四 参考
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值