Table of Contents
This chapter describes the clustering technology that groups multiple servers together to reduce JEUS MQ server loads and provide seamless services.
When using a single JEUS MQ server, too many stored messages or client connections on the server increases the network load or server memory usage.
This may cause some performance degradation or lead to server shutdowns. To handle such problems, additional JEUS MQ servers can be added and grouped to work together like a single server. This is called JEUS MQ clustering.
A client can access a clustered server in the same way it accesses a single server.
Note
In JEUS v7.0 Fix#1 and later, JEUS MQ clustering supports JEUS MQ failover function that enables additional functions through simple configurations. For more information, refer to "Chapter 5. JEUS MQ Failover".
There are two types of clustering, Connection Factory Clustering and Destination Clustering.
When two or more JEUS MQ servers are clustered, client connections to the servers must be distributed. Since the connections between servers and clients are established using connection factories, this distribution function must be provided by connection factories. This is called Connection Factory Clustering.
When a connection is created from a connection factory, each connection is established to a different server. Although the policy for selecting a different server each time can be configured, currently, only the round-robin method is supported.
The following figure shows connection factory clustering.
Note
A JEUS MQ client is connected to one server in the cluster, and the client does not need to be concerned about which server it is connected to.
Even if all client connections are distributed by connection factory clustering, depending on the processing speed and network conditions there may be cases when the messages on a server exceeds its capacity and can no longer receive messages.
To handle such problem, surplus messages have to be moved to the JEUS MQ servers with fewer messages. This is called Destination Clustering .
The following figure shows destination clustering.
This section describes the configurations required for JEUS MQ clustering.
JEUS MQ clustering is configured based on JEUS server clustering configurations. For more information about JEUS server clustering, refer to JEUS Domain Guide. "Chapter 5. JEUS Clustering"
JEUS MQ Clustering Configuration Requirements
Destinations and Durable Subscribers of JEUS MQ servers participating in JEUS MQ clustering are configured by using the [Clusters] menu in the left pane of the main WebAdmin page. The configurations apply to the servers in the cluster. Since each server has a different address, its connection factory is configured by using the [Servers] menu in the left pane, but all servers must have the same connection factory name.
To set a Destination or a Durable Subscriber in the cluster, go to [Clusters] > [Cluster Names] > [Engine] tab and click [Jms Engine]. The following configuration screen appears. For information about configuring individual Destination or Durable Subscriber, refer to "3.2. Configuring JMS Resources".
Note
1. For more information about how to add a server to the cluster, refer to JEUS Domain Guide. "5.6.1. Adding a Server to the Cluster".
2. If a destination is set, the destination or durable subscriber settings will be ignored. However, duplicate names must be avoided so that the system can accurately operate.
This section describes the client settings required for JEUS MQ clustering. To enable JEUS MQ clustering, the first thing to configure is a connection factory.
There are two types of connection factory clustering in JEUS MQ based on how a connection factory is obtained.
-
Using JNDI Service
-
Using JEUS MQ API
Using JNDI Service
JNDI services can be used in the same way as described in "2.2.2. Connection Factories", regardless of whether the JEUS MQ server is clustered or not. A client can either look up a new connection factory using JNDI service each time, or create only the connection by reusing an already obtained connection factory.
The policy for selecting a JEUS MQ server differs depending on how the client obtains a connection factory.
-
When JNDI service is used by a client to obtain a new connection factory each time, the policy for selecting a server depends on the JNDI service. In this case, the JEUS node clustering must be configured.
For more information about how to implement a client program that uses JNDI clustering, refer to JEUS Domain Guide. "Chapter 5. JEUS Clustering" and JEUS Server Guide. "4.5. JNDI Programming."
-
The policy for selecting a server can be configured if the client creates a connection by reusing an already obtained connection factory. Currently, JEUS only supports the round-robin method.
Using JEUS MQ API
If the JEUS MQ server is clustered when creating a connection factory using JEUS MQ API, there are some additional required tasks besides those described in "2.2.2. Connection Factories".
The information about all the servers participating in the cluster must be added using the JeusConnectionFactoryCreator.addBrokerAddress() method as in the following.
jeus.jms.client.util.JeusConnectionFactoryCreator connectionFactoryCreator =
new jeus.jms.client.util.JeusConnectionFactoryCreator();
connectionFactoryCreator.setFactoryName("ConnectionFactory");
connectionFactoryCreator.addBrokerAddress("192.168.1.2", 9741, <service-name>);
connectionFactoryCreator.addBrokerAddress("192.168.1.3", 9741, <service-name>);
connectionFactoryCreator.addBrokerAddress("192.168.1.4", 9741, <service-name>);
ConnectionFactory connectionFactory = connectionFactoryCreator.createConnectionFactory();
This section describes examples of good and bad JEUS MQ clustering practices.
Suppose that there is an e-store that uses JEUS MQ to process product orders.
The orders are implemented as messages. The messages are queued on the JEUS MQ queues and processed on the business servers, and the JEUS MQ servers are clustered.
The following is an ideal example of JEUS MQ server clustering configuration. Each business server receives messages from its corresponding JEUS MQ server, and the request messages are evenly distributed on the JEUS MQ servers. If a particular business server processes its requests fast, its JEUS MQ server can clear the queue faster than others. In this case, the JEUS MQ server can retrieve messages from other JEUS MQ servers through destination clustering and send them to its business server for processing.
The following JEUS MQ server clustering configuration may reduce processing efficiency.
If a JMS client continually reuses a connection from a particular JEUS MQ cluster, loads can be unevenly distributed across multiple connections causing unnecessary transmission of messages which can significantly reduce the processing efficiency.