O024、Nova组件如何协同工作

参考 https://www.cnblogs.com/CloudMan6/p/5415836.html

Nova 物理部署方案

前面大家已经看到 Nova 由很多子服务组成，我们也知道OpenStack 是一个分布式系统，可以部署到若干节点上，那么接下来大家可能就会问：Nova的这些服务在物理上应该如何部署呢？

对于Nova，这些服务会部署在两类节点上：计算节点和控制节点

计算节点上安装了Hypervisor，上面运行虚拟机，由此可知：

1、只有nova-compute需要放在计算节点上

2、其他子服务则是放在控制节点上的

下面我们可以看看实验环境的具体部署情况。通过在计算节点和控制节点上运行 ps -efl | grep nova 来查看运行的nova 子服务

 
  root@DevStack-Controller:~# ps -e | grep nova    #    控制节点 
 
pts/14   00:20:24 nova-conductor 
 
pts/14   00:09:12 nova-conductor 
 
pts/14   00:09:20 nova-conductor 
 
pts/15   00:03:29 nova-scheduler 
 
pts/16   00:00:57 nova-novncproxy 
 
pts/17   00:03:29 nova-consoleaut 
 
pts/18   00:10:13 nova-compute 
 
pts/8    00:20:41 nova-api 
 
pts/8    00:01:24 nova-api 
 
pts/8    00:01:03 nova-api 
 
pts/8    00:00:09 nova-api 
 
pts/8    00:00:09 nova-api 
 
  root@DevStack-Compute:~# ps -e | grep nova    #    计算节点 
 
pts/4    00:07:05 nova-compute

RabbitMQ 和 MySQL 也是放在控制节点上的。可能信息的同学已经发现我们的控制节点上运行了 nova-compute 。这实际上也就意味着DevStack-Controller既是一个计算节点，也是一个控制节点，也可以在上面运行虚机。

这也向我们展示了 OpenStack这种分布式架构部署上的灵活性：可以将所有服务都放在一台物理机上，作为一个 All-in-One的测试环境。也可以将服务部署在多台物理机上，获得更好的性能和高可用。

另外，也可以用命令查看 nova-* 子服务都分布在哪些节点上

 
  stack@DevStack-Controller:~$ nova service-list 
 
   +----+------------------+---------------------+----------+---------+-------+----------------------------+-----------------+ 
 
   | Id | Binary           | Host                | Zone     | Status  | State | Updated_at                 | Disabled Reason | 
 
   +----+------------------+---------------------+----------+---------+-------+----------------------------+-----------------+ 
 
   | 3  | nova-conductor   | DevStack-Controller | internal | enabled | up    | 2019-05-23T02:01:25.000000 | -               | 
 
   | 4  | nova-scheduler   | DevStack-Controller | internal | enabled | up    | 2019-05-23T02:01:35.000000 | -               | 
 
   | 5  | nova-consoleauth | DevStack-Controller | internal | enabled | up    | 2019-05-23T02:01:26.000000 | -               | 
 
  | 6  | nova-compute     | DevStack-Controller | nova     | enabled | up    | 2019-05-23T02:01:29.000000 | -               | 
 
  | 7  | nova-compute     | DevStack-Compute    | nova     | enabled | up    | 2019-05-23T02:01:30.000000 | -               | 
 
   +----+------------------+---------------------+----------+---------+-------+----------------------------+-----------------+

从虚机创建流程看 nova-* 子服务如何协同工作

从学习 Nova 的角度看，虚机创建是一个非常好的场景，涉及的 nova-* 子服务很全，下面是流程图

1、客户（也可以是OpenStack最终用户，也就是其他程序）向API（nova-api）发送请求“帮我创建一台虚机”

2、API对请求做一些必要的处理后，想 Messaging（RabbitMQ）发送一条消息“让Scheduler创建一台虚机”

3、Scheduler（nova-scheduler）从Messaging 获取到 API发给他的消息，然后执行调度算法，从若干计算节点中选出节点A

4、Scheduler 向 Messaging 发送了一条消息：“在计算节点A上创建这个虚拟”

5、计算节点A的Compute（nova-compute）从Messaging 中获取到 Scheduler 发给他的消息，然后在本节点的Hypervisor上启动虚机

6、在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过Messaging向 Conductor （nova-conductor）发送消息，Conductor 负责数据库访问

以上是创建虚机最核心的步骤，当然省略了很多细节，我们会在后面的章节详细讨论。这个几个步骤向我们展示了 nova-* 子服务之间的协作方式，也体现了OpenStack整个系统的分布式设计思想，掌握这种思想对我们深入理解OpenStack会非常有帮助。

O024、Nova组件如何协同工作

猜你喜欢