跳转到： 导航, 搜索

VMStateCleanupService

  • Launchpad 条目: NovaSpec:compute-instance-cleanup-service
  • 创建时间: 2012年5月9日
  • 贡献者: MandarVaze

总结

清理在特定操作期间卡住的各种虚拟机实例

发布说明

原理

Nova 操作依赖于各种 Nova 服务，以及数据库和 RabbitMQ 等外部组件。在创建/删除等操作的生命周期中，如果其中一个组件崩溃，则实例的状态将卡住。

用户无法从这种状态恢复实例。某些状态会阻止删除此类实例，从而导致仅占用资源的“悬挂”实例。

与此蓝图相关的几个实例卡住的 bug： https://blueprints.launchpad.net/nova/+spec/compute-instance-cleanup-service

用户故事

用户无法访问或删除卡住的虚拟机实例。

目标

需要一个清理服务来识别这些实例并修复其状态。

  • 最坏的情况是将 vm_state 标记为 Error（以便用户可以删除 VM 并回收资源）
  • 最好的情况是将其回滚到 ACTIVE 状态（请参阅 https://review.openstack.org/#/c/6632/ 的审查评论）

问题

  • 无法确定实例是否卡住，每个操作都没有明确定义的超时时间
  • 只能从 vm_state 和 task_state 的组合中推断 VM 的状态。不幸的是，这种组合无法提供足够的粒度来确定实例卡在哪个阶段。这在恢复期间可能很有用。

前提条件

  • 调用清理服务时，所有 Nova 进程以及数据库和 RabbitMQ 等第三方进程都已启动并正在运行。（否则清理任务可能会失败。）
  • 因此，它必须是一个单独的脚本 - 由手动调用。
    • Compute 中的周期性任务可能过于复杂，而且如果其他服务仍然关闭，则会浪费精力重复尝试
  • 在 Nova Compute 主机上执行
    • 它将在需要时对 Nova Network、Nova Volume 执行 RPC。所有其他操作都在本地完成。
    • 可以添加 Compute API，如果需要可以从远程机器调用

设计

定义超时时间

引入一组预定义的“操作允许的最大时间”查找表。这些可以从 nova.conf 中覆盖，例如：


#!highlight python
cfg.IntOpt('buildserver_maxtime',
		   default=3600, #One hour
		   help='How long can VM stay in building server state ? (In Seconds)'),
cfg.IntOpt('snapshot_maxtime',
			default=23200, #12 hours
			help='How long can VM stay in snapshoting state ? (In Seconds)'),


清理服务将使用这些值和“上次更新的时间”来确定“卡住”的 VM。

定义粒状任务子状态

来自 https://github.com/maoy/nova/tree/orchestration 的代码更改（与 https://wiki.openstack.org/TransactionalTaskManagement 相关）提供了一种有用的机制来捕获有关 task_state 的更多详细信息。

我们需要检查点，例如

 

task.update_task_info(context, "api.create.start") 
task.update_task_info(context, "api.create.end")

task.update_task_info(context, "scheduler.run_instance.start")
task.update_task_info(context, "scheduler.run_instance.end")

task.update_task_info(context, "compute.allocate_for_instance.start")


在操作的各个位置。

通用格式 <NovaProcess>.<function_name>.<start/end> 这类似于通知服务当前使用的检查点。

需要了解如何获取特定实例的 task_info（基于上下文吗？）

清理服务 - 正在进行中

  • 获取深度不为 None 且 time_since_last_update 大于 task_state 允许超时的卡住实例列表
  • 清理卡住的创建服务器操作
    • 如果 task_info 以 `api` 或 `scheduler` 开头
  • 失败太早，将状态设置为 ERROR.None。无需清理
    • 如果 task_info 以 `compute` 开头
      • 根据子任务 - 调用 _deallocate_network、_shutdown_instance 和 _cleanup 方法
      • 将状态设置为 ERROR.None
  • 清理卡住的删除服务器操作

实现

待定

UI 变更

待定

代码变更

待定

迁移

待定

测试/演示计划

待定

BoF 议程和讨论

  • 清理服务是否应该只 _修复_ vm_state 并让用户执行显式删除操作？还是应该尝试释放资源？
    • 即使我们释放了资源，稍后用户手动删除实例（因为它处于 ERROR 状态） - 日志中可能会出现一些错误，但实例最终将被删除。
  • 如何有效地使用 task_info 和 task_log？
  • 清理服务是否需要（复杂的）状态机？

链接

从 "https://wiki.openstack.org/w/index.php?title=VMStateCleanupService&oldid=17797" 检索