启用 oslo.messaging 的替代后端部署¶
包含您的 Launchpad 蓝图的 URL
https://blueprints.launchpad.net/tripleo/+spec/om-dual-backends
本文档描述了为 overcloud 部署的 messaging 服务添加两个功能特性。第一个特性是启用 oslo.messaging RPC 和 Notification 通信的独立 messaging 后端的选择和配置。第二个特性是为 oslo.messaging RPC 通信引入通过 AMQP 1.0 Apache qpid-dispatch-router 的无代理 messaging 后端支持。
问题描述¶
oslo.messaging 库支持部署双 messaging 系统后端。这使得可以为 RPC 和 Notification messaging 通信部署替代后端。用户已经指出了使用存储转发（基于代理）messaging 系统进行 RPC 通信的限制，并正在寻求直接 messaging（无代理）方法来优化 RPC messaging 模式。除了运营挑战之外，新兴的分布式云架构定义了关于对等关系和地理位置的要求，这些要求可以通过智能 messaging 传输路由功能来解决，例如 AMQP 1.0 qpid-dispatch-router 提供的功能。
提议的变更¶
概述¶
提供在 overcloud OpenStack 服务中选择和配置 oslo.messaging RPC 和 Notifications 的替代 transport_url 的能力。
保留当前默认行为，将 rabbitMQ 服务器作为 RPC 和 Notification 通信的 messaging 后端部署。
引入 qpid-dispatch-router 的替代部署，作为 RPC 通信的 messaging 后端。
利用 oslo.messaging AMQP 1.0 驱动程序通过 dispatch-router messaging 后端提供 RPC 服务。
替代方案¶
oslo.messaging 的双后端配置可以在 overcloud 部署后进行。
安全影响¶
将 AMQP 1.0 dispatch-router 作为 oslo.messaging RPC 通信的替代 messaging 后端使用，从安全角度来看，结果应该相同。驱动程序/路由器解决方案提供与当前 rabbitMQ 服务器部署相同的 SSL 和 SASL 支持。
其他最终用户影响¶
RPC 和 Notification messaging 通信的双后端配置应该对 OpenStack 服务的运行透明。
性能影响¶
使用 dispatch-router 网状拓扑而不是代理集群进行 messaging 通信，将通过以下方式对性能和可扩展性产生积极影响
直接扩展连接容量
在网状结构上提供并行通信流
提高总消息传输容量
提高 messaging 基础设施的资源利用率
其他部署者影响¶
然而，dispatch-router 的部署对于 OpenStack 操作员来说是新的。操作员需要了解与代理集群部署相比的架构差异。这包括容量规划、监控、故障排除和维护最佳实践。
开发人员影响¶
应为 tripleo-quickstart 实现对替代 oslo.messaging 后端的支持以及 rabbitMQ 之外的 qpid-dispatch-router 的部署。
实现¶
负责人¶
主要负责人
John Eckersberg <jeckersb@redhat.com>
Andy Smith <ansmith@redhat.com>
工作项¶
更新 overcloud 模板以支持双后端和 dispatch-router 服务
将 dispatch-router 包添加到 overcloud 镜像元素
添加 dispatch-router 的服务模板
更新 OpenStack 服务基本模板以选择和配置 RPC 和 Notification 的 transport_url
为拓扑部署控制器和计算节点的 dispatch-router
测试 dispatch-router 的故障和恢复场景
传输配置¶
oslo.messaging 配置选项定义了默认和附加的 notification transport_url。如果未指定 notification transport_url，oslo.messaging 将使用默认 transport_url 进行 RPC 和 Notification messaging 通信。
transport_url 参数的形式如下
transport://user:pass@host1:port[,hostN:porN]/virtual_host
其中传输方案指定 RPC 或 Notification 后端为 rabbit 或 amqp 等。Oslo.messaging 正在弃用 host、port 和 auth 配置选项。所有驱动程序都将通过 transport_url 获取这些选项。
依赖项¶
对双后端的支持以及与 dispatch-router 的 AMQP 1.0 驱动程序集成，取决于 oslo.messaging V5.10 或更高版本。
测试¶
为了在 CI 中进行测试，需要一个部署了双 messaging 系统后端（例如 rabbitMQ 服务器和 dispatch-router 服务器）的环境。任何现有的硬件配置都应该适合双后端部署。
文档影响¶
部署文档需要更新，以涵盖双 messaging 系统后端的配置以及 dispatch-router 的使用。TripleO Heat 模板示例也应该有助于使用双后端进行部署。
