配额、使用计划和容量管理

斜体中的章节是可选的。

问题描述

像 OpenStack 这样的 IaaS 系统的典型特性是“按需容量”。 用户期望能够根据需要通过 UI 或 API 分配新资源，并在需求结束后释放它们。 通过支持大量用户、汇集资源以及维护一些剩余容量，云服务提供商 (CSP) 呈现出无限容量的假象。

当然，在实践中，资源并非无限，CSP 必须实施措施来管理容量，从而最大限度地减少资源耗尽。 这通常是通过对特定项目可能消耗的资源施加上限或配额，以及通过管理可用物理资源与所有项目的聚合配额之间的关系来实现的。 当项目需要比其分配的配额更多的资源时，用户通常需要提交请求，通常需要人工审批。 CSP 可能会拒绝该请求，或者延迟它直到有足够的容量可用。 当请求获得批准时，项目的配额将被修改以反映新的限制。

其他 CSP 引入了许多机制来为他们提供容量管理方面的灵活性。 这些包括组配额（由相关项目共享）、预留实例、临时实例（可以回收以供重新分配）以及基于市场的分配模型。 目前，OpenStack 不支持这些机制中的任何一种。

所有这些流程的一个共同因素是，它们都没有反映资源使用的时序变化。 然而，在许多情况下，用户知道他们的使用情况会随着时间的推移而变化，并且这些信息对需要决定如何处理每个请求的 CSP 来说是有用的。 它也可能促进某些处理的自动化。 以下用户故事捕捉了这里的可能性。

用户故事

• 作为 OpenStack 用户，我希望以一种能够实现 CSP 自动处理的方式指定我的资源使用请求 (RUR)，以便我的 RUR 可以更快、更准确地处理。
• 作为 CSP，我希望能够自动化 RUR 的处理，以便我能够满足我的用户 SLA 并获得更多及时和准确的数据输入到我的容量管理和规划系统中。
• 作为用户，我希望能够描述我的 RUR 的时序特征，以便 CSP 可以更准确地规划容量并减少资源请求失败的风险。 我的 CSP 也可能会为更准确的使用预测提供更好的定价。 一些基于时间的 RUR 示例

1. 我计划从 2016 年 6 月 1 日到 2016 年 8 月 14 日使用最多 60 个 vCPU 和 240GB 的 RAM。
2. 我计划从 2016 年 8 月 14 日开始使用 200GB 的对象存储，此后每个日历月增加 100GB。
3. 我希望为我的项目保证访问 30 个 vCPU 和 200GB 的 RAM。 此外，在 10 月至 12 月期间，我希望能够将我的使用量增加到 150 个 vCPU 和 1TB 的 RAM

• 作为用户，我希望能够每月提交我的项目的滚动 RUR 的更新版本，以便我的 CSP 拥有准确的信息并能为我提供最佳的价格和 SLA。
• 作为用户，我希望能够利用 CSP 提供的定价和其他优惠，以满足我的项目的业务目标。 例如

1. 我需要至少 60 个 vCPU 一个小时。 过了这段时间，如果其他地方需要资源，CSP 可能会关闭我的所有实例。（我假设这些实例的价格较低。）
2. 我需要在未来 24 小时内使用最多 100 个 vCPU。 告诉我我可以拥有多少个。

• 作为 CSP，我希望能够自动化基于时间的资源使用计划的构建和解释，以便我能够安排最经济高效的行动来维护我的 SLA。 一些行动示例

1. 安排额外基础设施的配置。
2. 重新利用已分配的基础设施。
3. 根据使用情况预测将新项目分配到多个区域之一。
4. 从联盟合作伙伴或经销商处添加“爆发容量”。
5. 修改或推迟另一个项目。

用例示例

待定

机会/理由

无。

相关用户故事

此用例与无限弹性用例相关。 后者侧重于测试 OpenStack 云处理大规模容量请求的能力。

需求

• 这些功能的实现将在一定程度上取决于更灵活和全面的配额方案的存在，以便容量管理系统可以以编程方式调整配额。
• 它还需要一个丰富的监控、通知和可视化系统，以便用户和 CSP 都能拥有关于系统行为的准确和及时的信息。

差距

目前尚无已知问题。

受影响

无。

外部参考

无。

术语表