Check for new replies
Thread Rating:
  • 101 Vote(s) - 2.96 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Cluster Workload management attributes and algorithm
#1
Once the basics of clustering is known, we come across many attributes of queues, channels and queue manager related to clustering like Channel rank(CLWLRANK), Queue priority (CLWLPRTY) etc.

So now the question arises as to why these are actually used and how a queue manager decides the final destination of the message when the destination queue is clustered and is present in multiple queue mangers. By default, the messages should get routed in round robin fashion and if in case a queue manager in which the clustered queue is present is suspended or stopped, then the message will be routed to other queue managers hosting the clustered queue in round robin fashion.

However this might not be the actual requirement. It might be desirable in some cases where a particular queue manager should be preferred over another, hence taking all the traffic, or a particular queue manager with higher processing power take bulk of the traffic. For this , MQ has provided attributes giving a lot of control through which destination of messages can be controlled.

So this topic explains these attributes and the algorithm used by MQ in determining the destination of a message in clustering.

When a cluster contains more than one instance of the same queue, MQ uses the cluster workload management algorithm to determine the best queue manager to route a message to. Destinations are chosen, based on the availability of the queue manager and queue, and a number of cluster workload-specific attributes associated with queue managers, queues and channels.

Workload balancing attributes

[Image: 2NUMXNt.png]


The attributes can be broadly categorised into the following categories in sequential order (the upper ones have precedence over the lower ones):

• Use-queue attribute – CLWLUSEQ attribute for queue and queue manager
• Rank attribute – CLWLRANK attribute for queues and channels.
• Priority – NETPRTY for channel and CLWLPRTY for queues and channels.
• Weight – CLWLWGHT attribute for channel
• Most recently used (CLWLMRUC)

These attributes have been explained below :

Use Queue Attribute (CLWLUSEQ) –


This attribute is available for queues as well as queue manager. If a local instance of clustered queue exists, it allows option to choose either local queue manager or remote queue manager. This option has preference over other attributes mentioned in the categories. This means that this attribute is checked before checking other attributes while routing the message to its destination.


CLWLUSEQ - Queue attribute

DEFINE QL(Q1) CLUSTER(ACLUS) CLWLUSEQ( )

LOCAL --> Choose a local queue if it exists.
ANY --> Choose either local or remote clustered queues.
QMGR --> Use the use-queue value from the queue manager.

CLWLUSEQ - Queue manager attribute

ALTER QMGR CLWLUSEQ ( )

LOCAL --> If the queue specifies CLWLUSEQ (QMGR) and a local queue exists choose it
ANY --> If the queue specifies CLWLUSEQ (QMGR), choose either local or remote clustered queues

Scenario: There are 2 Queue managers QMA and QMB in cluster ‘"ACLUS”. Both host local queue “Q1” which is shared in cluster “ACLUS”. Application connected to QMA queue manager puts message to Q1 queue twice.

QMA queue manager has CLWLUSEQ set to ANY.
Q1 queue in QMA queue manager has CLWLUSEQ set to QMGR.

QMB queue manager has CLWLUSEQ set to ANY.
Q1 queue in QMB queue manager has CLWLUSEQ set to QMGR.


[Image: EURwP5w.png]

One message will end up in both QMA and QMB queue manager.

The explanation for this being

• Q1 queue in QMA Queue manager has CLWLUSEQ attribute as QMGR, implying the QMA queue manager attribute CLWLUSEQ is checked.
• QMA has CLWLUSEQ attribute “ANY” implying to choose either local or remote queue.
• So messages are sent to both QMA and QMB queue manager based on availably. If both queue managers are available, they route in round robin fashion.

If the Queue Q1 in QMA queue manager or QMA queue manager itself had CLWLUSEQ attribute as local, all the messages would end up in QMA queue manager.

RANK attribute:

This attribute gives more control over destination of a message to queue manager.

Channels and queues with highest rank attribute are chosen over channels and queues with lower ranks. Channel rank is checked before queue rank. This attribute has preference over other attributes like priority, weight and Most recently used channel attributes.

CLWLRANK will even ignore channel status, this means that a message will get routed to a queue manager having highest channel Rank attribute irrespective of the queue manager being down or the cluster sender channel to the queue manager being down. In such cases the messages will wait in the Cluster transmission queue till the channels come up and the message gets routed to destination the queue manager.

Now you might be wondering what could be the use of this attribute in clustering as the whole point of high availability and multiple instances of queues is lost. You would at least want the messages to get routed to other running queue managers when the queue manager with highest rank is down Smile


However it finds its uses in below cases:

• When the destination is not yet in use or is still under development. In such cases the queues could be put disabled or it could be taken out of cluster as well. But this is one of the ways to accomplish it too.
• To keep the DR or backup queue manager as standby. A manual change of CLWLRANK attribute to a higher value is required when actual switching needs to happen. This could be accomplished by suspending the DR queue manager and priority attributes as well which are actually better way to handle it.
• To have more specific control over the final destination for messages sent to a queue manager in another cluster. This is a little complicated to understand and I am not sure of its actual use as well. Am sure there is one though Smile However the below diagram should give some insight into it.


[Image: ZzORzLI.png]

A message put to “CLUSQ” queue in QMA queue manager will reach gateway queue managers QMB or QMC as it’s visible to it in the cluster “CLUSTER A” and both have equal channel rank. However once it reaches QMB or QMC queue manager, it finds that the same queue is shared in two more queue managers in a different cluster “CLUSTER B” and QMD has higher rank than QME , QMB and QMC. Hence the messages will always reach QMD queue manager.

Command to set Channel Rank attribute:

DEFINE CHL(TO.ME) CHLTYPE(CLUSRCVR) CLUSTER(CLUSTER_A) CLWLRANK( )
Range 0 – 9
Default 0

Command to set Queue Rank attribute:

DEFINE QL(CLUSQ) CLUSTER(CLUSTER_A) CLWLRANK( )
Range 0 – 9
Default 0


Highest Rank is 9 and lowest is 0.

It also has to be noted that queue rank has precedence only after channel rank. So queue rank is actually not checked unless if channel rank for all the channels with highest rank in cluster are equal.


Priority Attribute:

This attribute is used ensure that MQ selects destination queue managers in preference to others with a lower priority. Channels and queues with the highest priorities are chosen preferentially over channels and queues with lower priorities. Channel priority is checked before queue priority.
Now you might be wondering what the difference between Rank and the Priority attributes.

The biggest difference would be that with priority attribute, MQ considers the channel status before sending the message which means that if the queue manager or cluster sender channel is down, then that queue manager even with highest priority is not considered. It will send the message to a running queue manager with lower priority.

This was not the case in RANK attribute as the messages were always sent to queue manager with highest RANK attribute irrespective of its availability.

However Rank attribute is checked before Priority attribute as it has a higher precedence.


Commands to set channel priority attribute:

DEFINE CHL(To.QMA) CHLTYPE(CLUSRCVR) CLUSTER(CLUS_A) CLWLPRTY( )
Range: 0 – 9
Default: 0

Commands to set queue priority attribute:

DEFINE QL(CLUSQ) CLUSTER(CLUS_A) CLWLPRTY( )
Range: 0 – 9
Default: 0

Highest Rank is 9 and lowest is 0.

To understand priority attribute consider the below scenario:

Scenario: There are 4 queue managers QMA, QMB, QMC, and QMD. All of them have a local queue “CLUSQ” shared in cluster “CLUS_A”. The CLWLPRTY property for queue is depicted as QLWLPRTY so that it can be differentiated from the same property for channel. There is no attribute called QLWLRTY and it’s just for our understanding. The cluster Priority attribute values are shown in the picture itself.

[Image: 0QpuPFr.png]

All the messages will be delivered to QMC queue manager. The explanation for this is as below

1. QMB queue manager has highest channel priority. But the queue manager is down. Hence other queue managers with next highest channel priority will be considered.
2. QMC and QMD queue managers have next highest channel priority of 2. Since they both have same channel priority, their queue priority will be taken into consideration.
3. QMC has higher queue priority than QMD. Hence all the messages will be delivered to QMC queue manager.



Most recently used channels attribute (CLWLMRUC):


This is a queue manager attribute. As you all know, if there are ‘n’ possible destinations (same queue shared in ‘n’ queue managers’, with no specific cluster workload attributes set, the messages will get routed to all the queue managers in round robin fashion ideally. So this will mean that there will be hundreds of outbound channels in a huge cluster.


If the requirement is to limit the number of queue managers considered for routing in round robin fashion, CLWLMRUC is your friend Smile

It uses the most recently used channels while routing the requests.

Command:
ALTER QMGR CLWLMRUC( )

Range: 1 – 999999999
Default: 999999999

For example, if this attribute is set to 4, the messages will always get routed to the last 4 used queue managers in round robin fashion irrespective of total number of possible destinations.
This will limit the number of active channels in the queue manager from which the message is being sent.

Channel weight attribute (CLWLWGHT):


In some cases, few servers could have more processing power than others which host queue managers shared in the same cluster. So logically it’s desirable that the server having more processing power should take more traffic than the one having lesser processing power.

To accomplish this MQ provides a channel attribute called CLWLWGHT.

If more than one destinationis possible, the messages get routed to the queue managers proportional to their channel weights.

Command:

DEFINE CHL(TO.QMA) CHLTYPE(CLUSRCVR) CLUSTER(CLUS_A) CLWLWGHT( )

Range: 1 – 99
Default: 50

Scenario: There are 4 queue managers QMA, QMB,QMC,QMD and their channel weight attribute values is shown in the picture.

[Image: rBNsa7V.png]


If 10 messages are sent, then 4 messages get routed to QMC and 2 messages are routed to each remaining queue managers.

Now that we know the cluster workload management attributes , it becomes important to know the algorithm which MQ uses to find out the destination queue manager.


CLUSTER WORKLOAD MANAGEMENT ALOGORITHM:

The below steps are checked sequentially to find out the possible destinations.


1. Queue PUT (ENABLED/DISABLED) - Queues that are not put enabled are eliminated as possible destinations.
2. Queue manager aliases that are not put enabled are eliminated.
3. Local instance of queue depends on use-queue (CLWLUSEQ) - This attribute is checked to see if the messages are to be routed to local queue if it exists and shared in cluster.
4. Channel rank (CLWLRANK) - All channels to queue managers with a CLWLRANK less than the maximum rank of all remaining channels or queue manager aliases are eliminated.
5. Queue ranks (CLWLRANK) - All queues with a CLWLRANK less than the maximum rank of all remaining queues are eliminated.
6. If only remote instances of a queue remain, resumed queue managers are chosen in preference to queue managers which are suspended.
7. Channel status is considered to find out the available destinations.
8. Channel net priority (NETPRTY) - channels with the highest NETPRTY value r are chosen.
9. Channel priority (CLWLPRTY) – channels with highest priority is chosen over the one with lower priority.
10. Queue priority (CLWLPRTY) – queues with highest priority is chosen over the one with lower priority.
11. Most recently used (CLWLMRUC) – this attribute is checked to use only the most frequently used channels and the number of possible destinations is taken from this queue manager attribute
12. channel weighting (CLWLWGHT) - this attribute is checked to distribute the messages among the possible destinations after all the previous checks are done.


To understand this algorithm let’s consider a scenario where almost all of these attributes are used.



Scenario : There are 9 queue managers starting from QMA, QMB,QMC,....to QMI. A local queue called CLUSQ is present in all the queue managers and shared in CLUS_A cluster.

Cluster workload attributes of each QMGR are mentioned in the diagram.

[Image: YVR0oKe.png]

Lets apply Cluster workload management algorithm to find out the destination of the message

1. QMA queue manager is eliminated because the queue is put disabled even though it has the highest CHANNEL RANK.
2. All other queue managers have channel Rank as 4. So the queue rank is checked. QMB queue manager is eliminated because it has a lower queue rank compared to other queue managers.
3. QMD and QMF queue managers are eliminated because they are suspended.
4. QMC queue manager is eliminated because the queue manager is down hence the channel status is down.
5. That leaves us with QME, QMG, QMH and QMI queue managers. All have equal channel priority of 3. Hence queue priority is checked.
6. QME queue manager is eliminated because it has lower queue priority compared to other queue managers.
7. Now it is known that the possible destination is QMG, QMH and QMI queue managers. Cluster weight attribute is checked to send messages in numbers proportional to the weights.

So if 10 messages are sent, 5 will land in QMI queue manager, 3 in QMG and 2 in QMH queue managers.

Workload balancing BIND options :

Now that we have comprehensively covered the cluster workload attributes and algorithm in MQ some amount of control is given to application as well.

Applications can opt for one of these on MQOPEN call.

• MQOO_BIND_ON_OPEN
• MQOO_BIND_NOT_FIXED
• MQOO_BIND_ON_GROUP
• MQOO_BIND_AS_Q_DEF (default)


If it is “MQOO_BIND_AS_Q_DEF” then the DEFBIND attribute of the clustered queue is taken into consideration.

The value for this attribute could be either

• Open – for the first message, cluster workload algorithm is applied and the rest of the messages PUT in the same MQOPEN call are sent to the same destination as the first message.
• Notfixed – for every message sent by the application , cluster workload algorithm is applied and load balancing is done

Cheers,
Vinyas
Reply
#2
I am facing an issue where the CLWLRANK is taking priority over the CLWLUSEQ attributes.

QMGR A ==>CLWLUSEQ attribute has value LOCAL
LOCAL QUEUE L1 on QMGR A=====>CLWLUSEQ attribute has value QMGR and CLWLRANK as 0

LOCAL QUEUE L2 on QMGR B=====>CLWLRANK as 9

SETUP IS IN CLUSTER

When I post a message on a ALIASQ on QMA the messages are reachin QMBConfusedConfusedConfused
Reply
#3
Hi Ashishssood14,

I see that you have clustered two local queues L1 and L2. I am not sure if this is what you need. I think you would want the same queue , probably L1 created in both the queue managers with the cluster workload attributes as specified by you.

In such a case , the messages put to L1 queue from QMGR A would be put locally in the same queue manager as CLWLUSEQ attribute of the queue manager is local(with queue L1 - CLWLUSEQ attribute being QMGR).

However , I also see that you are putting message to an alias queue , and I believe you have clustered this alias queue as well. You should note that Alias queue don't have a CLWLUSEQ attribute and hence CLWLRANK attribute is considered. QMGR B has a higher CLWLRANK and hence the messages will be routed to QMGR B provided the alias queue is not put disabled in QMGR B.

Cheers,
Vinyas
Reply

Check for new replies

Forum Jump:


Users browsing this thread: 1 Guest(s)