Pacemaker 下一代架构¶
https://blueprints.launchpad.net/tripleo/+spec/ha-lightweight-architecture
更改现有的 HA 清单和模板，以部署一个精简的 pacemaker 架构，其中所有 openstack 服务都由 systemd 启动和监控，除了：VIP/Haproxy、rabbitmq、redis 和 galera。
问题描述¶
目前通过 puppet/manifests/overcloud_controller_pacemaker.pp 部署的 pacemaker 架构通过 pacemaker 管理控制器上的大部分服务。虽然这种方法具有单一实体管理和监控所有服务的优势，但也带来了一定的复杂性，并假设操作员非常熟悉 pacemaker 及其资源管理。目标是提出一种新的架构，取代现有的架构，其中 pacemaker 控制以下资源
虚拟 IP + HAProxy
RabbitMQ
Galera
Redis
openstack-cinder-volume（由于该服务尚未实现 A/A）
任何未来的主动/被动服务
基本上，当前由特定资源代理管理的任何服务，而不是 systemd，都将继续在 pacemaker 下运行。同样，对于需要主动/被动模式的任何服务（例如 openstack-cinder-volume）也是如此。
提议的变更¶
概述¶
最初的计划是创建一个全新的模板来实现这种新的 HA 架构。经过 TripleO 社区的几轮讨论，最终决定采用单一的 HA 架构。迁移到单一下一代 HA 架构的主要原因在于维护两个独立架构所需的工作量，以及之前的 HA 架构相对于这种下一代架构没有实质性的优势。
新的架构将通过 systemd 启用大部分服务，并删除大部分 pacemaker 资源定义及其相应的约束。在排序约束方面，我们将从像这样的图形开始：http://acksyn.org/files/tripleo/wsgi-openstack-core.pdf (mitaka)
到像这样的图形：http://acksyn.org/files/tripleo/light-cib-nomongo.pdf (next-generation-mitaka)
一旦这种新的架构到位并经过了广泛的测试，我们就可以开始研究从以前的完全成熟的 pacemaker HA 架构到这种新架构的升级路径。由于 pacemaker 在新架构中的影响非常小，因此可以考虑在未来为每次部署和每次 CI 作业放弃非 HA 模板。可以在稍后阶段，甚至在 newton 之后做出此决定。
另一个副作用是，使用这种较新的架构，TripleO 中的整个升级/更新主题更容易管理，因为在 pacemaker、openstack 服务更新、puppet 和更新过程本身之间需要的协调较少。
请注意，一旦可组合服务落地，这种下一代架构将仅仅包含一个环境文件，设置一些服务通过 systemd 启动，一些通过 pacemaker 启动，以及一些服务在 galera 和 rabbitmq 宕机时重新连接所需的环境变量。所有需要通过 systemd 启动的服务都将通过默认状态完成：https://github.com/openstack/tripleo-heat-templates/blob/40ad2899106bc5e5c0cf34c40c9f391e19122a49/overcloud-resource-registry-puppet.yaml#L124
通过 pacemaker 运行的服务将在环境文件中显式列出，如下所示：https://github.com/openstack/tripleo-heat-templates/blob/40ad2899106bc5e5c0cf34c40c9f391e19122a49/environments/puppet-pacemaker.yaml#L12
替代方案¶
HA 架构有很多替代设计。选择仅对某些“核心”服务和所有主动/被动服务使用 pacemaker 是在架构复杂性及其管理以及能够恢复已知故障状态的资源之间取得的谨慎平衡。这里有一个关于原生 openstack 服务的关键假设
它们必须能够在 broker 和数据库宕机时启动并继续重试。
仅对核心服务使用 pacemaker 而不是，例如，对虚拟 IP 使用 keepalived 的原因是为了保持堆栈简单，并且不引入多个分布式资源管理器。此外，如果我们只使用 keepalived，我们将无法在尝试重新定位 VIP 之外从故障中恢复。
将 haproxy 纳入 pacemaker 管理的原因是，我们可以保证在 haproxy 服务发生故障时，VIP 将始终在运行 haproxy 的地方运行。
安全影响¶
与现有状态相比，安全方面没有变化。
其他最终用户影响¶
使用云的操作员会受到以下影响
通过 pcs 以通常的方式管理服务（galera、redis、openstack-cinder-volume、VIP、haproxy）。Pacemaker 将监控这些服务并通过 pcs status 提供其状态。
所有其他服务都将通过 systemctl 管理，systemd 将配置为自动重启失败的服务。请注意，这已经在 RDO 中完成，服务文件中包含 (Restart={always,on-failure})。当 pacemaker 管理服务时，会创建一个覆盖文件，因此这是一种无操作。
使用新的架构，在所有控制器上重启原生 openstack 服务需要通过 systemctl 在每个节点上重启它（与今天使用单个 pcs 命令完成的操作相反）
所有服务都将配置为无限期地重试连接到数据库或消息代理。如果控制器发生故障，故障转移场景将与当前的 HA 架构相同，区别在于服务将只是无限期地重试重新连接。
以前使用 HA 模板，每个服务都将由 pacemaker 监控和管理。在 openstack 服务由 systemd 管理和“核心”服务由 pacemaker 管理之间进行拆分后，操作员需要知道使用哪个命令监控哪个服务。
性能影响¶
与现有架构相比，没有变化。
其他部署者影响¶
无
开发人员影响¶
在未来，我们可能会考虑是否可以删除非 HA 模板，从而简化我们的 CI 作业并拥有一个更易于维护的模板。
实现¶
负责人¶
- 主要负责人
michele
- 其他贡献者
…
工作项¶
准备部署下一代架构的角色。最初，尽可能地使其接近现有的 HA 模板，并在第二个迭代中使其更简单（删除不必要的步骤等）。模板当前位于此处并已成功部署
测试故障场景和恢复场景，针对在数据库和/或代理宕机时表现不佳的服务提交错误。
依赖项¶
无
测试¶
初步的冒烟测试已成功完成。另一组测试，重点关注在 galera 和 rabbitmq 宕机时 openstack 服务的行为，正在进行中。
特别关注故障转移场景和恢复时间，并确保与当前的 HA 架构相比没有回归。
文档影响¶
目前我们没有描述 TripleO 部署的架构，因此不需要进行更改。在文档中添加一页简短的页面来描述架构，在未来会是一件好事。
参考资料¶
这个设计主要来自布尔诺的一次会议，与会者如下
Andrew Beekhof
Chris Feist
Eoghan Glynn
Fabio Di Nitto
Graeme Gillies
Hugh Brock
Javier Peña
Jiri Stransky
Lars Kellogg-Steadman
Mark Mcloughlin
Michele Baldessari
Raoul Scarazzini
Rob Young
