MQ cluster is not about data replication or make data high available, it's about making object definitions known and available in a group of queue managers and providing a workload management capability.
The "what is it"
Put it simply, a MQ Cluster is a collection of queue managers that have been defined to be part of a group called a cluster.
Within this group, queue managers know all objects that are shared within the cluster. Objects are like queues, topics.
Within a cluster all queue managers know how to send messages to the target clustered destination. The message transfer are handled automatically by the queue manager in the cluster.
The "what does it brings"
The cluster provides the following main advantages:- Simplify administration for distribute queueing. When a message has to send to a destination located to another queue manager, the queue has to be simply shared in the cluster on the remote queue manager that's it. The transfer of the message from the queue manager where the application has put the message to the remote queue manage is carried out by the cluster: no remote queues, no transmission queues, no channels.
- Workload balancing: when multiple instances of queues are defined, the cluster can balance the message distribution to all instances shared in the cluster. Priority and weight can be defined for specific queue managers.
- Improve availability and simplify maintenance: when multiple instance of queues are defined and one queue manager that hosts this queue is not available, the messages are automatically routed to the remaining queues. This increases the availability since messages can still be processed but it also simplifies the maintenance as the queue manager is known to be stopped in the cluster.
Some disadvantages that I have in mind:
- Queue manager in a cluster are directly connected with each others. It increases the number of channels which means consume more resources.
- Less control on how the messages are sent from one queue manager to another
- Less flexibility in the queue name resolution compared to the distributed queueing (alias, remote queues, ...).
The "Principle"
Let's first discuss about queue destinations.When an application tries to put a message to a queue and this queue is not known by the local queue manager (the queue manager that the application is connected to), the queue manager queries the cluster (if it is part of one) to know if this queue is known.
If the queue is shared within the cluster, the information about its location is provided to the requestor queue manager. The local queue manager handles the message by putting it in the cluster transmission queue with a transmission header containing all the information to route it to the correct destination. The message is then sent by the local queue manager directly to the target queue manager.
Be aware that an application can get messages from local queue only, cluster defined or not. Local queues are queues defined on the queue manager that the application is connected to.
The story is a little bit different for topics. Indeed topic is used to define a destination where an application can publish or subscribe.
When a topic is shared within a cluster, it is known by all queue managers in this cluster.
Therefore if an application subscribes to a cluster topic it will receive all messages published to this topic even though the topic has been created in another queue manager.
The "how to make it"
You will be puzzled how simple it is to create a cluster !!Before going further there is one think to know about: the repositories. A repository is a store used by a queue manager to store cluster object definitions.
There are two types of repository: full and partial.
A full repository is a repository that contains cluster object definition from the whole cluster. When an object is shared in a cluster, the object definition is sent by this queue manager to the queue manager that holds the full repository.
A partial repository holds information about cluster object definitions that have been resolved from the queue manager that holds this repository. When an application puts a message for a remote queue shared in the cluster, the local queue manager requests the destination object information to the queue manager holding the full repository. This information is then stored in its local repository. Hence the name "partial repository" as it does not store all object definitions of the whole cluster.
In order to exchange these object definitions, queue managers use cluster channels:
- a cluster receiver channel to receive object definitions
- a cluster sender channel to send object definitions to the queue manager(s) holding the full repository.
- A queue manager can hold either a full repository or a partial repository (not both)
- Two (or one if not in production) full repositories is enough. All the other queue manager would hold a partial repository only.
The steps provided here after has to be performed in the same order.
For full repository
- Set the queue manager property "REPOS" to the name of the cluster. This will tell to the queue manager that he will host a full repository. A runmqsc command would be
ALTER QMGR REPOS('myCluster') - Create cluster receiver channel to define how to connect to this queue manager:
DEF CLUSRCVR(TO.MyQMgr) CONNAME('ipaddressOfThisQMgr(portNumberOfThisQMgr)') CLUSTER('myCluster') - Optionally cluster sender channels can be created to point to another full repository ONLY.
- Create cluster receiver channel to define how to connect to this queue manager:
DEF CLUSRCVR(TO.MyQMgr) CONNAME('ipaddressOfThisQMgr(portNumberOfThisQMgr)') CLUSTER('myCluster') - Create a cluster sender channel to define how to reach a queue manager holding a full repository (not partial).
DEF CLUSSDR(TO.FullRepoQMgr) CONNAME('ipaddressOfFullRepoQMgr(port)') CLUSTER('myCluster')
Now you can create a queue and share it to the cluster "myCuster" that you just created.
References
Information about the number of repositories in a cluster:https://www.ibm.com/developerworks/community/blogs/messaging/entry/wmq_clusters_why_only_two_full_repositories?lang=en
Best practices (old presentation but the principle are still valid):
http://www.academia.edu/5513555/WMQCluster_Best_Practices
And this ten things for having an healthy cluster
https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/ten_quick_tips_for_healthy_mq_cluster?lang=en
Very useful information about cluster questions
https://www.ibm.com/developerworks/community/blogs/messaging/tags/clustering?lang=en
Very good article that provides information about MQ HA
http://www.ibm.com/developerworks/websphere/library/techarticles/0505_hiscock/0505_hiscock.html
No comments:
Post a Comment