|
| |
| Sun Java System Message Queue 3 2005Q1 Technical Overview | |
Chapter 5
Broker ClustersMessage Queue Enterprise Edition supports the use of broker clusters: groups of brokers working together to provide message delivery services to clients. Clusters enable a message server to scale its operations with the volume of message traffic by distributing client connections among multiple brokers.
This chapter discusses the architecture and internal functioning of such broker clusters. It covers the following topics:
You need to read this chapter if you are an administrator charged with configuring and managing a broker cluster or a developer who needs to test a messaging application using a cluster.
Cluster ArchitectureFigure 5-1 shows Message Queue’s architecture for 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 on the server. Behind the scenes, the home broker works in concert with the other brokers in the cluster to share the load of providing delivery services for all connected clients.
One broker within the cluster can be designated as the master broker. The master broker maintains a configuration change record in which changes to the cluster’s persistent entities (destinations and durable subscriptions) are recorded. This record is used to propagate such change information to brokers that were offline at the time the changes occurred; see Cluster Synchronization, below, for further discussion.
Figure 5-1 Cluster Architecture
The following sections discuss how message delivery takes place within a cluster and how the brokers are configured and synchronized, even in the case when one or more has been offline.
Message Delivery
In a cluster configuration, each destination is replicated on all brokers in the cluster. Each broker knows about message consumers that are registered for destinations on all other brokers. Each broker can therefore route messages from its own directly connected message producers to remote message consumers, and can deliver messages from remote producers to its own directly connected consumers.
A message producer’s own home broker handles all storage and routing, and processes all client acknowledgments, for messages originated by that producer. To minimize message traffic within the cluster, messages are sent from one broker to another only when they are to be delivered to a consumer connected to the target broker. In some cases (such as queue delivery to multiple consumers), traffic can be further reduced by specifying that delivery to local consumers have priority over delivery to remote consumers. In situations requiring secure, encrypted message delivery between client and message server, a cluster can also be configured to provide secure delivery of messages between brokers.
Cluster Configuration
To establish connections between the brokers in a cluster at startup time, each broker must be passed the host names and port numbers of all the others (including the master broker, if any). This information is specified by a set of cluster configuration properties, which should be uniform for all brokers in the cluster. Although you can specify the configuration properties for each broker individually, this approach is error-prone and can easily lead to inconsistencies in the cluster configuration. Instead, it is recommended that you place all the configuration properties in one central cluster configuration file that is referenced by each broker at startup time. This ensures that all brokers share the same configuration information.
See the Message Queue Administration Guide for detailed information on cluster configuration properties.
Note
Although the cluster configuration file was originally intended for configuration purposes, it is also a convenient place to store other properties that are shared by all brokers in a cluster.
Cluster Synchronization
Whenever a cluster’s configuration is changed, information about the change is automatically propagated to all brokers in the cluster. Such configuration changes include the following:
- A destination on one of the cluster’s brokers is created or destroyed.
- A message consumer is registered with its home broker.
- A message consumer is disconnected from its home broker (whether explicitly or through failure of the client, the broker, or the network).
- A message consumer establishes a durable subscription to a topic.
Such configuration change information is propagated immediately to all brokers in the cluster that are online at the time of the change. However, a broker that is offline (one that has crashed, for example) will not receive notice of the change when it occurs. To accommodate offline brokers, Message Queue maintains a configuration change record for the cluster, recording all persistent entities (destinations and durable subscriptions) that have been created or destroyed. When an offline broker comes back online (or when a new broker is added to the cluster), it consults this record for information about destinations and durable subscribers, then exchanges information with other brokers about currently active message consumers.
One broker in the cluster, designated as the master broker, is responsible for maintaining the configuration change record. Because other brokers cannot complete their initialization without the master broker, it should always be the first broker started within the cluster. If the master broker goes offline, configuration information cannot be propagated throughout the cluster, because other brokers cannot access the configuration change record. Under these conditions, you will get an exception if you try to create or destroy a destination or a durable subscription or attempt a related operation such as reactivating a durable subscription. (Non-administrative message delivery continues to work normally, however.)
Deployment EnvironmentThe use of broker clusters depends on whether they are deployed in a development environment or a production environment.
Development Environments
In development environments, where a cluster is used for testing and where scalability and broker recovery are not important considerations, there is little need for a master broker. Under test conditions, destinations are often auto-created (see Auto-Created Destinations) and durable subscriptions to these destinations are created and destroyed by the applications being tested. In the absence of a master broker, Message Queue relaxes the requirement that a master broker be running in order to start other brokers, and allows changes in destinations and durable subscriptions to be made and propagated to all running brokers. (If a broker goes offline and is subsequently restored, however, it will not synchronize with changes made while it was offline.) If you reconfigure the environment to use a master broker, Message Queue will reimpose the normal requirements.
Production Environments
In production environments, where scalability and broker recovery are important considerations, it is essential to use a master broker and maintain the configuration change record. This guarantees that if a broker goes offline and is subsequently restored, it will synchronize with changes made while it was offline.
In fact, it is a good idea to make a periodic backup of the configuration change record to guard against accidental corruption of the record and safeguard against failure of the master broker. Message Queue provides command-line options for backing up and restoring the configuration change record. If necessary, you can also change the broker serving as the master broker. See the Message Queue Administration Guide for more information.
