Table of Contents
This chapter describes the clustering technology that groups multiple servers together to reduce JEUS MQ server loads and provide seamless services.
JEUS MQ clustering is provided as JEUS MQ failover function.
If you are using a single JEUS MQ server, it has to process too many stored messages or client connections, which increases the network load or server memory usage. This may cause performance degradation or server shutdowns. To prevent these problems, you can add and group JEUS MQ servers to work together like a single server. This process is called JEUS MQ clustering. A clustered server can be accessed by a client as it were a stand-alone server.
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. Because connection factories are used to make the connections between servers and clients, this distribution function must be provided by connection factories. This process is called connection factory clustering.
When a connection is created from a connection factory, the connection is assigned to a server using the round-robin method.
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, messages that a server receives may exceed its capacity and the server may not be able to receive more messages, depending on the processing speed and network conditions.
To prevent this problem, excess messages are moved to the JEUS MQ servers that are holding fewer messages. This process 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
In the left pane of the main WebAdmin page, click the [Clusters] menu. By navigating from here, you can configure destinations and durable subscribers of JEUS MQ servers that are clustered. The configurations are applied 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
When you are creating a connection factory by using JEUS MQ API, If the JEUS MQ server is clustered, you need to perform an additional task besides those described in "2.2.2. Connection Factories".
That is, you need to add information about all the clustered servers by 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 online shop that uses the JEUS MQ for processing product orders.
The orders are implemented as messages. The messages are queued in the JEUS MQ and processed on the business servers, and the JEUS MQ servers are clustered.
The following is an ideal example of a JEUS MQ server cluster. Each business server receives messages from its corresponding JEUS MQ server, and the request messages are evenly distributed to 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 receive messages from other JEUS MQ servers through destination clustering and pass 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 with a particular JEUS MQ server, loads can be unevenly distributed across multiple connections causing unnecessary transmission of messages, which can significantly reduce the processing efficiency.