跳转到： 导航, 搜索

EfficientMetering

OpenStack 计量蓝图

项目主页: Ceilometer

会议: https://wiki.openstack.org/Meetings/MeteringAgenda

用例

  • 需要一个工具来收集每个客户的使用情况
  • 需要一个 API 来查询现有计费系统中的收集到的数据
  • 所需数据，每个客户，小时级粒度，包括
    • 计算 - Nova
      • 实例 (类型，可用区) - 每小时使用量
      • cpu - 每小时使用量
      • ram - 每小时使用量
      • nova volume 块设备 (类型，可用区) - 每小时使用量
        • 保留
        • 已用
    • 网络 (数据进/出，可用区) - 每小时字节数 + 总字节数
      • 区分内部和外部端点
      • 外部浮动 IP - 每小时字节数 + 总字节数
  • 存储 - Swift
    • 总存储数据
    • 数据进/出 - 每小时字节数 + 总字节数
    • 区分内部和外部端点

建议设计

计量

当前已实现计量器的更完整列表可在 https://docs.openstack.org/developer/ceilometer/measurements.html 找到

以下是需要收集的计量器的初始列表，以便计费系统执行其任务。此列表必须随着时间的推移而可扩展，并且每个管理员必须能够根据其本地需求启用或禁用每个计量器。

计量器名称 组件 资源 ID 单位 有效载荷 注意
c1 instance nova compute 实例 ID 分钟 type 类型是使用的实例 flavor ID
c2 cpu nova compute 实例 ID 分钟 type Arm|x86|x86_64])
c3 ram nova compute 实例 ID 兆字节
c4 disk nova compute 实例 ID 兆字节 系统磁盘在实例关闭但未终止时保留，必须进行统计
c5 io nova compute 实例 ID 兆字节 磁盘 IO 每秒兆字节对服务可用性有很大影响，可以单独计费
v1 bd_reserved nova volume volume ID 兆字节
v2 bd_used nova volume volume ID 兆字节 (可选)
n1 net_in_int nova network IP 地址 千字节 从内部网络源接收的数据量
n2 net_in_ext nova network IP 地址 千字节 从外部网络源接收的数据量
n3 net_out_int nova network IP 地址 千字节 发送到内部网络目标的数据量
n4 net_out_ext nova network IP 地址 千字节 发送到外部网络目标的数据量
n5 net_float nova network IP 地址 分钟 type 类型根据其分配策略区分公共 IP，例如 IPv6 或 IPv4_FROM_RIPE 或 IPv4_FROM_OVH 等。浮动 IP 的获取或维护成本可能取决于其分配策略。
o1 obj_volume swift swift 帐户 ID 兆字节 存储的总对象体积
o2 obj_in_int swift swift 帐户 ID 千字节 从内部网络源接收的数据量
o3 obj_in_ext swift swift 帐户 ID 千字节 从外部网络源接收的数据量
o4 obj_out_int swift swift 帐户 ID 千字节 发送到内部网络目标的数据量
o5 obj_out_ext swift swift 帐户 ID 千字节 发送到外部网络目标的数据量
o6 obj_number swift swift 帐户 ID 容器 存储在容器中的对象数量。资源 ID 是容器 ID。
o7 obj_containers swift swift 帐户 ID 容器数量
o8 obj_requests swift swift 帐户 ID type HTTP 请求数量，类型是请求类型 (GET/HEAD/PUT/POST…)
i1 image_upload glance 镜像 ID (离散) 1 让我们统计创建的镜像数量，或者为每次上传收取固定费用

其他可能的计量器

  • 服务处理程序 (负载均衡器、数据库、队列...)
  • 服务使用情况

注意网络计量器 (n1-n4): 区分内部和外部流量需要显式列出代理配置中的内部网络。

注意(dhellmann): 这将无法扩展到实际系统，租户可能会创建自己的网络。我们应该只收集每个网络的的数据，让计费系统决定以什么费率收费 (可能内部网络为 $0)。

存储

字段名称 类型
来源  ?
user_id 字符串
project_id 字符串
resource_id 字符串
resource_metadata 字符串
meter_type 字符串
meter_volume 数字
meter_duration 整数
meter_datetime 时间戳
message_signature 字符串
message_id
  • 数据库不能通过 API 以外的任何方式直接访问
  • 必须有一个进程从代理收集消息并存储数据
  • 一个进程可以对照 nova 事件数据库验证计量器
  • 一个进程可以验证消息是否丢失
  • 一个进程可以验证帐户状态是否与 keystone 同步

注意: instance_metadata 字段内容针对每个计量器重复。例如，它将针对所有 c? 字段重复。存储优化将在 Ceilometer 的未来版本中处理。

注意: 存储可以折叠记录，或者 API 可以折叠记录以优化减少返回的信息量。例如，如果两个连续 c1 计数器的所有字段相等，并且它们在时间上相邻 (即 meter_datetime[second] - meter_datetime[first] == meter_duration[second] - meter_duration[second])，则可以删除第一条记录，因为它具有冗余性。

替代计量设计

在 Folsom ODS 会议期间，讨论了一种替代设计，其中事件而不是记录 delta，将记录计量器的绝对值。这将需要扩展事件以包含与计量器关联的“对象 ID” (实例、网络、卷)。

delta 模型可以从绝对模型导出，这意味着它在缺少 delta 注册时具有弹性。

代理

  • 每个 nova compute 节点上的代理，以累积和发送 c1、c2、c3、c4、c5、n1、n2、n3、n4 的计量器。该代理可能正在从 libvirt 中提取此信息。
    • c5 可以使用 libvirt 的 virDomainBlockStats 获取磁盘 I/O 统计信息
    • n3 / n4 可以使用 iptables 记账规则？ (外部流量？)
    • n1 / n2 可以使用 libvirt 的 virDomainInterfaceStats？ (所有流量？)
  • 每个 nova volume 节点上的代理，以累积和发送 v1、v2 的计量器
  • 每个 swift 代理上的代理，以转发现有的记账数据 o1 并累积和发送 o2-o5

注意: nova network 节点不需要累积和发送 n5 的计量器，因为它们可以直接从 nova 数据库中提取 (例如 nova-manage floating list)

架构

请参阅 EfficientMetering/ArchitectureProposalV1

  • 一个代理在每个 OpenStack 节点 (裸机) 上运行，并本地收集数据
    • 如果计量器来自现有的 OpenStack 组件，则应使用它
    • 一个独立的 Ceilometer 代理实现尚未由现有的 OpenStack 组件提供的计量器
  • 存储守护程序与代理通信以收集其数据并进行聚合
  • 收集数据的代理经过身份验证以避免污染计量服务
  • 数据通过受信任的消息传递系统 (RabbitMQ?) 从代理发送到存储守护程序
  • 代理和存储守护程序之间交换的消息使用通用的消息格式
  • 存储的内容通过提供聚合的 REST API 提供
  • 消息队列与其它队列 (例如 nova 队列) 分开
  • 队列中的消息已签名且不可否认 (http://en.wikipedia.org/wiki/Non-repudiation)

注意(jking-6): 消息格式应使用协议缓冲区。JSON 字节字符串占用太多带宽和解析时间。

注意: 记录一些用例场景以真正确定架构。谁向计量服务发出信号？API 服务还是 nova、quantum、swift、glance、volume？

注意: 理想情况下，所有计量器都来自负责给定资源的 OpenStack 组件 (例如，临时磁盘的磁盘 I/O 在 nova 中可用)。但是，假设它始终可以实现是不现实的。在 OpenStack 节点上运行的独立的 Ceilometer 代理提供了在 OpenStack 组件不提供计量器时的访问权限。在 Ceilometer 代理中实现的计量器应始终贡献给 OpenStack 组件。这种针对每个给定计量器的孵化 (首先在 Ceilometer 代理中实现，然后在 OpenStack 组件中实现) 既对短期目的实用，也是一种健全的长期实践，可以避免分叉代码。

消息传递用例

实例创建

  • 创建实例，nova 发送消息 ( https://wiki.openstack.org/SystemUsageData )
  • 计量存储代理侦听 nova 队列并获取创建消息
  • 计量存储代理将创建事件本地存储，并带有时间戳
  • 代理通知计量存储守护程序，实例创建于五分钟前，并将此信息聚合到租户记录中

API

数据量

计量系统始终会生成大量数据。为了估计您的云可能生成的数据量，已提出 Google 表格。

贡献给 Ceilometer

开发人员文档正在形成 在源代码中 并且也以更友好的格式发布在 http://ceilometer.readthedocs.org 上。

项目团队在 Freenode 的 #openstack-metering 频道中闲逛，欢迎随时加入并停留尽可能长的时间来讨论您的未来实现。我们使用 OpenStack 通用邮件列表 进行我们的电子邮件讨论，主题标记为 [metering]。

如果您想知道可以为 Ceilometer 贡献什么，这里有一个我们缺少的功能列表。

路线图

See EfficientMetering/RoadMap

免费软件计费系统

当可用时，可以使用计量系统的计费系统实现列表。

相关资源

资源

  • Julien Danjou 在 2012 年 7 月用来展示 Ceilometer 的 幻灯片。

常见问题解答

问：为什么重复造轮子？XXXX 已经实现了它。

答：请将您认为可以完成这项工作的工具发到邮件列表，除非它已经在下面列出。

  • https://wiki.openstack.org/SystemUsageData 例如，是专门针对 nova 的，而计量旨在汇总所有 OpenStack 组件
  • collectd、munin 等都有一些拼图碎片，但它们没有全部，并且没有为计费而设计，不适合这个蓝图
  • Riemann -- http://aphyr.github.com/riemann/concepts.html 我能够在下午搭建一个基本的仪表板。即使它不适合这个项目，也有很多值得借鉴的好点子：协议缓冲区、基于推送的数据流图、极其简单的 API（流处理器只是接受单个参数的函数，即事件消息）。
从 "https://wiki.openstack.org/w/index.php?title=EfficientMetering&oldid=75190" 检索而来