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 » Is it good practice to differ clustered remote q defs?

Post new topic  Reply to topic Goto page 1, 2  Next
 Is it good practice to differ clustered remote q defs? « View previous topic :: View next topic » 
Author Message
issac
PostPosted: Wed May 29, 2013 6:05 am    Post subject: Is it good practice to differ clustered remote q defs? Reply with quote

Disciple

Joined: 02 Oct 2008
Posts: 158
Location: Shanghai

Here shows how to put to a qmgr out of the cluster.

http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc10880_.htm


What if I have a QM1_B (another qmgr inside the cluster), which contains another Q3 defined like this:

DEFINE QREMOTE(Q3) RNAME(Q3) RQMNAME(QM3_B) CLUSTER(DEMO)

QM3_B is another qmgr outside the cluster. In this way, when my app puts to Q3, I wish the network would actually load balance between Q3s of QM3 and QM3_B.

It sounds somewhat unfamiliar to me. Is this good practice? Or something not recommended?

Thanks!
_________________
Bazinga!
Back to top
View user's profile Send private message
mqjeff
PostPosted: Wed May 29, 2013 6:20 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

So you have channels to the out-of-cluster queue manager on more than one in-cluster queue manager?

If you do, then you would end up doing exactly what you're talking about, creating two qremotes (one on each qmgr that has an xmitq and sender) and sharing both in the cluster. Then the cluster will workload balance messages between instances of the cluster queue, which ends up workload balancing them between sender channels, both of which are presumed to be triggered or running.

Whether or not this makes the performance on the receiving qmgr any better is a separate question.

If you only have one sender channel on one queue manager, then creating a second qremote will merely strand messages on the DLQ or the default XMITQ of the other qmgr that hosts an instance of the clustered queue.
Back to top
View user's profile Send private message
issac
PostPosted: Wed May 29, 2013 10:46 pm    Post subject: Reply with quote

Disciple

Joined: 02 Oct 2008
Posts: 158
Location: Shanghai

Thank you very much!

We're using this for failover purpose. If one outside qmgr fails, we would wish for msgs going to another for substitue.
_________________
Bazinga!
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Thu May 30, 2013 4:45 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

issac wrote:
We're using this for failover purpose. If one outside qmgr fails, we would wish for msgs going to another for substitue.

If all you did is just what you wrote in the first post of this thread, then you won't get exactly that behaviour.

As apps on QM2 put to Q3, the messages will be load balanced across Q3 on QM1 and QM1B, so messages will continually flow to QM3 and QM3B.

If one of the QM3s fails, nothing changes! Lets say QM3 fails. The DEMO cluster will continue to load balance messages across the two Q3s. Half the messages will successfully flow to QM3_B, and the other half will be stuck on the QM3 XMITQ on QM1, trying to get to QM3.

Now, let's saying everything is back to normal. If you cluster Q3 on QM1, and do not cluster Q3 on QM1_B, 100% of the messages will go to QM3. If QM3 fails, then you will have to cluster Q3 on QM1_B, uncluster Q3 on QM1 and optionally manually move messages that might be stuck in the XMITQ to QM3 on QM1 over to QM1_B so they can get to QM3_B. Tools like MO71 would help dealing with changing the XMITQ header of those stuck messages so they could successfully go to the other QM.

If QM3 and QM3_B are not in the DEMO cluster, MQ will not do any auto failover of routing for you for messages trying to get to QM3 and/or QM3B.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Thu May 30, 2013 5:34 am    Post subject: Reply with quote

Grand High Poobah

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

Say you have 2 gateways GW1 and GW2.
On each of the gateways you have a channel to OUTSIDE.
Set up on each GW an xmitq with name TO.OUTSIDE.
Set up on each GW the Remote queue

Code:
def qr(outside) rqmname(outside) xmitq(to.outside) cluster(demo)

This will provide you with a default load balanced routing to Outside from anywhere in the cluster where you have authority to put to those clustered Remote queues.

The assumption is that Outside is a single qmgr (highly available (MI?)) with channels to and from GW1 and GW2

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
issac
PostPosted: Thu May 30, 2013 6:49 pm    Post subject: Reply with quote

Disciple

Joined: 02 Oct 2008
Posts: 158
Location: Shanghai

PeterPotkay wrote:
issac wrote:
We're using this for failover purpose. If one outside qmgr fails, we would wish for msgs going to another for substitue.

If all you did is just what you wrote in the first post of this thread, then you won't get exactly that behaviour.

As apps on QM2 put to Q3, the messages will be load balanced across Q3 on QM1 and QM1B, so messages will continually flow to QM3 and QM3B.

If one of the QM3s fails, nothing changes! Lets say QM3 fails. The DEMO cluster will continue to load balance messages across the two Q3s. Half the messages will successfully flow to QM3_B, and the other half will be stuck on the QM3 XMITQ on QM1, trying to get to QM3.

Now, let's saying everything is back to normal. If you cluster Q3 on QM1, and do not cluster Q3 on QM1_B, 100% of the messages will go to QM3. If QM3 fails, then you will have to cluster Q3 on QM1_B, uncluster Q3 on QM1 and optionally manually move messages that might be stuck in the XMITQ to QM3 on QM1 over to QM1_B so they can get to QM3_B. Tools like MO71 would help dealing with changing the XMITQ header of those stuck messages so they could successfully go to the other QM.

If QM3 and QM3_B are not in the DEMO cluster, MQ will not do any auto failover of routing for you for messages trying to get to QM3 and/or QM3B.



We're seriously concerned about this. So far as we've tested, in case QM3 fails, messages do accumulate in the xmitq of QM1, it's not going to QM1B untill xmitq of QM1 is full && DLQ of QM1 is full.

It's not desirable, but is there an alternative way to achive the load-balancing while sending data outside the cluster? I don't know.

I checked for amqsclm, but sadly when the channel QM1.QM3 is retrying, IPPROCS of the xmitq QM3@QM1 keeps switching between 1 and 0, thus I don't think amqsclm would correctly reroute future messages to QM1B.

To have only one instance of Q3 in cluster would not make the action to send to QM3 & QM3B load-balanced. It's not a problem for us to lose messages stuck in the xmitq. Our app could just re-send them. So the only concern is to make sure future messages flow to the working qmgr.

I plan to write a shell script, triggered when QDEPTH of xmitq QM1.QM3 @ QM1 reaches 100, when it would reset CLWLPRTY of the remote queue Q3 to 1. (I have set all instances of Q3 in both QM1 & QM1B to 5 ahead). It should work, but is it good practice anyway? I'm inexperienced with mq network designing...
_________________
Bazinga!
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri May 31, 2013 6:49 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

If you want to load balance MQ messages to QM3 and QM3_B you know the best answer - put them in the DEMO MQ cluster.

That may not be desireable for other reasons or requirements not shared with us, but its the right way to solve this specific requirement.

Or make a new overlapping cluster that only contains QM1, QM1_B, QM3, QM3_B.

I wouldn't consider your script idea best practice. Properly implemented it should work, but its another failure point and it adds complexity.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri May 31, 2013 7:30 am    Post subject: Reply with quote

Grand High Poobah

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

Going back to my earlier post... If the channel goes into retry mode you should have a script to disable put on the Clustered qmgr alias for routing outside the cluster.

Put enable it when the channel goes back into running state...

This would minimize the number of stranded messages.

Have fun.
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
issac
PostPosted: Sun Jun 02, 2013 10:13 pm    Post subject: Reply with quote

Disciple

Joined: 02 Oct 2008
Posts: 158
Location: Shanghai

fjb_saper wrote:
Going back to my earlier post... If the channel goes into retry mode you should have a script to disable put on the Clustered qmgr alias for routing outside the cluster.

Put enable it when the channel goes back into running state...

This would minimize the number of stranded messages.

Have fun.


Thank you. We're thinking about something very similar, when the chl is in retrying mode, we are intending to disable put on the clustered remoteq, which works fairly the same way and stops msgs from flowing in.
_________________
Bazinga!
Back to top
View user's profile Send private message
issac
PostPosted: Sun Jun 02, 2013 10:20 pm    Post subject: Reply with quote

Disciple

Joined: 02 Oct 2008
Posts: 158
Location: Shanghai

PeterPotkay wrote:
If you want to load balance MQ messages to QM3 and QM3_B you know the best answer - put them in the DEMO MQ cluster.

That may not be desireable for other reasons or requirements not shared with us, but its the right way to solve this specific requirement.

Or make a new overlapping cluster that only contains QM1, QM1_B, QM3, QM3_B.

I wouldn't consider your script idea best practice. Properly implemented it should work, but its another failure point and it adds complexity.


Thanks for the idea. We're dealing with an ESB's cluster, which connects to over 500 systems each with a cluster of their own. After reading about this "Task 7: Adding a new, interconnected cluster" in the INFOCENTER WMQ V7.0.1, it appears to me that a certain pair of qmgrs will be full repository for over 500 (and growing) clusters. Additionally I'm not confident if I'm experienced enough to maintain such a network.

I'll do more investigation now.
_________________
Bazinga!
Back to top
View user's profile Send private message
issac
PostPosted: Mon Jun 03, 2013 1:01 am    Post subject: Reply with quote

Disciple

Joined: 02 Oct 2008
Posts: 158
Location: Shanghai

issac wrote:
PeterPotkay wrote:
If you want to load balance MQ messages to QM3 and QM3_B you know the best answer - put them in the DEMO MQ cluster.

That may not be desireable for other reasons or requirements not shared with us, but its the right way to solve this specific requirement.

Or make a new overlapping cluster that only contains QM1, QM1_B, QM3, QM3_B.

I wouldn't consider your script idea best practice. Properly implemented it should work, but its another failure point and it adds complexity.


Thanks for the idea. We're dealing with an ESB's cluster, which connects to over 500 systems each with a cluster of their own. After reading about this "Task 7: Adding a new, interconnected cluster" in the INFOCENTER WMQ V7.0.1, it appears to me that a certain pair of qmgrs will be full repository for over 500 (and growing) clusters. Additionally I'm not confident if I'm experienced enough to maintain such a network.

I'll do more investigation now.



Aha! I've managed to make the QMGR bridge work. It's different from overlapping clusters, however providing enough features for my scenario. I'll just make QM3 and QM3B cluster bridges individually, which allows them to reside inside the consuming app's cluster, while stays in DEMO cluster for load-balancing purpose. Thank you guys!
_________________
Bazinga!
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Jun 03, 2013 4:29 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

issac,
Continuing to use the same QM, queue and cluster names we have been in this thread, can you detail what you plan on doing when you say:
Quote:
I'll just make QM3 and QM3B cluster bridges individually

_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
issac
PostPosted: Mon Jun 03, 2013 3:05 pm    Post subject: Reply with quote

Disciple

Joined: 02 Oct 2008
Posts: 158
Location: Shanghai

Hello, peter

Okay, but I need to expand the scenario a little.

The idea comes from :http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzah.doc/qc10900_.htm

QM3 belongs to a cluster DEMO1, which has two qmgrs inside, besides QM3, the other one is QM4. I define a cluster queue BBQ1 on QM4
Code:

DEFINE QL(BBQ1) CLUSTER(DEMO1)


QM3B belongs to a cluster DEMO2, which has two qmgrs inside too, besides QM3B, the other one is QM4B. I define a cluster queue BBQ2 on QM4.
Code:

DEFINE QL(BBQ2) CLUSTER(DEMO2)


Now I make QM3 the bridge.

On QM3 Connect channels (let's say QM2 & QM4 are the full repositories):
Code:

DEF CHL(DEMO.QM2) CHLTYPE(CLUSSDR) CONNAME(XXX) CLUSTER(DEMO)
DEF CHL(DEMO.QM3) CHLTYPE(CLUSRCVR) CONNAME(YYY) CLUSTER(DEMO)

DEF CHL(DEMO2.QM4) CHLTYPE(CLUSSDR) CONNAME(ZZZ) CLUSTER(DEMO2)
DEF CHL(DEMO2.QM3) CHLTYPE(CLUSRCVR) CONNAME(YYY) CLUSTER(DEMO2)


Now the QM3 belongs to DEMO and DEMO2 at the same time. I define an alias for DEMO cluster to access DEMO2's clustered queue.

Code:

DEF QA(BBQ.ALIAS) TARGQ(BBQ1) DEFBIND(NOTFIXED) CLUSTER(DEMO)


The same shall be done for QM3B, e.g. on QM3B the qalias would be sharing the name BBQ.ALIAS.

Code:

DEF QA(BBQ.ALIAS) TARGQ(BBQ2) DEFBIND(NOTFIXED) CLUSTER(DEMO)



Then I test putting from QM2
Code:

amqsput BBQ.ALIAS QM2


The result is msgs are now load-balanced between BBQ1 on QM4 and BBQ2 on QM4B.

Now I simulate a QM3 host crash:
endmqm -p QM3

Resending through QM2
amqsput BBQ.ALIAS QM2

Result: Message all goes to QM4B as expected.

So I think I've got what I want, and without a script, and not required to merge full repositories like overlapping clusters Wondering if this is actually the most popular design when clusters interact.

The only shortage is messages have to accept DEFBIND(NOTFIXED), but I don't think it could be too much a problem for applications.

What do you think?[/code]
_________________
Bazinga!
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue Jun 04, 2013 3:53 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

I tried to follow along by drawing what you describe but had problems representing it. I think you have missed describing some QMs and I'm not sure how many clusters you have.

What are the Full Repositories for DEMO1?
What are the Full Repositories for DEMO2?
Is there a DEMO cluster, if yes, what are the Full Repositories for that one?
Is QM3B supposed to be in both DEMO1 and DEMO2?

issac wrote:

On QM3 Connect channels (let's say QM2 & QM4 are the full repositories):
Code:

DEF CHL(DEMO.QM2) CHLTYPE(CLUSSDR) CONNAME(XXX) CLUSTER(DEMO)
DEF CHL(DEMO.QM3) CHLTYPE(CLUSRCVR) CONNAME(YYY) CLUSTER(DEMO)

DEF CHL(DEMO2.QM4) CHLTYPE(CLUSSDR) CONNAME(ZZZ) CLUSTER(DEMO2)
DEF CHL(DEMO2.QM3) CHLTYPE(CLUSRCVR) CONNAME(YYY) CLUSTER(DEMO2)


I think you meant DEMO1 and not plain DEMO?
I think you meant QM4B here, not QM4?

I started writing up some other questiosn but so much depends on first understanding the basic topology I deleted them and will wait for your clarification.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
issac
PostPosted: Tue Jun 04, 2013 5:50 am    Post subject: Reply with quote

Disciple

Joined: 02 Oct 2008
Posts: 158
Location: Shanghai

Sorry, my bad. Here's the network:

please plaste the whole line
https://skydrive.live.com/?cid=ab5d7e947d340e20&id=AB5D7E947D340E20%21477&sff=1&authkey=!AGxUTTZJXSVm2qE


What are the Full Repositories for DEMO1? QM4
What are the Full Repositories for DEMO2? QM4B
Is there a DEMO cluster, if yes, what are the Full Repositories for that one? Yes, there is a DEMO cluster. FR is QM2.
Is QM3B supposed to be in both DEMO1 and DEMO2? No, it's supposed to be in both DEMO & DEMO1.

Please see to the image. QM1 seems useless now, though.

Is this the correct way for clusters to interact? Apparently it meets my needs, it load-balances messages incoming from QM1 or QM2 to BBQ1 and BBQ2; it fail-overs automatically when QM3 or QM3B fails, and the only shortage it brings along is to require msgs to DEFBIND(NOTFIXED), which doesn't look like big deal
_________________
Bazinga!
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » Is it good practice to differ clustered remote q defs?
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.