Tripleo RPC 和通知消息支持¶
https://blueprints.launchpad.net/tripleo
本文档提出对 tripleo 进行更改，以支持为 oslo.messaging RPC 和通知通信选择和配置单独的消息后端。该提案源于最初的蓝图 [1] 和规范 [2] 相关的工作，旨在为 tripleo 中的 oslo.messaging 实现双后端。
在 pike 版本期间，已经完成了启用双后端的大部分基础工作，并且引入了一种替代消息后端 (qdrouterd) 服务。目前，通过将 rabbitmq 服务别名为 tripleo 实现，从而部署此替代消息后端，因为 tripleo 没有对单独的消息后端进行建模。
问题描述¶
oslo.messaging 库支持为 RPC 和通知通信部署双消息系统后端。但是，tripleo 当前部署单个 rabbitmq 服务器（集群），该服务器充当 RPC 和通知的单个消息后端。
+------------+ +----------+
| RPC Caller | | Notifier |
+-----+------+ +----+-----+
| |
+--+ +--+
| |
v v
+-+---------------+-+
| RabbitMQ Service |
| Messaging Backend |
| |
+-+---------------+-+
^ ^
| |
+--+ +--+
| |
v v
+------+-----+ +------+-------+
| RPC | | Notification |
| Server | | Server |
+------------+ +--------------+
为了支持两个独立且不同的消息后端，tripleo 需要“复制”指定每个消息系统所需的参数集。OpenStack 中的 oslo.messaging 库为消息服务提供 API。建议实现以后端消息服务器（例如 rabbitmq）为替代，对 RPC 和通知消息服务进行建模。
+------------+ +----------+
| RPC Caller | | Notifier |
+-----+------+ +----+-----+
| |
| |
v v
+-------------------+ +-------------------+
| RPC | | Notification |
| Messaging Service | | Messaging Service |
| | | |
+--------+----------+ +--------+----------+
| |
| |
v v
+------------+ +------+-------+
| RPC | | Notification |
| Server | | Server |
+------------+ +--------------+
用单独的消息服务和相关参数替换 rabbitmq 服务器不是一个重大的重构，但必须特别考虑升级路径和功能，以确保现有的配置不受影响。
为 RPC 和通知通信提供单独的消息后端具有许多好处。这些好处包括
根据消息模式调整后端
增加聚合消息容量
降低消息服务器上的负载
提高消息吞吐量
降低消息延迟
等等。
提议的变更¶
需要解决许多问题，才能在后端消息系统之上表达 RPC 和通知消息服务。
概述¶
拟议的更改类似于 tripleo 配置的 service “后端” 概念。许多现有服务都支持这种后端（或插件）模型。消息服务后端模型的实现应考虑以下要求
为 RPC 和通知部署单个消息后端
两次部署消息后端，一次用于 RPC，一次用于通知
为 RPC 部署消息后端，为通知部署不同的消息后端
为 RPC 部署外部消息后端
为通知部署外部消息后端
通常，用于部署 rabbitmq 服务的参数应复制并重命名为“RPC 消息”和“通知消息”后端服务定义。将为每种可能的后端类型（例如 rabbitmq、qdrouterd、zeromq、kafka 或外部）存在单独的后端文件。所选后端将相应地定义消息系统的消息传输。
传输说明符
username
密码（和生成）
host
port
虚拟主机
ssl（已启用）
ssl 配置
健康检查
Tripleo 应继续具有默认配置，该配置在单个 rabbitmq 后端服务器（集群）之上部署 RPC 和通知消息服务。Tripleo 升级应将旧版 rabbitmq 服务部署映射到 RPC 和通知消息服务模型。
替代方案¶
单独的消息后端配置可以在 overcloud 部署后进行（例如，在 tripleo 框架外部）。这将在部署生命周期中存在问题，例如在升级期间等。
安全影响¶
从安全角度来看，为 RPC 和通知通信部署双消息后端应相同。假设后端在安全功能方面具有同等性，例如身份验证和加密。
其他最终用户影响¶
根据消息后端部署的配置，可能会对最终用户产生许多影响，包括以下内容
监控分离的消息后端服务
了解不同消息后端之间的功能/行为差异（例如，代理与路由器等）
处理异常（例如，日志的不同位置等）
性能影响¶
为 RPC 和通知使用单独的消息系统应通过以下方式对性能和可扩展性产生积极影响
分离 RPC 和通知消息负载
提高消息处理的并行性
提高聚合消息传输容量
调整与消息模式对齐的后端配置
其他部署者影响¶
混合消息的部署对于 OpenStack 操作员来说是全新的。操作员需要了解与单个后端部署相比的架构差异。这包括容量规划、监控、故障排除和维护最佳实践。
开发人员影响¶
讨论将影响在 OpenStack 上工作的其他开发人员的事情。
实现¶
负责人¶
主要负责人
Andy Smith <ansmith@redhat.com>
John Eckersberg <jeckersb@redhat.com>
工作项¶
tripleo-heat-templates
修改 puppet/services/<service>base.yaml 以引入单独的 RPC 和通知消息参数（例如，替换“rabbit”参数）
支持两种 ssl 环境（例如，在部署单独的后端时，一个用于 RPC，一个用于通知）
考虑以下示例后端模型
tripleo-heat-templates
|
+--+ /environments
| |
| +--+ /messaging
| |
| +--+ messaging-(rpc/notify)-rabbitmq.yaml
| +--+ messaging-(rpc/notify)-qdrouterd.yaml
| +--+ messaging-(rpc/notify)-zmq.yaml
| +--+ messaging-(rpc/notify)-kafka.yaml
+--+ /puppet
| |
| +--+ /services
| |
| +--+ messaging-(rpc/notify)-backend-rabbitmq.yaml
| +--+ messaging-(rpc/notify)-backend-qdrouterd.yaml
| +--+ messaging-(rpc/notify)-backend-zmq.yaml
| +--+ messaging-(rpc/notify)-backend-kafka.yaml
|
+--+ /roles
puppet_tripleo
将 rabbitmq_node_names 替换为 messaging_rpc_node_names 和 messaging_notify_node_names 或类似名称
添加 vhost 支持
考虑以下示例后端模型
puppet-tripleo
|
+--+ /manifests
|
+--+ /profile
|
+--+ /base
|
+--+ /messaging
|
+--+ backend.pp
+--+ rpc.pp
+--+ notify.pp
|
+--+ /backend
|
+--+ rabbitmq.pp
+--+ qdrouterd.pp
+--+ zmq.pp
+--+ kafka.pp
tripleo_common
添加 RPC 和消息服务的用户和密码管理
支持分离的消息后端的不同健康检查
packemaker
确定在部署两个单独的 rabbitmq 集群时应该发生什么。这会导致两个 pacemaker 服务还是一个？可能需要进行一些实验。
依赖项¶
无。
测试¶
为了在 CI 中测试此功能，需要一个环境，在该环境中部署单独的消息系统后端（例如，rabbitMQ 服务器和 dispatch-router 服务器）。任何现有的硬件配置都应适合双后端部署。
文档影响¶
部署文档需要更新，以涵盖单独的消息（RPC 和通知）服务的配置。
