openstack--nova的运行机制分析（一）

openstack的个人总结与理解

1·主要作用

openstack运行在Iaas层，为不同的硬件设备提供一个通用的虚拟化以及管理平台。

2·与分布式系统的不同之处

3·部件组成--第三方库

作为一个开放的平台，openstack提供了一个通用的框架以及核心的功能，开发者可以根据实际的应用场景，将第三方库快速地引入，并进行扩展，如：为提高处理速度与效率，可以引入memcache第三方库，暂存一些不常更改但是频繁访问的数据，为了支持更多的节点访问，选择合适的memcache server的库部署成集群cache服务器。

4·硬件设备的虚拟化

openstack本身并不具备虚拟化的能力，而是通过应用libvirt库进行虚拟化。libvirt作为一个成熟的虚拟化库，被广泛地使用。

Nova的个人总结与理解

1·地位

较早的版本中，Nova负责了虚拟机实例的生命周期管理、网络管理、存储卷管理、用户管理以及其他的相关的平台管理功能，是opnestack最核心模块。

新版本中，为了简化Nova的功能，将部分功能剥离出来作为独立的模块，如：网络管理、存储卷管理，使得Nova的代码更为简洁，易于维护与开发。

2·主要功能

• Nova-api：提供用于的交互接口，主要是以wsgi的方式提供同一的交互界面
• Nova-scheduler：根据指定的算法，选取符合条件的硬件设备，以安装虚拟机实例
• Nova-conductor：Nova-computer的管理器，简化computer节点的部分管理功能
• Nova-computer：负责虚拟机安装部署、启动、运行、迁移等的实际执行

3· Nova-api

Nova-api是向用户提供相关服务的接口的一个http web服务，符合wsgi规范（如何一个应用A基于wsgi规范定义的接口编写、它将可以在任何遵守wgsi规范的server上运行）。api接收的request，调用相应的action进行处理，并且返回response。

* 符合WSGI规范有何好处？

虽然Nova api已经可以很好地实现与的交互，但是对于一些特定的应用，为了提高用户的连接数量、增加api的并发处理能力等，需要进行扩展，Nova api这时候表现为中间件（Middleware），接收用户的请求并且自动转发。使用WSGI规范，统一了其他扩展模块与Nova api的接口。

4· 响应api的处理请求--rpc机制

传入一个request后，将调用相应的方法进行处理。

* 为什么需要RPC机制？（Remote process call）

Nova 是一个多进程的模块，不同的进程负责不同的功能，因此，需要解决不同进程间的功能的调用，例如：

nova-scheduler选取合适的物理机后，需要：（这个例子与实际可能不一致，但是原理差不多）

1）调用nova-compute模块的创建实例的功能

2）将相关的数据传入到nova-compute的创建实例这个功能的函数中

3）nova-scheduler等待nova-compute的函数执行结果

4）nova-scheduler将执行结果返回给上层

* RPC机制的类型？

不同的应用场景需要不同的远程函数调用与反馈机制，在RPC中，大致分为如下两种方式：

1）RPC.Call方式

需要远程调用的函数返回结果信息

2）RPC.Cast方式

远程函数无需返回结果信息

* RPC机制下远程进程间如何传递消息？--AMQP & Rabbitmq

1）传统的传递消息的机制

在同一个操作系统下，进程间传递参数信息一般使用共享文件、共享内存、信号量等方式，而对于C/S架构，则一般使用socket将消息从client传递到server，server调用相应的方法处理消息。

2）RPC机制下使用了AMQP协议传递消息（Advance Message Queue Protocol）

amqp协议规定了类似于C/S模式的消息共享机制，但是，server在这里只当做一个消息的中转站，消息的最终处理是接收到该消息的节点/模块。

这里有重要的两点是区分于普通的消息传递方式：

• 对于AMQP，将客户端的角色分为：消息生产者与消息的消费者
• 所有不同类型的消息都需要经过消息的server进行分发，以实现对消息的统一管理

3）AMQP的Server的消息转发机制--消息何去何从？（Exchange）

对于消息转发，无非关心：接收到的消息该往何处去？

一种最简单的方式：

在消息中指定接收者的id，然后通过一个对应的映射表将该消息发往该接受者。

这种映射转发类似于交换机（Exchange）的数据包转发方式。是否有更为高端的转发方式？

一种更高级的转发方式：

消息可以通过一定的匹配方式，传递给符合条件的所有消息消费者。

在这种模式下，可以指定消息发送给某类以.compute结尾的消息消费者。因此，需要为消息的消费者定义一种特殊的标志方式。

比如：

标志两个消费者为node1.compute、node2.compute，则：

•  “*.compute”可以使node1与node2都接收到消息，
•  “ node1.compute”则只能由node1.compute的消息消费者接收到。

4）消息的消费者无法立即消费数据--需要对消息进行缓存

远程进程的取消息的机制--轮询定时取消息

由于无法获知远程进程的当前执行状况，而我们又不想要消息的消费者或者是消息服务器主动通知该远程进程去取数据，那么，远程进程就需要以轮询的方式主动将消息从server中取出来。

那么，这必然引起一个问题：当前服务器接收到的消息存储在哪里？

server中的消息队列（Queue）缓存消息

为了缓存接收到的消息，server在内存中开辟出一个队列存储已接收到的消息，并等待消息消费者从队列中读取数据。

5）Queue与消息消费者的关系

在server中，消息消费者为了能够取消息，需要去server上注册，注册 过程中，服务器会为其生成一个对应queue，那么这个queue就是消费者日后取走数据的通道。

因此，server中的一个queue对应一个唯一的消费者。

6）Queue与Exchange的绑定--绑定指定的消费者

既然Queue与消费者是一一对应关系，那么Queue就可以唯一地代表消费者。

因此，server将消息Exchange到queue就是将消息传递给该消费者。

queue与Exchange的绑定就是将queue的名字（这里可能不准确，但原理大致如此）注册（通过绑定的方式）到Exchange表中。一个queue在Exchange表中可以有多个名字以接收不同条件的消息。

7）Server异常状况下如何保证消息的有效性？--备份

既然消息是通过server传递的，那么一旦server崩溃后，消息队列的消息将直接丢失。

因此，需要一种保障机制，这里即：消息备份机制。

消息备份机制的方式，无非如下两种，或者两种同时组合使用：

• 备份到server的硬盘中
• 备份到其他节点的内存上

不同的方式各有利弊。

8）消息传递以及远程函数的调用

当消息消费者获取到消息后，如何确定需要调用的函数？

最简单的方法是：

将需要调用的方法名作为消息的一部分传递给消费者，消费者直接根据函数名找到方法进行处理。

9）如何实现AMQP--Rabbitmq

AMQP只是一种协议规范，Rabbitmq是其一种实现。

* RPC.Call的具体过程

1）消息生产者：

调用Call方法时，需要指定处理返回信息的方法，然后，将消息发送处理。

等待反馈信息（这里使用了异步的概念，即继续执行其他过程，而不是以阻塞的方式原地等待）

从direct中接收到反馈信息，调用callback方法进行处理--（这里，是作为反馈信息的消费者）

2）消息的消费者

消息消费者从队列中获取到消息

然后调用相应的方法处理这条消息

通过direct的方式将消息传回消息的生产者。--（这里，是作为反馈信息的生产者）

* RPC.Cast的具体过程

Cast的过程与Call类似，除了没有返回反馈信息的相关过程。

注：限于知识与文笔有限，本文先写到这里，后续会再发一些学习过程中的心得与总结。

文章为个人总结，如发现文中有明显错误，请帮忙指出，如有更好的见解，欢迎交流！