自动化实时迁移完成策略¶
蓝图：https://blueprints.launchpad.net/nova/+spec/auto-live-migration-completion
有许多策略可以用来帮助实时迁移操作完成。根据操作者对实时迁移完成的重视程度，自动化使用这些策略是可取的。
问题描述¶
当操作者执行实时迁移时，需要监控它以确保其正在取得进展，并采取措施帮助其完成。这需要大量的人力，并且在云运营成本方面非常昂贵。如果实时迁移过程可以自动采取措施尝试完成迁移，那将是更好的选择。
用例¶
作为 OpenStack 云的运营商，我希望实时迁移尽可能地推进到完成，而无需操作者干预。
提议的变更¶
实时迁移处理将自动确定要使用的策略，如果实时迁移由于实例的内存访问或磁盘 I/O 速率而难以完成。
可用的选项如下
最大停机时间设置
为了执行从源实例到目标实例的切换，实时迁移过程需要暂停实例一小段时间。默认值为 500 毫秒，但可以在实时迁移过程中通过 libvirt API 调用进行调整。增加此值可能会使迁移完成。
自动收敛
此功能提供了一种减慢客户机执行速度的方法，以便实时迁移可以将脏内存页复制到目标并完成迁移。必须在实时迁移操作开始之前启用它。如果启用，实时迁移过程将首先将所有内存页复制到目标，然后逐步降低实例的 CPU 速度，直到完成迁移。
默认情况下，它最初会将 CPU 速度降低 30%，然后进一步降低 10% 的增量，直到实例实际上暂停。初始降低和增量大小可以在实时迁移过程中通过 libvirt API 进行调整。但是，这些 API 调用是实验性的，因此 nova 将不会使用它们。
仅当源计算节点上安装了 libvirt 版本 1.2.3 和 qemu 版本 1.6 时，才能使用自动收敛。将添加一个 nova 配置标志，称为 live_migration_permit_auto_converge。此标志可以具有以下值
no - 永远不要使用自动收敛。
- yes - 如果可用且没有更好的迁移
策略可用时使用自动收敛。
事后复制
如果要在迁移开始时使用它，则必须在迁移开始之前启用事后复制。执行 libvirt API 调用以告知它切换。只有在源和目标计算节点上安装了 libvirt 版本 1.3.3 和 qemu 版本 2.5 时，才能使用事后复制。将添加一个 nova 配置标志，称为 live_migration_permit_post_copy。此标志可以具有以下值
no - 永远不要使用事后复制。
yes - 如果可用则使用事后复制。
Nova 将允许实时迁移过程首先将所有内存页复制到目标，然后再考虑切换到事后复制模式。切换到事后复制将导致目标上的实例变为活动状态，而不是源节点上的实例。然后，qemu 将开始从源拉取尚未更新到目标上的内存页。如果目标实例尝试访问尚未复制到目标的内存页，qemu 将从源获取该页。
使用事后复制会影响切换到事后复制模式后实例的性能。此外，一旦进入事后复制模式，如果迁移处理失败，则实例将崩溃并需要重新启动。
实时迁移策略
如果迁移未完成但已复制了大部分内存，则逐步增加切换期间允许的停机时间，直到迁移完成或达到配置的最大停机时间。
仅当 live_migration_permit_auto_converge 设置为“yes”且 live_migration_permit_post_copy 设置为 no 或由于使用的 libvirt 和 qemu 版本而不可用时，才会使用自动收敛。
如果可用，将根据需要使用事后复制来完成迁移。Nova 应该允许迁移在预复制模式下运行一个内存页复制迭代，然后它应该开始监控剩余数据高水位线。如果每个迭代剩余数据高水位线没有减少至少 10%，则表明实时迁移无法在合适的时间范围内完成。此时，Nova 将自动切换到事后复制模式。
如果可用且未启用事后复制，则将启用自动收敛功能。
强制完成实时迁移
对正在进行的实时迁移执行“live-migration-force-complete”操作可以将实例置于暂停（在 libvirt 术语中为暂停）状态，以便允许迁移完成。当迁移完成并切换到目标时，它将自动恢复。
建议当操作者执行 live-migration-force-complete 操作时，所采取的措施取决于是否可用事后复制功能。如果可用，即 live_migration_permit_post_copy 设置为“yes”并且受使用的 libvirt/qemu 版本支持，则将执行切换到事后复制模式，而不是暂停实例。但是，如果在完成第一次内存页复制迭代之前执行 live-migration-force-complete 操作，它将推迟切换到事后复制，直到完成第一次内存页复制迭代。将使用迁移内存计数器来确定是否已完成第一次内存复制周期。这可以通过比较已处理的内存和内存总数来实现。如果已处理的内存超过内存总数，则至少已完成一次完整的内存复制周期。
尝试在切换到事后复制后中止实时迁移将被拒绝。如果迁移已切换到事后复制模式，libvirt 将拒绝中止作业 API 调用。但是，当驱动程序发出切换到事后复制模式的请求时，它可以更新迁移状态以指示事后复制模式生效，即将其从“running”更新为“running (post-copy)”。“live-migration-abort”调用的 API 方法可以增强，以检查迁移状态以确保它不在事后复制模式中。如果切换到事后复制发生在 API 中的检查之后但在驱动程序执行中止之前，我们将依赖 libvirt 拒绝中止请求。
请注意，一旦执行了切换到事后复制的操作，就无法使用 live-migration-force-complete 来暂停实例。请注意，如果可用事后复制功能，则“live-migration-force-complete”操作将切换到事后复制，而不是尝试暂停实例，因此不应该出现问题，libvirt 将拒绝尝试将迁移操作切换到已经处于事后复制模式的迁移。如果 live_migration_permit_post_copy 标志在实时迁移操作期间更改（即，如果将来设置为可变，请参阅 https://review.openstack.org/#/c/280851/），则存在“live-migration-force-complete”操作将尝试暂停处于事后复制模式的实例的风险。可以通过“live-migration-force-complete”调用的 API 方法检查迁移状态来解决此问题，如上所述。如果切换到事后复制发生在 API 中的检查之后但在驱动程序执行暂停之前，则实例将被不必要地暂停，但这不会造成任何损害，因为源实例在切换到事后复制后将不会处于活动状态。
备选方案¶
一种替代方案是不这样做，让操作者来管理实时迁移。
另一种方法是通过 nova 配置标志启用或禁用迁移选项（例如事后复制、自动收敛和最大停机时间设置）。全局启用这些选项可能会导致客户抱怨实例性能和可用性，因为使用这些功能可能会对实例性能产生重大影响。
另一种方法是向操作者提供 API，以便他们在实时迁移之前和期间选择和调整这些设置。但是，不希望将驱动程序特定内容暴露给 Nova API。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
如果可用且已启用，则事后复制功能将改变 live-migration-force-complete 操作的影响。
性能影响¶
对 Nova 管理应用程序性能没有重大影响（即计算管理器）。但是，迁移对正在迁移的实例的影响将取决于使用的迁移策略。
其他部署者影响¶
操作者在执行影响 libvirt 或 qemu 的操作时需要小心，以确保他们不会对正在进行的操作（例如实时迁移）产生不利影响。
开发人员影响¶
无
实现¶
负责人¶
主要负责人：Paul Carlton (irc: paul-carlton2)
其他负责人：None
工作项¶
更新实时迁移启动和监控代码。
依赖项¶
请参阅下面的参考资料。
测试¶
将根据需要添加单元测试。
文档影响¶
无
参考资料¶
使用 KVM 确保迁移完成的技术分析 https://www.berrange.com/posts/2016/05/12/analysis-of-techniques-for-ensuring-migration-completion-with-kvm/
历史¶
发布名称 |
描述 |
|---|---|
Newton |
引入 |
