关于OpenStack中Nova的几个基本概念

问题导读
1、学习OpenStack API，从何入门？
2、server、manager、driver的关系是什么？
3、Nova中重点有哪些代码尤其值得重视？





这一篇文，主要分为以下几个部分：
1、OpenStack API的类型，通过这一部分学习，使大家在阅读源码时候，对OpenStack 的API有一个基本的了解，虽然粗陋，但是非常有助于入门者对于代码的理解。
2、service、manager、driver之间的关系，通过这块，会让大家简单了解到OpenStack的一个设计思想，同样非常有助于大家对代码的理解。
3、组件之间（比如Scheduler和Nova）到底是如何传递消息的，通过这块，大家可以把之前翻译的联系起来，通过这两部分的学习，让rpc机制能在自己的大脑中跑起来。同时，再补充一点关于rpc_dispatcher的概念。
4、关于rpc_dispatcher，通过这个我们可以知道守护进程server接收到请求后，怎么把请求转发给manage（即调用manager中的方法去执行）
        这篇博文多是讲简单概念为主，东西并不深入，只是我作为初学者的一个简单理解而已，希望能对还没入门的同学有一个帮助。简单的理解，有助于我们把问题简化，先把整个东西串起来，脑子中有印象。在此基础上，我们更加需要对Python代码的细致分析，这就需要我继续努力了，加油咯。奋斗
        有讲错的地方，希望路过的大神，能够帮我纠正一下，好让我别在错误的道路上越走越远，谢谢了。大笑

（一)   OpenStack API类型
       （1）nova-api 起到了Cloud Controller的作用，主要为所有的API查询提供了一个接口（比如Openstack API ，EC2 API），引发多数业务流程的活动（如运行一个实例），并实施一些政策（主要是配额检查）。----这个api会在具体Scheduler 时候讲到。
       （2）这里分析一下OpenStack中的几种常见api类型。
        第一种：程序内部的api主要是给本机程序内部使用，如/nova/compute/api.py文件中的API主要是为了给manager去调用，其中调用哪个API也是利用OpenStack中非常重要的动态载入方法来确定的，非常灵活。
        第二种：RpcAPI，就是通过高级消息队列的方式，实现不同主机的方法的远程调用。如/nova/compute/rpcapi.py，其中调用的方法都是manager中的方法。
          第三种：api就是通过web资源的方式暴露给外界的api，将提供的服务暴露成web资源，可以方便外界的访问。（关于WSGI可以另外写一个话题，现在暂时不研究这个）

（二）server、manager、driver关系
    （1）server是一个服务进程，类似于Linux中的守护进程。一个server对应一个RpcAPI,接收特定topic的消息。server接收到请求之后，会转发给manager去处理。一个server具体有什么功能，由manager来决定。
    （2） manager顾名思义，一个服务请求的管理者，处理者，不做实际的工作。
    （3）而driver就相当于一个workers，实际的工作都由它来完成。
    （4）按照OpenStack的官方定义，一个manager可以对应有多个driver。简单来说，driver可以理解为一个适配器，比如调度，我们可以选择chance方法的调度，也可以选择FilterScheduler的调度器，这就是两个不同的drivers。同样。这在Compute虚拟化层特别明显，比如虚拟化层可以xem，kvm技术，不同技术，driver不一样。
      基于以上四点+外加（二），我们把上面的分类和设计思想，套用到代码的学习当中，那么我们就拥有了一条学习OpenStack源码的捷径，亲们，试试吧。相信短时间内，咱们就会对OpenStack源码有一个整体的了解。

（三）组件之间（比如Scheduler和Nova）到底是如何传递消息的
        先来简单介绍一下，两个组件：
        nova-schedule ：接受一个消息队列的虚拟实例请求，通过算法决定该请求应该在那台主机上运行，这个算法可以由我们指定。即起到调度器（Scheduler）的作用。nova-compute：是一个非常重要的守护进程，负责创建和终止虚拟机实例，即管理着虚拟机实例的生命周期。该模块内部非常复杂，基本原理是简单的，就是接受来自队列的动作然后执行一些列的系统操作（如启动一个KVM实例），并且更新数据库的状态。
        接下来，就从一个简单的例子，来简单讲述下，如何实现两个组件之间消息的传递；

1、Scheduler完成调度过，需要将过滤完成后，把选出来compute node发送给相应的节点，并且让该节点启动一个虚拟机实例。

/nova/scheduler/filter_scheduler.py  
复制代码

找到def _provision_resource最后一句调用  

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)  
复制代码

2、开始调用Compute的RpcAPI接口,找到/nova/compute/rpcapi.py文件，并找到run_instance方法

def run_instance(self, ctxt, instance, host, request_spec,  
                   filter_properties, requested_networks,  
                   injected_files, admin_password,  
                   is_first_time, node=None, legacy_bdm_in_spec=True):  
      instance_p = jsonutils.to_primitive(instance)  
      msg_kwargs = {'instance': instance_p, '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': node}  
  
      if self.client.can_send_version('2.37'):  
          version = '2.37'  
          msg_kwargs['legacy_bdm_in_spec'] = legacy_bdm_in_spec  
      else:  
          version = '2.19'  
      cctxt = self.client.prepare(server=host, version=version)  
      cctxt.cast(ctxt, 'run_instance', **msg_kwargs)  
复制代码

A）注意到最后一行，cctxt.cast(ctxt, 'run_instance', **msg_kwargs)，这就是非常关键的，一直在讲的RPC调用。
scheduler将需要运行的方法通过rpc机制发送给需要启动虚拟机的compute node的服务程序，守护服务进程接收命令后，由compute-manager处理该请求，最后实现虚拟机的启动。
当初没有理解AMQP机制的时候，一直被Scheduler如何把消息发送给Compute给纠结了好几天。-_-！
B）看到cast传递了两个参数，'run_instance',以及'msg_kwargs'。
（1）run_instance是一个方法，记得前面讲的service、manager、driver关系么，Scheduler通过rpc把该方法，传递给了compute服务（守护进程）中一直在监听的consumer绿色线程，然后server守护进程把方法传给manager（即调用manager中的run_instance方法）去执行这个方法。
（2）msg_kwargs的话，是一个字典，可以理解为把run_instance()方法需要的参数，打包到一起发送给compute node，再由compute服务的consumer把参数解析出来。

（四）关于rpc_dispatcher
1、我们再回头来看看，创建一个守护进程的步骤，首先，获取一个conn对象连接到rabbitMQ服务器，再创建3个consumer，再把consumer放到绿色线程中。

#获取一个连接到rabbit MQ的连接  
      self.conn = rpc.create_connection(new=True)  
      LOG.debug(_("Creating Consumer connection for Service %s") %  
                self.topic)  
#注册一个rpc_dispatcher，该对象与回调函数callback有关  
#MQ过来的消息，由rpc_dispatcher处理，具体函数在manager下定义  
      rpc_dispatcher = self.manager.create_rpc_dispatcher(self.backdoor_port)  
  
#创建第一个RPC的consumer，格式为topic.node  
      # Share this same connection for these Consumers  
      self.conn.create_consumer(self.topic, rpc_dispatcher, fanout=False)  
  
#创建一个RPC的consumer，格式为topic.node.host[1,N]  
      node_topic = '%s.%s' % (self.topic, self.host)  
      self.conn.create_consumer(node_topic, rpc_dispatcher, fanout=False)  
  
#再创建一个consumer，但是只用在在Scheduler更新信息的时候  
      self.conn.create_consumer(self.topic, rpc_dispatcher, fanout=True)  
  
#把RPC服务放到一个绿色线程中开始执行  
      # Consume from all consumers in a thread  
      self.conn.consume_in_thread()  
复制代码

重点看下面这两行代码
1、rpc_dispatcher = self.manager.create_rpc_dispatcher(self.backdoor_port)
2、self.conn.create_consumer(self.topic, rpc_dispatcher, fanout=False)
     在consumer创建的时候，已经注册了callback函数，因为发送到server有不同的请求msg｛method：**kwargs｝，当consumer取出msg后，设计了一个rpcproxy来处理不同的msg。因为rpc_dispatcher属性里面含有callback，所以，dispatcher就可以理解为我们需要的callback函数。
     再者，因为msg特别多，执行任务长，所以对于每个任务都创建了一个绿色线程去执行。

3、存在一个conn来连接RabbitMQ，因为我们同时需要多个connection，故使用eventlets.pools.pool来维护一个全局的pool，来管理这些connection。
总之，rpc_dispatcher = callback, server守护进程接收到请求后，由rpc_dispatcher的dispatch()方法执行msg｛method：**kwargs｝中的method方法（即调用对应的manager如compute-manager的run_instance执行）。
好了，以上四个问题，是我自己的一个小总结，希望对大家看代码有一定的帮助。