Introduction on Clustering
Today's enterprise depends on the availability of mail and web services. Failure is never far away, whether it be a hardware failure or a human error. We have to try to make an infrastructure as highly available as possible. No company would afford to lose a customer when the services they offer to be unreachable, especially since that downtime will almost undoubtedly cost them money. Clustering is the approach towards maintaining highly available Customer service.
What is Clustering & High Availability?
A cluster is two or more interconnected servers (sometimes called nodes) that create a solution to provide higher availability, higher scalability or both. The advantage of clustering servers for high availability is seen if one node fails, another node in the cluster can assume the workload of the failed node, and users see no interruption of access. The advantages of clustering servers for scalability include increased application performance and a greater number of users that can be supported. You can think of a cluster of servers as if they were a single, unified computing resource. With the total redundancy of multiple servers, the cluster can help achieve greater system uptime.
Clustering can be implemented at different levels of the system, including hardware, operating systems, middleware, systems management and applications. The more layers that incorporate clustering technology, the more reliable, scalable and manageable the cluster.
Sun MQ Introduction
Sun Message Queue is a messaging middleware product that implements the Java Message Service (JMS) standard.
Connects legacy and new applications, extending current IT assets
Minimizes application downtime through failover capabilities and high availability with Sun Cluster software.
Message server clusters enables the system to optimize network performance and throughput, providing performance that meets large-scale enterprise needs
Ensures only authorized individuals have access; messages are tamper-proof and confidential
Includes broker clustering as well as load distribution and scaling
Sun MQ Broker Introduction
In order to send or receive messages, a JMS(Java Messaging Service) client must first connect to a JMS message server (most often called a broker): the connection opens a channel of communication between the client and the broker. Next, the client must set up a session for creating, producing, and consuming messages. You can think of the session as a stream of messages defining a particular conversation between the client and the broker. The client itself is a message producer and/or a message consumer. The message producer sends a message to a destination that the broker manages. The message consumer accesses that destination to consume the message. The message includes a header, optional properties, and a body. The body holds the data; the header contains information the broker needs to route and manage the message; and the properties can be defined by client applications or by a provider to serve their own needs in processing messages. Connections, sessions, destinations, messages, producers, and consumers are the basic objects that make up a JMS application.
Using these basic objects, a client application can use two messaging patterns (or domains) to send and receive messages
Sun MQ Broker Architecture
Sun MQ Broker Architecture Explanation
Clients A and B are message producers, sending messages to clients C, D, E, and F by way of two different kinds of destinations.
Messaging between clients A, C, and D illustrates the point-to-point domain. Using this pattern, a client sends a message to a queue destination from which only one receiver may get it. No other receiver accessing that destination can get that specific message.
Messaging between clients B, E, and F illustrates the publish/subscribe domain. Using this broadcast pattern, a client sends a message to a topic destination from which any number of consuming subscribers can retrieve it. Each subscriber gets its own copy of the message.
Message consumers in either domain can choose to receive messages synchronously or asynchronously. Synchronous consumers make an explicit call to retrieve a message; asynchronous consumers specify a callback method that is invoked to pass a pending message. Consumers can also filter out messages by specifying selection criteria for incoming messages
Steps to Achieve SunMQ clustering
Two Windows Machines running either Windows Xp or Windows 2000/2003 series Operating system.
Two machines should be in network and ping-able to each other.
MySQL is installed on these two machines and are highly available to each other
Machine 1 IP address x.x.x.x and Machine 2 IP address y.y.y.y
Details regarding MySQL clustering can be found in the KM site. Document name is “MySQL Clustering”
1) Download "mq4_1-installer“
2) Click on "installer.vbs“
3) It will open an installation window .Stick to all default values and install SUN MQ.
4) Go to path "C:\Program Files\Sun\MessageQueue\mq\lib\ext". Place JdbcOdbc.dll and mysql-connector-java-3.1.14-bin.jar file.
5) Go to path "C:\Program Files\Sun\MessageQueue\mq\ var\instances\imqbroker\props". Open config.properties in Machine1 and Machine 2 and copy the configuration in the next slides at the end of file in Machine 1 and Machine 2 respectively. Modify the values according to the required setup in the systems required
Machine 1 Configuration. Machine 1 IP address :x.x.x.x
Machine 2 Configuration. Machine 2 IP address :y.y.y.y
Configuration Parameters Explained
- Broker list specifies the IP address of the Machines to be added for SUN MQ high availability.
- Heartbeat interval specifies interval in seconds for checking the other system status
- Heartbeat port specifies the port on which heart beat functionality needs to be checked.
- Heartbeat hostname specifies the hostname for which heartbeat functionality needs to be checked.
- Mysql.property.url specifies the database which is used with their relevant details. In this case we are using clustered Mysql setup with HDA3 database.
- Imq.brokerid specifies the Idname for the broker. This will be different for different systems that are being clustered. In the above configuration Machine 1 broker id is “tom” and Machine 2 broker id is “david”.
- Imq.cluster.hostname specifies the hostip of the system.
6) Start Sun MQ by typing “Imqbrokerd” from command prompt in the path "C:\Program Files\Sun\MessageQueue\mq\bin" in both the machines. Message in next slide shows the establishment of clustered connection on machine x.x.x.x. Similar output will be generated on the other machine with IP address y.y.y.y.
Imqbrokerd command output on Machine x.x.x.x.
C:\Program Files\Sun\MessageQueue\mq\bin >imqbrokerd
Sun Java(tm) System Message Queue 4.1
Sun Microsystems, Inc.
Version: 4.1 (Build 36-e)
Compile: Thu 07/26/2007
Copyright (c) 2007 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
Java Runtime: 1.5.0_15 Sun Microsystems Inc. C:\Program Files\Java\jdk1.5.0_15\jre
[06/Oct/2009:12:19:10 IST] IMQ_HOME=C:\mq\mq
[06/Oct/2009:12:19:10 IST] IMQ_VARHOME=C:\mq\mq\var
[06/Oct/2009:12:19:10 IST] Windows XP 5.1 x86 host1 (2 cpu) tom
[06/Oct/2009:12:19:10 IST] Java Heap Size: max=194432k, current=16256k
[06/Oct/2009:12:19:10 IST] Arguments:
[06/Oct/2009:12:19:10 IST] [B1060]: Loading persistent data...
[06/Oct/2009:12:19:10 IST] Using plugged-in persistent store:
database connection url=jdbc:mysql://localhost:3306/HDA3?autoReconnect=true&jdbcCompliantTruncation=false&am
ull database user=root
[06/Oct/2009:12:19:18 IST] [B1039]: Broker "imqbroker@host1:7676" ready.
[06/Oct/2009:12:19:31 IST] [B1071]: Established cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker
[06/Oct/2009:14:22:07 IST] [B1072]: Closed cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker&brok
[06/Oct/2009:14:22:13 IST] WARNING [B2105]: Attempting to initiate a cluster connection to mq://y.y.y.y:7676/?inst
Name=imqbroker&brokerID=david&brokerSessionUID=7928908375671418112&ha=true&storeSessionUID=7928908375671418112 failed: [
B4256]: Unable to get cluster service port from broker mq://y.y.y.y:7676/?instName=imqbroker&brokerID=david&broker
[06/Oct/2009:14:22:25 IST] [B1071]: Established cluster connection to broker mq://y.y.y.y:7676/?instName=imqbroker
Working with IMQ Admin for Creating Brokers
1)Type imqadmin in command prompt at “C:\Program Files\Sun\MessageQueue\mq\bin”.
2)Window as shown below will be opened
Right click on Broker and give "Add Broker". It gives a window as shown below. Give password as "admin " .Click "OK"
Right click on the broker added and select option "Connect to Broker"
After the broker got connected, six elements in the Service could be seen (refer to the picture below)
Right click on the destination and select option "Add New Broker Destination". A new window will open up as shown below
6) Choose the destination type as topic or a Queue and give the destination Name
7) Generate Message using pre configured application.
8) Make any one of the Sun MQ machine down. The other working Sun MQ machine will show the messages that were there in the Sun MQ which went down. This happens after predefined interval of time. This interval can be set in configuration file.
When a Non-clustered Sun MQ goes down, the entire Message stored is unavailable until the server is brought back up. Any Message that is stored is lost and will have high impact on business performance. The clustered configuration provides uninterrupted service and Message data persistence by providing failover
Following sites can be referred for further information.