Placement 中返回整个树的资源¶
https://blueprints.launchpad.net/nova/+spec/placement-return-all-resources
本规范旨在扩展 placement 的 GET /allocation_candidates API,以在响应体的 provider_summaries 字段中包含树中的所有资源。
问题描述¶
GET /allocation_candidates API 的响应包含 allocation_requests 和 provider_summaries 两个字段。调用者,例如 nova 中的筛选调度器,将使用 provider_summaries 中的信息对提供者进行排序或筛选,以分配消费者。
但是,provider_summaries 不包含不在 allocation_request 字段中的资源提供者信息。当计算主机资源提供者没有资源库存,但其子项(NUMA 资源提供者)可以提供资源时,这将成为一个问题。(请参阅 带有资源提供者的 NUMA 拓扑 规范)
Case1:计算节点本身没有任何资源¶
例如,让我们考虑一个具有每个 NUMA 节点多个资源的宿主机。
+-----------------+
| <CN_NAME> |
+-----------------+
/ \
+------------------+ +-----------------+
| <NUMA_NODE_0> | | <NUMA_NODE_1> |
| PCPU: 8 | | PCPU: 8 | (dedicated CPUs)
| MEMORY_MB: 4096 | | MEMORY_MB: 4096 |
+------------------+ +-----------------+
|
+--------------------+
| <PHYS_FUNC_PCI_ID> |
| SRIOV_NET_VF: 8 |
+--------------------+
Case2:计算节点本身没有请求的资源¶
类似地,我们可以考虑一个宿主机,它为其资源类具有 VCPU 库存,并且为其子项(NUMA 资源提供者)具有 PCPU 库存。
+-----------------+
| <CN_NAME> |
| VCPU: 8 | (shared CPUs)
+-----------------+
/ \
+------------------+ +-----------------+
| <NUMA_NODE_0> | | <NUMA_NODE_1> |
| PCPU: 8 | | PCPU: 8 | (dedicated CPUs)
| MEMORY_MB: 4096 | | MEMORY_MB: 4096 |
+------------------+ +-----------------+
|
+--------------------+
| <PHYS_FUNC_PCI_ID> |
| SRIOV_NET_VF: 8 |
+--------------------+
如果用户请求每个 NUMA 节点 4 个 PCPU 和 2048 MB 内存,在 细粒度资源请求语法 规范下,nova 将向 placement 发出以下请求;
GET /allocation_candidates?resources1=PCPU:4,MEMORY_MB=2048
&resources2=PCPU:4,MEMORY_MB=2048
&group_policy=isolate
在 Case1 和 Case2 这两种情况下,nova 将获得以下 JSON 响应,其中存在 NUMA 资源提供者,但没有计算主机资源提供者。
{
"allocation_requests": [
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": 4,
"MEMORY_MB":2048
},
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": 4,
"MEMORY_MB":2048
},
},
},
},
],
"provider_summaries": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": {
"used": 0,
"capacity": 8
},
"MEMORY_MB": {
"used": 0,
"capacity": 6144
}
},
"traits": []
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": {
"used": 0,
"capacity": 8
},
"MEMORY_MB": {
"used": 0,
"capacity": 6144
}
},
"traits": []
}
}
}
这是因为 placement 当前具有以下逻辑。
在
provider_summaries中,我们不显示不在allocation_requests中的资源提供者。在 Case1 和 Case2 中,这都会阻止计算节点出现。在
provider_summaries中,我们不显示没有资源库存的资源提供者。在 Case1 中,这会阻止计算节点出现。在
provider_summaries中,我们不显示未请求的资源类。在 Case2 中,这会阻止计算节点出现。
从这个响应中,nova 调度器无法知道这些资源提供者是计算主机还是它们的子项。这将成为一个问题,因为 nova 调度器需要随后将候选主机传递给 nova 内部的过滤器和称重器。
用例¶
作为 NFV 运营商,我希望在 Placement 中启用 NUMA 感知的资源管理。
提议的变更¶
0. 返回树中的所有嵌套提供者¶
首先,我们需要更改 GET /allocation_candidates,以在 provider_summaries 中包含不在 allocation_requests 中的资源提供者,只要这些其他资源提供者位于同一提供者树中。此外,我们添加了新的字段 root_provider_uuid 和 parent_provider_uuid,用于每个资源提供者,以暴露层次结构。
此要求对于 Case1 和 Case2 都是必需的。
1. 返回没有库存的资源提供者¶
此外,我们需要更改代码,以便在 provider_summaries 中包含没有库存的资源提供者。这将允许运营商获得 Case1 的以下响应,其中计算节点没有库存。
{
"allocation_requests": [
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": 4,
"MEMORY_MB":2048
},
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": 4,
"MEMORY_MB":2048
},
},
},
},
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": 8,
"MEMORY_MB":4096
},
},
},
},
{
"allocations": {
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": 8,
"MEMORY_MB":4096
},
},
},
},
],
"provider_summaries": {
"99c09379-6e52-4ef8-9a95-b9ce6f68452e": {
"resources": {},
"traits": [],
"parent_provider_uuid": "",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
},
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": {
"used": 0,
"capacity": 8
},
"MEMORY_MB": {
"used": 0,
"capacity": 6144
},
},
"traits": [],
"parent_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e"
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": {
"used": 0,
"capacity": 8
},
"MEMORY_MB": {
"used": 0,
"capacity": 6144
},
},
"traits": [],
"parent_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
},
"542df8ed-9be2-49b9-b4db-6d3183ff8ec8": {
"resources": {
"SRIOV_NET_VF": {
"used": 0,
"capacity": 16
},
},
"traits": [],
"parent_provider_uuid": "7d2590ae-fb85-4080-9306-058b4c915e3f",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
},
},
}
2. 返回 provider_summaries 中的所有资源¶
此外,我们需要更改代码,以便在 provider_summaries 中包含具有未请求库存的资源提供者。这将允许运营商在 Case2 中获得以下响应,其中计算节点具有 8 个 VCPU 库存,这并未请求。
{
"allocation_requests": [
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": 4,
"MEMORY_MB":2048
},
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": 4,
"MEMORY_MB":2048
},
},
},
},
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": 8,
"MEMORY_MB":4096
},
},
},
},
{
"allocations": {
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": 8,
"MEMORY_MB":4096
},
},
},
},
],
"provider_summaries": {
"99c09379-6e52-4ef8-9a95-b9ce6f68452e": {
"resources": {
"VCPU": {
"used": 0,
"capacity": 8
},
},
"traits": [],
"parent_provider_uuid": "",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
},
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": {
"used": 0,
"capacity": 8
},
"MEMORY_MB": {
"used": 0,
"capacity": 6144
},
},
"traits": [],
"parent_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e"
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": {
"used": 0,
"capacity": 8
},
"MEMORY_MB": {
"used": 0,
"capacity": 6144
},
},
"traits": [],
"parent_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
},
"542df8ed-9be2-49b9-b4db-6d3183ff8ec8": {
"resources": {
"SRIOV_NET_VF": {
"used": 0,
"capacity": 16
},
},
"traits": [],
"parent_provider_uuid": "7d2590ae-fb85-4080-9306-058b4c915e3f",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
},
},
}
相应地,nova 调度器会更改为感知层次结构,并找出要传递给内部过滤器和称重器的计算主机。
备选方案¶
我们可以只在 provider_summaries 中添加 root_provider_uuid 字段,而不是暴露整个树。对于 Case1 和 Case2,响应将是
{
"allocation_requests": [
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": 4,
"MEMORY_MB":2048
},
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": 4,
"MEMORY_MB":2048
},
},
},
},
{
"allocations": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": 8,
"MEMORY_MB":4096
},
},
},
},
{
"allocations": {
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": 8,
"MEMORY_MB":4096
},
},
},
},
],
"provider_summaries": {
"35791f28-fb45-4717-9ea9-435b3ef7c3b3": {
"resources": {
"PCPU": {
"used": 0,
"capacity": 8
},
"MEMORY_MB": {
"used": 0,
"capacity": 6144
}
},
"traits": [],
"parent_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
},
"7d2590ae-fb85-4080-9306-058b4c915e3f": {
"resources": {
"PCPU": {
"used": 0,
"capacity": 8
},
"MEMORY_MB": {
"used": 0,
"capacity": 6144
}
},
"traits": [],
"parent_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
"root_provider_uuid": "99c09379-6e52-4ef8-9a95-b9ce6f68452e",
},
},
}
但是,将树中的所有资源都放入其中可以为以下用例启用进一步的称重和过滤,例如。
作为部署具有 VCPU、MEMORY_MB 和 DISK_GB 的实例的用户,我不想将此实例部署到具有 VGPU 或 SRIOV_NET_VF 的主机上,以节省需要这些设备的实例的资源。
在 placement 中构建称重器或过滤器超出本规范的范围,但利用这个机会为这些用例做好准备是好的。
另一种选择是在 placement 中不做任何事情,并更改 nova 调度器以向 placement 发出额外的查询以获取整个树的信息。
GET /resource_providers?in_tree={uuid}
但是,为每个资源提供者候选项查询请求效率不高。
数据模型影响¶
无
REST API 影响¶
使用新的微版本,GET /allocation_candidates 将包含树中的所有资源提供者,并带有新的字段 root_provider_uuid 和 parent_provider_uuid,如 提议的更改 部分所述。
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
由于它将构建更多数据发送回客户端,因此评估分配候选项的速度会变慢。对此别无选择,因此在实施时,我们至少应注意不要增加 SQL 查询的数量来启用此功能。
其他部署者影响¶
无
开发人员影响¶
无
升级影响¶
无
实现¶
负责人¶
- 主要负责人
Tetsuro Nakamura (tetsuro)
工作项¶
更改代码以在
provider_summaries中包含树中的所有提供者。即,我们需要对当前行为进行以下更改。即使资源提供者不在
allocation_requests中,也包含provider_summaries中的整个树的资源提供者。- 有关详细信息,请参阅 返回树中的所有嵌套提供者 补丁。即使资源类不在请求的资源中,也包含
provider_summaries中的所有资源类信息。- 有关详细信息,请参阅 返回 provider_summaries 中的所有资源 补丁。即使资源提供者没有任何库存,也包含
provider_summaries中的资源提供者 - 有关详细信息,请参阅 返回没有库存的资源提供者 补丁。
使用新的微版本,在
provider_summaries中添加root_provider_uuid和parent_provider_uuid字段。更改 nova 调度器以感知层次结构,并找出要传递给内部过滤器和称重器的根提供者。
依赖项¶
本规范依赖于 嵌套资源提供者 - 分配候选者 规范。
测试¶
提供新的 gabbi 测试以及单元测试。
文档影响¶
带有新微版本的新的行为应在发布说明和 Placement api-ref 文档 中得到很好的描述。 微版本历史记录文档 也将更新。