将计算更新从周期性改为按需¶
包含您的 Launchpad 蓝图的 URL
https://blueprints.launchpad.net/nova/+spec/on-demand-compute-update
目前，所有计算节点都在数据库中以周期性方式（当前周期为 60 秒）更新状态信息。鉴于节点状态仅在特定时间点发生变化（主要是镜像创建/销毁），这会导致大型系统中的数据库开销显著增加。此 BP 将更新机制更改为仅在节点状态发生变化时更新数据库，具体是在节点启动、实例创建和实例销毁时。
问题描述¶
计算节点的状态信息以周期性方式更新到数据库中。这意味着系统中的每个计算节点每 60 秒（此更新的默认周期）在数据库中更新一行。鉴于状态信息大多是静态的并且不经常变化，主要是在创建或销毁实例时才会发生变化，因此这是不必要的且存在可扩展性问题。
提议的变更¶
计算节点仅在状态发生变化时发送更新。在周期性间隔（使用当前默认周期 60 秒）内，计算节点会将自身的状态与上次更新时保存的状态进行比较。只有当状态或声明发生变化时，才会更新数据库。
这种方法的优点是它应该显著减少数据库更新的数量，同时几乎不会改变系统当前的工作方式。计算节点的变化仍然需要 60 秒才能更新，但任何原因导致的任何变化最终都会被报告。
一个潜在的问题是可能的敏感性问题，如果例如，稳定系统活动导致 RAM 使用量略有变化，则不应持续发送更新。需要进行一些实验来确定是否需要为某些状态指标添加敏感性控制。如果需要，这可以作为后续优化，因为此设计不会比当前机制更差。
备选方案¶
另一个想法是在某些明确定义的事件时才更新数据库。更新代码仅会在系统启动、实例创建和实例删除时调用。这将减少状态更新的延迟（数据库在系统状态发生变化时立即修改），但它存在一些缺点
1) 找到所有记录状态变化的适当事件。启动/创建/销毁是否是系统状态发生变化的唯一位置，也许还有其他事件应该被跟踪。
2) 未来的更改可能会添加新的更改状态的事件，并且识别需要更新是一个容易忽略的错误。
3) 状态可能在 nova 代码不知情的情况下发生变化，例如内存的热插拔。
数据模型影响¶
数据库中存储的数据没有变化，所有当前字段都以相同的方式存储，此 BP 只是更改了更新这些字段的频率。
REST API 影响¶
无。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
根据数据库更新的测量结果，此更改显然不会导致比当前技术更多的数据库更新，并且假设节点上实例的创建速率低于每 60 秒一个，应该导致更少的数据库更新。
其他部署者影响¶
无。
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Don Dugger <donald.d.dugger@intel.com>
其他贡献者
工作项¶
更改应该相当简单，将当前更新代码更改为仅在“state_modified”例程返回 true 时才更新数据库。“state_modified”例程如果当前状态与上次记录的状态匹配则返回 false。否则，它将当前状态保存为上次记录的状态并返回 true。
“state_modified”例程维护一个内存副本，其中包含计算节点的当前状态。将此状态的副本与当前状态进行比较，并且仅当副本和当前状态不同时才发生数据库更新。请注意，内存副本在节点启动时初始化为零值，因此第一次周期性更新调用将发现两个状态之间的不匹配，并且数据库将被更新。
基于实验，确定简单比较整个当前状态与保存状态就足够了。如果将来将更多快速变化的数据添加到计算节点状态中，而这些数据不应存储在数据库中，则可以轻松更改“state_modified”以忽略不需要的此类数据。
依赖项¶
无。
测试¶
将创建一个单元测试，以确保在计算节点状态发生变化时更新数据库，并且在状态未发生变化时不会更新数据库。
文档影响¶
Associate Training Guide 的第 5 节
https://docs.openstack.org/training-guides/content/associate-computer-node.html
略有不正确，应该进行修复。目前它说“所有计算节点（在 OpenStack 术语中也称为主机）会定期通过队列将其状态、可用资源和硬件功能发布到 nova-scheduler。” 这应该修改为反映状态更新到数据库中，然后调度器查询数据库。（请注意，这是一个通用修复，与此蓝图无关。）
参考资料¶
无。
