【云计算学习笔记（十九）】之Nova服务架构与执行流程详解

本文章由公号【开发小鸽】发布！欢迎关注！！！

老规矩–妹妹镇楼：

一．Nova服务

（一）Nova架构

1.架构图

       Nova的架构非常复杂，包含很多组件，这些组件以后台守护进程的方式运行。架构图如下所示：：

2.组件介绍

（1）API

1) nova-api

       接受和响应客户的API调用，除了接受OpenStack自己的API，还支持Amazon EC2 API，也就是说nova-api兼容EC2 API。

（2）Compute Core

1) nova-scheduler

       虚拟机调度服务，该组件负责决定应该在哪个计算节点上运行虚拟机。

2) nova-compute

       该组件是管理虚拟机的核心服务，通过调用Hypervisor API实现虚拟机的生命周期管理。

3) Hypervisor

       计算节点上跑的虚拟化管理程序，是虚拟机管理最底层的程序。不同的虚拟化技术提供自己的Hypervisor，常用的有KVM, Xen, VMware等。

4) nova-comductor

       计算节点经常需要更新数据库，比如更新虚拟机的状态，处于安全性和伸缩性的考虑，nova-compute并不会直接访问数据库，而是将这个任务交给nova-conductor。

（3）Console Interface

1) nova-console

       用户可以通过多种方式访问虚机的控制台：

nova-novncproxy:基于Web浏览器的VNC访问；

nova-spicehtml5proxy:基于HTML5浏览器的SPICE访问；

nova-xvncproxy:基于Java客户端的VNC访问；

2) nova-consoleauth

       该组件负责对访问虚机控制台的请求进行Token认证。

3) nova-cert

       提供x509证书支持。

（4）Database

       Nova有一些数据需要存放在数据库中，一般使用Mysql。数据库一般安装在控制节点上，Nova服务使用的数据库名称为nova。

（5）Message Queue

       由于Nova包含众多的子服务，这些子服务之间需要相互协调和通信，为了解耦各个子服务，Nova通过Message Queue作为子服务的信息中转站，默认是RabbitMQ。

3.nova组件的物理部署方案

       Nova的组件会部署在两类节点上：计算节点和控制节点。

计算节点：Hypervisor（运行着虚拟机）以及nova-compute；

控制节点：nova-scheduler,nova- conductor, nova-consleauth, nova-cert, nova-api, nova-novncpoxy, nova-compute, my-server（消息队列）, mysqld（Mysql服务端）

4. nova子服务的协同工作

（1）客户向nova-api发送请求，请求创建虚拟机；

（2）nova-api对请求作出处理后，向mq发送消息“让scheduler创建虚机”；

（3）nova-scheduler从mq中获取到API发送给它的消息，然后执行调度算法，从若干个计算节点中选出节点A；

（4）noav-scheduler向mq发送消息“在节点A上创建虚拟”；

（5）计算节点A的nova-compute从mq中获取到nova-scheduler发给它的消息，然后在本节点的Hypervisor上启动虚拟机；

（6）在虚拟机创建的过程中，计算节点A的nova-compute如果需要查询或更新数据库消息，会通过mq向nova-conductor发送消息，nova-conductor负责数据库访问。

（二）Nova组件介绍

1.nova-api

       nova-api是整个Nova组件的门户，所有对Nova的请求都首先经由nova-api处理。nova-api向外暴露若干个HTTP REST API的接口。在Keystone中我们可以查询nova-api的endpoints，客户端可以将请求发送到endpoints指定的地址，向nova-api请求操作。只要是和虚拟机生命周期相关的操作，nova-api都可以响应。

2.nova-scheduler

（1）flavor

       创建Instance时，用户会提出资源需求，如CPU，内存，磁盘各需要多少，OpenStack会将这些需求定义在flavor中，用户只需要指定使用哪个flavor就可以了。Flavor中定义了VCPU，RAM，DISK和Metadata这四类细节，nova-scheduler会按照flavor来选择合适的计算节点。

（2）nova-scheduler的参数配置

       在/etc/nova/nova.conf中，nova通过schedulerdriver, scheduleravailable_filters和schedulerdefaultfilters这三个参数来配置nova-scheduler。

（3）Filter Scheduler

       Filter Scheduler是nova-scheduler默认的调度器，调度过程分为两步：

       通过过滤器filter选择满足条件的计算节点（nova-compute）；

       通过权重计算（weighting）选择最大权重的计算节点上创建Instance；

       Nova允许使用第三方的scheduler，配置scheduler_driver即可。

（4）Filter

       当Filter scheduler需要进行调度操作时，会让filter对计算节点进行判断，返回True或False。

       nova.conf中的scheduleravaiablefilters选项用于配置scheduler可用的filter，默认所有nova自带的filter都可以用于过滤操作。

       另一个选项schedulerdefaultfilters，用于指定scheduler真正使用的filter。有如下的filter：

1)RetryFilter

       作用是刷掉之前已经调度过的节点。这种过滤器是为了防止一个被分配的计算节点操作失败，通过RetryFilter可以直接过滤掉失败的节点，避免操作再次失败。

2)AvailabilityZoneFilter

       为了提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中。OpenStack默认有一个Nova的Availability Zone，所有的计算节点初始都放在Nova空间中。创建Instance时，可以指定将Instance部署到指定的Availability Zone中。
AvailabilityZoneFilter会将不属于指定Availability Zone的计算节点过滤掉。

3)RAMFilter

       RamFilter将不能满足flavor内存需求的计算节点过滤掉。注意，为了提高系统的资源使用率，计算节点的可用内存是允许overcommit的，即可以超过实际内存大小，nova.conf中通过ramallocationratio控制，默认值是1.5。

4)DiskFilter

       DiskFilter将不能满足flavor磁盘需求的计算节点过滤掉。同样磁盘也允许overcommit，通过nova.conf中的diskallocationratio控制，默认值是1。

5)CoreFilter

       CoreFilter将不能满足flavor VCPU需求的计算节点过滤器，VCPU同样允许overcommit，通过nova.conf的cpuallocationration控制，默认值是16。

6)ComputeFilter

       ComputeFilter保证只有nova-compute服务正常工作的计算节点，才能够被nova-scheduler调度。

7)ComputeCapabilitiesFilter

       该过滤器根据计算节点的特性来筛选，如计算节点的架构是X86还是ARM的，这些都是通过该过滤器过滤的。

8)ImagePropertiesFilter

       该过滤器根据所选Image的属性来筛选匹配的计算节点，如Image指定运行在某种Hypervisor，这都是根据Image的Metadata来过滤的，如果Image没有设置Metadata，该过滤器就不会起作用。

（5）Weight

       经过一堆过滤器的过滤后，nova-scheduler选出了能够部署instance的计算节点，再通过weight来对每个计算节点打分，打分最高的获胜。nova-scheduler默认的计算权重策略是通过计算节点空闲的内存量计算权重值，空闲内存越多，权重越大。

（6）scheduler日志

       整个调度过程都记录在nova-scheduler日志中了，在/var/log/nova/scheduler.log中。如果要查询debug日志，就需要在/etc/nova/nova.conf中打开debug选项。

3.nova-compute

（1）Hypervisor

       nova-compute在计算节点上运行，负责管理节点上的instance，nova-compute与Hypervisor一起实现OpenStack对instance生命周期的管理。nova-compute为不同的Hypervisor定义了统一的接口，Hypervisor只需要实现这些接口，就可以以Driver的形式直接插入到OpenStack系统中。
       在计算节点nova-compute的配置文件/etc/nova/nova.conf中配置所对应的compute_driver，如KVM配置的是Libvirt的driver。

（2）nova-compute功能

       nova-compute的功能分为两类：

1)定时向OpenStack报告计算节点的状态

       要得到计算节点的资源使用情况，需要知道当前节点上所有instance的资源占用信息，这些都是通过Hypervisor的driver驱动获取instance的资源信息。

2)实现instance生命周期的管理

       OpenStack对instance的操作都是通过nova-compute实现的，包括instance的启动，停止，重启，暂停，恢复，终止，迁移，快照。
当nova-scheduler选定了部署instance的计算节点之后，会通过RabbitMQ向选定的计算节点发出启动实例的命令，该计算节点上的nova-compute收到消息后会执行instance创建操作。

（3）nova-compute创建instance的步骤

分为四步：

1)为instance准备资源；

       nova-compute首先会根据指定的flavor依次为instance分配内存，磁盘空间和VCPU和网络资源。

2)创建instance的镜像文件；

       资源准备好之后，nova-compute会为instance创建镜像文件。首先选择一个Glance中的Image，检查计算节点中是否已有该Image，如果没有则从Glance下载到计算节点中，然后将其作为backing file创建instance的镜像文件。镜像文件是通过qemu-img命令从Image中创建的，注意，镜像文件是instance启动盘对应的文件，而Image是Glance上保存的模板，即instance运行的模板。

3)创建instance的XML定义文件；

       创建instance的XML定义文件。

4)创建虚拟网络并启动虚拟机；

       为instance创建虚拟网络设备之后，就可以启动instance了。

4.nova-conductor

       由于nova-compte需要获取和更新数据库中instance的信息，但是nova-compute并不会直接访问数据库，而是通过nova-conductor实现数据库访问。这样能够保证数据库的访问安全，以及更好的系统伸缩性，对于高并发的数据库访问请求，可以通过配置nova-conductor集群来分摊访问压力。

（三）Nova 操作详解

a)常规操作

1.Launch

       启动一个实例，通过nova-api，nova-scheduler，rabbitmq，nova-compute，nova-conductor来协调。
（1） 向nova-api发送请求；

（2） nova-api向RabbitMQ发送消息；

（3） nova-scheduler从RabbitMQ获取消息，执行调度选出节点；

（4） nova-scheduler向RabbitMQ发送消息；

（5） 节点的nova-compute从rabbitMQ中获取消息，通过本节点的Hypervisor Driver创建Instance；

2.Shut Off

停止一个实例 。

（1） 向nova-api发送请求；

（2） nova-api向RabbitMQ发送消息；

（3） 节点的nova-compute从rabbitMQ中获取消息，停止Instance；

3.Start

生成一个新的实例。

（1） 向nova-api发送请求；

（2） nova-api向RabbitMQ发送消息；

（3） 节点的nova-compute从rabbitMQ中获取消息之后，开始启动，准备虚拟网卡，准备Instance的XML文件，准备Instance的镜像文件，最后启动Instance；

4.Soft/Hartd Reboot

两种重启方式
（1） soft reboot
重启操作系统，整个过程中，Instance依然处于运行状态。

（2） hard reboot
重启Instance，相当于关机后再开机。

5.Lock/Unlock

       为了避免误操作，可以锁定Instance，通过解锁（Lock）操作恢复正常。Lock/Unlock操作都是在nova-api中进行的，操作成功后，nova-api会更新Instance加锁的状态，执行其他操作时，nova-api根据加锁状态来判断是否允许操作。

6.Terminate

删除Instance。
（1） 向nova-api发送请求；

（2） nova-api向RabbitMQ发送消息；

（3） 节点的nova-compute从rabbitMQ中获取消息，关闭Instance，删除Instance的镜像文件，释放虚拟网络等其他资源；

7.Pause/Resume

       短时间暂停Instance，通过Pause操作将Instance的状态保存到宿主机的内存中，当需要恢复时，执行Resume操作，从内存中读回Instance的状态，然后继续运行Instance。
（1） 向nova-api发送请求；

（2） nova-api向RabbitMQ发送消息；

（3） 节点的nova-compute从rabbitMQ中获取消息，暂停Instance后，Instance的状态变为Paused；

8.Suspend/Resume

       长时间暂停Instance，可以通过Suspend操作将Instance的状态保存到宿主机的磁盘上，当需要恢复的时候，执行Resume操作，从磁盘中读回Instance的状态，继续运行。Instance被Suspend后的状态是Shut Down。

9.Snapshot

       有时候操作系统损坏地很严重，无法通过Rescue操作恢复，因此考虑使用备份恢复。Nova的备份操作为Snapshot，工作原理是对Instance的镜像文件（系统盘）进行全量备份，生成一个类型为snapshot的Image，然后将其保存在Glance上。

（1） 向nova-api发送请求；

（2） nova-api向RabbitMQ发送消息；

（3） 节点的nova-compute从rabbitMQ中获取消息，暂停Instance，对Instance的镜像文件做快照，恢复Instance，将快照上传到Glance中。

10.Resize

       Resize操作是用于调整Instance的VCPU，内存和磁盘资源大小的，即为Instance选择新的flavor。通过nova-scheduler重新为Instance选择一个合适的计算节点，如果选择的节点与当前的节点不是同一个，那么就需要做Migrate操作。

b）计划内的故障处理（系统升级，更换硬件）

1.Sleve

       当Instance被Suspend后虽然处于Shut Down的状态，但是Hypervisor依然在宿主机上为其预留了资源，以便能够成功Resume。如果希望释放这些资源，可以使用Shele操作，它会将Instance作为Image保存到Glance中，然后在宿主机上删除该Instance。

（1） 向nova-api发送请求；

（2） nova-api向RabbitMQ发送消息；

（3） 节点的nova-compute从rabbitMQ中获取消息，关闭Instance，然后对Instance指定snapshot操作，成功后，snapshot生成的Image会保存在Glance中，最后删除Instance在宿主机上的资源；

2.Unshelve

       通过Unshelve操作恢复被Shelve的Instance。它的操作其实就是通过Glance中保存的Image启动一个新的Instance，同时nova-scheduler也会调度合适的计算节点来创建该Instance。

3.Migrate

       Migrate操作的作用是将Instance从当前的计算节点迁移到其他的节点上，Migrate操作不要求源节点和目标节点共享存储，但是必须满足一个条件，就是计算节点之间需要配置nova用户无密码访问。

（1） 只能由Admin用户向nova-api发送请求；

（2） nova-api向RabbitMQ发送消息；

（3） nova-scheduler收到消息后，会为Instance选择合适的计算节点，然后通知计算节点迁移Instance；

（4） 源节点的nova-compute从rabbitMQ中获取消息，关闭Instance，然后将Instance的镜像我传送到目标节点上。nova-compute尝试通过ssh在目标节点上的Instance目录里touch一个临时文件，然后关闭Instance，将Instance镜像文件通过scp传送到目标节点；（注意，跨节点复制文件时，必须保证nova-compute进程的启动用户能够在计算节点之间无密码访问）

（5） 在目标节点上启动Instance，过程与lauch Instance非常类似；

（6） 此时的Instance处于“Confirm or Revert Resize/Migrate”状态，需要用户确认或退回当前的迁移操作。

（7） 当按下Confirm按钮后，源计算节点会删除Instance的目录，并在Hypervisor上删除Instance；

（8） 当按下Revert按钮后，在目标节点上关闭Instance，删除Instance没目录，并在Hypervisor上删除Instance，在源节点上启动Instance即可。

4.Live Migrate

       Migrate操作会将Instance停止，即冷迁移。Live Migrate是热迁移，Instance不会停机。Live Migrate分为两种：
（1） 源和目标节点没有共享存储，Instance在迁移的时候需要将其镜像文件从源节点传到目标节点，这叫块迁移；

（2） 源和目标节点共享存储，Instance的镜像文件不需要迁移，只需要将Instance的装填迁移到目标节点；

源和目标节点需要满足一定的条件才能实现Live Migrate：
（1） 源和目标节点的CPU类型一致；

（2） 源和目标节点的Libvirt版本一致；

（3） 源和目标节点能够互相识别对方的主机名称，如在/etc/hosts中加入对方的条目；

（4） 在源和目标节点的/etc/nova/nova.conf中指明在线迁移时使用 TCP协议；

（5） 由于Instance使用config driver保存其metadata，因此在块迁移的过程中，该config driver也需要迁移到目标节点，由于目前的libvirt只支持vfat类型的config driver，所以必须在/etc/nova/nova.conf指出lauch instance时创建vfat类型的config driver；

（6） 源和目标节点的libvirt TCP远程监听服务需要打开；

       共享存储有多种方式实现，如NFS服务器，NAS服务器，分布式文件系统都可以实现。不需要传输镜像文件，只需要传输Instance的状态，速度比块迁移快很多。

c）计划外的故障处理（文件损坏，硬件故障）

1.Rescue/Unrescue

       当操作系统故障时，无法重启，我们可以使用一张系统盘先将系统引导起来，然后再尝试恢复，这种处理方式适用于不太严重的故障，称为Rescue。
       Rescue用指定的Image作为启动盘引导In斯坦猜测，将Instance本身的系统盘作为第二个磁盘挂载到操作系统上。

（1） 向nova-api发送请求，nova默认使用Instance部署时使用的Image；

（2） nova-api向RabbitMQ发送消息；

（3） 节点的nova-compute从rabbitMQ中获取消息，关闭Instance，通过Image创建新的引导盘，命名为disk.rescue，启动Instance。当Rescue执行成功后，可以通过virsh edit< instance >查看Instance的XML文件，可以看到disk.rescue是启动盘vda，原始的启动盘disk是第二个磁盘vdb。
修复完毕后，使用Unrescue操作从原启动盘重新引导Instance。

2.Rebuild

       Rebuild操作可以恢复snapshot，用snapshot替换当前Instance的镜像文件，同时保持Instance的其他，诸如网络，资源分配属性不变。

（1） 向nova-api发送请求，选择用于恢复的Image；

（2） nova-api向RabbitMQ发送消息；

（3） 节点的nova-compute从rabbitMQ中获取消息，关闭Instance，下载新的Image，并准备Instance的镜像文件，启动Instance；

3.Evacuate

       宿主机损坏，怎样恢复宿主机上的Instance。通过Evacuate操作，在nova-compute无法工作的情况下将节点的Instance迁移到其他的计算节点上，前提是Instance的镜像文件必须放在共享存储上。

（四）OpenStack日志阅读

       OpenStack的日志记录了详细的信息，对于我们排错有很大的帮助。

1.目录位置

       对于非devstack安装的OpenStack，日志一般放在/var/log/xxx目录下。

2.日志格式

       OpenStack的日志格式都是统一的，如下所示：
       <时间戳><日志等级> <日志内容> <源代码位置>
       日志戳：日志记录的时间；

       日志等级：有INFO，WARNING，ERROR，DEBUG；
       Request ID：每个操作都会被分配唯一的Request ID，便于查找；

       日志内容：日志的主体，记录当前执行的操作和结果；

       源代码位置：日志代码的位置，包括方法名称，源代码文件的目录位置和行号；

3.查看日志

       首先需要掌握OpenStack的运行机制，才能针对性地查看日志，不然日志内容太多容易让人眼花缭乱。分析清楚一个操作的运行流程，然后再到相应的节点上查看日志。

       可以先确定大的范围，如在操作之前用tail -f 打印日志文件，这样需要查看的日志一定在操作之后打印的内容中；

       另外也可以通过时间戳来确定需要的日志范围；