改进 Nova 实例计量¶
https://blueprints.launchpad.net/ceilometer/+spec/improve-nova-instance-metering
目前 Ceilometer 使用“compute”命名空间的轮询会周期性地对 Nova API 造成很大的负载。本提案旨在通过放弃当前使用周期性轮询收集指标的方式来降低负载。
注意：之前名为 ceilometer-agent-compute 的 Ceilometer 轮询服务使用“compute”命名空间。
问题描述¶
考虑以下示例。在一个拥有 500 个计算节点的环境中，每个计算节点都部署了使用“compute”命名空间的 ceilometer-polling（这是我们公司真实的部署规模）。轮询间隔设置为 60 秒。在每个轮询周期中，ceilometer-polling 将调用“instance_get_all_by_host()”方法（可能还需要查询镜像和 flavor）从 Nova API 查询该主机的实例。这意味着 Nova API 每分钟会收到 500 个请求。这将大大增加 Nova API 的工作负载。
在元数据缓存提案[1]中，Nova 的实例信息通过 Nova server-list API 的“change-since”查询过滤器被缓存在 ceilometer-polling 中。这显著减少了每次 Nova 查询的项目数量。但它无法帮助减少查询频率。
为了说明这一点，我们假设一个主机最多可以部署 100 个实例。使用提案[1]，每次 Nova 列表请求返回的实例数量可能会从 100 个减少到 20 个，这并不是一个显著的改进。但通过本次提出的更改，可以将 Nova API 请求次数从每分钟 500 次减少到每分钟 1 次，这将是一个显著的改进，也是本提案的目标。
提议的变更¶
本提案尝试通过以下更改来解决上述问题
具有“compute”命名空间的 ceilometer-polling 代理在每个计算节点上运行。当前，代理需要通过调用 novaclient 的“instance_get_all_by_host”方法获取该主机的实例列表，然后遍历此实例列表以通过 inspector 获取实例指标（例如 cpu、disk.read.bytes、network.incoming.bytes），这将调用 virt 层的接口来获取此指标数据。然后 ceilometer-polling 将从 virt 层组装指标数据和来自 Nova API 的实例信息作为样本对象。
相反，此更改希望添加一种全局缓存机制来缓存资源元数据（来自 Nova db 的实例信息）。ceilometer-polling 将使用“instance_get_all”查询 Nova 中的所有实例，然后将其缓存到全局缓存中。此外，ceilometer-polling 还会将资源缓存时间记录到缓存系统中，并添加一个名为“interval_to_update_resource”的选项来指示资源缓存更新的最大间隔。如果从上次更新的时间超过此选项值，则需要再次更新资源缓存。
“change-since”也将用作“instance_get_all”的查询过滤器，以大幅减少每次查询的数量，并仅将更改的实例更新到资源缓存。
在每个 ceilometer-polling 的每个计算节点上，与之前不同，如果缓存的资源未过期，代理将尝试从全局资源缓存查询该主机的实例列表，否则，将查询 Nova API 中的所有实例以更新缓存的实例资源并获取该主机的实例。其余过程与之前相同。上述“过期”是指从上次缓存资源更新的时间超过“interval_to_update_resource”选项值。
它允许用户启用/禁用此全局资源缓存机制，禁用此机制时，过程与之前相同，ceilometer-polling 不会使用全局缓存，而是使用提案[1]实现的本地缓存。
替代方案¶
另一种资源元数据更新解决方案
另一种建议的解决方案是通过通知中的实例事件而不是通过轮询实例指标来收集实例资源元数据来实现此目标。
使用事件在 Ceilometer 或 Gnocchi 中更新资源元数据将更有效，因为资源元数据可能只需要在资源发生变化时更新。但我对此方法有一些担忧
资源元数据更新将取决于事件收集，如果某些事件未被收集怎么办？
我们需要确保 OpenStack 的其他项目中所有资源更新操作都有相应的事件发布，这需要其他资源提供者来确保。
所有事件是否包含 Ceilometer 所需的足够信息？我们可能需要对资源元数据进行一些过滤查询。例如，使用按实例元数据过滤的查询进行自动缩放。
另一种使用全局缓存的位置
与其由 ceilometer-polling 服务的计算轮询器直接使用全局缓存，不如将其用于 notification-agent 服务中的全局缓存。实例信息将被轮询并缓存到全局缓存中，指标数据将被 ceilometer-polling 轮询并发送到 notification-agent，在 notification-agent 中，实例信息将从全局缓存查询，然后将实例信息和指标数据组装成样本对象，然后推送到管道。
通过此提案，资源元数据不会从 ceilometer-polling 传递到 notification-agent，只有轻量级的指标数据才会被推送到 notification-agent。在大型部署中，这也会显著降低消息总线上的负载。
数据模型影响¶
无。
REST API 影响¶
无。
安全影响¶
无。
Pipeline 影响¶
无。
其他最终用户影响¶
无。
性能/可扩展性影响¶
需要部署外部全局缓存系统，更多详细信息请参见[2]。
其他部署影响¶
无。
开发者影响¶
无。
实现¶
负责人¶
- 主要负责人
liusheng
- 持续维护者
liusheng
工作项¶
实现全局资源缓存机制以缓存实例信息。
更改实例指标发现以使用缓存的资源。
未来生命周期¶
无
依赖项¶
无
测试¶
当前的测试需要修改以适应这些更改。
应添加单元测试以覆盖这些更改。
文档影响¶
应更新文档以添加对此的描述。
