Este contenido no está disponible en el idioma seleccionado.
Chapter 16. Configuring a multi-site, fault-tolerant messaging system using broker connections
Large-scale enterprise messaging systems commonly have discrete broker clusters located in geographically distributed data centers. In the event of a data center outage, system administrators might need to preserve existing messaging data and ensure that client applications can continue to produce and consume messages. You can use broker connections to ensure continuity of your messaging system during a data center outage. This type of solution is called a multi-site, fault-tolerant architecture.
Only the AMQP protocol is supported for communication between brokers for broker connections. A client can use any supported protocol. Currently, messages are converted to AMQP through the mirroring process.
The following sections explain how to protect your messaging system from data center outages using broker connections:
Multi-site fault tolerance is not a replacement for high-availability (HA) broker redundancy within data centers. Broker redundancy based on live-backup groups provides automatic protection against single broker failures within single clusters. In contrast, multi-site fault tolerance protects against large-scale data center outages.
16.1. About broker connections
With broker connections, a broker can establish a connection to another broker and mirror messages to and from that broker.
- AMQP server connections
- A broker can initiate connections to other endpoints using the AMQP protocol using broker connections. This means, for example, that the broker can connect to other AMQP servers and create elements on those connections.
The following types of operations are supported on an AMQP server connection:
- Mirrors - The broker uses an AMQP connection to another broker and duplicates messages and sends acknowledgements over the wire.
- Senders - Messages received on specific queues are transferred to another broker.
- Receivers - The broker pulls messages from another broker.
- Peers - The broker creates both senders and receivers on AMQ Interconnect endpoints.
This chapter describes how to use broker connections to create a fault-tolerant system. See Chapter 17, Bridging brokers for information about sender, receiver, and peer options.
The following events are sent through mirroring:
- Message sending - Messages sent to one broker will be "replicated" to the target broker.
- Message acknowledgement - Acknowledgements removing messages at one broker will be sent to the target broker.
- Queue and address creation.
- Queue and address deletion.
If the message is pending for a consumer on the target mirror, the acknowledgement will not succeed and the message might be delivered by both brokers.
Mirroring does not block any operation and does not affect the performance of a broker.
The broker only mirrors messages arriving from the point in time the mirror was configured. Previously existing messages will not be forwarded to other brokers.
16.2. Configuring broker connections
The following procedure shows how to configure broker connections to mirror messages between brokers. Only one of the brokers is active at any time, all messages are mirrored to the other broker.
Prerequisites
- You have two working brokers.
Procedure
Create a
broker-connectionselement in thebroker.xmlfile for the first broker, for example:<broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC1"> <mirror/> </amqp-connection> </broker-connections><hostname>- The hostname of the other broker instance.
<port>- The port used by the broker on the other host.
All messages on the first broker will be mirrored to the second broker, but messages that existed before the mirror was created are not mirrored.
You can also configure the following additional features:
-
queue-removal: Specifies whether a queue- or address-removal event is sent. The default value istrue. -
message-acknowledgements: Specifies whether message acknowledgements are sent. The default value istrue. -
queue-creation: Specifies whether a queue- or address-creation event is sent. The default value istrue.
NoteThe broker connections name in the example,
DC1, is used to create a queue named$ACTIVEMQ_ARTEMIS_MIRROR_mirror. Make sure that the corresponding broker is configured to accept those messages, even though the queue is not visible on that broker.Create a
broker-connectionselement in thebroker.xmlfile for the second broker, for example:<broker-connections> <amqp-connection uri="tcp://<hostname>:<port>" name="DC2"> <mirror/> </amqp-connection> </broker-connections>NoteRed Hat recommends that consumers are configured to accept messages from one of the brokers, not both.
- Configure clients using the instructions documented in Section 15.6, “Configuring clients in a multi-site, fault-tolerant messaging system”, noting that with broker connections, there is no shared storage.
