1、       nova-compute 在计算节点上运行,负责管理节点上的 instance。

OpenStack 对 instance 的操作,最后都是交给 nova-compute 来完成的。

nova-compute 与 Hypervisor 一起实现 OpenStack 对 instance 生命周期的管理。

———————————————————————————————————————————————————————————————————————————

2、nova-compute 的功能可以分为两类:

  1. 定时向 OpenStack 报告计算节点的状态(通过hypervisor来获取主机资源信息)

  2. 实现 instance     生命周期的管理·

 

3、虚拟机创建

nova-compute 创建 instance 的过程可以分为 4 步:

  1. 为 instance 准备资源(根据规格flavor准备内存,cpu,硬盘等)

  2. 创建 instance 的镜像文件(通过glance下载image并创建instance的镜像文件)

  3. 创建 instance 的 XML 定义文件

  4. 创建虚拟网络并启动虚拟机

——————————————————————————————————————————————————————————————————————————

4、日志查看:

每个操作都被分配唯一的Request ID,且夸文件

 

OpenStack 的日志格式都是统一的,如下

<时间戳><日志等级><代码模块><RequestID><日志内容><源代码位置>

简单说明一下
时间戳       日志记录的时间,包括 年 月 日 时 分 秒 毫秒
日志等级          有INFO WARNING ERRORDEBUG等
代码模块          当前运行的模块Request ID     日志会记录连续不同的操作,为了便于区分和增加可读性,每个操作都被分配唯一的Request ID,便于查找
日志内容          这是日志的主体,记录当前正在执行的操作和结果等重要信息
源代码位置日志代码的位置,包括方法名称,源代码文件的目录位置和行号。这一项不是所有日志都有

下面举例说明

2015-12-10 20:46:49.566 DEBUG nova.virt.libvirt.config [req-5c973fff-e9ba-4317-bfd9-76678cc96584None None] Generated XML('<cpu>\n  <arch>x86_64</arch>\n <model>Westmere</model>\n <vendor>Intel</vendor>\n  <topologysockets="2" cores="3" threads="1"/>\n  <featurename="avx"/>\n  <feature name="ds"/>\n <feature name="ht"/>\n  <featurename="hypervisor"/>\n  <featurename="osxsave"/>\n  <featurename="pclmuldq"/>\n  <featurename="rdtscp"/>\n  <feature name="ss"/>\n <feature name="vme"/>\n  <featurename="xsave"/>\n</cpu>\n',)  to_xml/opt/stack/nova/nova/virt/libvirt/config.py:82

这条日志我们可以得知:

  1. 代码模块是 nova.virt.libvirt.config,由此可知应该是 Hypervisor Libvirt 相关的操作

  2. 日志内容是生成 XML

  3. 如果要跟踪源代码,可以到 /opt/stack/nova/nova/virt/libvirt/config.py 的 82 行,方法是 to_xml

5、Suspend 和 Pause 操作做个比较:

相同点
两者都是暂停 instance 的运行,并保存当前状态,之后可以通过 Resume 操作恢复

不同点
1.   Suspend 将 instance 的状态保存在磁盘上;Pause 是保存在内存中,所以 Resume 被 Pause的 instance 要比 Suspend 快。

2.   Suspend 之后的 instance,其状态是 Shut Down;而被 Pause 的 instance 状态是Paused。

3.   虽然都是通过 Resume 操作恢复,Pause 对应的 Resume 在OpenStack 内部被叫作 “Unpause”;Suspend对应的 Resume 才是真正的 “Resume”。这个在日志中能体现出来。

6、Nova 虚拟机快照(snapshot)

暂停Instance à对Instance的镜像文件创建快照à恢复Instanceà将快照(snapshot)上传到Glance上

 

7、恢复故障虚拟机(Rebuild Instance)

RebuildInstance 会用snapshot替换Instance当前的镜像文件,并且保持该Instance的其他资源属性不变

流程:

Rebuild请求à关闭当前Instanceà下载新的Image,并准备Instance的镜像文件 à启动Instance

 

8、Instance shelve(释放占用的资源)

Instance 被 Suspend 后虽然处于 Shut Down 状态,但 Hypervisor 依然在宿主机上为其预留了资源,以便在以后能够成功 Resume。

如果希望释放这些预留资源,可以使用 Shelve 操作。Shelve 会将 instance 作为 image 保存到 Glance 中,然后在宿主机上删除该 instance。

流程:

接收shelve消息à关闭instanceà对Instance 执行snapshot操作,成功后将snapshot生成的image保存到glance上,命名为<instance name>-shelvedà最后删除 instance 在宿主机上的资源à暂停操作成功执行后,instance 的状态变为 Shelved Offloaded,电源状态是 Shut Down

—————————————————————————————————————————————————————————————————————————————————————

9、Unshelve (相当于用snapshot快照生成的image去重新创建一个与原来的instance一样的虚拟机,故流程与launch instance时一直的)

因为 Glance 中保存了 instance 的 image,unshelve 的过程其实就是通过该 image launch 一个新的 instance,nova-scheduler 也会调度合适的计算节点来创建该 instance。

instance unshelve 后可能运行在与 shelve 之前不同的计算节点上,但 instance 的其他属性(比如 flavor,IP 等)不会改变。

 

10、Migrate 虚拟机迁移

迁移schedule时防止选择源主机的机制:nova-compute 在做 migrate 的时候会检查目标节点,如果发现目标节点与源节点相同,会抛出 UnableToMigrateToSelf 异常。Nova-compute 失败之后,scheduler 会重新调度,由于有 RetryFilter,会将之前选择的源节点过滤掉,这样就能选到不同的计算节点了。

总体思路:

nova-scheduler 发送消息,通知计算节点可以迁移instance 了ànova-compute 执行操作 à源节点的instacne关闭,将instance的镜像文件上传到目的主机

详细流程:

nova-compute 首先会尝试通过 ssh 在目标节点上的 instance 目录里 touch 一个临时文件,如果 touch 失败,说明目标节点上还没有该 instance 的目录,也就是说,源节点和目标节点没有共享存储。那么接下来就要在目标节点上创建 instance 的目录à关闭 instanceà将 instance 的镜像文件通过 scp 传到目标节点上à在目标节点上启动 instance(类似launch)

注:ssh 和scp需要密码验证,各个计算节点之间需要无密码连接,因为后台无法输入密码

11、虚拟机热迁移(Live Migrate):

a、基于共享存储的虚拟机热迁移(instance的镜像文件不需要迁移,只需要将instance的状态迁移到目标节点)

b、基于本地存储的整机热迁移(block Migrate:instance在迁移的时候需要将其镜像文件从源节点传到目标节点)

虚拟机block Migrate

源和目标节点的CPU类型需要一致。

源和目标节点的Libvirt版本要一致。

块迁移(block Migrate)目前只支持vfat类型的config driver 所以在nova-compute.conf中指定config_drive_format=vfat

具体流程:

Api接收消息(live_migrate)à目标节点执行迁移前的准备工作(首先将instance的数据迁移过来,包括镜像文件,虚拟机网络,内存等资源,目标节点会创建Instance目录)à源节点暂停Instance à在目标节点上Resume instance à在源节点上执行迁移后的处理工作,删除instance à在目标节点上创建XML文件,在hyphervisor中定义instance 使之下次可以正常启动。

 

共享存储迁移:

流程:

1、instance在迁移的时候需要将其镜像文件从元节点传到目标节点

 

12、虚拟机系统挂了(rescue)

流程:

Nova rescue 虚拟机名 (默认使用当前instance的image) à使用image创建引导盘 disk.rescue à启动虚拟机 à使用virsh edit 虚拟机名 修改disk.rescue为vda 真正的启动盘修改为vdb

 

13计算节点宕机,nova-compute进程已经挂掉

Rebuild 可以恢复损坏的 instance。

那如果是宿主机坏了怎么办呢? 比如硬件故障或者断电造成整台计算节点无法工作,该节点上运行的 instance 如何恢复呢?

用 Shelve 或者 Migrate 可不可以? 很不幸,这两个操作都要求 instance 所在计算节点的 nova-compute 服务正常运行。幸运的是,还有 Evacuate 操作。

Evacuate可在 nova-compute 无法工作的情况下将节点上的instance 迁移到其他计算节点上。但有个前提: Instance 的镜像文件必须放在共享存储上。

流程:(只能在后台执行

执行命令nova evacuate 主机名--no-shared-storage  à消息下发到nova-api ànova-schedule筛选好主机 ànova-compute分配资源,使用共享存储上的镜像文件à启动instance