Red Hat Training

A Red Hat training course is available for Red Hat AMQ

Chapter 3. Common Deployment Patterns

Red Hat JBoss AMQ 7.0 can be set up in a large variety of topologies. The following are just some of the common deployment patterns you can implement using Red Hat JBoss AMQ 7.0 components.

3.1. Central Broker

The central broker pattern is relatively easy to set up and maintain. It is also relatively robust. Routes are typically local, since the broker and its clients are always within one network hop of each other, no matter how many nodes are added. This pattern is also known as hub and spoke, where the central broker becomes the hub and the clients the spokes.

Figure 3.1. Central Broker Pattern

Central Broker Pattern

The only critical element is the central broker node. You would need to focus your maintenance efforts on keeping this broker up and running.

3.2. Routed Messaging

Sometimes an application requires sending request and response messages in real time. In these cases, having a broker in the middle that stores and forwards messages as it routes them is unnecessary and costly. With Red Hat JBoss AMQ 7.0 you can use a router in place of a broker to avoid such costs. The router does not store messages before forwarding them to a destination and works as a lightweight conduit that directly connects two endpoints.

Figure 3.2. Brokerless Router Pattern

Brokerless Router Pattern

3.3. Highly Available Brokers

To ensure brokers are up and running for their clients, deploy a highly available (HA) master-slave pair to create a backup group. You could, for example, deploy two master-slave groups on two nodes. Such a deployment would provide a backup for each active broker, as seen in the following diagram.

Figure 3.3. Master-slave Pair

Master-Slave Pair

Under normal operating conditions, one master broker is active on each node, here defined as either a physical server or a virtual machine. If one node fails, the slave on the other node takes over. The result is two active brokers residing on the same healthy node.

Using the basic principles of the master-slave group, you could scale up to an entire network of such backup groups. Larger deployments of this type are useful for distributing the message processing load across many brokers. The broker network in the diagram below consists of eight master-slave groups distributed over eight nodes.

Figure 3.4. Master-slave Network

Master-Slave Network

3.4. Router Pair Behind a Load Balancer

Deploying two routers behind a load balancer provides high availability, resiliency, and increased scalability for a single-datacenter deployment. Endpoints make their connections to a known URL, supported by the load balancer. Next, the load balancer spreads the incoming connections among the routers so that the connection and messaging load is distributed. If one of the routers fails, the endpoints connected to it will reconnect to the remaining active router.

Figure 3.5. Router Pair behind a Load Balancer

Two Routers behind load balancer

For even greater scalability, you could use a larger number of routers, three or four for example. Each router would be connected directly to all of the others.

3.5. Router Pair in a DMZ

In this deployment architecture, the router network is providing a layer of protection and isolation between the clients in the outside world and the brokers backing an enterprise application.

Figure 3.6. Router Pair in a DMZ

Two Routers in a DMZ

Important notes about the DMZ topology:

  • Security for the connections within the deployment is separate from the security used for external clients. For example, your deployment might use a private Certificate Authority (CA) for internal security, issuing x.509 certificates to each router and broker for authentication, while external users might use a different, public CA.
  • Inter-router connections between the enterprise and the DMZ are always established from the enterprise to the DMZ for security. Therefore, no AMQP connections are permitted from the outside into the enterprise. The AMQP protocol permits bi-directional communication once a connection is established, however.

3.6. Router Pairs in Different Data Centers

You can use a more complex topology in a deployment of Red Hat JBoss AMQ 7.0 components that spans multiple locations. You could, for example, deploy a pair of load-balanced routers in each of four locations. You might include two backbone routers in the center to provide redundant connectivity between the four locations. Below is a diagram of an example deployment that spans multiple locations.

Figure 3.7. Multiple Interconnected Routers

Interconnected Routers

Revised on 2017-09-01 11:04:07 EDT