NetworkBandwidthEntitlement

• Launchpad 条目: NovaSpec:network-bandwidth-entitlement
• 创建时间: 2013年5月6日
• 贡献者: Phil Day, HP Cloud Services

总结

目前 Nova 的 host_manager 会跟踪每个主机的磁盘、内存和 #_vCPU 资源，这些资源随后可用于调度器过滤器。这些信息也反映在 flavor 定义中。

我们希望扩展此模型，以增加可供此 flavor 的实例使用的网络带宽指标。每个物理主机将报告其总网络带宽容量。这将支持具有混合网络配置（10Gb、多 10Gb 等）的主机，并允许定义和调度“高带宽”实例类型。

此更改涉及多个方面

• 如何将这些值定义为实例类型的一部分
• 如何定义相应的物理主机容量
• 如何将此信息提供给调度器
• 如何将此信息提供给物理主机上的资源管理层
• 如何以不破坏现有系统的方式添加此功能，并且可以被不需要/不需要此附加功能的人员忽略

如何将这些值定义为实例类型的一部分 ?

实例类型已经有一个相关的 rxtx_factor，但当前在系统中的使用仅限于 Xen。rxtx_factor (float)：受 API 扩展支持。传递到 Nova Networking 和 Quantum API。在 Nova Network 中，它用于通过与网络的 rxtx_base 因子相乘来计算实例的 rxtx_cap。然后 rxtx_cap 在 Xen 驱动程序中用于为 VIF 设置速率限制上限。

存在的问题

• rxtx_factor 用作逻辑网络的缩放因子（即 Nova DB 中 Network 的属性），不考虑主机配置。
• rxtx_factor 意味着实例类型根据其连接的网络获得不同的容量
• 它被认为是 host_manager 跟踪的易变资源。

对于网络带宽，我们真正想要的是将 rxtx_cap 作为 rxtx_factor 的替代方案。然后我们需要将其传递给 Quantum

我们还需要为这些新属性提供配额控制

如何定义相应的物理主机容量

总主机网络带宽容量同样很难自动推断。主机的物理 NIC 可能以多种不同的方式呈现给 Nova。

为每个主机添加一个 total_rxtx 属性，该属性描述了可供实例使用的总带宽。

值将从 nova.conf 读取并保存在 compute_nodes 表中

如何将此信息提供给调度器 

rxtx_total 是每个主机的属性，消耗的 rxtx 是每个实例类型 rxtx_cap 的总和。（这意味着 rxtx_cap 聚合到所有 NIC 上）

将创建一个新的调度器过滤器来应用网络带宽容量。

随着越来越多的资源类型被管理，可能需要不同的加权函数（例如，按消耗最多的资源的消耗百分比排名，而不仅仅是内存）

rxtx_factor 的可见性已经通过其自身的 API 扩展进行控制，这在 API 层是好的。但是，由于我们希望调度器将这些因素考虑在内，这是否意味着调度器现在需要知道启用了哪些 API 扩展 ?

如何将此信息提供给物理主机上的资源管理层

这实际上是一个 hypervisor / quantum 驱动程序实现问题。（例如，Xen 驱动程序已经具有其实现和对 vcpu_weight 的解释）。通常，每个 hypervisor 驱动程序都需要转换为适合其资源管理系统的单位（例如，vcpu_weight/cpu_base）。

当前的实例类型属性（#vcpus、内存）易于转换为 VM 定义。带宽可能不太容易，因为不同的云提供商可能对实现有不同的看法（共享与上限）。

问：这其中有多少可以直接在 Hypervisor 层处理 ？ 有太多的实现方式（共享与配额、限制哪些线程等），任何内置模型都需要太多的配置选项才能满足每个人的需求。

相反，我们更喜欢一种更简单的方法，即使 flavor 数据可用，并让外部脚本对其进行操作。例如：确保所有 flavor 数据都在通知消息中 创建实例目录中的一个附加文件，其中包含所有 flavor 值

如何以不破坏现有系统的方式添加此功能，并且可以被不需要/不需要此附加功能的人员忽略

• 为主机属性提供默认值（例如，cpu_base=100，vcpu_weight=100）
• 新的调度器过滤器可以默认情况下从调度器中排除
• 使 flavor 数据可供外部资源管理使用，避免尝试在 hypervisor 驱动程序中构建通用方法
• 与 Xen 的兼容性需要工作（假设我们重用 vcpu_weight 并添加 rxtx_cap 属性）