Nova服务详解

# Nova服务详解 Nova是最后讲解的组件，是因为它所依赖的其他服务，像存储、网络、镜像等都在前面已经详细讲解过了，启动一个虚拟机所需要的资源也都已经准备好了，然后我们再来详细看OpenStack中对虚拟机进行管理的组件Nova。

Nova是用来对虚拟机进行全生命周期的管理，包括虚拟机的创建、维护、销毁等等，Nova也是OpenStack项目中最早的核心项目。在之前的项目中也提到，像Cinder、Neutron、Placement服务都是从早期的Nova服务中独立出去的。当这些功能都独立出去以后，Nova就变成了一个更加专注的项目，专注于统一的计算资源抽象和管理。资源可以是虚拟机、物理机。物理机的管理现在抽取出来归属于独立的Ironic项目，因此Nova现在只专注于虚拟机的管理。

# Nova体系架构 Nova是由多个不同的组件组成，外部通过API接口和它进行交互，nova内部则通过RPC接口进行通信，同时还需要外部数据库来存储虚拟机的相关信息。它的基本体系架构如下图所示：

从图上可以看到，目前Nova的主要组件有API、Conductor、Scheduler、Compute，前三个是部署在控制节点上，最后一个Compute组件主要是部署在计算节点上。

# Nova和Ceph的对接 nova组件也可以和Ceph集群对接，直接使用Ceph的存储池来存放虚拟机的系统盘，可以保证在计算节点故障的时候，能够快速在其他计算节点中重建虚拟机，这也是为什么云存储在OpenStack上最终占据主导地位的原因。

nova和Ceph对接的配置

先在计算节点上安装好ceph-common工具，因为nova需要利用这个工具里提供的命令来挂载ceph 存储到虚拟机上，安装命令是：

yum install ceph-common

1然后在Ceph节点上获取cinder keyring文件的一个临时副本：

ceph auth get-key client.cinder | ssh {your-compute-node} tee client.cinder.key

1这个命令会把这个副本密钥文件client.cinder.key发送到计算节点上。然后在计算节点上生成一个uuid，命令是：

uuidgen

1生成的uuid如下所示：

f1ce6a51-d46b-4af0-88d2-593d45edd899

1然后在计算节点上编译一个secret.yml文件，内容如下：

f1ce6a51-d46b-4af0-88d2-593d45edd899

client.cinder secret

123456然后定义一个secret，命令是：

sudo virsh secret-define --file secret.xml

1它会提示创建成功了一个secret，并生成了一个secret uuid。

Secret f1ce6a51-d46b-4af0-88d2-593d45edd899 created

1然后我们将它设置为一个固定的键值对：

sudo virsh secret-set-value --secret f1ce6a51-d46b-4af0-88d2-593d45edd899 \

--base64 $(cat client.cinder.key) && rm client.cinder.key secret.xml

12设置成功后删除临时的keyring文件和secret.xml文件，这里的操作实际上就是把uuid和认证文件的key绑定到一起。

你在实际测试过程中的uuid值可能不一样，替换为你自己的uuid值即可。

修改/etc/nova/nova.conf文件，添加下面的配置：

[libvirt]

images_rbd_pool=vms

images_type=rbd

images_rbd_ceph_conf=/etc/ceph/ceph.conf

rbd_user = cinder

rbd_secret_uuid = f1ce6a51-d46b-4af0-88d2-593d45edd899

123456修改完成后，重启nova服务，命令是：

systemctl restart openstack-nova-compute

1重启完成后，新建的虚拟机默认系统盘就会在Ceph集群上了，可以创建一个虚拟机测试一下。

# Cells V2 Cell这个概念实际上也是用来隔离资源的一个抽象逻辑概念，目的是为了在计算节点数据太多时，为了避免单个数据库和消息队列的压力过大，通过cell把计算节点分隔到不同的组里，每个组对接单独的数据库和消息队列，以降低单个数据库和消息队列的压力，提高整个OpenStack集群的稳定性和各个组件的响应速度。

我们之前部署的一主一从架构就是单个cell架构，单个cell的架构图如下所示：

多cell架构图如下所示

和单cell架构相比，从图中我们可以看到，多cell架构使用cell的概念把不同的计算节点隔离开来，每个独立的cell中都有独立的：

nova-conductor，负责和db以及上层的super-conductor交互 Cell Database，负责存储单个Cell中所有计算节点的信息 Cell MQ，负责处理单个Cell内组件的消息队列并和上级的nova-api、super-condutor交互，传递控制消息。

super conductor负责调度所有的Cell中的nova-conductor。 # nova虚拟机管理常见的虚拟机管理操作有以下这些：

# 冷迁移、规格调整和热迁移迁移指的是把虚拟机从一台计算节点转移到另外一个计算节点的操作，分为冷迁移和热迁移两种方式，冷迁移比较好理解，就是迁移的过程中虚拟机处于关机或者挂起的状态，而热迁移则是迁移过程虚拟机一直处于可用状态。不管是冷迁移还是热迁移，都会受到一些条件的制约，常见的有：

迁移前后的计算节点硬件规格是否一样，计算节点硬件不同时，支持的硬件特性也不一样，特别是CPU的兼容性，一些新CPU支持的指令集在旧CPU上并不支持，因此在新CPU机器上启动的虚拟机迁移到使用旧CPU的机器上可能会失败。相对来说冷迁移的实现要更简单一点，特别是Nova组件对接了后端云存储时，它的基本流程就是：

计算节点获取实例的磁盘、网络信息；在新的计算节点上调用nova-compute服务启动一个实例

把云存储上的rbd文件映射到本地并启动虚拟机绑定之前的网络端口到这个实例上让IP地址保持变。

虚拟机启动成功后即完成了冷迁移操作。规格调整和冷迁移操作类似，首先根据规格调整操作过程中选择的新实例规格信息（通常新实例规格要比旧实例规格要大，例如CPU数量、内存数量、硬盘空间），然后在选择的计算节点上使用新的实例规格信息创建出新的实例，创建新实例的过程中还会调用后端云存储的API对RBD文件进行扩容，然后虚拟机启动以后调用cloud-init工具对磁盘进行扩容。

# 热迁移热迁移指的是把一个正常工作的虚拟机迁移到另外的计算节点上，常见的场景有

监控组件发现这个实例所在物理机出现了硬件或者不可修复的软件故障需要停机修复部分节点资源使用率比较低，需要调整计算节点资源负载以节省资源

为了避免虚拟机受到影响，需要提前把虚拟机迁移出去。热迁移操作的主要难点是需要保证两个实例的数据一致性，因此在迁移过程中需要不断的把旧实例的内存数据拷贝到新实例上，因此需要判断底层的硬件性能（例如网卡带宽、PCI设备带宽）是否足够支撑热迁移，如果旧实例业务比较繁忙，特别是IO密集型操作，那么产生内存脏页数据的速度远大于迁移的速度，就会导致迁移失败。

同时热迁移最后一部分内存数据拷贝时，会把旧实例短暂挂起，完成最后一份内存脏数据的拷贝，此时旧实例会出现短暂的无法响应状态，因此如果实例上运行的业务属于IO敏感型的，那么可能会出现短暂的业务不可用情况。

# 重建和疏散重建操作比较好理解，类似于重装操作系统，一般在需要清除虚拟机上的所有系统配置的时候，使用这个命令直接重建虚拟机，和手机恢复出厂设置操作一样。

重建的流程也比较简单：

使用镜像创建一个新的实例实例启动过程中调用cloud-init工具注入实例元数据把旧实例的网络端口绑定到新实例上销毁旧实例

疏散这个操作从字面意思上理解，就是从当前节点撤离，一般在物理计算节点故障的时候使用，同时还要求虚拟机的系统盘和数据盘都使用网络存储才能够进行这个操作，这个时候nova会自动从正常工作的节点中选择一个新的节点来启动这个虚拟机。 # 虚拟机启动的完整流程虚拟机启动流程开始部分和正常的物理机启动流程一样，唯一的区别在于启动完成后，cloud-init组件开始工作，这个组件会帮助完成一系列的初始化动作，例如：

获取虚拟机元数据获取网络配置获取用户注入信息执行初始化脚本

等等操作。 # 虚拟机metadata获取流程虚拟机路由->dhcp-agent -> haproxy -> metadata_proxy -> metadata_agent -> nova_metadata虚拟机启动过程中，dhcp-agent会向虚拟机中注入一条特殊路由，通常是：

169.254.169.254 192.168.116.150 255.255.255.255 UGH 1002 0 0 eth0

1这个路由的目标地址通常是dhcp-agent的地址，如果dhcp-agent没有向虚拟机里注入特殊路由，则后面会提示no active metadata service.

虚拟机启动后，cloud-init工具会向下面这个地址请求主机的元数据：

http://169.254.169.254/1.0/meta-data

1根据上面的路由规则，这个请求就会转发到dhcp-agent，而每个dhcp-agent都有一个自己独立的namespace，在控制节点上查看当前的网络名称空间如下所示：

ip netns

qdhcp-5c77a782-7534-45de-ba22-056ea7238d34 (id: 0)

12qdhcp-开头的就是dhcp-agent的网络名称空间，我们查看这个名称空间的路由信息：

ip netns exec qdhcp-5c77a782-7534-45de-ba22-056ea7238d34 route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

0.0.0.0 192.168.116.2 0.0.0.0 UG 0 0 0 ns-77c85b7e-d2

169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 ns-77c85b7e-d2

192.168.116.0 0.0.0.0 255.255.255.0 U 0 0 0 ns-77c85b7e-d2

123456可以看到，请求路由到dhcp-agent后，是通过ns-77c85b7e-d2这个网卡出去的，然后我们看一下网卡

和IP信息：

ip netns exec qdhcp-5c77a782-7534-45de-ba22-056ea7238d34 ip ad

1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen

1000

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo