Nova 子服务协作流程
image
消息队列使用rabbitMQ：OpenStack组件的各个子服务之间不直接调用，全部通过消息队列异步调用。
数据库使用MySQL：每个OpenStack组件在MySQL中都有自己的数据库。
1. nova api
nova api是nova服务的门户，所有对nova的调用都会经由 nova api 处理。nova api向外界暴露nova服务的HTTP REST api接口。
作为终端用户，不会直接调用api。命令行、dashboard负责调用这些api，进一步封装。
nova api 对 收到的 HTTP api 的处理：
-
检查参数有效性
-
调用nova其他子服务
-
格式化调用结果返回给客户端
OpenStack使用 实例(Instance) 描述虚拟机。
2. nova-scheduler
创建instance时，用户会提出需要多少资源。OpenStack把这些资源需求定义在flavor中，flavor就是一个个资源套餐。
Flavor定义了 VCPU、RAM、DISK和Metadata。
在/etc/nova/nova.conf中，配置三个配置项：schedulerdriver, scheduleravailable_filters, schedulerdefaultfilters。
-
Filter scheduler 是nova-scheduler默认的调度器。
-
通过过滤器(Filter)选择满足条件的计算节点
-
通过权重(Weight)选择在权重最大的计算节点上创建instance
-
-
Filter
scheduleravailable_filters 定义nova可用的过滤器，默认是nova自带的所有过滤器。
schedulerdefaultfilters 则定义实际使用的过滤器。
默认值：
image
-
RetryFilter: 刷掉之前已经调度过的节点
-
AvailabilityZoneFilter: 考虑容灾性和隔离性，将计算节点划分在不同的Zone中。初始时将所有的节点放在默认的nova zone中。
-
RamFilter：将不满足 flavor 内存需求的计算节点过滤掉。OpenStack在计算节点内存时，认定可用内存是实际内存的倍数。
-
DiskFilter：将不满足 flavor 磁盘需求的计算节点过滤掉。同样允许超载。
-
CoreFilter：将不满足 flavor CPU需求的计算节点过滤掉。nova 默认的filters没有包含这个filter。
-
ComputeFilter：将 nova-compute 服务不能正常工作的节点过滤掉。
-
ComputeCapabilitiesFilter: 根据节点的计算特性筛选。
-
ImagePropertiesFilter: 根据镜像属性筛选节点。
-
ServerGroupAntiAffinityFilter：尽量让 instance 散落在不同的计算节点上。
-
ServerGroupAffinityFilter：尽量让 instance 聚集在一个计算节点上。
-
-
Weight
经过第2步的过滤，scheduler过滤出一组符合各个过滤器条件的计算节点。
如何确定最终在哪个节点上创建 instance？ 权重。
节点 i 的权重默认定义为 i 节点空闲的内存量。
空闲内存越多，权重越大，被选中概率越大。
3. nova-compute
nova-compute 和 hypervisor 一起实现 OpenStack 对 instance 的管理。
-
driver 架构支持多种 hypervisor
配置不同的driver， 使用不同的hypervisor。各自的hypervisor实现统一的接口，以driver的形式提供给OpenStack使用。
nova-compute的作用有两个：报告计算节点状态； 管理 instance 生命周期。
-
报告节点状态。nova-compute 通过hypervisor得知节点的资源使用情况，进而发送给OpenStack其他子服务(如 Filters) 使用。
-
管理 instance。
nova 创建 instance 分为4步：
-
按flavor套餐为 instance 准备资源
-
创建 instance的镜像文件，如果没有就从Glance处下载，类似docker镜像的构建过程
-
创建 instance的XML定义文件，类似Dockerfile
-
创建虚拟网络并启动虚拟机，创建NFV(网桥，NAT)
-
-
4. nova-conductor
nova-compute通过 nova-conductor 访问MySQL数据库。
这么做是因为：
-
安全性：如果计算节点的nova-compute 直接访问控制节点上的 MySQL数据库，那么就要在计算节点上存储数据库的连接信息，如果任一计算节点被攻击，数据库位置也就暴露了。因此，compute 通过 conductor 访问MySQL，而conductor部署在控制节点上。
-
伸缩性
compute 与 conductor 通过消息队列通信，允许配置多个 conductor 实例，适应大量或少量数据库访问场景。
5. 日志相关
- devstack日志同一放在
/opt/stack/logs目录下。
image
每个服务都有自己的日志
Nova 以 ”n-“ 开头
Glance 以 “g-”开头
Cinder 以 “c-”开头
Neutron 以 “q-” 开头
-
创建 instance 流程
image
-
软/硬 启动
-
soft reboot 只重启操作系统，instance 仍在运行，相当于 Linux的
reboot命令 -
hard reboot等效于 关机再开机
-
-
Lock/Unlock
被加锁的 instance 不允许执行重启或删除等关键操作。
注： admin用户不受限制，它相当于
root用户。 -
suspend 和 pause比较
pause 是短时间暂停，它把虚拟机状态保存在内存中。
suspend 是长时间暂停，它把虚拟机状态保存在磁盘上。
suspend后 instance 处于 shutdown 状态，但 hypervisor 仍为 instance 保留资源，为实现该 instance 的快速启动。若回收这些资源，使用
Shelve操作。Shelve会将 instance 作为 image 上传到 Glance，然后在宿主机中删除该 instance。Unshelve还原被shelve的 instance。 -
Migrate
Migrate 允许将 instance 从当前计算节点迁移到另一个计算节点。Migrate不要求源节点和目标节点共享存储，要求计算节点间配置ssh无密码访问。
-
Live Migrate
Migrate 执行的是"冷迁移"，把 instance 关掉再迁移。而 Live Migrate 属于热迁移，instance 不会停机。
Live Migrate分两种：
-
源节点和目的节点没有共享存储， image + instance一起迁移。
-
源节点和目的节点共享存储，只需要迁移 instance。
热迁移的条件：
-
源节点和目的节点的CPU类型一致
-
Libvirt 版本一致
-
源节点和目标节点能互相识别对方的主机名
-
源节点和目标节点的
nova.conf中指明热迁移使用 TCP 协议 -
instance 使用 config driver 保存其 metadata
-
源和目标节点的 Libvirt TCP 远程监听服务得打开
-
-
Resize
Resize负责调整 instance 的vCPU、内存和磁盘资源。具体需要多少资源定义在 flavor。
resize 通过选择新的flavor来调整资源的分配。resize的本质是在 migrate 同时选择新的 flavor，而 migrate 是 resize 特例：flavor没有变化的resize。
-
Evacuate
Rebuild 可以修复损坏的 image。
Evacuate 可以在宿主机崩溃，nova-compute 无法工作的情况下将节点上的 instance 迁移到其他计算节点上，实际上在其他计算节点上重建 instance。前提是 image 的镜像文件必须共享存储。
instance 操作总结
image
网友评论