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

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

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

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

相关问题

The placement API service provides a well-documented, JSON-based HTTP API and data model. It is designed to be easy to use from whatever HTTP client is suitable. There is a plugin to the openstackclient command line tool called osc-placement which is useful for occasional inspection and manipulation of the resources in the placement service.

placement API服务提供了一个经过良好文档化的基于JSON的HTTP API和数据模型。它被设计成可以轻松地从适当的HTTP客户端使用。还有一个插件可以集成到openstackclient命令行工具中，名为osc-placement，它对于偶尔检查和操作placement服务中的资源非常有用。

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的地址空间，会导致性能下降，并且对于某些高性能虚拟机工作负载来说，这种性能损失是不可接受的。