Nova 系统架构¶
Nova 包含多个服务器进程，每个进程执行不同的功能。面向用户的接口是 REST API，而 Nova 组件内部通过 RPC 消息传递机制进行通信。
API 服务器处理 REST 请求，这些请求通常涉及数据库读取/写入，可以选择性地向其他 Nova 服务发送 RPC 消息，并生成对 REST 请求的响应。RPC 消息传递通过 oslo.messaging 库完成，该库是对消息队列的抽象。Nova 使用基于消息传递的“无共享”架构，并且大多数主要的 nova 组件可以在多台服务器上运行，并具有监听 RPC 消息的管理器。主要的例外是计算服务，单个进程在其管理的 hypervisor 上运行（除非使用 VMware 或 Ironic 驱动程序）。管理器还可选地具有定期任务。有关我们 RPC 系统的更多详细信息，请参阅 AMQP 和 Nova。
Nova 使用传统的 SQL 数据库来存储信息。这些数据库（在逻辑上）在多个组件之间共享。为了帮助升级，数据库通过一个对象层访问，该对象层确保升级后的控制平面仍然可以与运行先前版本的计算节点进行通信。为了使之成为可能，在计算节点上运行的服务通过 RPC 将数据库请求代理到中央管理器，该管理器称为 conductor。
为了水平扩展 Nova 部署，我们有一个部署分片概念，称为 cells。所有部署至少包含一个 cell。有关更多信息，请参阅 Cells (v2)。
组件¶
下面您将找到对典型 Nova 部署的关键组件的有用解释。
DB：用于数据存储的 SQL 数据库。
API：接收 HTTP 请求、转换命令并与通过 oslo.messaging 队列或 HTTP 进行通信的其他组件。
Scheduler：决定哪个主机获得每个实例。
Compute：管理与 hypervisor 和虚拟机的通信。
Conductor：处理需要协调的请求（构建/调整大小），充当数据库代理，或处理对象转换。
:placement-doc:`Placement <>`：跟踪资源提供商的库存和使用情况。
虽然所有服务都设计为可水平扩展的，但您应该拥有比其他任何服务都多的计算节点。
Hypervisors¶
Nova 通过 API 服务器控制 hypervisor。选择要使用的最佳 hypervisor 可能会很困难，您必须考虑预算、资源限制、支持的功能和所需的规格。但是，大多数 OpenStack 开发都在使用基于 KVM 的 hypervisor 的系统上完成的。有关不同 hypervisor 的功能和支持的详细列表，请参阅 Feature Support Matrix。
您还可以使用多个 hypervisor 在不同的可用区中编排云。Nova 支持以下 hypervisor
有关 hypervisor 的更多信息，请参阅 Nova 配置参考中的 Hypervisors 部分。
Projects, users, and roles¶
要开始使用 Nova，您必须创建一个具有 Identity service 的用户。
Nova 系统设计为在共享系统上的项目形式下由不同的消费者使用，以及基于角色的访问分配。角色控制用户允许执行的操作。
项目是隔离的资源容器，它们构成了 Nova 服务内的主要组织结构。它们通常包括网络、卷、实例、镜像、密钥和用户。用户可以通过将 project_id 附加到他们的访问密钥来指定项目。
对于项目，您可以使用配额控制来限制可以分配的处理器核心数量和 RAM 量。其他项目也允许对其自身资源设置配额。例如，neutron 允许您管理可以在项目内创建的网络数量。
角色控制用户允许执行的操作。默认情况下，大多数操作不需要特定的角色，但您可以编辑 policy.yaml 文件来配置它们。例如，可以定义一个规则，要求用户必须具有 admin 角色才能分配公共 IP 地址。
项目限制用户对特定镜像的访问。每个用户都分配了一个用户名和密码。授予对实例的访问权限的密钥对针对每个用户启用，但设置了配额，以便每个项目可以控制可用硬件资源上的资源消耗。
注意
OpenStack 的早期版本使用术语 tenant 代替 project。由于这种遗留术语，一些命令行工具使用 --tenant_id，而您通常期望输入项目 ID。
Block storage¶
OpenStack 提供两类块存储：Nova 本身配置的存储，以及由块存储服务 Cinder 管理的存储。
Nova-provisioned block storage
Nova 提供了创建根磁盘和可选“ephemeral”卷的能力。除非实例是 Boot From Volume 实例，否则根磁盘将始终存在。
根磁盘与实例关联，并且仅在实例的生命周期内存在。通常，它用于存储实例的根文件系统，在来宾操作系统重新启动时持久存在，并在实例删除时被删除。根 ephemeral 卷的数量由实例的 flavor 定义。
除了根卷之外，flavor 还可以提供额外的 ephemeral 块设备。它表示一个原始块设备，没有分区表或文件系统。一个了解云的操作系统可以发现、格式化和挂载这样的存储设备。Nova 为不同的操作系统定义了默认文件系统，Linux 发行版为 ext4，非 Linux 和非 Windows 操作系统为 VFAT，Windows 为 NTFS。但是，可以配置其他文件系统类型。
注意
例如，包含在 Ubuntu 的标准云镜像中的 cloud-init 包，默认情况下将此空间格式化为 ext4 文件系统并将其挂载到 /mnt。这是一个 cloud-init 功能，不是 OpenStack 机制。OpenStack 仅配置原始存储。
Cinder-provisioned block storage
OpenStack 块存储服务 Cinder 提供持久卷，这些卷由持久虚拟化块设备表示，与任何特定实例无关。
持久卷可以被单个实例访问或附加到多个实例。这种类型的配置需要传统的网络文件系统才能允许多个实例访问持久卷。它还需要传统的网络文件系统，例如 NFS、CIFS 或集群文件系统，例如 Ceph。这些系统可以在 OpenStack 集群内构建，也可以在 OpenStack 外部配置，但 OpenStack 软件不提供这些功能。
您可以将持久卷配置为可引导，并使用它来提供持久虚拟实例，类似于传统的非云虚拟化系统。根据所选的 flavor，结果实例仍然可以拥有 ephemeral 存储。在这种情况下，根文件系统可以位于持久卷上，并且即使实例被关闭，其状态也会保持不变。有关此类型配置的更多信息，请参阅 Introduction to the Block Storage service。
Building blocks¶
在 OpenStack 中，基本操作系统通常从存储在 OpenStack Image 服务 glance 中的镜像复制而来。这是最常见的情况，并导致在虚拟机器删除时从已知模板状态启动并丢失所有累积状态的 ephemeral 实例。也可以将操作系统放在 OpenStack 块存储服务中的持久卷上。这提供了一个更传统的持久系统，该系统积累了跨 OpenStack 块存储卷删除和重新创建虚拟机的状态。
$ openstack image list
+--------------------------------------+-----------------------------+--------+
| ID | Name | Status |
+--------------------------------------+-----------------------------+--------+
| aee1d242-730f-431f-88c1-87630c0f07ba | Ubuntu 14.04 cloudimg amd64 | active |
| 0b27baa1-0ca6-49a7-b3f4-48388e440245 | Ubuntu 14.10 cloudimg amd64 | active |
| df8d56fc-9cea-4dfd-a8d3-28764de3cb08 | jenkins | active |
+--------------------------------------+-----------------------------+--------+
显示的镜像属性是
ID自动生成的镜像 UUID
名称镜像的自由形式、人类可读的名称
状态镜像的状态。标记为
ACTIVE的镜像可供使用。服务器对于作为运行实例的快照创建的镜像，这是快照派生的实例的 UUID。对于上传的镜像，此字段为空。
虚拟硬件模板称为 flavors。默认情况下，这些可以由管理员用户配置，但是可以通过重新定义访问控制 policy.yaml 在 nova-api 服务器上更改该行为。有关更多信息，请参阅 Nova Policies。
要列出系统中可用的 flavor
$ openstack flavor list
+-----+-----------+-------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is_Public |
+-----+-----------+-------+------+-----------+-------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | 1 | True |
| 2 | m1.small | 2048 | 20 | 0 | 1 | True |
| 3 | m1.medium | 4096 | 40 | 0 | 2 | True |
| 4 | m1.large | 8192 | 80 | 0 | 4 | True |
| 5 | m1.xlarge | 16384 | 160 | 0 | 8 | True |
+-----+-----------+-------+------+-----------+-------+-----------+
Nova service architecture¶
这些基本类别描述了服务架构和有关云控制器的信息。
API server
云框架的核心是一个 API 服务器，它使对 hypervisor、存储和网络的命令和控制以编程方式可供用户使用。
API 端点是基本的 HTTP Web 服务，它使用各种 API 接口（包括 Amazon、Rackspace 和相关模型）处理身份验证、授权和基本的命令和控制功能。这使得与来自其他供应商的产品的工具集兼容。这种广泛的兼容性可以防止供应商锁定。
消息队列
消息队列代理计算节点（处理）、网络控制器（控制网络基础设施）、API 端点、调度器（确定将哪些物理硬件分配给虚拟资源）以及类似组件之间的交互。通过多个 API 端点通过 HTTP 请求处理与云控制器的通信。
典型的消息传递事件从 API 服务器接收来自用户的请求开始。API 服务器验证用户并确保他们被允许发出主题命令。评估与请求相关的对象的可用性，如果可用，则将请求路由到相关工作者的队列引擎。工作者不断监听基于其角色和有时主机名的队列，当适用的工作请求到达队列时，工作者接受任务的分配并开始执行它。完成时，响应被发送到队列，由 API 服务器接收并转发给发起用户。数据库条目在过程中根据需要进行查询、添加或删除。
Compute worker
计算工作者管理主机上的计算实例。API 将命令调度到计算工作者以完成这些任务
运行实例
删除实例（终止实例）
重新启动实例
附加卷
分离卷
获取控制台输出
Network Controller
网络控制器管理主机上的网络资源。API 服务器通过消息队列调度命令，然后由网络控制器处理。具体操作包括
分配固定 IP 地址
为项目配置 VLAN
为计算节点配置网络
