事务任务管理

• 创建时间: 2011年12月21日
• 贡献者: Yun Mao <maoy AT research.att.com>

这是正在进行中的工作

高可用事务任务管理

问题

Nova中的任务，例如启动实例，由于以下原因，往往复杂且容易出错

• 每个任务可能包含多个步骤，并且执行时间较长。
• 一个任务涉及多个节点，并且容易受到意外错误、节点故障和瞬态网络分区的影响。当发生意外错误时（虽然这种情况不常见），清理过程通常没有经过充分测试。例如，参见bug 837687和839910。
• 多个任务可以操作相同的资源（例如，虚拟机、磁盘卷），从而导致竞争条件。例如，虚拟机可能正在迁移，而用户点击了终止按钮，或者后台仲裁进程（参见instance-state-arbiter蓝图）可能正在尝试修复不一致的状态。

目前没有系统化、可重用的方法来跟踪分布式任务的执行情况。也没有机制来了解当前哪些任务正在使用哪些资源。任务管理被隐式地假定为虚拟机状态管理。

目标

此蓝图建议构建一个高可用服务，以提供一流的任务和资源锁管理API。有了该服务，操作员将具备以下能力：

• 监控每个任务的进度，包括任务正在执行的步骤、运行的节点以及持有的资源锁
• 自动原子回滚：使用撤销函数来处理执行期间的意外错误，以避免不一致的状态。
• 轻松重试失败的任务，或中止（杀死）任务。应适当获取和释放资源锁。
• 无忧的并发控制，以自动避免任务之间的竞争条件和死锁

设计

• 存储：任务状态，包括资源锁，是硬状态，应存储在高度可用且轻量级的组件中，例如ZooKeeper。MySQL可能可以接受，但不是理想选择。
• 任务内容

  - task_id, owner
  - shared and exclusive locks. e.g. ["instance-deadbeef", "volume-1234"]
  - task execution logs for rollback and retry
  - last_updated timestamp
  - state: e.g. [running on node X, waiting on lock Y, aborting, ended]
  - opaque, task-specific information: e.g. imaging, booting, migrating

• 更改任务数据结构的API

  - task_id = create_task()
  - send_signal(task_id, ...) # kill, terminate, etc
  - aquire_locks( tid, type, resource_objects)
  - release_locks(tid, ..)
  - update_task(tid, ...) # execution log, task specific state
  - end_task()

实现

• 更改调度器以利用API来创建、中止或重试任务。
• 更改工作者（计算、网络）以更新任务状态、执行日志并检查中止信号。
• 通过添加撤销声明来更改工作者，以便于自动原子回滚。
• 构建命令行工具，通过查询任务状态进行管理，秉承“ps、kill、top、lsof、strace”的精神

目标：essex发布之后

此蓝图与以下内容相关

https://blueprints.launchpad.net/nova/+spec/instance-state-arbiter

https://blueprints.launchpad.net/nova/+spec/transaction-orchestration

https://blueprints.launchpad.net/nova/+spec/rpc-improvements

http://etherpad.openstack.org/vmstatemachine

https://blueprints.launchpad.net/nova/+spec/fail-gracefully-on-resource-overcommit

---