Ceilometer/blueprints/support-for-advance-service-billing-models

概要

额外服务（例如 PaaS）的推出，突显了计量架构的需求，该架构能够支持 Ceilometer 收集器当前无法处理的高级计费模式。具体用例包括直接 Nova 计费、Windows 实例以及 PaaS 服务控制器拥有的 Nova 实例（即控制器与用户租户 ID）、PaaS 应用程序计费以及数量和超额计费的变化。添加对这些模型的支持可能会影响收集、数据存储和访问控制方法。

主要用例

用例	子用例	详情
Nova 实例的直接计费（基本用例）		Nova 计算服务及其相关服务的标准用法；每个 Nova 实例都由单个最终客户租户拥有。在 Nova 中运行的镜像不包含任何特殊的许可条款，因此不会对使用费增加任何额外的费用。使用情况报告捕获该实例使用的资源（CPU、IO、网络、卷存储）并将其归因于客户租户。租户直接为使用情况付费。
已许可的 Nova 实例		正在运行已许可镜像（操作系统或应用程序）的 Nova 实例，租户可能需要为此支付高于基本实例使用费的额外费用。实例由租户帐户拥有和管理，因此使用记录直接归因于租户帐户。此用例需要一种识别已许可镜像的机制，以便可以对其进行处理和计费。 此用例的一个例子是运行 Windows 的镜像。这些镜像可能与一个额外费用（例如，许可费）相关联，因此系统必须提供关于镜像和实例的适当元数据，以便应用适当的费用。
由 PaaS 服务控制器拥有的服务实例使用费的高价计费		这是已许可 Nova 实例用例的变体（即，对特别许可的操作系统或应用程序功能进行高价计费），但具有不同的 VM 实例所有权/管理模型。由 PaaS 服务控制器实例化和管理的 Nova 或其他服务实例，该控制器在其自己的帐户下运行。具体来说，实例分配的 tenantID 与服务控制器相关联，而不是实际用户。用户不直接控制该实例，而是访问运行在其之上的抽象服务，并且他们购买的是该服务。使用情况报告以与基本 Nova 用例相同的方式进行，但使用记录中的 tenantID 是服务控制器的 tenantID。需要机制来 识别与此服务类型关联的使用记录 将实例映射到实际的最终租户帐户
托管应用程序计费		用户为在 Nova 实例集合上运行的应用程序付费，而主机 Nova 实例本身可能未被计量。运行这些类型应用程序的 Nova 实例必须可识别，以便进行适当的处理。在许多情况下，这意味着底层 VM 的使用情况不会被计费，而是跟踪一组应用程序使用记录。此模型有三种变体（如下所示）
	持续订阅	用户订阅服务并根据订阅持续时间付费。使用情况报告必须跟踪订阅的创建、持续存在和状态、删除，并生成适当的计费记录。用户无需为底层 VM 实例或支持订阅生成的特定活动付费。 此计费模型的一个例子是监控服务。用户订阅以监控一个或多个实例。在订阅期间，系统必须生成一组跟踪订阅状态的使用记录。
	基于仪表数量的使用	用户使用在 VM 实例上运行的服务。他们为生成的实际仪表数量付费，而不是 VM 的底层使用情况。此类型服务的使用记录将包含自定义仪表和关联数量。 此计费模型的一个例子是消息传递服务。用户将注册该服务，但可能仅为他们生成的消息数量付费。
	超额使用	此模型是订阅和数量应用程序计费模型的组合。在这种情况下，用户将订阅基本服务，但如果其使用量超过特定阈值，则会产生额外费用。

通用说明/注释

1. 使用情况处理必须包含状态的概念，因为这会影响被监控组件的可计费状态。例如，VM 可能会运行并生成使用记录，但处于错误状态。根据提供商的计费策略，这可能会导致用户无需为此期间付费。

2. 需要能够合并进行计费处理所需的其他元数据：服务位置、服务类型、帐户层次结构（超出 OpenStack 租户概念）

问题

为了启动对话，以下是我们正在评估的几个问题，并且希望进行坦诚的讨论

1. 当前的 Ceilometer 收集机制（通常：中央代理+插件）是否提供了构建这些用例所需的各种仪表板的足够框架？
2. 在收集的数据量以及关联跨多个租户/项目/资源的数据的能力方面，存储收集的数据有什么影响？
3. 访问 Cinder/Quantum/Nova/RedDwarf 通知并利用它们进行计费有什么具体的障碍？

© 版权所有 2013 Hewlett-Packard Development Company