what happened while start nova compute service

原创 2015年07月10日 16:32:43

前面已经对nova创建instance和其他操作讲了不少,回到detail上,

在nova中,api,conductor,scheduler,compute都有对应的manager,在cmd包中启动各种service时,除了api是WSGI service,其他的都是Service,

更直接一点儿的话启动的是RPC的service,但这些服务中,compute的地位是不一样的,特别是启动时,做了很多工作,下面从细节上trace一下看看。

至于启动rpc service时候rpc server对应的target是什么,收到message处理的逻辑是什么,之前都讲过,主要看三个动作:

1. self.manager.init_host()

2. self.manager.pre_start_hook()

3. self.manager.post_start_hook()

对nova-compute来说这里manage自然是compute-manager,先看init_host:

        self.driver.init_host(host=self.host)

#self.driver默认情况为libvirt.LibvirtDriver,因此执行libvirt driver的init_host方法,其他的driver也需要执行对应的init_host, 传入的参数

host=self.host,host从nova.netconf中读出,在compute node则是读取配置文件中的host,而driver的init_host又执行了一大串动作:

initialize:注册driver的error handler,并将libvirt产生的event进行dispatch并处理,即不同的event对应不同的处理方式,比如连接失败之类的

_do_quality_warnings:连接libvirt driver得到cpu feature,分析cpu架构,若配置的virt type不是qemu或者kvm,或者cpu 的arch不是“arch.I686, arch.X86_64”,

给出警告的log

接下来对不同的virt type做不同的处理,若是lxc则判断容器是否有user/group 的namespace,若不是kvm则不进行kvm 加速,检查libvirt version的版本,不能

过低等。


        context = nova.context.get_admin_context()

#得到admin的context,user/project都是null,要的是admin context去objects里面做一些数据库的查询

        instances = objects.InstanceList.get_by_host(
            context, self.host, expected_attrs=['info_cache'])

#得到host中包含的instance list,如果是boot from image,只有临时数据,临时数据之类的都会存在coompute node上,boot from volume则存在volume所在处,

其临时数据?

        if CONF.defer_iptables_apply:
            self.driver.filter_defer_apply_on()

#执行firewall driver的filter_defer_apply_on, 对LibVirtDriver来说,默认的是IptablesFirewallDriver, 最终执行:

self.iptables.defer_apply_on(), self.iptables=linux_net.iptables_manager

只是将iptables_apply_deferred置为True,置为True之后,推迟使用当前iptable rule(当L3 driver使用linux_net作为backend时候,会调到

linux_net.metadata_forward(),应用防火墙规则,若这里defer了的话,就暂时不apply了)


        self.init_virt_events()
#若配置CONF.workarounds.handle_virt_lifecycle_events, 注册对virt driver的event listener

        try:
            # checking that instance was not already evacuated to other host
            self._destroy_evacuated_instances(context)

#这一段逻辑比较绕,先获得本机现有的所有instance(virt driver在本机获得),然后判断每个instance现在的host还是否是当前的host,如果不是,

但是instance的task state属于迁移/resize相关的状态,则不删除该instance; 如果设置CONF.workarounds.destroy_after_evacuate是False,警告,修改为True

之后重启方可;否则获得instance的网络/block device/共享存储,之后删除该instance

            for instance in instances:
                self._init_instance(context, instance)

#初始化所有的instance,这个判断的种类非常多, 很多种情况,针对不对情况,初始化虚机。

        finally:
            if CONF.defer_iptables_apply:
                self.driver.filter_defer_apply_off()
            self._update_scheduler_instance_info(context, instances)

#最后,应用iptables,并执行nova.scheduler.client.query.SchedulerQueryClient.update_instance_info,即通过scheduler去update instance(

对应HostManager中的_instance_info)信息



再来看看pre_start_hook:

只有一句:self.update_available_resource(nova.context.get_admin_context()),注意到这个方法是period_task,

想起ironic里面的period_task:@periodic_task.periodic_task(spacing=CONF.update_resources_interval)

compute_nodes_in_db = self._get_compute_nodes_in_db(context, use_slave=True)

#首先根据self.host拿到host中的所有compute_node(可能使用虚机做hypervisor?不然一个host如何多个compute node?),

nodenames = set(self.driver.get_available_nodes())

#拿到hypervisor对应的host name,然后根据host,driver,hostname对每个node得到一个resource tracker:

rt = self._get_resource_tracker(nodename)
rt.update_available_resource(context)

在resource tracker中,根据前面传入的driver,获得实际available resource(使用libvirt拿到一系列的值),这些数据包括vcpu,memory,local_gb,

vcpu_used等等,使用log记录(report),最重要的是执行_update_available_resource(注意前面有下划线),这里的最重要的步骤是:

_init_compute_node:

#如果compute不存在数据库中,就创建它,所以如果新加入的节点,经过一段时间或者重启nova-compute之后会自检测出来

主要更新的信息包括:

self.stats = importutils.import_object(CONF.compute_stats_class)
self.tracked_instances = {}
self.tracked_migrations = {}


最后看post_start_hook:

不是所有的manager都实现了,cellmanager实现了一些功能


nova-compute不能成功启动的原因总结

按照官方文档做到添加compute服务时,列出服务组件以验证是否每个进程都成功启动:$ nova service-list 发现如下结果:(缺少nova-compute的服务) [root@contr...
  • zhouminganga
  • zhouminganga
  • 2015年11月11日 18:21
  • 4271

关于nova-manage service list检测服务状态原理

环境:centos6.5 openstack ice版 1、 2、 3、 vim /usr/bin/nova-manage ...
  • tantexian
  • tantexian
  • 2014年09月11日 12:42
  • 39523

OpenStack源码分析之Nova-Compute服务启动过程(icehouse)

学习OpenStack有半年多了,一直都停留在使用和trouble shooting的阶段,最近有时间来好好研究了一下代码,因为以前是C++/Windows出生的,所以对Linux下面的Python开...
  • JJKJHK
  • JJKJHK
  • 2015年01月08日 10:56
  • 1277

OpenStack之Nova分析——Nova Compute定时任务(一)

我们在分析虚拟机的创建和Nova Scheduler调度算法中,其实已经涉及到了Nova Compute服务的一些内容,不过Nova Compute服务完成的工作要更多。这篇文章我们来详细的分析一下N...
  • qiuhan0314
  • qiuhan0314
  • 2015年02月16日 09:05
  • 1297

openstack中删除一个计算节点

openstack中删除一个计算节点 nova service-disable ,nova service-delete
  • chinagissoft
  • chinagissoft
  • 2016年01月13日 11:39
  • 4138

openstack-nova-创建云主机代码分析

Nova API的实现,以创建云主机过程分析 1. 首先我们要清楚,为nova添加一个新的api是很简单的,因为上面的那一套HTTP请求不需要我们管,只是照着来写就行了,    主要是你的api内的自...
  • u014022631
  • u014022631
  • 2016年09月13日 22:54
  • 2718

nova的服务心跳机制和服务状态监控机制的实现

Openstack中的服务是分布式部署,因此,各个服务的启停状态,决定了此系统的可用性。我们可以 通过openstack提供的接口来查看服务的运行状态,比如: nova service的相关配置 ...
  • gzhouc
  • gzhouc
  • 2017年03月25日 21:27
  • 836

Ubuntu下Swift、Keystone和Horizon安装集成小结

Ubuntu下Swift、Keystone和Horizon安装测试小结 崔炳华 2013年12月4日 1       环境准备 1.1        版本 Linux系统版本:Ubuntu Ser...
  • i_chips
  • i_chips
  • 2013年12月04日 11:43
  • 4278

OpenStack之Nova分析——Nova Compute定时任务(二)

这篇文章,我们来详细的分析一下Nova Compute服务的update_available_resource定时任务。 update_available_resource定时任务的主要功能是定...
  • qiuhan0314
  • qiuhan0314
  • 2015年03月03日 09:23
  • 1674

学会看openstack的日志

OpenStack日志 日志对于一个稳定的系统来说相当重要,对于OpenStack这样一个大型的系统,日志当然也是必不可少,理解Openstack系统的日志对于保证OpenStack环境稳定非常重要...
  • tuolaji8
  • tuolaji8
  • 2016年09月13日 10:03
  • 941
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:what happened while start nova compute service
举报原因:
原因补充:

(最多只允许输入30个字)