实现主机故障工作流的 RESERVED_HOST 恢复操作¶
https://blueprints.launchpad.net/masakari/+spec/implement-recovery-methods
本文档讨论为主机故障工作流添加 RESERVED_HOST 恢复操作。在 masakari 中，每个故障转移段都定义了 recovery_method，以便在该故障转移段内的任何主机发生故障时，将根据 recovery_method 执行恢复操作，以从该主机驱逐“HA_Enabled”或所有实例，具体取决于“evacuate_all_instances”配置选项。
什么是 RESERVED_HOST？
在每个故障转移段中，操作员会通过禁用这些主机上的计算服务并将该主机的“reserved”属性设置为“True”来保留一些主机。因此，这些主机在配置新实例或执行任何其他实例操作（如调整大小、迁移等）时不会被 nova 调度器选中。这些主机可以由 masakari 引擎用于从故障主机驱逐实例。一旦保留主机被用于驱逐实例，它就不再被视为保留主机，nova 调度器可以使用该主机来调度实例。
问题描述¶
Masakari 提供了一个驱动程序接口，用于同步或异步地实现工作流。任何想要实现工作流的人都可以继承 masakari 驱动程序并实现工作流。
为了实现 RESERVED_HOST 恢复操作，masakari 引擎应向驱动程序提供与其故障转移段关联的保留主机列表。然后，驱动程序的工作是执行工作流并使用此列表从故障主机驱逐实例。工作流的一个任务是在保留主机上启用计算服务，以便可以将实例驱逐到该主机上。同时，需要将该主机的“reserved”属性设置为 False。在单个故障转移段下，可能会发生多个主机故障，导致相同的保留主机并同时启动恢复工作流。为了避免这种情况，将在每个任务上获取当前保留主机名称的锁，如果获取了锁，则跳过该保留主机，并在列表中执行下一个保留主机上的驱逐操作。
用例¶
操作员可能希望使用“RESERVED_HOST”恢复方法执行 host_failure 工作流。
提议的变更¶
Masakari 引擎应仅同步执行工作流。Masakari 引擎将加载所有驱动程序。任何将实现新驱动程序的人，都有责任获取工作流的结果并将其发送回 masakari 引擎。如果有人想要添加一个将在不同主机上而不是在 masakari 引擎运行的同一主机上执行工作流的驱动程序，那么他们需要以这样一种方式设计该驱动程序，即工作流将在任何主机上异步执行，并将结果发送回 masakari 引擎，以便 masakari 引擎可以根据结果将通知状态设置为“ERROR”或“FINISHED”。
为了实现“reserved_host”恢复方法，我们需要在保留主机上实现锁定机制，以便 masakari-engine 不会为多个故障通知使用相同的保留主机。实现锁定机制有两种方法
使用 oslo_concurrency.lockutils 文件锁：易于实现，但无法管理多个节点之间的锁。
使用 Tooz 实现锁定机制：操作员可能希望在不同的节点上部署多个 masakari-engine 服务。为此，我们建议使用 Tooz 库提供的分布式锁定机制。默认情况下，Tooz 将配置为使用文件锁，因此一切都将像 oslo_concurrency 锁定机制一样工作。如果操作员想要运行多个 masakari-engine 服务，则需要配置 Tooz 后端服务并在 masakari.conf 中进行设置。目前最可靠的 Tooz 后端是 ZooKeeper 和 Redis。
目前，masakari 已经使用了基于文件的锁（oslo_concurrency.lockutils）。将使用相同的机制来获取保留主机上的锁。Tooz 支持将在以后添加，并且所有现有锁都将被迁移以使用 Tooz 锁定机制。
优点：¶
无需更改当前的 masakari 引擎实现。
使用这种设计，可以轻松实现其他恢复操作，例如“AUTO_PRIORITY”和“RH_PRIORITY”。
备选方案¶
异步执行工作流，即工作流可以在 masakari 引擎运行的同一主机上或完全在不同的主机上执行。在这种情况下，masakari 引擎可能无法从工作流执行中获取结果，并且无法更新通知状态并将保留主机设置为 False。
为了实现这一点，masakari 引擎将基于 notification_id 生成一个回调 URL，并将其传递给驱动程序。示例回调 URL 将如下所示：
http://<host>:<port>/v1/notification/<notification_id>
驱动程序将进一步将此 URL 和所需的信息（例如保留主机列表、主机名等）传递给工作流。工作流将负责使用回调 URL 调用 masakari，并将通知状态和工作流使用的保留主机作为请求体。
一旦 masakari 收到此请求，它将根据 notification_id 将其映射到数据库表中的通知，并相应地更新通知的状态。此外，masakari 将在请求体中获取使用的保留主机列表，因此它将循环遍历它并将这些主机的“reserved”属性设置为 False。
REST API 可以是
method: PUT
URL: URL that is passed to the workflow(contains notification_id)
Body:
result {
notification_status: status of the notification, either 'error' or
'finished', used_reserved_hosts: list of actually used reserved_hosts
by workflow
}
优点：¶
更好地实现新的工作流驱动程序。
缺点：¶
将使用 REST api 请求 masakari 的其他服务应具有所需的管理员凭据才能调用 API。
需要更改当前驱动程序（taskflow）实现以采用这种设计。
需要修改 PUT api 以合并此更改。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Dinesh Bhor <dinesh.bhor@nttdata.com> Abhishek Kekane <abhishek.kekane@nttdata.com>
工作项¶
以同步方式为 taskflow 驱动程序实现 host_failure 恢复中的 RESERVED_HOST recovery_method
添加单元测试以覆盖
依赖项¶
无
测试¶
无
文档影响¶
无
参考资料¶
http://eavesdrop.openstack.org/meetings/masakari/2016/masakari.2016-12-13-04.02.log.html http://eavesdrop.openstack.org/meetings/masakari/2017/masakari.2017-02-07-04.01.log.html
