暴露静态/非静态API¶
https://blueprints.launchpad.net/nova/+spec/expose-quiesce-unquiesce-api
从 Nova 提供静态/非静态API,用于对由一组虚拟机组成的应用进行一致性快照,以实现异地容灾。
问题描述¶
目前,Nova 提供了单虚拟机快照 API (createImage),该 API 会对虚拟机及其相关卷进行一致性快照,并在支持访客代理的情况下自动静态/非静态虚拟机。此方法适用于单虚拟机的一致性快照,但无法对通常由多个虚拟机组成的应用进行一致性快照。
用例¶
在 NFV 场景中,VNF(电信应用)通常由一组虚拟机组成。为了在发生灾难性故障时能够在异地恢复,这组虚拟机的快照/备份/恢复应以事务方式完成,以保证应用级别的一致性,而不仅仅是单虚拟机级别:例如,静态 VM1,静态 VM2,静态 VM3,快照 VM1 的卷,快照 VM2 的卷,快照 VM3 的卷,非静态 VM3,非静态 VM2,非静态 VM1。对于某些电信应用,对于具有强关联性的一组虚拟机,顺序非常重要。
因此,OPNFV 多站点项目期望 Nova 提供静态/非静态API,以便能够以事务方式对一组虚拟机进行一致性快照(而不仅仅是单个虚拟机)。
容灾过程将如下进行:
- 1).DR(异地容灾)软件从 Nova 获取 VNF 中每个虚拟机的卷。
在 VNF 中从 Nova 获取
- 2).DR 软件调用 Nova 静态 API,以保证按预期顺序静态虚拟机。
顺序
- 3).DR 软件在 Cinder 中对这些卷进行快照(注意:因为
存储通常提供快速快照,因此静态和非静态之间的时间间隔很短)
- 4).DR 软件调用 Nova 非静态 API,以逆序非静态 VNF 的虚拟机。
顺序
5).DR 软件从 Cinder 中刚刚创建的快照创建卷。
- 6).DR 软件为这些卷创建(增量)备份到远程
Cinder 中的备份存储(swift 或 ceph,或...)
7).如果此站点发生故障,
- 7.1)DR 软件在远程 Cinder 中恢复这些备份卷。
备份站点。
- 7.2)DR 软件从远程 Cinder 中的可引导卷启动虚拟机。
备份站点并挂载相关数据卷。
注意:如何使用 API 取决于 DR 策略和 VNF 特性。一些 VNF 可能允许 VNF 的备用或集群成员进行静态/非静态操作,以避免干扰 VNF 提供的服务。其他一些 VNF 可能为了 DR 目的而承受短暂的不可用。
不仅 VNF(电信应用)可以从 API 中受益,而且它还应该可用于任何其他应用,以实现应用级别的一致性快照。
项目优先级¶
无
提议的变更¶
暴露“静态”和“非静态”管理 API 操作,供 DR 软件为应用容灾目的创建应用级别的一致性快照。
“静态”和“非静态”已在 VM createImage 中实现,但没有暴露 API。它仅应用于单虚拟机快照场景。
此功能的先决条件是虚拟机管理程序驱动程序支持此操作,并已安装并启用访客代理。
此 BP 主要关注 Nova-API 部分,以暴露 API,nova.virt driver.py 已经提供了“静态”和“非静态”接口,其他一些虚拟机管理程序驱动程序可能现在或将来支持此功能,这应该超出此 BP 的范围。
“静态”和“非静态”API 应该以异步方式工作,这意味着 API 的调用者应该检查操作是否成功完成。DR 软件应保证多个虚拟机的静态/非静态操作的 API 调用顺序。
将添加一个 vm_state“quiesced”。还将添加两个 task_state“quiescing”和“unquiescing”。
命令要求:命令要求 VM 状态要求 任务状态 目标状态 静态 活跃 无 静态 非静态 静态 无 活跃
VM 状态和可能的命令 VM 状态 命令 静态 非静态
如果虚拟机管理程序不支持静态、非静态,则 VM 状态应保持为活动,task_state 将设置为 None,并使用实例操作告知用户发生了什么。
如果在静态、非静态操作期间捕获到异常,VM 状态将设置为错误,异常将像其他操作一样保存到数据库。
无论处于静态还是错误状态,管理员重置 VM 状态操作都将使 VM 进入所需状态。
备选方案¶
通常 Nova API 将每个操作操作一个 VM。一个建议是按顺序对多个 VM 暴露静态、非静态单个 API 操作,这将打破 Nova API 的风格并导致实现复杂性,尤其是在单元部署下。
另一个建议是由于静态、非静态的执行时间短,使得静态、非静态 API 以“同步”方式工作。“同步”实现不是 Web 服务和 Nova API 的风格。
数据模型影响¶
无
REST API 影响¶
- URL
/v2/{tenant_id}/servers/{server_id}/action
/v2.1/servers/{server_id}/action/{server_id}/action
- 请求方法
POST
“静态”的 JSON 请求体
{ "quiesce": null }
“非静态”的 JSON 请求体
{ "unquiesce": null }
此操作不返回响应体
- 正常响应代码
202: Accepted
- 错误响应代码
409:无效实例状态。静态操作期望虚拟机在执行命令前处于活动状态,非静态操作期望虚拟机处于静态状态。虚拟机状态与上述状态不同将导致 409 响应。
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
在进行静态操作时,实例的磁盘写入被阻塞。
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
joehuang
工作项¶
为 Nova 添加“静态”和“非静态”服务器管理操作 API
依赖项¶
无
测试¶
应将使用 qemu-guest-agent 启动的虚拟机的实时静态/非静态操作添加到场景测试中。
还应为此添加一个 tempest 测试。
请注意,这需要支持该操作的虚拟机管理程序环境。
文档影响¶
新的 REST API(服务器管理操作)应添加到 API 文档中。此外,还需要在操作指南中记录如何使用此功能(目前建议您手动使用 fsfreeze 工具,或在 VM createImage 操作中不可见)。
参考资料¶
nova-specs:“在镜像快照期间使用 QEMU 访客代理静态文件系统”:https://review.openstack.org/#/c/126966/
libvirt 驱动程序的“静态”和“非静态”方法:https://blueprints.launchpad.net/nova/+spec/quiesced-image-snapshots-with-qemu-guest-agen/atomic/async
VNF(电信应用)应该能够在发生灾难性故障时在另一个站点恢复:https://git.opnfv.org/cgit/multisite/tree/multisite-vnf-gr-requirement.rst