ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » CLuster Work load Balancing

Post new topic  Reply to topic
 CLuster Work load Balancing « View previous topic :: View next topic » 
Author Message
MQMITH
PostPosted: Thu May 22, 2014 2:52 am    Post subject: CLuster Work load Balancing Reply with quote

Novice

Joined: 22 May 2014
Posts: 10

Hi Guys.

Need your help here. I have 3 QMGRS A, B and C. A and B are Full Repos and C is Partial Repos. I have created a Cluster LQ on A and B and changed DEFBIND option to NOTFIXED. then created a QA (DEFBIND changed to NOTFIXED)on C and pointed it to the LQ.

Now I placed some messages on QA on C using amqsput. I can see the messages on LQ on both QMGR equally. LB is working fine as expected.

Now I changed the LQ DEFBIND option to OPEN on QMGR A. When I place messages on QA on QMGR C, I am expecting all the messages on LQ on QMGR A, But still I am seeing messages on both QMGRs.

What should I change if I want to see all the messages on LQ on QMGR A without touching any option on QMGR B?

(Requirement: Application don't have the reconnect logic to the QMGR A and B. And all the messages sent by C expecting a reply in 5 sec. IF QMGR B crashes all the messages are coming to A through Cluster LB.
But issue is when QMGR B comes up Cluster LB sending the messages LQ on A & B, but since there is no reconnect logic no application connected to B and messages piling up on B QMGR. and C getting timeouts for B messages.

TO overcome this I though when QMGR B goes down I'll change the DEFBIN option to OPEN on QMGR A, so all the messages point to qmgr A even after QMGR B comes UP. Once QMGR B comes up, application team start their process to QMGR B and evrything fine then I'll change the DEFBIND option to NATFIXED on A, so message load balancing can happen. But this scenario is not woking, not sure any workaround for this.)

Please suggest any resolution or possibility for above scenario.
Let me know if you need any other details. Thanks in advance.

MQ MITH
Back to top
View user's profile Send private message
McueMart
PostPosted: Thu May 22, 2014 4:45 am    Post subject: Reply with quote

Chevalier

Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere

How about just PUT inhibiting the LQ on QMGR B, before it becomes active again? I.e. before the Listener or Cluster-receiver channel is started?

That'll mean that no messages are sent to it.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu May 22, 2014 4:47 am    Post subject: Re: CLuster Work load Balancing Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

MQMITH wrote:
What should I change if I want to see all the messages on LQ on QMGR A without touching any option on QMGR B?


Put disable the queue on QMGR B?

MQMITH wrote:
TO overcome this I though when QMGR B goes down I'll change the DEFBIN option to OPEN on QMGR A, so all the messages point to qmgr A even after QMGR B comes UP. Once QMGR B comes up, application team start their process to QMGR B and evrything fine then I'll change the DEFBIND option to NATFIXED on A, so message load balancing can happen. But this scenario is not woking, not sure any workaround for this.)


Do note that if the application(s) in question have not specificed "bind as queue definition" you can change the options all you like and it won't help. So in the scenario you give above (where changing DEFBIND to OPEN doesn't seem to have any effect) this could well be because the applicaiton is specifying NOTFIXED so of course you all get is balancing.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Thu May 22, 2014 6:44 am    Post subject: Re: CLuster Work load Balancing Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

MQMITH wrote:
Application don't have the reconnect logic to the QMGR A and B. And all the messages sent by C expecting a reply in 5 sec. IF QMGR B crashes all the messages are coming to A through Cluster LB.

So the app could also lose its connection to QMB even if QMB never has a problem....

You should Google the term 'AMQSCLM'. This will help your situation.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
JosephGramig
PostPosted: Thu May 22, 2014 11:22 am    Post subject: Reply with quote

Grand Master

Joined: 09 Feb 2006
Posts: 1231
Location: Gold Coast of Florida, USA

MQ MITH,

Your QA at Qmgr C overrode the DEFBIND option of the actual CQs. If you inhibit PUTs at either Qmgr A or B, then some msgs will most certainly go to the DLQ because there will be a gap of time between the inhibit and the Qmgr C learning of the inhibit.

So, if Qmgrs A and B are on z/OS and the CQs are also "shared" queues, then if either Qmgr fails, the other Qmgr will process the msg (if it gets rolled back).

Otherwise, you need an HA solution to restart the Qmgr on another machine and whatever service process' the request when a failure does occur. This will most likely take more than 5 seconds.
Back to top
View user's profile Send private message AIM Address
PeterPotkay
PostPosted: Thu May 22, 2014 11:44 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Joseph, the main variable in his scenario is that the dopey app won't reconnect if it loses its connection to the QM. Ironically, a typical H.A. solution will only make his problem worse - better the QM stay down and not take on more work if the app won't connect to it.

Shared Queues on z/OS would help, but I doubt that is in play here.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu May 22, 2014 3:56 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

The typical restart sequence there is following:
  1. Restart the qmgr with option -ns
  2. start the command server (optional)
  3. use runmqsc to suspend the qmgr from the cluster
  4. bounce the qmgr
  5. have all the consuming applications reconnect
  6. resume the qmgr in the cluster
  7. end


If the qmgr is not the only available destination in the cluster it will get bypassed by the load balancing algo until resumed.

You can either reroute the few messages that may get stranded, or have them consumed by the attaching consumers...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
MQMITH
PostPosted: Thu May 29, 2014 12:10 am    Post subject: Reply with quote

Novice

Joined: 22 May 2014
Posts: 10

Thnaks fjb_saper. yes that can be possible solution for the scenario. Thanks Peter for your suggestion. Thanks guys for all your time.[/quote]
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » CLuster Work load Balancing
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.