Juno 的从机更多周期性任务¶
https://blueprints.launchpad.net/nova/+spec/juno-slaveification
在 Icehouse 开发周期中，我们为部署者提供了将 nova-compute 周期性任务的大部分读取操作卸载到 DB 复制从机的选项。 我们将在 Juno 中继续这项工作，通过“从机化”适当的其余周期性任务来实现。
问题描述¶
目前，Nova 扩展数据库读取和写入的常用方法是进行多主设置或使用某种数据库集群。 这种方法的缺点是，虽然通过提供更多硬件资源（CPU、RAM、iops 等）可以潜在地提高读取可扩展性，但写入可扩展性会降低，并且会继承更多的运维复杂性。
提议的变更¶
我希望继续在 Icehouse 中所做的工作，完成周期性任务的“从机化”。
备选方案¶
扩展读取和写入的替代方法有
-通过某种分片方案在应用程序内处理扩展。 -在 DB 级别处理扩展。
Nova 目前拥有分片模型，cells。 可以认为，将时间花在改进这种方法上，而不是花时间尝试使用可用的 DB 技术来扩展它，会更好。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
没有负面变化，希望这能让我们从“写主”服务器上卸载一些负载，并将其卸载到从机或从机群。
其他部署者影响¶
如果部署者更改了数据库部分中的 slave_connection 配置参数，则假定他们接受所有来自周期性任务的读取操作都发送到该连接的行为。 部署者需要了解并清楚复制数据库从机的运行含义，以及从该从机获取可操作数据的影响。 这些包括但不限于
-需要监控从机状态 -运维人员熟悉复制从机的维护 -可能在操作略微过时的的数据
开发人员影响¶
开发人员应考虑哪些读取操作可能受益于可选地使用从机句柄。 在引入新的读取操作时，请考虑代码调用的上下文。 如果此代码在可能过时的的数据上运行，会产生影响吗？ 卸载读取操作的好处是否大于因处理旧数据而造成的不便？
实现¶
负责人¶
- 主要负责人
<geekinutah>
- 其他贡献者
<None>
工作项¶
从机化 nova/compute/manager.py 中的以下周期性任务
update_available_resource _run_pending_deletes _instance_usage_audit _poll_bandwidth_usage _poll_volume_usage
依赖项¶
我们需要一个 bw_usage 对象，这在 https://blueprints.launchpad.net/nova/+spec/compute-manager-objects-juno 中涵盖。
测试¶
目前，Tempest 中没有针对读取操作转到替代从机句柄的测试。 我们应该在我们的测试运行中添加一个复制从机，并启用和禁用 slave_connection 来测试周期性任务。
文档影响¶
操作指南应更新，并提供有关设置和维护从机的 MySQL 和 Postgres 文档的说明。 我们还应该讨论使用异步从机和处理此问题的各种自动化框架的 HA 可能性。 解释指定 slave_connection 主要是一个扩展功能，但使用它来实现可用性的能力也是存在的，也是一个好主意。
参考资料¶
https://wiki.openstack.org/wiki/Slave_usage
带有代码历史记录和讨论的原始蓝图：https://blueprints.launchpad.net/nova/+spec/db-slave-handle
Icehouse 蓝图：https://blueprints.launchpad.net/nova/+spec/periodic-tasks-to-db-slave
