nova组件简介

组件关系图

controller节点

openstack-nova-api.service:

openstack-nova-conductor.service:

openstack-nova-consoleauth.service:

openstack-nova-novncproxy.service:

openstack-nova-scheduler.service:

openstack-nova-conductor.service详解

作用和功能：

工作流程：

openstack-nova-conductor.service与openstack-nova-scheduler.service在调度功能上的区别

openstack-nova-conductor.service 的调度功能：

openstack-nova-scheduler.service 的调度功能：

总结：

compute节点

openstack-nova-compute.service

作用和功能：

总结：

nova相关服务代码路径

组件关系图

controller节点

[root@controller ~]# rpm -qa | grep nova
openstack-nova-conductor-18.3.0-1.el7.noarch
puppet-nova-13.3.1-1.el7.noarch
openstack-nova-common-18.3.0-1.el7.noarch
openstack-nova-scheduler-18.3.0-1.el7.noarch
openstack-nova-console-18.3.0-1.el7.noarch
openstack-nova-api-18.3.0-1.el7.noarch
openstack-nova-placement-api-18.3.0-1.el7.noarch
python2-novaclient-11.0.1-1.el7.noarch
python-nova-18.3.0-1.el7.noarch
openstack-nova-novncproxy-18.3.0-1.el7.noarch


[root@controller ~]# systemctl list-unit-files | grep -i nova | grep ena
openstack-nova-api.service                    enabled 
openstack-nova-conductor.service              enabled 
openstack-nova-consoleauth.service            enabled 
openstack-nova-novncproxy.service             enabled 
openstack-nova-scheduler.service              enabled

这五个服务都是与OpenStack项目中的Nova组件相关的服务，用于管理和提供计算资源的功能。以下是它们的作用：

openstack-nova-api.service:
- 作用：提供了OpenStack Nova API 服务，允许用户和其他OpenStack组件通过API进行与计算资源相关的操作，例如创建、管理和监控虚拟机实例。
openstack-nova-conductor.service:
- 作用：Nova Conductor服务充当调度和创建实例的中间层，负责处理来自Nova API的请求并将它们传递给合适的计算节点。这有助于分离控制节点和计算节点的功能，提高系统的可伸缩性。
openstack-nova-consoleauth.service:
- 作用：提供了Nova Console Authorization服务，用于验证和授权对控制台的访问。当用户尝试连接到虚拟机控制台时，此服务确保用户有权访问相关的控制台。
openstack-nova-novncproxy.service:
- 作用：Nova NoVNC Proxy服务允许用户通过Web浏览器访问虚拟机的图形控制台。这个服务负责代理和提供对虚拟机图形控制台的访问。
openstack-nova-scheduler.service:
- 作用：Nova Scheduler服务负责根据用户请求和系统资源的可用性，选择合适的计算节点来启动虚拟机实例。它确保虚拟机实例被分配到适当的计算节点上，以满足用户的需求并实现负载均衡。

这些服务一起协作，为OpenStack云平台提供了计算资源管理的核心功能。

openstack-nova-conductor.service详解

openstack-nova-conductor.service 是 OpenStack 中 Nova 组件的一个服务，其主要作用是充当调度和创建实例的中间层，通过将请求从 Nova API 传递到合适的计算节点来协助分离控制节点和计算节点的功能。以下是对 openstack-nova-conductor.service 的详细介绍：

作用和功能：

调度功能：
- Nova Conductor 负责实现虚拟机实例的调度。当用户通过 Nova API 提交创建虚拟机的请求时，Conductor 会决定将实例分配到哪个计算节点上运行。这有助于确保资源的合理利用和负载均衡。
实例创建和管理：
- 接收来自 Nova API 的创建虚拟机的请求，并负责将这些请求传递给计算节点。通过 Conductor，可以在计算节点上启动、停止、暂停等虚拟机实例的操作。
中间层的作用：
- 作为中间层，Conductor 的存在使得 Nova 控制节点和计算节点之间的通信更加高效和解耦。它充当了请求的代理，处理了一些计算节点上不需要直接执行的任务，使得计算节点可以专注于实际的虚拟机实例的管理和运行。
分布式架构支持：
- Nova Conductor 的设计使得它能够支持分布式架构。这对于大规模的云平台来说是至关重要的，因为它允许 Nova 部署在多个节点上，以提高系统的可伸缩性和容错性。

工作流程：

用户通过 Nova API 提交创建虚拟机的请求。
Nova API 将请求发送到 Nova Conductor。
Nova Conductor 决定将虚拟机实例分配到哪个计算节点上。
Nova Conductor 将请求传递给相应的计算节点。
计算节点执行实际的虚拟机实例创建和管理操作。
计算节点将结果返回给 Nova Conductor。
Nova Conductor 将结果传递给 Nova API，最终反馈给用户。

通过这个工作流程，Nova Conductor 起到了协调和调度的作用，确保虚拟机实例被有效地分配和管理。

openstack-nova-conductor.service与openstack-nova-scheduler.service在调度功能上的区别

openstack-nova-conductor.service 和 openstack-nova-scheduler.service 都在 OpenStack 中的 Nova 组件中扮演了调度的角色，但它们的功能和职责略有不同。

`openstack-nova-conductor.service` 的调度功能：

调度实例的位置：
- Nova Conductor 通过将请求从 Nova API 传递到合适的计算节点，实现了虚拟机实例的调度。它确保将实例分配到可用的计算节点上，考虑到系统资源的利用率和负载均衡。
中间层的作用：
- Nova Conductor 充当了调度和计算节点之间的中间层。它负责处理一些计算节点上不需要直接执行的任务，从而解耦了控制节点和计算节点之间的通信。
实例的创建和管理：
- 在实现调度的同时，Nova Conductor 也负责实例的创建和管理。它接收来自 Nova API 的创建虚拟机的请求，并将这些请求传递给适当的计算节点。

`openstack-nova-scheduler.service` 的调度功能：

决定实例的位置：
- Nova Scheduler 负责决定将虚拟机实例分配到哪个计算节点上。它在接收到来自 Nova API 的请求时，通过考虑计算节点的可用性、负载和其他条件，选择最合适的节点来放置实例。
负载均衡：
- Nova Scheduler 通过考虑各个计算节点的负载情况，努力实现资源的均衡分配。这有助于防止某些计算节点过载，同时保证系统资源的有效利用。
可插拔的调度器：
- Nova Scheduler 具有可插拔的调度器框架，允许管理员选择使用不同的调度算法。这样，可以根据实际需求配置调度器，以满足不同环境和策略的需求。

总结：

openstack-nova-conductor.service 主要负责调度和管理虚拟机实例的创建，充当了调度和计算节点之间的中间层。
openstack-nova-scheduler.service 则专注于选择最合适的计算节点来放置虚拟机实例，实现资源的均衡分配。

综合来看，Nova Conductor 更加直接参与实例的创建和管理，而 Nova Scheduler 则更专注于选择合适的计算节点进行实例的分配。在一些部署中，它们可能会协同工作以实现全面的资源管理和调度。

compute节点

[root@compute1 compute]# rpm -qa | grep nova
openstack-nova-compute-18.3.0-1.el7.noarch
python-nova-18.3.0-1.el7.noarch
openstack-nova-novncproxy-18.3.0-1.el7.noarch
openstack-nova-common-18.3.0-1.el7.noarch
openstack-nova-migration-18.3.0-1.el7.noarch
python2-novaclient-11.0.1-1.el7.noarch


[root@compute1 ~]# systemctl list-unit-files | grep -i nova
openstack-nova-compute.service                enabled

由于计算节点也安装了nova客户端，所以nova命令行也可以使用（进行身份验证即可）

`openstack-nova-compute.service`

openstack-nova-compute.service 是 OpenStack 中 Nova 组件的一个服务，它在计算节点上运行，并负责实际的虚拟机实例的创建、管理和监控。以下是该服务的主要功能：

作用和功能：

虚拟机实例的创建和管理：
- Nova Compute 服务负责在计算节点上启动、停止、暂停、重启等虚拟机实例的操作。当 Nova Conductor 接收到来自 Nova API 的创建虚拟机的请求后，它将请求传递给相应的 Nova Compute 服务来执行实际的操作。
资源的监控和报告：
- Nova Compute 监控计算节点上的资源使用情况，包括 CPU、内存、磁盘等。这些监控信息对于调度器（比如 Nova Scheduler）做出智能的虚拟机实例分配决策非常重要。
虚拟机的生命周期管理：
- Nova Compute 管理虚拟机实例的整个生命周期，包括创建、暂停、恢复、迁移、销毁等操作。这确保了在整个云平台中，虚拟机实例的状态得以有效管理。
与其他组件的通信：
- 与 Nova Conductor、Nova API 以及其他相关服务的通信。Nova Compute 接收来自 Conductor 的指令，执行相应的操作，并将结果反馈给 Conductor。这种协作确保了在分布式环境中的计算节点能够有效地执行管理任务。
Hypervisor 交互：
- 与底层的虚拟化技术（例如 KVM、QEMU、VMware 等）进行交互，以实现虚拟机的创建、启动和管理。Nova Compute 通过支持多种不同的 Hypervisor，使得 OpenStack 能够在不同的虚拟化环境中运行。

总结：

openstack-nova-compute.service 在整个 OpenStack 架构中的作用非常关键，它负责将云计算平台的抽象概念（虚拟机实例）映射到实际的计算节点上，通过与其他 Nova 组件协同工作，实现了虚拟化环境中的资源管理和虚拟机实例的运行。

nova相关服务代码路径

OpenStack所有代码都是python写的，代码默认存放路径为/usr/lib/python2.7/site-packages/

此处以openstack-nova-api.service为例进行查看演示

[root@controller nova]# systemctl status openstack-nova-api.service
● openstack-nova-api.service - OpenStack Nova API Server
   Loaded: loaded (/usr/lib/systemd/system/openstack-nova-api.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2023-10-09 08:42:44 CST; 4h 15min ago
 Main PID: 1607 (nova-api)
   CGroup: /system.slice/openstack-nova-api.service
           ├─1607 /usr/bin/python2 /usr/bin/nova-api
           ├─3565 /usr/bin/python2 /usr/bin/nova-api
           ├─3568 /usr/bin/python2 /usr/bin/nova-api
           ├─3575 /usr/bin/python2 /usr/bin/nova-api
           └─3576 /usr/bin/python2 /usr/bin/nova-api

Oct 09 08:42:15 controller systemd[1]: Starting OpenStack Nova API Server...
Oct 09 08:42:44 controller systemd[1]: Started OpenStack Nova API Server.


[root@controller nova]# cat /usr/lib/systemd/system/openstack-nova-api.service
[Unit]
Description=OpenStack Nova API Server
After=syslog.target network.target

[Service]
Type=notify
NotifyAccess=all
TimeoutStartSec=0
Restart=always
User=nova
ExecStart=/usr/bin/nova-api

[Install]
WantedBy=multi-user.target


[root@controller nova]# cat /usr/bin/nova-api
#!/usr/bin/python2
# PBR Generated from u'console_scripts'

import sys

from nova.cmd.api import main


if __name__ == "__main__":
    sys.exit(main())
[root@controller nova]# pwd
/usr/lib/python2.7/site-packages/nova
[root@controller nova]#

[root@controller nova]# ll /usr/lib/python2.7/site-packages/nova/cmd/api.py
-rw-r--r-- 1 root root 2246 Feb 29  2020 /usr/lib/python2.7/site-packages/nova/cmd/api.py


[root@controller nova]# cat /usr/lib/python2.7/site-packages/nova/cmd/api.py
...
def main():
    config.parse_args(sys.argv)
    logging.setup(CONF, "nova")
    objects.register_all()
    gmr_opts.set_defaults(CONF)
    if 'osapi_compute' in CONF.enabled_apis:
        # NOTE(mriedem): This is needed for caching the nova-compute service
        # version.
        objects.Service.enable_min_version_cache()
    log = logging.getLogger(__name__)

    gmr.TextGuruMeditation.setup_autorun(version, conf=CONF)

    launcher = service.process_launcher()
    started = 0
    for api in CONF.enabled_apis:
        should_use_ssl = api in CONF.enabled_ssl_apis
        try:
            server = service.WSGIService(api, use_ssl=should_use_ssl)
            launcher.launch_service(server, workers=server.workers or 1)
            started += 1
        except exception.PasteAppNotFound as ex:
            log.warning("%s. ``enabled_apis`` includes bad values. "
                        "Fix to remove this warning.", ex)

    if started == 0:
        log.error('No APIs were started. '
                  'Check the enabled_apis config option.')
        sys.exit(1)

    launcher.wait()