恢复方法定制

https://blueprints.launchpad.net/masakari/+spec/recovery-method-customization

本文档讨论了使恢复工作流可配置。操作员可以在配置文件中配置工作流,该文件可用于构建和执行恢复工作流。

什么是恢复工作流?

恢复工作流只不过是执行以从故障中恢复的一系列操作。Masakari 支持三种类型的恢复故障

  • 实例故障

  • 进程故障

  • 主机故障

对于这些故障中的每一个,Masakari 在接收到通知后都会执行一个工作流来从故障中恢复。

问题描述

Masakari 使用 taskflow 库来执行工作流,这些工作流由预定义的恢复操作组成,这些操作按线性方式执行。如果操作员想要向这些工作流中的任何一个添加/删除现有的恢复操作,那么在不更改代码的情况下,没有其他方法可以做到。例如,在“主机故障恢复工作流”的情况下,预定义的流程是

  • 禁用计算节点

  • 准备 HA 启用的实例

  • 疏散并确认疏散

如果操作员想要从工作流中删除任务“禁用计算节点”,或者添加一个新的任务,例如向操作员发送警报邮件,那么在当前的实现中这是不可能的。

用例

操作员可能希望根据他们的要求从现有工作流中添加/删除任务。例如,在“主机故障恢复”工作流的情况下,预定义的流程是:禁用计算节点、准备 HA 启用的实例、疏散和确认疏散。一些可能的恢复工作流组合可以是

  • 向操作员/VM 用户发送警报/邮件 -> 禁用计算节点 -> 准备 HA 启用的实例 -> 疏散 -> 更新定价/计量数据库 -> 确认疏散 -> 向操作员/用户发送警报/邮件(恢复完成)

  • 向操作员/VM 用户发送警报/邮件 -> 禁用计算节点 -> 准备 HA 启用的实例 -> 疏散 -> 确认疏散 -> 向操作员/VM 用户发送警报/邮件(恢复完成)

  • 向操作员/VM 用户发送警报/邮件

提议的变更

提供一种根据需求从现有工作流中添加/删除任务的机制。我们计划将现有的硬编码恢复工作流分解为单独的任务,然后将它们绑定在一起以形成可以在新的 conf 文件“masakari-custom-recovery-methods.conf”中配置的工作流,如下所示:在新添加的 masakari-custom-recovery-methods.conf 文件中添加一个部分“[taskflow_driver_recovery_flows]”。在此之下,添加以下配置选项以配置每种类型工作流的自定义恢复操作。每个配置选项将是一个字典,包含要执行的任务的键/值对。例如:pre:[v1,v2],main:[v1,v2],post:[v1,v2,v3] 这里的键将是 pre/main/post,值将是要为恢复故障执行的任务列表。如果文件不存在,则将执行配置在配置选项注册期间的默认任务。

  • “instance_failure_recovery_tasks”是一个字典,包含键作为

    pre/main/post,值将是要为进程故障执行的逗号分隔的任务列表。

  • “process_failure_recovery_tasks”是一个字典,包含键作为

    pre/main/post,值将是要为进程故障执行的逗号分隔的任务列表。

  • “host_auto_failure_recovery_tasks”是一个字典,包含键作为

    pre/main/post,值将是要为主机故障自动恢复执行的逗号分隔的任务列表。

  • “host_rh_failure_recovery_tasks”是一个字典,包含键作为

    pre/main/post,值将是要为主机故障 RH 恢复执行的逗号分隔的任务列表。

例如,

[taskflow_driver_recovery_flows]
instance_failure_recovery_tasks = pre:['custom_pre_task','stop_instance_task'],
                                  main:['start_instance_task','custom_main_task'],
                                  post:['confirm_instance_active_task','custom_post_task']
process_failure_recovery_tasks = pre:['disable_compute_node_task'],
                                 main:['confirm_compute_node_disabled_task','custom_main_task'],
                                 post:['custom_post_task']
host_auto_failure_recovery_tasks = pre:['disable_compute_service_task'],
                                   main:['prepare_HA_enabled_instances_task'],
                                   post:['evacuate_instances_task','custom_post_task']
host_rh_failure_recovery_tasks = pre:['custom_pre_task','disable_compute_service_task'],
                                 main:['prepare_HA_enabled_instances_task',
                                 'evacuate_instances_task']
                                 post:['custom_post_task']

需要在 setup.cfg 中添加入口点,以便这些任务可以在创建恢复工作流期间使用 stevedore 动态加载。

例如,Masakari setup.cfg 将具有以下入口点

  • 对于 setup.cfg 中的每个入口点,都应该具有如下示例中所示的完整类路径

masakari.task_flow.tasks =
    stop_instance_task = masakari.engine.drivers.taskflow.instance_failure:StopInstanceTask
masakari.task_flow.tasks =
    disable_compute_service_task = <full_class_path_of_task>
    prepare_HA_enabled_instances_task = <full_class_path_of_task>
    evacuate_instances_task = <full_class_path_of_task>
    stop_instance_task = <full_class_path_of_task>
    start_instance_task = <full_class_path_of_task>
    confirm_instance_active_task = <full_class_path_of_task>
    disable_compute_node_task = <full_class_path_of_task>
    confirm_compute_node_disabled_task = <full_class_path_of_task>

如果操作员想要在第三方库中配置自定义任务,则他们需要遵循以下指南,将新添加的任务与 Masakari 中的相应恢复工作流关联起来

  • 首先,确保所需的第三方库已安装在 Masakari 引擎节点上。

  • 在第三方库的 setup.cfg 中配置自定义任务如下

例如,第三方库的 setup.cfg 将具有以下入口点

masakari.task_flow.tasks =
    custom_pre_task = <custom_task_class_path_from_third_party_library>
    custom_main_task = <custom_task_class_path_from_third_party_library>
    custom_post_task = <custom_task_class_path_from_third_party_library>
注意

第三方库 setup.cfg 中的入口点应该与 Masakari setup.cfg 中相应故障恢复的键相同。

  • 如果自定义任务需要任何配置参数,则将它们添加到 masakari-custom-recovery-methods.conf 中的相同组/部分,这些参数是在第三方库中注册的。操作员将负责自行生成 masakari 配置文件。

  • 操作员应确保每个任务的输出都可供需要它们的后续任务使用。

备选方案

对于从故障中恢复,而不是完全可配置的任务流,可以在预定义的现有工作流的开始或完成之后添加自定义任务。

可以在 masakari-custom-recovery-methods.conf 中自定义恢复工作流,如下所示,Masakari 将根据需要将这些自定义任务注入到预定义工作流的开始或结束处。

例如,

[taskflow_driver_recovery_flows]
instance_failure_recovery_tasks = ['custom_pre_task','custom_main_task']
process_failure_recovery_tasks = ['custom_pre_task']
host_auto_failure_recovery_tasks = ['custom_pre_task','custom_main_task']
host_rh_failure_recovery_tasks = ['custom_pre_task']

custom_pre_task 和 custom_main_task 将在现有的“instance_failure”工作流的开始或结束处执行。

注意

对于具有 RH 恢复方法的 host 故障,开发人员应将自定义任务添加到嵌套流程中,以便它只执行一次。

数据模型影响

REST API 影响

安全影响

通知影响

其他最终用户影响

性能影响

其他部署者影响

将添加一个新的配置文件“masakari-custom-recovery-methods.conf”,其中需要更新“taskflow_driver_recovery_flows”部分以进行自定义恢复工作流。如果操作员不希望对任何恢复工作流进行自定义,那么不会有任何影响,因为它将加载每个恢复工作流的默认任务。例如,

[taskflow_driver_recovery_flows]
instance_failure_recovery_tasks = pre:['custom_pre_task','stop_instance_task'],
                                  main:['start_instance_task','custom_main_task'],
                                  post:['confirm_instance_active_task','custom_post_task']
process_failure_recovery_tasks = pre:['disable_compute_node_task'],
                                 main:['confirm_compute_node_disabled_task','custom_main_task'],
                                 post:['custom_post_task']
host_auto_failure_recovery_tasks = pre:['disable_compute_service_task'],
                                   main:['prepare_HA_enabled_instances_task'],
                                   post:['evacuate_instances_task','custom_post_task']
host_rh_failure_recovery_tasks = pre:['custom_pre_task','disable_compute_service_task'],
                                 main:['prepare_HA_enabled_instances_task',
                                 'evacuate_instances_task']
                                 post:['custom_post_task']

开发人员影响

实现

负责人

主要负责人

工作项

  • 实现自定义任务流执行。

  • 添加单元测试以覆盖。

  • 添加文档指南以描述如何配置可自定义的工作流。

依赖项

测试

文档影响

添加文档指南以描述如何配置可自定义的工作流。

参考资料

https://etherpad.openstack.org/p/masakari-recovery-method-customization http://eavesdrop.openstack.org/meetings/masakari/2018/masakari.2018-07-03-03.00.log.html

历史