With the addition of the new placement API, we now have a new way to account for quantitative resources in the system. Resource providers contain inventories of various resource classes. These inventories are simple integer amounts and, along with the concept of allocation records, are designed to answer the questions: “how many of a type of resource does this provider have available?” “how much of a type of resource is being consumed in the system?” “what level of over-commit does each provider expose for each type of resource?”

通过添加新的placement API，我们现在有了一种新的方式来对系统的定量资源进行核算。资源供者包含各种资源类别的库存。这些库存是简单的整数数量，并且与分配记录的概念一起，旨在回答以下问题：

“这个提供者有多少可用的某种类型资源？”

“系统中有多少某种类型的资源正在被使用？”

“每个提供者对每种类型的资源公开了多少超额承诺级别？”

相关问题

In the initial version of the resource provider schema in the placement API, we stuck with a simple world-view that resource providers could be related to each other only via an aggregate relationship. In other words, a resource provider “X” may provide shared resources to a set of other resource providers “S” if and only if “X” was associated with an aggregate “A” that all members of “S” were also associated with. This relationship works perfectly fine for things like shared storage or IP pools. However, certain classes of resource require a more parent->child relationship than a many-to-many relationship that the aggregate association offers. Two examples of where a parent->child relationship is more appropriate are when handling VCPU/MEMORY_MB resources on NUMA nodes on a compute host and when handling SRIOV_NET_VF resources for NICs on a compute host. In the case of NUMA nodes, the system must be able to track how many VCPU and MEMORY_MB have been allocated from each individual NUMA node on the host. Allocating memory to a guest and having that memory span address space across two banks of DIMMs attached to different NUMA nodes results in sub-optimal performance, and for certain high-performance guest workloads this penalty is not acceptable.

在placement API中的资源提供者模式的初始版本中，我们坚持了一个简单的观点，即资源提供者之间只能通过聚合关系相互关联。换句话说，如果且仅当资源提供者“X”与所有成员资源提供者“S”都关联到同一个聚合“A”时，资源提供者“X”才能向资源提供者“S”提供共享资源。

这种关系对于共享存储或IP池等情况非常适用。然而，某些类型的资源需要比聚合关联提供更多的父->子关系。两个更适合父->子关系的例子是在计算主机上处理NUMA节点上的VCPU/MEMORY_MB资源以及在计算主机上处理SRIOV_NET_VF资源的网卡。

在NUMA节点的情况下，系统必须能够跟踪从主机上的每个单独NUMA节点分配了多少VCPU和MEMORY_MB。将内存分配给虚拟机，并使该内存跨越连接到不同NUMA节点的两组DIMM的地址空间，会导致性能下降，并且对于某些高性能虚拟机工作负载来说，这种性能损失是不可接受的。

The placement API service was introduced in the 14.0.0 Newton release within the nova repository and extracted to the placement repository in the 19.0.0 Stein release. This is a REST API stack and data model used to track resource provider inventories and usages, along with different classes of resources. For example, a resource provider can be a compute node, a shared storage pool, or an IP allocation pool. The placement service tracks the inventory and usage of each provider. For example, an instance created on a compute node may be a consumer of resources such as RAM and CPU from a compute node resource provider, disk from an external shared storage pool resource provider and IP addresses from an external IP pool resource provider. The types of resources consumed are tracked as classes. The service provides a set of standard resource classes (for example DISK_GB, MEMORY_MB, and VCPU) and provides the ability to define custom resource classes as needed. Each resource provider may also have a set of traits which describe qualitative aspects of the resource provider. Traits describe an aspect of a resource provider that cannot itself be consumed but a workload may wish to specify. For example, available disk may be solid state drives (SSD).

placement API服务在14.0.0版本的Newton发布中首次引入到nova存储库中，并在19.0.0版本的Stein发布中提取到placement存储库中。这是一个用于跟踪资源提供者库存、使用情况和不同资源类别的REST API堆栈和数据模型。例如，一个资源提供者可以是计算节点、共享存储池或IP地址分配池。placement服务跟踪每个提供者的库存和使用情况。例如，创建在计算节点上的实例可能会消耗来自计算节点资源提供者的RAM和CPU资源、来自外部共享存储池资源提供者的磁盘资源，以及来自外部IP地址池资源提供者的IP地址资源。

消耗的资源类型被跟踪为类别。该服务提供一组标准的资源类别（例如DISK_GB、MEMORY_MB和VCPU），并提供根据需要定义自定义资源类别的能力。

每个资源提供者还可以拥有一组描述资源提供者质量特征的特征。特征描述了一个资源提供者的某个方面，它本身不能被消耗，但工作负载可能希望指定。例如，可用磁盘可以是固态驱动器（SSD）。