OpenStack入门以及一些资料之（零，nova计算）

最近看了些OpenStack的代码，深感自己还有很多不足，于是便想起了之前读过的华为孔令贤的csdn博客（原地址，现已迁移到github，地址），花费了一些时间通读了一遍，获益颇多，在这里整理并记录一下。

0，计算

关于调度（scheduler），它的主要作用是决定虚拟机创建在哪个节点上，主要是通过一些过滤器（filter）来实现的。

参考：OpenStack Scheduler 入门

         Grizzly版本中Scheduler filter机制详解

         Nova目前的filter及其功能

---------------------------------------------------------------------------

关于消息队列，nova中的每个组件都会连接消息服务器，一个组件可能是一个消息发送者（如API、Scheduler），也可能是一个消息接收者（如compute、volume、network）。发送消息主要有两种方式：同步调用rpc.call和异步调用rpc.cast。还有其他的消息发送方式，比如notify等。

一些比较重要的概念：

交换器(exchange)：接收消息并且将消息转发给队列。在每个主机的内部，交换器都有唯一对应的名字。交换器可以使持久的，临时的或者自动删除的。持久的交换器会一直存在与server端直到它被显式的删除；临时交换器在服务器关闭时停止工作哦；自动删除的交换器在没有应用程序使用它的时候被服务器删除。交换器主要有三种类型：

广播式交换器类型(fanout）:不分析所接收到消息中的routingkey，默认将消息转发到所有与该交换器绑定的队列中去。

直接式交换器类型(direct)：需要精确匹配routingkey和bindingkey，如消息的routingkey = cloud，那么该条消息只能被转发至bindingkey = cloud的消息队列中去。

主题式交换器(Topic Exchange)：通过消息的routingkey与bindingkey的模式匹配，将消息转发至所有符合绑定规则的队列中。

队列：“消息队列”，它是一个具名缓冲区，代表一组消费者应用程序保存消息。这些应用程序在它们的全县范围内可以创建、使用、共享消息队列。类似于交换器，消息队列也可以是持久的，临时的或者自动删除的。

绑定：可以理解为交换器和消息队列之间的一种关系，绑定之后交换器会知道应该把消息发给哪个队列，绑定的关键字称为binding_key.

参考：OpenStack 消息队列入门

         依据AMQP通信架构实现消息发送机制解析之一

---------------------------------------------------------------------------

在Folsom版本中，对应不同的hypervisor实现，所有插件类全部继承于一个基类/nova/virt/driver.py

参考：Nova虚拟化层Driver分析(基于F版)

         OpenStack使用XenServer资源池浅析

---------------------------------------------------------------------------

[nova中的policy]任何对外暴露接口的系统，都必须有分权分域以及认证鉴权的功能。在openstack中，keystone组件用来对用户进行认证，说白了就是看用户是否是系统的合法用户，而policy机制则主要看用户的操作是否满足特定的条件，比如一些接口是特权接口（仅限管理员使用），普通用户不允许调用。

参考：OpenStack Nova中的policy

---------------------------------------------------------------------------

OpenStack的循环任务以及资源刷新机制。对于循环任务，OpenStack并未使用python中的threading或者multiprocessing模块，而是大量使用了一种叫做协程(coroutine)的东西，也叫“绿色线程”，主要在eventlet库中，OpenStack又对其作了一些封装。而资源刷新，并不是计算节点定期将自己的信息写入共享DB，让scheduler在调度时从DB中读取资源数据，而是让个节点定时上报，把对DB的压力转移到了nova-scheduler进程。但是当节点数目上去之后，nova-scheduler进程能否支撑如此频繁调用和如此大的数据量，还是一个疑问。

参考：OpenStack Nova的资源刷新机制

         OpenStack中的循环任务和子任务--以Nova为例

         Openstack Eventlet分析(1)

         OpenStack Eventlet分析(2)

---------------------------------------------------------------------------

Cell in nova：为了增加横向扩展以及分布式，大规模(地理位置级别)部署能力，但又不增加数据库和消息中间件的复杂度，并将cell调度和主机调度隔离。G版重新提出cell概念。Cell之间的通信的可信的，基于AMQP协议。概括如下：
》每一个Cell中拥有独立的DB和AMQP broker
》引入新的nova-cell服务
    -消息路由
    -调度(与主机调度不同，子Cell通过定时刷新将自己能力和资源上报给父Cell)
》cell之间通信通过RPC
》cells之间是树状结构
    -顶层是API cell，不感知底层物理主机以及虚拟化
    -子cell无nova-api服务
    -子cell无quota概念(NoopQuota)

参考：G版中关于Nova的Cell

       F版和G版中的AvailabilityZone

---------------------------------------------------------------------------

nova-conductor：在G版的nova中，取消了nova-compute的直接数据库访问，主要以下几个原因：

1，安全：

a)     Benefit：因为compute节点通常会运行不可信的用户负载，一旦服务被攻击或用户虚拟机的流量溢出，则数据库会边临直接暴露的风险，增加nova-conductor更加安全。

b)    Limitation：虽然nova-conductor限制了直接DB访问，但compute节点仍然可以通过nova-conductor获取所有节点的虚拟机数据，删除虚拟机等操作。特别是使用E版的multihost，nova-api-metadata和nova-network不能使用nova-conductor。这样计算节点仍然是不安全地。

2，方便升级：

a)     Benefit：将nova-compute与数据库解耦的同时，也会与模式（schema）解耦，因此就不会担心就的代码访问新的数据库模式。

b)    Limitation：目前rolling upgrade在G版并不ready

3，性能：

a)     Benefit：当使用green thread时，所有的DB访问都是阻塞的。而如果使用nova-conductor，可以多线程使用RPC访问。

b)    Limitation：通过rpc访问nova-conductor会受网络时延影响。同时，nova-conductor的DB访问也是阻塞的，如果nova-conductor实例较少，效果反而会更差。

目前，nova-conductor暴露的方法主要是数据库访问，但后续从nova-compute移植更多的功能，让nova-compute看起来更像一个没有大脑的干活者，而nova-conductor则会实现一些复杂而耗时的任务，比如migration（迁移）或者resize（修改虚拟机规格）。

 

参考：Grizzly中的nova-conductor

 ---------------------------------------------------------------------------

虚拟机创建时与网络的交互

 

参考：创建虚拟机时与Quantum的交互（F版）

 ---------------------------------------------------------------------------

关于nova中虚拟机的三个操作：forcedelete,delete(soft delete),restore.相关配置项:reclaim_instance_interval

1.    delete(soft delete)

如果配置了reclaim_instance_interval,则讲虚拟机“假删除”，状态置为soft_delete，底层不会真正删除。但过了reclaim_instance_interval表示的时间（单位是秒），用户没有触发restore操作，虚拟机就会被自动删除。

如果没有配置，则虚拟机就被彻底删除。

2.    restore

用来回退状态为soft_delete的虚拟机，只要虚拟机还没有被自动删除

3.    force delete

无视reclaim_instance_interval配置，直接将虚拟机彻底删除。

参考：Nova中的delete和restore

 ---------------------------------------------------------------------------

Nova中的rebuild，evacuate，resize，migrate，liva-migration

rebuild：类似于重装系统的过程，原先是windows，想要更换linux，用rebuild。实现上，就是在虚拟机所在的host上，将原来的虚拟机删除，再根据新的镜像创建新的虚拟机，实现虚拟机系统盘的变更，而用户盘的数据是不变的，虚拟机的网络信息也不变。

 

evacuate：虚拟机所在的host宕机，用evacuate讲虚拟机在另外一个host上启起来。（利用这个接口配合host监控工具，可以实现虚拟机的HA能力）。Evacuate和rebuild的底层实现是一样的。区别在于：1、rebuild需要多做一步删除虚拟机的操作，而evacuate是直接创建新虚拟机。2、rebuild使用的竟像是接口指定的新的镜像（可以与老镜像相同），而evacuate使用的是虚拟机原来的镜像。

 

migrate/resize:在虚拟机active和stopped状态下可以进行migrate/resize，两者的区别是在迁移的同时，改变虚拟机的flavor。配置项allow_resize_to_same_host表示是否允许迁移到本机，默认是False。

 

os-migrateLive：migrate操作会先将虚拟机停掉，也就是所谓的“冷迁移”，而os-migrateLive是“热迁移”，虚拟机不会停机。live-migration是在虚拟机active状态下的操作，且不允许热迁移到本机。

热迁移步骤：

1、 准备libvirt开启tcp监控

2、 Scp镜像文件和console.log以及其他文件到目标主机

3、 迁移 virsh migrate vm_name --live qemu+ssh://intent_ip/system --copy-storage-inc 

4、 清理源节点

 

参考：基于libvirt的虚机热迁移

         Nova中的rebuild和evacuate

         nova resize修改实例配置报错的解决办法

         Nova中的migrate/resize/live-migration

---------------------------------------------------------------------------