Skip to main content

Setting up the WebSphere MQ cluster - Middleware News

Setting up the WebSphere MQ cluster - Middleware News

After you have created a message queue on each server, work on the Initial server to create the cluster.

About this task

Set up the IBM® WebSphere® MQ cluster by completing the following tasks in the sequence shown:

Creating the WebSphere MQ cluster on the Initial server

On the cluster's Initial server, use WebSphere MQ Explorer to define the cluster by naming it, specifying the queue managers that belong to the cluster, and then connecting them to the Initial server.

Creating the configuration manager on the Initial server

After you create the WebSphere MQ cluster, create a Configuration Manager that will control all of the event brokers after you gather them into a collective in a later task.

Creating a broker on the Initial server

Use the IBM Message Broker Command Console to create a message broker on the Initial server in your IBM WebSphere MQ cluster.

Enabling broker security on the Initial server

Start the broker services for the instance of IBM WebSphere Event Broker on the cluster's Initial server, and enable security for them.




Creating the WebSphere MQ cluster on the Initial server

On the cluster's Initial server, use WebSphere® MQ Explorer to define the cluster by naming it, specifying the queue managers that belong to the cluster, and then connecting them to the Initial server.

Before you begin

A cluster consists of one "Initial server" plus one or more "Additional servers." You create the cluster on the Initial server by defining channels for transmitting data between the Initial server and each Additional server. For each Additional server, you specify three connections between it and the Initial server:
A basic connection between the two servers, which is immediately tested for validity; this ensures that the next two connections (cluster-receive channels) will work.
A cluster-receiver channel on the Initial server, where you specify a unique name for the channel, and a target host (the computer where the Additional server is installed).
A matching cluster-send channel is created automatically on that Additional server, using the same name. Now data can be transmitted from the Additional server to the Initial server.

A corresponding cluster-receiver channel on the Additional server, which also uses a unique name and then specifies the Initial server as the target host.
A matching cluster-send channel is created automatically the Initial server, using the same name. Now data can be sent from the Initial server to the Additional server, closing the loop.

When you finished, you will have two valid, one-way channels for transmitting cluster data between the Initial server and each Additional server.

About this task
Begin by opening WebSphere MQ Explorer. In the Navigator, right-click on Queue Manager Clusters, and click New > Queue manager cluster.
Name the cluster In the "Create Cluster" screen, type STA_MQ_CLUSTER as the name of the new cluster, and then click Next.
Select the first full repository queue manager In the list, select the queue manager for the Initial server (sccs.queue1.manager in this documentation), click Add a queue manager to WebSphere MQ, and then click Next.
Add the queue manager for one Additional server by completing these steps:
You must complete the following sub-steps for every Additional server in sequence before attempting to add the queue manager for the next one.

Select the queue manager and connection method In the queue manager name field, type the name of the Additional server's queue manager (for example, sccs.queue2.manager in this documentation); click Connect directly, and then click Next.
Specify new connection details In the Host name or IP address field, type either the host name or the IP address of the Additional server; leave the rest of the default settings alone, and click Next.
Define the cluster-receiver channel for the queue manager Here, you are specifying how the Additional server's queue manager will receive cluster information from the Initial server's queue manager by defining a channel from the Initial server to the Additional server. Leave the default channel name alone and type the host name of the first queue manager (the server where sccs.queue1.manager is hosted) in the Cluster-receiver channel connection name field; then click Next.
Trying to connect to the queue manager... This message appears while WebSphere MQ tests to make sure there is a valid connection between the two servers before you begin defining send and receive channels. If the connection fails, you will see a warning and must fix the problem before proceeding. When the connection is successful, you can continue with the next step.
Creating cluster channels Review the information on this screen before proceeding to create the send and receive channels that will connect the Additional server to the Initial server.
In short, server's cluster-receiver channel must use a unique name. This name defaults to a form of the server's queue-manager name. If you used unique names for your queue managers when setting them up (as in sccs.queue1.manager and sccs.queue2.manager), then accepting the default names for each cluster-receiver channel will ensure that they receive unique names. Then, the cluster-receiver channel's name on each server is used as the cluster-send channel on its opposite, so that a send/receive pair always use the same name.

Begin defining cluster-receiver channels. In the "Create cluster" screen, click Add a queue manager to WebSphere MQ, and then click Next.
Select the queue manager and connection method In the queue manager name field, type the name of the Additional server's queue manager (for example, sccs.queue2.manager); click Connect directly, and then click Next.
Name the first full repository's cluster-receive channel Here, you are specifying how the Initial server's queue manager will receive cluster information from the Additional server's queue manager by defining a cluster-receive channel on the Initial server. Leave the default channel name alone and type the host name of the Additional server's queue manager (for example, where sccs.queue2.manager is hosted) in the Cluster-receiver channel connection name field; then click Next.
Name the second full repository's cluster-receive channel Now you will define a corresponding cluster-receiver channel on the Additional server. Leave the default channel name alone and type the host name of the Initial server's queue manager (for example, where sccs.queue1.manager is hosted) in the Cluster-receiver channel connection name field; then click Next.
Repeat from Substep a for every Additional server in the cluster.
Create the cluster Review the Summary, which details the operations that will be completed to create the cluster, and then click Finish.
Use WebSphere MQ Explorer to start all of the cluster-senders and cluster-receivers:
In the Navigator, expand Queue Managers > queue_mgr_name on 'initial_server_host_name( > port)' > Advanced > Channels.
For example, the channels for the Initial server will look similar to this: sccs.queue1.manager on 'initialhost.acme.com(1414)'

Make sure that each channel is up and running (the arrow should be pointing up in the "Channels" panel); start the channel if needed.
Repeat for every server in the cluster.

Comments

adsrerrapop

Popular posts from this blog

Troubleshooting Java/JMS SSL Configurations - Middleware News

 This document is intended to help diagnose WebSphere MQ V7 Java™ or JMS SSL setup errors. It lists most of the common configuration errors that can cause an SSL connection from a Java/JMS client to a queue manager to fail, and gives the course of action to resolve the problem. In each case the error can be diagnosed by a combination of the error seen in the client log - either a console output, trace file or SystemOut.log file - and the queue manager's error logs. The document is quite long, so the easiest way to find the potential error is to search for one of the errors seen in this list, then filter this list using the error from the opposite end of the channel. All cases here assume that 2-way authentication is being attempted (SSLCAUTH set to REQUIRED on the queue manager's SVRCONN channel). This is the default, and the errors are very similar for 1-way authentication (SSLCAUTH set to OPTIONAL). Symptom Instructions on collecting documentation...

Using telnet to test connectivity between IBM Websphere MQ Client and MQ server - Middleware News

You are having trouble connecting a WebSphere MQ client to a MQ server, receiving errors that you can not connect to the MQ queue manager. One of the first things to determine is if the two machines can communicate, and using the telnet tool is one way to accomplish it. Symptom Receiving errors which state that a queue manager is not found or not available. Connection errors. For example: AMQ9213, AMQ9524, AMQ9202 or AMQ9508 or MQRC =2059 0x0000080b MQRC_Q_MGR_NOT_AVAILABLE. Please note, this is by no means an exclusive list of errors related to this type a problem but just a sample of some of the more common error messages and codes that might occur. Cause One possible cause is that the two machines can not communicate. May be the IP address or hostname was not properly specified by the MQ client. The port number might be incorrect. A queue manager is not running at the desired host. The queue manager could be running, but the corresponding listener is not runnin...

IBM Websphere MQ interview Questions Part 5

MQ Series: - It is an IBM web sphere product which is evolved in 1990’s. MQ series does transportation from one point to other. It is an EAI tool (Middle ware) VERSIONS:-5.0, 5.1, 5.3, 6.0, 7.0(new version). The currently using version is 6.2 Note: – MQ series supports more than 35+ operating systems. It is platform Independent. For every OS we have different MQ series software’s. But the functionality of MQ series Default path for installing MQ series is:- C: programfiles\BM\clipse\SDK30 C: programfiles\IBM\WebsphereMQ After installation it will create a group and user. Some middleware technologies are Tibco, SAP XI. MQ series deals with two things, they are OBJECTS, SERVICES. In OBJECTS we have • QUEUES • CHANNELS • PROCESS • AUTHENTICATION • QUERY MANAGER. In SERVICES we have LISTENERS. Objects: – objects are used to handle the transactions with the help of services. QUEUE MANAGER maintains all the objects and services. QUEUE: – it is a database structure ...