Enable Oslo.Messaging Dual Backends
This spec describes adding two functional capabilities to the messaging services of an overcloud deployment. The first capability is to enable the selection and configuration of separate messaging backends for oslo.messaging RPC and Notification communications. The second capability is to introduce support for a brokerless messaging backend for oslo.messaging RPC communications via the AMQP 1.0 Apache qpid-dispatch-router. Change-Id: Idcbd264e12b28c6118cf7ff80c01a392580a58e5
This commit is contained in:
Andrew Smith
parent
0ebc186107
commit
20ba6d0c2d
190
specs/ocata/om-dual-backends.rst
Normal file
190
specs/ocata/om-dual-backends.rst
Normal file
@ -0,0 +1,190 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
============================================================
|
||||
Enable deployment of alternative backends for oslo.messaging
|
||||
============================================================
|
||||
|
||||
Include the URL of your launchpad blueprint:
|
||||
|
||||
https://blueprints.launchpad.net/tripleo/+spec/om-dual-backends
|
||||
|
||||
This spec describes adding two functional capabilities to the messaging
|
||||
services of an overcloud deployment. The first capability is to enable
|
||||
the selection and configuration of separate messaging backends for
|
||||
oslo.messaging RPC and Notification communications. The second
|
||||
capability is to introduce support for a brokerless messaging backend
|
||||
for oslo.messaging RPC communications via the AMQP 1.0 Apache
|
||||
qpid-dispatch-router.
|
||||
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
The oslo.messaging library supports the deployment of dual messaging system
|
||||
backends. This enables alternative backends to be deployed for RPC and
|
||||
Notification messaging communications. Users have identified the
|
||||
constraints of using a store and forward (broker based) messaging system for RPC
|
||||
communications and are seeking direct messaging (brokerless)
|
||||
approaches to optimize the RPC messaging pattern. In addition to
|
||||
operational challenges, emerging distributed cloud architectures
|
||||
define requirements around peer-to-peer relationships and geo-locality
|
||||
that can be addressed through intelligent messaging transport routing
|
||||
capabilities such as is provided by the AMQP 1.0 qpid-dispatch-router.
|
||||
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Provide the capability to select and configure alternative
|
||||
transport_url's for oslo.messaging RPCs and Notifications across
|
||||
overcloud OpenStack services.
|
||||
|
||||
Retain the current default behavior to deploy the rabbitMQ server as
|
||||
the messaging backend for both RPC and Notification communications.
|
||||
|
||||
Introduce an alternative deployment of the qpid-dispatch-router as the
|
||||
messaging backend for RPC communications.
|
||||
|
||||
Utilize the oslo.messaging AMQP 1.0 driver for delivering RPC services
|
||||
via the dispatch-router messaging backend.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
The configuration of dual backends for oslo.messaging could be
|
||||
performed post overcloud deployment.
|
||||
|
||||
Security Impact
|
||||
---------------
|
||||
|
||||
The end result of using the AMQP 1.0 dispatch-router as an alternative
|
||||
messaging backend for oslo.messaging RPC communications should be the
|
||||
same from a security standpoint. The driver/router solution provides
|
||||
SSL and SASL support in parity to the current rabbitMQ server deployment.
|
||||
|
||||
Other End User Impact
|
||||
---------------------
|
||||
|
||||
The configuration of the dual backends for RPC and Notification
|
||||
messaging communications should be transparent to the operation of the OpenStack
|
||||
services.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
Using a dispatch-router mesh topology rather than broker clustering
|
||||
for messaging communications will have a positive impact on
|
||||
performance and scalability by:
|
||||
|
||||
* Directly expanding connection capacity
|
||||
|
||||
* Providing parallel communication flows across the mesh
|
||||
|
||||
* Increasing aggregate message transfer capacity
|
||||
|
||||
* Improving resource utilization of messaging infrastructure
|
||||
|
||||
Other Deployer Impact
|
||||
---------------------
|
||||
|
||||
The deployment of the dispatch-router, however, will be new to
|
||||
OpenStack operators. Operators will need to learn the
|
||||
architectural differences as compared to a broker cluster
|
||||
deployment. This will include capacity planning, monitoring,
|
||||
troubleshooting and maintenance best practices.
|
||||
|
||||
Developer Impact
|
||||
----------------
|
||||
|
||||
Support for alternative oslo.messaging backends and deployment of
|
||||
qpid-dispatch-router in addition to rabbitMQ should be implemented for
|
||||
tripleo-quickstart.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
|
||||
* John Eckersberg <jeckersb@redhat.com>
|
||||
|
||||
* Andy Smith <ansmith@redhat.com>
|
||||
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Update overcloud templates for dual backends and dispatch-router service
|
||||
|
||||
* Add dispatch-router packages to overcloud image elements
|
||||
|
||||
* Add services template for dispatch-router
|
||||
|
||||
* Update OpenStack services base templates to select and configure
|
||||
transport_urls for RPC and Notification
|
||||
|
||||
* Deploy dispatch-router for controller and compute for topology
|
||||
|
||||
* Test failure and recovery scenarios for dispatch-router
|
||||
|
||||
Transport Configuration
|
||||
-----------------------
|
||||
|
||||
The oslo.messaging configuration options define a default and
|
||||
additional notification transport_url. If the notification
|
||||
transport_url is not specified, oslo.messaging will use the default
|
||||
transport_url for both RPC and Notification messaging communications.
|
||||
|
||||
The transport_url parameter is of the form::
|
||||
|
||||
transport://user:pass@host1:port[,hostN:porN]/virtual_host
|
||||
|
||||
Where the transport scheme specifies the RPC or Notification backend as
|
||||
one of rabbit or amqp, etc. Oslo.messaging is deprecating the host,
|
||||
port and auth configuration options. All drivers will get these
|
||||
options via the transport_url.
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
Support for dual backends in and AMQP 1.0 driver integration
|
||||
with the dispatch-router depends on oslo.messaging V5.10 or later.
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
In order to test this in CI, an environment will be needed where dual
|
||||
messaging system backends (e.g. rabbitMQ server and dispatch-router
|
||||
server) are deployed. Any existing hardware configuration should be
|
||||
appropriate for the dual backend deployment.
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
The deployment documentation will need to be updated to cover the
|
||||
configuration of dual messaging system backends and the use of the
|
||||
dispatch-router. TripleO Heat template examples should also help with
|
||||
deployments using dual backends.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
* [1] https://blueprints.launchpad.net/oslo.messaging/+spec/amqp-dispatch-router
|
||||
* [2] http://qpid.apache.org/components/dispatch-router/
|
||||
* [3] http://docs.openstack.org/developer/oslo.messaging/AMQP1.0.html
|
||||
* [4] https://etherpad.openstack.org/p/ocata-oslo-consistent-mq-backends
|
||||
* [5] https://github.com/openstack/puppet-qdr
|
||||
Loading…
x
Reference in New Issue
Block a user