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             |
+---------------------+--------------------+
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 # 将compute节点移出AZ#001（2为AZ id，通过nova aggregate-list 查的）
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).
root@controller:~#nova aggregate-create aggregate-name az-name #创建aggregate的时候会关联az;一般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。
这样做有两个显著好处：

1. 更高的系统安全性
2. 更好的系统伸缩性

创建虚机过程

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 负责数据库访问。