TripleO 用于测试高可用性部署的工具¶

我们需要一种方法来验证高可用性的 TripleO 部署，并进行适当的测试，以检查高可用性组件是否正常运行。

问题描述¶

目前，我们只通过部署具有三个控制器的环境来测试 TripleO 部署的高可用性行为，并查看是否能够生成实例，但这还不够。

应该有一种方法来验证部署的高可用性能力，以及在诱导故障、模拟中断等之后，环境的行为是否仍然正确。

该工具应该是一个独立的组件，用户在必要时可以包含它，而不会破坏 TripleO 中存在的任何动态。

提议的变更¶

概述¶

提议是创建一个基于 Ansible 的项目，名为 tripleo-ha-utils，该项目将可供我们用于部署 TripleO 环境的各种工具（如 tripleo-quickstart 或 infrared）或手动部署使用。

该项目最初将涵盖三个主要角色

stonith-config：一个用于在 overcloud 中自动化创建故障隔离设备的 playbook；
instance-ha：一个 playbook，它自动化了在 overcloud 中配置实例高可用性所需的十七个手动步骤，通过 rally 进行测试并验证实例高可用性是否正常工作；
validate-ha：一个 playbook，它在 overcloud 中运行一系列破坏性操作，并通过部署一个包含所有 overcloud 组件的 heat 模板来验证它始终表现正确；

今天，该项目存在于 TripleO 之外，名为 tripleo-quickstart-utils [1]（有关此名称的历史原因，请参阅“替代方案”）。它在内部的推广管道中使用，并在 RDOCloud 中也成功进行了测试。

可插拔实现¶

该项目的基本原则是让人们能够将第一个角色与各种类型的测试集成。例如，今天我们使用一个简单的 bash 框架与集群进行交互（所以是 pcs 命令和其他交互），使用 rally 来测试实例高可用性，并使用 Ansible 本身来模拟完全断电场景。我们的想法是保持这种可插拔的方法，让最终用户选择使用什么。

向后兼容性¶

该项目的目标之一是与以前版本的 OpenStack 向后兼容。从 Liberty 开始，我们为所有版本提供实例高可用性和 stonith-config Ansible playbook。在测试高可用性时也是如此，因为所有测试都根据版本进行插入。

替代方案¶

在评估替代方案时，首先要考虑的是该项目旨在成为一套以 TripleO 为中心的高可用性工具，而不是通用的 OpenStack 工具。我们希望这些工具能帮助用户回答诸如“Galera 捆绑集群资源是否能够在不影响环境功能的情况下容忍停止和连续启动？”或“在配置了实例高可用性之后，环境是否能够迁移实例？”之类的问题。我们想要的答案是“是”或“否”。

tripleo-validations：至少从名称上看，最
合乎逻辑的放置位置将是 tripleo-validations。通过与从事该项目的人员交流，发现 tripleo-validations 项目的含义不是进行破坏性测试。集成这些内容将超出范围。
tripleo-quickstart-extras：除了这不仅仅是为 quickstart
而设计（该项目也支持 infrared 和“普通”环境），即使我们最初从那里开始，最终发现没有人关注这些补丁，因为没有人能够验证它们。结果是一系列评论永远卡住了。所以回到 extras 将是一个倒退。

其他最终用户影响¶

无。该解决方案的好处是，除非该解决方案加载到现有项目中，否则不会对任何人产生影响。由于这将是一个外部项目，它不会影响当前的任何内容。

性能影响¶

无。除非部署、CI 运行或任何其他操作包含这些角色，否则不会产生影响，因此性能不会改变。

实现¶

主要负责人

rscarazz

工作项¶

将 tripleo-quickstart-utils [1] 作为新仓库导入，并从那里开始新的部署。

测试¶

由于这些测试的破坏性性质，TripleO CI 不应更新以包含这些测试，主要是因为时间问题。该项目应在需要时或在旨在支持比平常更长时间作业的特定 CI 环境中，由人们选择性使用。

文档影响¶

今天，所有已实现的角色都已在 tripleo-quickstart-utils [1] 项目中完全记录，因此按原样导入其仓库也将提供其完整文档。

参考资料¶

[1] 要导入为新项目的原始项目: https://github.com/redhat-openstack/tripleo-quickstart-utils

TripleO 用于测试 HA 部署的工具