| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| z/os MQ workload balancing query |
« View previous topic :: View next topic » |
| Author |
Message
|
| vishnusram |
 Posted: Wed Jan 15, 2014 7:31 pm Post subject: z/os MQ workload balancing query |
 |
|
Newbie
Joined: 15 Jan 2014
Posts: 3
|
All,
I am a newbie to this forum and to MQs as well.So terminologies and questions might not be in par.
I have an MQ which is being loaded by real time services.A mainframe job which is scheduled to run for 24 hrs will sweep the MQ and on insert into the DB2 table if any messages comes in.
We want to make sure that when the LPAR over which the MQ manager resides goes down for some reason, we should be able to capture the messages that flows in during the run time.
We thought of going for a mirrored MQ in a different LPAR and run another instance of the same MQ processing mainframe batch job in that LPAR to do the sweeping.
But due to some application specific design we can't afford for round-robin type of load balancing.
I would like to know if the following idea might work,
1)Create a mirrored MQ#2 in a different LPAR as a standby for MQ#1.
2)Set up in such a way that under normal conditions, all the messages should go to MQ#1.
3)When the active MQ manager/LPAR goes down, then all the messages should go to the standby MQ(MQ#2) in the other LPAR and MQ#2 should become/treated as active and MQ#1 should be turned as standby.
4)After some days, if the MQ#2 LPAR goes down then the messages should go to the MQ#1.Thus the active and standby status are swapped.
I am planning to schedule the MQ processing mainframe job in both the LPARs on a daily basis.So that swapping of message delivery can be processed with out any issues.
Please let me know if you have any better solution as well.I can take that to my MQ administrator as viable options.
Thanks,
Vishnu. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Jan 15, 2014 8:54 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Are you also new to WMQ for z/OS Queue Sharing Groups (QSGs), z/OS Parallel Sysplex, and other z/OS facilities? Most things on z/OS are dramatically different from Windows and UNIX. WMQ for z/OS is different, too.
With QSGs, messages can be stored in a Coupling Facility or an LPAR running Coupling Facility Control Code (CFCC). Multiple qmgrs can process messages from the QSG queues.
Visit with your z/OS systems programmers.
What does "sweep" in you post mean?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| vishnusram |
| Posted: Wed Jan 15, 2014 9:15 pm Post subject: |
|
|
Newbie
Joined: 15 Jan 2014
Posts: 3
|
Bruce,
Yes. I am a mainframes application developer and am not into MQ admin or something.So not aware of the QSGs, etc.
I have been asked to look for solutions to the challenge that we are facing right now, so thought of using the forum's expertise in understanding whether the approach that I have proposed in the original post is feasible in z/os MQ architecture.
As you have suggested, we have to meet up with the z/os platform team in our application as well but thought of gathering the more inputs/options so that I can discuss the same in the meeting.
BTW, I could be misleading with "sweep", I was actually referring to the process of reading and subsequent clearing of the messages from the MQ by the mainframes job.
Thanks for taking time to reply.!
Vishnu. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 16, 2014 5:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I agree with my worthy associate; if you're on z/OS a QSG is a good way of achiveing what you're looking for.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 16, 2014 10:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| vishnusram wrote: |
| I have been asked to look for solutions to the challenge that we are facing right now, so thought of using the forum's expertise in understanding whether the approach that I have proposed in the original post is feasible in z/os MQ architecture. |
Do a bit of research on WMQ clusters. WMQ clusters allow for multiple instances of the same queue-name; and if one queue becomes unavailable, messages will be directed to the remaining queue. WMQ clusters are supported on and across all platforms.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| vishnusram |
| Posted: Sun Jan 19, 2014 9:10 am Post subject: |
|
|
Newbie
Joined: 15 Jan 2014
Posts: 3
|
Thanks Everyone..!
We had meetings with our MQ admin group and had discussions on using the QSGs/WMQs.
Per them, so far in our applications we have tried MQ clusters with having both the Qs in the cluster as active and they term them as mirrored queues.So messages are routed currently in round-robin fashion.
And they wanted to test more on the new recommendations to conclude.
In the meantime, from the business side we worked out few options in such a way that we can remove the design dependancy to expect messages to be received in a specific sequence in queue.And this turned out to be fruitfull for our immediate release.
The programing logic was expecting the messages to be received in sequence, which forced us to look for way out of this round-robin and since now this has been addressed programatically, the issue is resolved.
Thanks again for your help in this...
Cheers,
Vishnu. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jan 19, 2014 12:03 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| vishnusram wrote: |
The programing logic was expecting the messages to be received in sequence, which forced us to look for way out of this round-robin and since now this has been addressed programatically, the issue is resolved.
|
There are well-known and well-documented issues regarding message-affinity (one message related to another message) in a distributed queuing design. Message-affinity design is not a best-practice, as messages could end up delayed, out-of-order, or in a dead-letter-queue (not delivered to the destination queue).
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
