Overview

Skill Level: Advanced

MQ Cluster, Full & Partial Repositories, Overlapping Clusters using Namelist, Qmgr Aliasing Techniques, Cluster WorkLoad Management

This article demonstrates the Technical Implementation of Advanced Clustering Concepts like Gateway Qmgr, Aliasing Techniques, Work Load Balancing, Multi-Hopping, Overlapping Clusters along with Distributed Queuing in Real World Scenarios.

Ingredients

IBM MQ v7.0 & Above

Platform: Windows & Linux

Concepts Covered: Distributed Queueing, Knowledge on MQ Cluster, Full & Partial Repositories, Gateway Queue Managers, Qmgr Aliasing Techniques, Overlapping Clusters using Namelist, Cluster Workload Balancing, Muti-Hopping Technique, Sending Message Inside/Outside the Cluster.

Introduction: The Objective of this article is to demonstate the technical implementation of some of the Advanced Clustering concepts using IBM MQ. We will start by setting up simple MQ Cluster called CLUS1 as shown in the below diagram & then add / remove configuration items based a specific Test Case. One can you use any one below mentioned technique or a combination of multiple techniques to achieve a technical solution involving IBM® MQ Clusters at an Enterprise Level.

1-1

                                The above diagram represents a simple MQ Cluster of 4 Qmgrs

Initial Configuration Items:

  • MQ Cluster Name: CLUS1
  • QM1 & QM2 hosts the Full Repository (FR) Qmgrs.
  • QM3 & QM4 represents the Partial Repository (PR) Qmgrs.
  • QM1 & QM2 should be Fully Interconnected using Cluster Sender/Receiver Channels.
  • QM3 is connected to QM1 using Cluster Sender/Receiver Channel.
  • QM4 is conneced to QM2 using Cluster Sender/Receiver Channel.

Step-by-step

  1. Setup a MQ Cluster

    The following screenshots illustrate how to create a simple MQ Cluster using MQ Explorer Cluster Setup wizard. Here we have created a Cluster called CLUS1. Made QM1 & QM2 as the Full Repos Qmgrs whereas QM3 & QM4 as the Partial Repos Qmgrs.

    1. Righ Click on the ‘Queue Manager Clusters’ & select a new Cluster called CLUS1

    1-2

     2. Select QM1 as the first FULL Repos Qmgr.

    2-1

     3. Select QM2 as the second FULL Repos Qmgr.

    3-1

     4. Interconnect the 2 FULL Repos Qmgrs (QM1 & QM2) using explicitly defined Cluster Sender / Receiver Channel pairs. In this case, the Cluster wizard automatically takes   care of the Channel connection parameters.

    4-1

     5. Once Finished, the Cluster Channels between the FULL Repos qmgr should start running automatically. Also as shown below, a MQ Cluster called CLUS1 has been create with QM1 & QM2 being the Full Repos Qmgrs marked in red.

    5-1

     6. Now, its time to add the QM3 & QM4 into the newly created MQ Cluster i.e. CLUS1 as Partial Repos Qmgr.

    6-1

    7. Similarly, repeat Step 6 for QM4 Qmgr. Once completed, you will now see the Cluster 2 FULL Repos Qmgrs & 2 Partial Repos Qmgrs as shown below in the screenshot.

    7-1

    Alternatively, you can see the same output from Command prompt (Applicable for UNIX Platform as well) using the Cluster Command from any one of the FULL Repos Qmgr:

    DIS CLUSQMGR(*) QMTYPE

    QMTYPE ==> REPOS Signifies Full Repository Qmgr

    QMTYPE ==> NORMAL Signifies Partial Repository Qmgr

    8-1

    UNIX Commands to Create & Configure MQ Cluster ‘CLUS1’

    #######################################################

    runmqsc QM1

    ################

    ALTER QMGR REPOS(‘CLUS1’)

    DEFINE CHANNEL(TO.QM1) CHLTYPE(CLUSRCVR) CONNAME(127.0.0.1(1414)) CLUSTER(‘CLUS1’)

    DEFINE CHANNEL(TO.QM2) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1415)) CLUSTER(‘CLUS1’)

    runmqsc QM2

    #############

    ALTER QMGR REPOS(‘CLUS1’)

    DEFINE CHANNEL(TO.QM1) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1414)) CLUSTER(‘CLUS1’)

    DEFINE CHANNEL(TO.QM2) CHLTYPE(CLUSRCVR) CONNAME(127.0.0.1(1415)) CLUSTER(‘CLUS1’)

    runmqsc QM3

    #############

    DEFINE CHANNEL(TO.QM1) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1414)) CLUSTER(‘CLUS1’)

    DEFINE CHANNEL(TO.QM3) CHLTYPE(CLUSRCVR) CONNAME(127.0.0.1(1416)) CLUSTER(‘CLUS1’)

    runmqsc QM4

    #############

    DEFINE CHANNEL(TO.QM2) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1415)) CLUSTER(‘CLUS1’)

    DEFINE CHANNEL(TO.QM4) CHLTYPE(CLUSRCVR) CONNAME(127.0.0.1(1417)) CLUSTER(‘CLUS1’)

  2. Send Message Inside the Cluster (Qmgr Alias)

    Case 1: This is the first test case scenario where we are going to send messages Inside the Cluster CLUS1 from an external Qmgr EXT as shown in the below figure. QM4 (PR) has been used as the Gateway Qmgr for the Cluster CLUS1. It is connected with the EXT Qmgr using normal distributed Sender/Receiver Channels. We are going to use Qmgr Aliasing technique at the Gateway Qmgr QM4 to be able to achieve our objective of sending messages inside the Cluster.

    Case2Configuration Definitions (Windows & Unix Platforms):

    1. Under QM2 (FR), we have defined a Local Queue named QM2.RECEIVE & make it part of the Cluster CLUS1.

    runmqsc QM2

    #############

    DEFINE QL(QM2.RECEIVE) CLUSTER(‘CLUS1’)

    2. On the Gatway Qmgr, create a Remote Queue Definitions by keeping the RNAME as BLANK to be able to achieve Qmgr Aliasing.

    runmqsc QM4

    #############

    DEFINE QR(ANY) RNAME(‘ ‘) RQMNAME(‘ ‘) XMITQ(SCTQ) CLUSTER’CLUS1’)

    3. Under external Qmgr EXT, define the Remote Queue by mentioning the Target Queue & Remote Qmgr name inside the Cluster.

    runmqsc EXT

    ############

    DEFINE QR(TO.QM2) RNAME(QM2.RECEIVE) RQMNAME(ANY) XMITQ(QM4)

    Test Result: Put messages in the QR(TO.QM2) under EXT Qmgr, it will first reach the Gateway Qmgr QM4. Since RNAME & RQNAME is mentioned as BLANK, it will use the definitions mentioned in TO.QM2 to be able to route its destination to actual target queue QM2.RECEIVE under QM2 Qmgr.

    TR1

  3. Send Message Inside the Cluster (RQD)

    Case 2: In this scenario, again we are going to send messages Inside the Cluster CLUS1 from an external Qmgr EXT as shown in the below figure similar to Case 1, however, this time though we are going to use Remote Queue Definitions instead of Qmgr Aliasing. QM4 (PR) has been used as the Gateway Qmgr for the Cluster CLUS1. It is connected with the EXT Qmgr using normal distributed Sender/Receiver Channels. We are going to use Remote Queue Definitions technique at the external Qmgr EXT to be able to achieve our objective of sending messages inside the Cluster. 

    Case1Configuration Definitions (Windows & Unix Platforms):

    1. Under external Qmgr EXT, define the Remote Queue by mentioning the Target Queue (RNAME) & Remote Qmgr name (RQMNAME) inside the Cluster.

    runmqsc EXT

    ############

    DEFINE QR(TO.QM1) RNAME(QM1.RECEIVE) RQMNAME(QM1) XMITQ(QM4)

    2. Define the Cluster Local Queue QM1.RECEIVE under QM1(PR) Qmgr.

    runmqsc QM1

    #############

    DEFINE QL(QM1.RECEIVE) CLUSTER(‘CLUS1’)

    Test Result: Put messages into the remote queue QR(TO.QM1) under the EXT Qmgr (outside the Cluster). The messages will first arrive at the Gateway Qmgr QM4 before being routed to the correct destination i.e. QM1.RECEIVE as mentioned in the Remote Queue definition.

    TR2

  4. Send Message Outside the Cluster (Qmgr Alias)

    Case 3: In this scenario, we are going to send messages Outside the Cluster CLUS1 to the external Qmgr EXT using Qmgr Aliasing Technique. QM4 has been used as the Gateway Qmgr for the Cluster CLUS1 which is connected with the external Qmgr EXT using distributed Sender / Receiver channel pairs. As mentioned in the below figure, we are going to put test messages from the FR Qmgr QM1 to a Remote queue (EXT.RECEIVE.A) defined under QM1 which points to another Cluster Remote queue defined on the Gateway Qmgr QM4. This remote Queue has the Aliasing definitions which routes the messages to EXT Qmgr as mentioned in the below figure.

    Case4-1Configuration Definitions (Windows & Unix Platforms):

    Define a Remote Queue EXT.RECEIVE.Q under QM1 (FR) which points to the cluster Remote Queue EXT.RECEIVE.Q on the Gateway Qmgr QM4. Here RNAME(‘ ‘) has been  kept BLANK to use aliasing technique & routes the messages outside the cluster to destination Local Queue EXT.RECEIVE.A on EXT qmgr.

    runmqsc QM1

    #############

    DEFINE QR(EXT.RECEIVE.A) RNAME(EXT.RECEIVE.A) RQMNAME(EXT.RECEIVE.A) XMITQ(‘ ‘)

    runmqsc QM4

    #############

    DEFINE QR(EXT.RECEIVE.A) RNAME(‘ ‘) RQMNAME(EXT) XMITQ(EXT) CLUSTER(‘CLUS1’)

    runmqsc EXT

    #############

    DEFINE QL(EXT.RECEIVE.A)

    Test Result: Here, I am putting a sample test message into the Remote Queue EXT.RECEIVE.A defined under QM1. This message then goes to the Cluster Remote Queue EXT.RECEIVE.A defined on the Gateway Qmgr QM4 & subsequently getting colledt into the Local Queue under EXT qmgr outside the cluster.

    TR3

  5. Send Message Outside the Cluster (RQD)

    Case 4: In this scenario, we are going to send messages Outside the Cluster CLUS1 to the external Qmgr EXT from any Qmgr inside the Cluster using Remote Queue Definitions. QM4 has been used as the Gateway Qmgr for the Cluster CLUS1 which is connected with the external Qmgr EXT using distributed Sender / Receiver channel pairs. As mentioned in the below figure, we are going to put test messages from the FR Qmgr QM1 to a Cluster Remote Queue defined on the Gateway Qmgr QM4. This remote Queue definition has the details of the target Local Queue & Qmgr outside the Cluster CLUS1. The below figure demonstrate the test case of sending msgs outside Cluster.Case3-1Configuration Definitions (Windows & Unix Platforms):

    1. Under Gateway Qmgr QM4, define a Cluster Remote Queue (TO.EXT) which effectively points to a target Local Queue defined under the external Qmgr EXT (Outside the Cluster)

    runmqsc QM4

    #############

    DEFINE QR(TO.EXT) RNAME(EXT.RECEIVE) RQMNAME(EXT) CLUSTER(‘CLUS1’)

    2. Create the Local Queue EXT.RECEIVE under the external Qmgr EXT.

    runmqsc EXT

    #############

    DEFINE QL(EXT.RECEIVE)

    Test Result: Here, I am putting a message into the Cluster Remote Queue (Locally defined under QM4 Gateway Qmgr) using QM1 (FR) which finally goes out of the Cluster CLUS1 & getting collected in the Local Queu EXT.RECEIVE defined under external Qmgr EXT.

    TR4

  6. Cluster Workload Balancing

    Case 5: In this scenario, we are going to implement Cluster Workload balacing of incoming Messages from an external Qmgr EXT (outside the Cluster). As mentioned in Case 1, we are going to make use of Qmgr Alias technique to be able to send messages inside the Cluster & distribute the workload either in Round Robin fashion or customize the workload (by alterting the CLWL parameters) based on your choice or Application designing requirements. In this case, we have defined a Cluster Local Queue called POC1 under each Qmgr inside the Cluster Except Gateway Qmgr QM4. Using Remote Queue defined under the external Qmgr we will now send message inside the Cluster & demonstrate Workload balcing using IBM MQ Cluster.CLWL-ClusConfiguration Definitions (Windows & Unix Platforms):

    1. Define a Cluster Local Queue called POC1 under all Qmgr inside the Cluster CLUS1 except on the Gateway Qmgr QM4.

    runmqsc QM(1,2,3)

    #################

    DEFINE QL(POC1) CLUSTER(‘CLUS1’)

    2. Alter the Qmgr Level Parameter called CLWLUSEQ to ANY (from Default value LOCAL) for all the Qmgrs in the Cluster.

    runmqsc QM(1,2,3,4)

    ##################

    ALTER QMGR CLWLUSEQ(ANY)

    3. Alter the Queue Level Parameters CLWLUSEQ to either (ANY or QMGR) from default value LOCAL and DEFBIND option to NOTFIXED from default value OPEN.

    runmqsc QM(1,2,3)

    ##################

    ALTER QL(POC1) CLWLUSEQ(ANY or QMGR)

    ALTER QL(POC1) DEFBIND(NOTFIXED)

    /* If you have already selected CLWLUSEQ paramater at the Qmgr Level to ANY, then CLWLUSEQ parameter at the Queue Level can be selected as QMGR */

    With these configurations in place, if we put message into the Cluster from the external Qmgr EXT, it should distribute the workload in Round Robin Fashion i.e. if I send 6 messages inside the Cluster, each of the 3 POC1 Cluster queues will receive 2 messages each under QM1, QM2 & QM3 Qmgrs respectively.

    Test Result for Round Robin (RR): I put 6 Messages in the Remote Queue defined under the external Qmgr EXT (outside the Cluster) as shown in the below screenshot. These 6 messages has been equally distributed in RR fashion among the 3 Cluster Queues POC1 under Qmgrs QM1,2&3 as shown in the below screenshot.

    TR5

    Additional Configuration Items for Workload Customizations (Windows & Unix Platforms):

    Alter the CLWLWGHT parameter of the Cluster Receiver Channel only for each of the Qmgr QM1, QM2 & QM3 to the ratio in which you want the workload of incoming messages to be distributed. In this case, I want the incoming messages to be distributed in the ratio of 4(QM1) : 4(QM2) : 2(MQ3). Accordingly, I have modified the CLWLWGHT parameter of the Cluster Receiver channels. Apart from this CLWLWGHT parameter, one can use other CLWL parameters like Rank, Priority, Net priority at the Channel level to distribute the workload accordingly.

    runmqsc QM(1,2,3)

    ##################

    ALTER CHANNEL(TO.QM1) CHLTYPE(CLUSRCVR) CLWLWGHT(4)

    ALTER CHANNEL(TO.QM2) CHLTYPE(CLUSRCVR) CLWLWGHT(4)

    ALTER CHANNEL(TO.QM3) CHLTYPE(CLUSRCVR) CLWLWGHT(2)

    Test Result for Workload Customization: Now, as per the CLWL Design, I want the incoming traffic to be distributed in the ration 4:4:2 among the 3 Qmgrs QM1, QM2 & QM3 respectively. I have put exactly 10 messages into Remote Queue TO.ANY under the External Qmgr EXT. All the 10 messages are distributed based on the CLWLWGHT as per the below screenshot. Thus we have achieved our Test Case objective of Workload balancing!

    CLWL

  7. Multi-Hopping Technique

    Case 6: In this test case, we are going to demonstrate on how to send messages across Qmgrs using Multi-Hopping technique. We made use of the below Network configurations to achieve our objective. There are basically two orgizations A & B, one which has a distributed MQ network (Org.A) connected with Org.B having a MQ Cluster. EXT is the Gatway Qmgr of the Org A whereas QM4 is the Gateway Qmgr of Org B. This two Gatway Qmgrs are connected using standard Sender/Receiver channels. TEST1 is one of the Qmgrs inside Org. A and is connected its Gateway EXT using distributed channels. As part of the Multi-hop requirement, we are going to put messages into a Remote Queue defined under TEST1 Qmgr which will eventually multi-hop through Gateway Qmgrs of Org. A & B i.e EXT and QM4 to  reach its final destination local queue QM3.RECEIVE defined under QM3 qmgr as shown in the below figure.

    Case5-MultiHopping-1Configuration Definitions (Windows & Unix Platforms):

    As per the configuration, Messages will hop starting from TEST1 (Source)  ==> EXT ==> QM4 ==> QM3 (Destination)

    1. Define a Remote Queue under TEST1 Qmgr which contains the details of the actual Target queue & Qmgr.

    runmqsc TEST1

    ###############

    DEFINE QR(TO.QM3) RNAME(QM3.RECEIVE) RQMNAME(QM3) XMITQ(EXT)

    2. Define another Remote Queue (QM3) on the EXT Qmgr using Alias technique {RNAME(”)} to be able to hop the message to the next Qmgr QM4.

    runmqsc EXT

    ############

    DEFINE QR(QM3) RNAME(‘ ‘) RQMNAME(QM3) XMITQ(QM4)

    3. Once the hopping messages reaches the Gateway Qmgr QM4, it will make use of Case2 techniques to be able to route the messages to the destination Qmgr. There won’t be any additional MQ definitions required on QM4.

    runmqsc QM4

    ############

    ** No additional Object definition required on QM4 **

    4. Define the Local queue QM3.RECEIVE & publish the same in the CLuster CLUS1.

    runmqsc QM3

    #############

    DEFINE QL(QM3.RECEIVE) CLUSTER(‘CLUS1’)

    Test Results: Put messages into the Remote Queue TO.QM3 under TEST1 Qmgr as shown below. The messages will mult-hop across Qmgrs between two different networks and finally get collected on the destion queue QM3.RECEIVE on QM3 Qmgr of Org. B

    Multi-Hopping

  8. Cluster Overlapping (Namelists)

    Case 7: In this scenario, we are going to Join 2 MQ Clusters (CLUS1 & CLUS2) using Namelist (CLUS) as shown in the below figure. Both QM1 & QM2 has been designated as the FULL Repos Qmgrs on both Clusters. Alternatively, QM1 & QM2 can be referred to as the Bridge Qmgrs between 2 overlapping Clusters i.e. CLUS1 & CLUS2. We have already created CLUS1 in Section 1, so we are going to create a new Cluster called CLUS2 & make QM1 & QM2 as of the FR Qmgrs of CLUS2 as well.Master-Bridge

    1. Since we are going to use the existing FR Qmgrs (QM1 & QM2) of cluster CLUS1 as the FR Qmgrs of the cluster CLUS2 as well, we don’t need to create the new Cluster CLUS2 using the Wizard as shown in Section1 (Setup a MQ Cluster). Instead, we are going to create a Namelists called CLUS under both QM1 & QM2 qmgrs & make CLUS1 & CLUS2 as its members. The below figures demonstrate the same.

     

    15

    16

    After this Step, we have alter the following configuration items to be able to make QM1 & QM2 as the FR Qmgrs of both Clusters.

    Configuration Definitions (Windows & Unix Platforms):

    runmqsc QM(1,2)

    ###############

    DEFINE NAMELIST(CLUS) NAMES(CLUS1,CLUS2)

    ALTER QMGR REPOS(‘ ‘) REPOSNL(‘CLUS’)

    ALTER CHANNEL(TO.QM1) CHLTYPE(CLUSRCVR) CLUSNL(CLUS)

    ALTER CHANNEL(TO.QM2) CHLTYPE(CLUSRCVR) CLUSNL(CLUS)

    ALTER CHANNEL(TO.QM1) CHLTYPE(CLUSSDR) CLUSNL(CLUS)

    ALTER CHANNEL(TO.QM2) CHLTYPE(CLUSSDR) CLUSNL(CLUS)

    ########################################################

    Once, the above configuration commands has been executed, you will observe that a New Cluster CLUS2 has been created with QM1 & QM2 as it’s FULL Repos Qmgr as shown below.

    17

    Now, follow the same procedure as mentioned in Step 6 (Section1) to add the Partial Repository Qmgrs (QM5 & QM6) into the newly built cluster CLUS2. The following screenshot demonstrate the final output of two overlapping clusters using Namelist CLUS where QM1&2 (FR) are designated as the Bridge Qmgrs.

    18

    Similar output using runmqsc command showing both QM1 & QM2 are the FULL Repos Qmgrs of both Clusters CLUS1 & CLUS2 joined together by Namelist CLUS.

    19

     

  9. Sending Messages across Clusters

    Case 8: This is the last scenario of the Advanced Clustering article. In this test case, we are going to demonstrate the messaging technique between two overlapping Clusters. In the previous Section 8, we have already established an overlapping Cluster (CLUS1 & CLUS2) joined together by a Namelist CLUS. QM1 & QM2 are the 2 FULL Repos Qmgrs of both CLUS1 & CLUS2, thus acting as the Bridge Qmgrs across 2 separate clusters. In this test case, we are going to send messages from QM3 (PR of CLUS1) to QM5 (PR of CLUS2) & vice versa as shown in the below figure. Thus our objective of sending message across cluster will be established.

    2-2Configuration Definitions (Windows & Unix Platforms):

    Define two Alias queues called ALCUS & BCLUS. Publish both in the Cluster CLUS1 & CLUS2 whose base / target queues are QM5.RECEIVE defined under QM5 in CLUS2 & QM3.RECEIVE defined under QM3 in CLUS1 respectively.

    runmqsc QM1

    #############

    DEFINE QA(ACLUS) CLUSTER(‘CLUS1’)

    DEFINE QA(BCLUS) CLUSTER(‘CLUS2’)

    runmqsc QM5

    #############

    DEFINE QL(QM5.RECEIVE) CLUSTER(‘CLUS2’)

    runmqsc QM3

    ############

    DEFINE QL(QM3.RECEIVE) CLUSTER(‘CLUS1’)

    Test Result: Here, I have put a Sample message into an Alias Q called ACLUS which is locally defined under QM1 (FR) Qmgr. The target Queue for this ACLUS is QM5.RECEIVE defined under QM5 Qmgr in CLUS2. Since QM1 is the FR Qmgr for both Clusters, it is able to transfer the messages across clusters.

    TR8-1

  10. Conclusion

    This article thus demonstrates the technical implementation of Advanced MQ Clustering concepts in a series of 8 different test cases which includes Sending Messages In/Out of Clusters using Qmgr Aliasing Technique and Remote Queue Definitions. We have also implemented Cluster Workload balacing using Round Robin (RR) Fashion along with Customization of the RR algorithm by altering the CLWL parameters at Queue, Channel & Qmgr levels. Multi-hopping technique has been implemented in conjunction with MQ Cluster & Distributed network using Gateway Qmgrs. And lastly, we have shown how to Join 2 differnent Clusters using Namelist & creation of Bridge Qmgrs.

    From technical solution perspective, you can use any one of the 8 test cases discussed above or a combination of multiple ones to suite your solutioning requirements as far as IBM MQ Cluster is concerned. Please note that technical solutions for all the above discussed Test Cases can be achieved using other configurations as well.

    Additionally, you can refer my other tech. articles on IBM® MQ:

    1. End to End Message Security using IBM MQ

    2. Multi-Certs in IBM MQ v8.0

    3. Working with IBM® MQ Managed File Transfer (MQMFT)…

    4. IBM® MQ, an Enterprise Messaging Backbone in a True Sense!

  11. Related Topics & References

    1. Securing MQ Cluster & End to End Message Security

    2. http://www-01.ibm.com/support/docview.wss?uid=swg27009247&aid=1

    3. WebSphere MQ Clustering – Cluster hints and tips

    4. https://www.ibm.com/developerworks/websphere/library/techarticles/1212_bhat/1212_bhat.html

    5. MQ Series Primer

    6. http://www.mqug.org.uk/downloads/201307/201307%20-%20WMQ01%20-%20MQ%20Clustering.pdf

    7. Download IBM MQ trial version

Join The Discussion