Cluster Models

Message Queue offers two cluster architectures, depending on the degree of availability desired.

• Conventional clusters provide service availability but not data availability. If one broker in a cluster fails, clients connected to that broker can reconnect to another broker in the cluster but may be unable to access some data while they are reconnected to the alternate broker.

• High availability clusters provide both service availability and data availability. If one broker in a cluster fails, clients connected to that broker are automatically reconnected to that broker in the cluster which takes over the failed broker's store. Clients continue to operate with all persistent data available to the new broker at all times.

The ability of brokers to work together in a cluster is provided by a cluster connection service. This service is configured using broker properties; which properties you configure depend on the model you want to use.

Each cluster model is described next and the sections that follow describe additional concerns and tasks that you need to consider when working with clusters. The chapter ends with a summary of the differences between the two models.

Conventional Clusters

Figure 4–1 shows Message Queue’s architecture for conventional broker clusters. Each broker within a cluster is directly connected to all the others. Each client (message producer or consumer) has a single home broker with which it communicates directly, sending and receiving messages as if that broker were the only one in the cluster. Behind the scenes, the home broker works in concert with the other brokers to provide delivery services for all connected clients.

In a cluster, service availability depends on brokers being able to share information about destinations and durable subscribers. If a clustered broker fails, it is possible that this state information gets out of sync. To guard against this possibility, you can designate one broker within the cluster as the master broker. The master broker maintains a configuration change record to track changes to the cluster’s persistent entities (destinations and durable subscriptions). This record is used to propagate such change information to brokers that were offline when the changes occurred.

Figure 4–1 Cluster Architecture

Following a discussion of the high availability model, this chapter explains how message delivery takes place within a cluster and how the brokers are configured and synchronized.

High Availability Clusters

High availability clusters provide both service and data availability.

Each broker within a cluster is directly connected to all the others. Each client (message producer or consumer) has a single home broker with which it communicates directly, sending and receiving messages as if that broker were the only one in the cluster. Behind the scenes, the home broker works in concert with the other brokers to provide delivery services for all connected clients.

All brokers in a high availability cluster share a common JDBC-based persistent data store that holds dynamic state information (destinations, persistent messages, durable subscriptions, open transactions, and so on) for each broker. If a broker in the cluster fails, another broker takes over the failed broker's lock in the persistent store. Clients connected to the failed broker are reconnected to the broker that has taken over the failed broker's store. The broker that takes over the connection becomes the client's new home broker.

Figure 4–2 shows three brokers connected into a high availability cluster. The dotted line represents the cluster service. In the event that Broker 1 fails or the connection (C1) between clients at Broker 1 is broken, clients are reconnected to Broker 3 using a new connection (C2). Note that all brokers belonging to the high availability cluster are connected to the same highly available database.

Figure 4–2 High Availability Cluster

To configure a high availability cluster you set cluster configuration properties for each broker in the cluster. These specify the cluster id and the broker id in the cluster and they configure the protocol governing the failover process.