nova组件

闲云野鹤cs

已于 2024-05-24 09:31:22 修改

阅读量2.4k

点赞数 8

文章标签：云计算 linux

于 2022-04-22 23:24:30 首次发布

本文链接：https://blog.csdn.net/ddddddddfeng/article/details/124356618

版权

文章目录

Nova aggregate
Nova schedule
Filters
Nova service-list
Nova conductor
创建虚机过程
- 迁移&&疏散

Nova aggregate

az: availability zone 可用区，在openstack内主要作为容灾使用
AZ没有数据表，不在Nova库中的service表，AZ这个信息可以被创建，这个az信息被放到aggregate中的metadata中，我们平时增删改az,可以通过nova aggregate去修改。
az在openstack中其实是nova-scheduler来决定的，当创建vm（虚机）的时候，会指定一个az, 然后schedule 会在这个az的范围内选一台适合的compute去创建。az是用户可见的，用户手动的来指定vm运行在哪个az上。

root@controller:~# nova boot --image image-id --flavor large --availability-zone zone-name

root@controller:~# nova availability-zone-list #查看现有的availability zone，默认有两个az,当新建了一个az,
\\而没有主机加入，这命令执行完不会显示新建的az
internel: nova服务
nova: 默认计算节点az

root@controller:~# nova aggregate-details AZ#00
| Id | Name    | Availability Zone |Hosts  | Metadata                 |
+----+---------+-------------------+-------+---------------------------
| 1  |         |                   |       |'availability_zone=AZ#00' |
root@controller:~# nova aggregate-list 
+----+---------+-------------------+
| Id | Name    | Availability Zone |
+----+---------+-------------------+
root@controller:~# nova availability-zone-list 
+----------------------------------+----------------------------------------+
| Name                | Status             |
+---------------------+--------------------+
# 将compute节点加入AZ#001（2为AZ id,通过nova aggregate-list 查的）
root@controller:~# nova aggregate-add-host 2 compute 
# 将compute节点移出AZ#001（2为AZ id，通过nova aggregate-list 查的）
root@controller:~# nova aggregate-remove-host 2 compute 
root@controller:~# nova help aggregate-create 
usage: nova aggregate-create <name> [<availability-zone>]
Create a new aggregate with the specified details.
Positional arguments:
  <name>               Name of aggregate.
  <availability-zone>  The availability zone of the aggregate (optional).
#创建aggregate的时候会关联az;一般aggregate-name和az-name一样,也可也不一样
root@controller:~#nova aggregate-create aggregate-name az-name 

comment：创建完aggregate后通过nova availability-zone-list不会显示新创建的az，因为没有主机添加到新的az；
通过nova aggregate-list可以查到自己新建的az

主机一旦加到aggregate中，nova compute 会自动使用aggregate中的az信息，主机会自动关联az

root@controller: nova availability-zone-list 
root@controller: nova service-list
上面两条命令的数据是一样的，nova availability-zone-list的信息是nova service-list重组的

Nova schedule

schedule主要有两个步骤：通过过滤器filter去过滤出有哪些主机符合要求；通过权重weight去做个排序，选择一台主机
虚机调度服务，负责决定在哪个计算节点上运行虚机。创建虚机时，用户会提出资源需求，例如 CPU、内存、磁盘各需要多少。OpenStack 将这些需求定义在 flavor 中，用户只需要指定用哪个 flavor 就可以了

Filters

filters是在/etc/nova/nova.conf下的
scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,DiskFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,
RetryFilter 的作用是刷掉之前已经调度过的节点;eg,例如已经选出3台节点ABC，当最终选择A去操作的时候，执行中由于某种原因，A失败，\\
重新过滤的时候，会把A去除；默认次数为3（nova.conf：scheduler_max_attempts=3）
AvailabilityZoneFilter，提高容灾性和提供隔离服务，可以将计算节点划分到不同的Availability Zone中，先选择az
RamFilter 将内存不满足要求的compute过滤掉
超过的程度是通过 nova.conf 中 ram_allocation_ratio 这个参数来控制的，默认值为 1.5
root@controller:~# cat /etc/nova/nova.conf  | grep -v "^#\|^$" | grep ram_all
ram_allocation_ratio=1.0
其含义是：如果计算节点的内存有 20GB，OpenStack 则会认为它有 30GB（20*1.5）的内存。
DiskFilter 将不满足flavor磁盘需求的计算节点过滤掉（设置在nova.conf 中 disk_allocation_ratio）
CoreFilter 将不满足flavor vCPU需求的计算节点过滤掉（设置在nova.conf 中 cpu_allocation_ratio，默认值为 16）
cpu_allocation_ratio = 16.0
也就是说一个 4 vCPU 的计算节点，nova-scheduler 在调度时认为它有 64 个 vCPU。nova-scheduler 默认使用的 filter 并没有包含 CoreFilter
ComputeFilter 只有 nova-compute 服务正常工作的计算节点才能够被 nova-scheduler调度。
ComputeCapabilitiesFilter 根据计算节点的特性来筛选
例如有x86_64和ARM架构的，如果想将 Instance 指定部署到 x86_64架构的节点上，就可以用ComputeCapabilitiesFilter，应该在flavor中指定
ImagePropertiesFilter 根据所选 image 的属性来筛选匹配的计算节点。image也有 metadata，用于指定其属性。

Nova service-list

root@controller:~# nova service-list
+-----+------------------+-------------------------------+----------+----------+-------+----------------------------+-----------------+
| Id  | Binary           | Host                          | Zone     | Status   | State | Updated_at                 | Disabled Reason |
+-----+------------------+-------------------------------+----------+----------+-------+----------------------------+-----------------+
| 1   | nova-cert        | controller.domain.tld         | internal | enabled  | up    | 2022-04-23T12:57:23.000000 | -               |
这些信息可以去nova库中，services表中去查看--去控制节点登录数据库
Zone\Status\State在表中不存在
Status是指的如nova-compute这个服务是否可用，也就是说是否开启要往这个server调度
States:Up/Down,,这是nova-api去检查的
nova-compute stop/waiting----服务停掉之后，nova服务也是down
当systemctl status rebbitmq-server状态不正常的时候，也会down
当nova-compute所在的server关机，就可以看到Status为disable,并且nova-compute服务也停了，也变成down
当想使nova-compute变成disable，可以通过关闭（shutdown）所在的server,或者通过nova service-disable 
nova service-disable compute-1 nova-compute --reason maintenance
Binary:二进制名； nova-cert    -   
                nova-scheduler  
                nova-consoleauth
                nova-conductor 
mysql> describe services;
+-----------------+--------------+------+-----+---------+----------------+
| Field           | Type         | Null | Key | Default | Extra          |
+-----------------+--------------+------+-----+---------+----------------+
| created_at      | datetime     | YES  |     | NULL    |                |
| updated_at      | datetime     | YES  |     | NULL    |                |
| deleted_at      | datetime     | YES  |     | NULL    |                |
| id              | int(11)      | NO   |     | NULL    |                |
| host            | varchar      | YES  |     | NULL    |                |
| binary          | varchar      | YES  |     | NULL    |                |
| topic           | varchar      | YES  |     | NULL    |                |
| report_count    | int(11)      | NO   |     | NULL    |                |
| disabled        | tinyint(1)   | YES  |     | NULL    |                |
| deleted         | int(11)      | YES  |     | NULL    |                |
| disabled_reason | varchar      | YES  |     | NULL    |                |
| last_seen_up    | datetime     | YES  |     | NULL    |                |
| forced_down     | tinyint(1)   | YES  |     | NULL    |                |
| version         | int(11)      | YES  |     | NULL    |                |
+-----------------+--------------+------+-----+---------+----------------+

Nova conductor

nova-compute 经常需要更新数据库，比如更新和获取虚机的状态。出于安全性和伸缩性的考虑，nova-compute 并不会直接访问数据库，而是将这个任务委托给 nova-conductor。
这样做有两个显著好处：

更高的系统安全性
更好的系统伸缩性

创建虚机过程

Nova 创建虚拟机（VM-instance）过程:
1、用户通过界面或命令行（CLI）通过RESTful API向keystone获取认证信息。
2、keystone通过用户请求认证信息，并生成auth-token返回给对应的认证请求。
3、用户在界面或命令行（CLI）通过RESTful API向nova-api发送一个boot instance的请求（携带auth-token）。
4、nova-api接受请求后向keystone发送认证请求，查看token是否为有效用户和token。
5、keystone验证token是否有效，如有效则返回有效的认证和对应的角色（注：有些操作需要有角色权限才能操作）。
6、通过认证后nova-api和数据库通讯。
7、初始化新建虚拟机的数据库记录。
8、nova-api通过rpc.call向nova-scheduler请求是否有创建虚拟机的资源(Host ID)。
9、nova-scheduler进程侦听消息队列，获取nova-api的请求。
10、nova-scheduler通过查询nova数据库中计算资源的情况，并通过调度算法计算符合虚拟机创建需要的主机。
11、对于有符合虚拟机创建的主机，nova-scheduler更新数据库中虚拟机对应的物理主机信息。
12、nova-scheduler通过rpc.cast向nova-compute发送对应的创建虚拟机请求的消息。
13、nova-compute会从对应的消息队列中获取创建虚拟机请求的消息。
14、nova-compute通过rpc.call向nova-conductor请求获取虚拟机消息。（Flavor）
15、nova-conductor从消息队队列中拿到nova-compute请求消息。
16、nova-conductor根据消息查询虚拟机对应的信息。
17、nova-conductor从数据库中获得虚拟机对应信息。
18、nova-conductor把虚拟机信息通过消息的方式发送到消息队列中。
19、nova-compute从对应的消息队列中获取虚拟机信息消息。
20、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求glance-api获取创建虚拟机所需要镜像。
21、glance-api向keystone认证token是否有效，并返回验证结果。
22、token验证通过，nova-compute获得虚拟机镜像信息(URL)。
23、nova-compute通过keystone的RESTfull API拿到认证k的token，并通过HTTP请求neutron-server获取创建虚拟机所需要的网络信息。
24、neutron-server向keystone认证token是否有效，并返回验证结果。
25、token验证通过，nova-compute获得虚拟机网络信息。
26、nova-compute通过keystone的RESTfull API拿到认证的token，并通过HTTP请求cinder-api获取创建虚拟机所需要的持久化存储信息。
27、cinder-api向keystone认证token是否有效，并返回验证结果。
28、token验证通过，nova-compute获得虚拟机持久化存储信息。
29、nova-compute根据instance的信息调用配置的虚拟化驱动来创建虚拟机。

简单描述nova-*各个子服务之间的协同工作流程
客户（可以是 OpenStack 最终用户，也可以是其他程序）向 API（nova-api）发送请求：“帮我创建一个虚机”
API 对请求做一些必要处理后，向 Messaging（RabbitMQ）发送了一条消息：“让 Scheduler 创建一个虚机”
Scheduler（nova-scheduler）从 Messaging 获取到 API 发给它的消息，然后执行调度算法，从若干计算节点中选出节点 A
Scheduler 向 Messaging 发送了一条消息：“在计算节点 A 上创建这个虚机”
计算节点 A 的 Compute（nova-compute）从 Messaging 中获取到 Scheduler 发给它的消息，然后在本节点的 Hypervisor 上启动虚机。
在虚机创建的过程中，Compute 如果需要查询或更新数据库信息，会通过 Messaging 向 Conductor（nova-conductor）发送消息，Conductor 负责数据库访问。

迁移&&疏散

虚拟机迁移适用于负载均衡和资源调整，核疏散适用于物理服务器故障和预警情况。

virsh migrate --help

[--domain] <string> 域名，id 或 uuid
[--desturi] <string> 客户端（常规迁移）或者源（p2p 迁移）中看到到目的地主机连接 URI
--live 热迁移
--offline 离线迁移
--p2p 点对点迁移
--direct 直接迁移--tunnelled 管道迁移
--persistent 目的地中的持久 VM
--undefinesource 在源中取消定义 VM
--suspend 部启用目的地主机中的域
--copy-storage-all 使用全磁盘复制的非共享存储进行迁移
--copy-storage-inc 使用增值复制（源和目的地共享同一基础映像）的非共享存储进行迁移
--change-protection 迁移结束前不得对域进行任何配置更改
--unsafe 即使不安全也要强制迁移
--verbose 显示迁移进程
--compressed 实时迁移过程中压缩重复的页
--auto-converge force convergence during live migration
--rdma-pin-all support memory pinning during RDMA live migration
--abort-on-error 在迁移过程中忽略软错误
--migrateuri <string> 迁移 URI， 通常可省略
--graphicsuri <string> 无空隙图形迁移中使用的图形 URI
--listen-address <string> listen address that destination should bind to forincoming migration
--dname <string> 在迁移过长中重新命名为一个新名称（如果支持）
--timeout <number> 如果 live 迁移超时（以秒计）则强制虚拟机挂起
--xml <string> 包含为目标更新的 XML 的文件名
--migrate-disks <string> comma separated list of disks to be migrated

冷迁移–静态

关机后迁移，类似与克隆

1.拷贝机器A中源镜像文件和虚拟机配置文件到另一台机器B
2.重新在B机器中定义此虚拟机

###机器A操作
[root@kvm1 ~]# virsh list --all
[root@kvm1 ~]# virsh shutdown myvm01
[root@kvm1 ~]# scp /kvm/img/vm02.qcow2 目标serverIP:/kvm/img 
[root@kvm1 ~]# virsh dumpxml myvm02 > /tmp/vm02.xml
[root@kvm1 ~]# scp /tmp/vm02.xml root@目标serverIP:/etc/libvirt/qemu/

##机器B操作
[root@kvm2 ~]# virsh define /etc/libvirt/qemu/vm02.xml 
Domain myvm02 defined from /etc/libvirt/qemu/vm02.xml
[root@kvm2 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 -     myvm01                         shut off
[root@kvm2 ~]# virsh start myvm02

热迁移–动态迁移

疏散

从computeA 疏散到computeB；可执行evacuate操作，在另外一个新节点rebuild该实例

root@controller1:~# nova list --all-tenants --fields name,status,host
root@controller1:~# nova service-disable computeA nova-compute --reason maintenance  ##disable nova-compute service
root@controller1:~# nova service-list
root@controller1:~# nova stop VM1  ##先停掉虚拟
computeA:~# shutdown -h now&&exit
root@controller1:~# nova evacuate VM1  ##自动疏散，目标主机不指定
root@controller1:~#  nova evacuate VM1 computeB  ##指定主机

迁移和疏散

虚拟机迁移是一种将运行中的虚拟机从一台物理服务器迁移到另一台物理服务器的技术。它可以在不影响虚拟机运行的情况下，实现对物理服务器的负载均衡、资源调整和故障恢复等目的。虚拟机迁移通常包括以下步骤：

-选择目标主机：根据负载均衡策略或资源需求，选择合适的目标物理服务器。
-内存迁移：将虚拟机的内存数据从源主机传输到目标主机。
-迁移虚拟机磁盘：将虚拟机的磁盘数据传输到目标主机。
-网络切换：将虚拟机的网络连接从源主机切换到目标主机。
-迁移完成：启动虚拟机在目标主机上运行，停止源主机上的虚拟机实例。

虚拟机迁移适用于负载均衡、资源调整和故障恢复等场景，可以提高系统的可用性和性能。