| Author |
Message
|
| sebastia |
 Posted: Mon Sep 24, 2007 2:07 am Post subject: Router model(s) |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi!
We are going to have a MQ cluster
to balance the workload coming from lots of MQ Clients
and going to few MB Brokers, whose MQ are also in the cluster.
Lets say, 6 PC in the cluster,
3 "front end" MQ Servers,
and 3 with MQ for the MB's.
The MQ Clients shall access the MQ Cluster thru a Router.
Are there any "well know" routers for this environment ?
By example, does it exist such a router that can detect
a MQ server status is "not ok"
and not sending him any more messages ?
( or open for us to program such an MQ API access ...
I'd say Linux is able to provide it ... )
Or do they all split the messages chunk based on pseudo-static tables,
as "from this IP to this IP (range),
send the messages to QM-n" and so on ?
(human intervention required if a QM fails .... bad thing in August)
Is there one that works "round-robin" ?
Can someone provide few model numbers and manufacturer, please ?
Cheers. Sebastian. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Sep 24, 2007 2:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If you've got a cluster, why are you trying to workload balance at the network level?
Especially as the 2 requirements you specifically mention are round robin distribution of messages & the detection of non-working queue managers, both of which clustering provide?? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Sep 24, 2007 2:34 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Vitor : the client program is already written
and the Connection Name is fixed there.
So, a specific Client tries to connect to a specific IP,
am I right ?
(maybe a clever DNS can change that ... I dont know)
If so, that IP's Queue Manager is a SPOF (single point of failure),
isn't it ?
That is, if that IP's Queue Manager stops working,
that MQ CLient shall have no way to reach the MB's queue manager....
as far as I know.
Of course, our knowledge is short, and that is the reason I am writing to this forum ...
a) to find a router name + family and number ...
or
b) to find any other solution we did not see
to increase the availability for the MQ Clients.
Thanks. Sebastian.
Vitor - feel free to illuminate me with your own solution for this environment !!!
( ) |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 24, 2007 2:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
So, a specific Client tries to connect to a specific IP,
am I right ? |
No, clients connect to queue managers. Clients with client connection tables rather than MQSERVER variables connect to the first queue manager on the list that's working.
Unless there's something Javaish going on with QCFs or something. My Java is not production strength but AFAIK you still specify a name.
Given the above caveat, I'd define as many client gateway machines as you feel you need to provide failover and stick them in client table(s)
OR
I'd not bother to find some esoteric router for which I need the assistance of the network wizards but instead purchase the high-availability software product of my choice, put the gateway(s) under it's control and sit back!
But that's just me. You know your setup, restrictions and requirements better than I do.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Sep 24, 2007 2:46 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Let me see if I understand you ...
You sugest to ...
a) modify the client application to change the Connection Name (MQCONNX) or the MQSERVER envir var
b) use HACMP
For me (a) is the best
And (b) is not the case, as they want to use Windows Server machines.
Do you think MSCS is ok for the situation ?
Sebastian.
What is you opinion about "Red Hat Cluster Suite" ???
>>> http://www.redhat.com/software/rha/cluster/ |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 24, 2007 2:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
We have a setup similar to what you require...
The front end is a web farm...
The front end attaches to MQ gateways and has a choice of 3 gateways to attach to. Programming has determined a primary and secondary gateway of choice. These are different depending on the attaching server...
That would mean at least 3 different client channel tables for you. (changing the order of the connections).
Services attach to all 3 gateways. Publishes are load balanced through the subscription queue mgr ( a cluster alias).
As for Vitor's comment about Java: MQ V6 supports the client channel table in Java and JMS...
3+ brokers publish, route and transform the messages.
Any single broker qmgr can be suspended from the cluster without impacting the front end. In fact for our maintenance we rotate which broker box (broker + gateway qmgr) we take down so as not to interrupt service.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 24, 2007 3:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
As for Vitor's comment about Java: MQ V6 supports the client channel table in Java and JMS...
|
I did think I'd read that someplace, but I hesitate to speak authoritatively on Java matters unless I can quote a reference (and I couldn't find one in this case quickly enough!)
My preference is a) in your post, or exactly the setup fjb_saper has quite sucinctly described. You'd need tables rather than MQSERVER, and I'd not bother with MQCONNX - use MQCONN and let the system work it out.
This eliminates the need for additional HACMP software but does require you to draw a lot of diagrams for management trying to explain how client connections work. Depending on the technical grasp of your audience, HACMP software may be easier & allow you to retain your hair by not pulling it out at the roots.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 24, 2007 3:28 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
This eliminates the need for additional HACMP software but does require you to draw a lot of diagrams for management trying to explain how client connections work. Depending on the technical grasp of your audience, HACMP software may be easier & allow you to retain your hair by not pulling it out at the roots.... |
My experience: As long as you can guarantee no single point of failure and explain the difference between HACMP and the MQ cluster failover (i.e. risk of some stuck messages) management will decide depending on industry and requirements and bottom line cost. (Typically the Financial industry will go for HA)
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Sep 24, 2007 3:28 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
2 items :
1) Java : I think customer does not use it, bu t I have to admit I find more and more MQ API programmers using it. Myself I do not like Java at all.
2) TABLES versus MQSERVER versus MQCONNX - first I have to make sure customer allows us to change client application, which I am not sure they accept.
Thanks a lot ! |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 24, 2007 3:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| 1) Java : I think customer does not use it, bu t I have to admit I find more and more MQ API programmers using it. Myself I do not like Java at all. |
If they're not using Java all your problems are over.
| sebastia wrote: |
2) TABLES versus MQSERVER versus MQCONNX - first I have to make sure customer allows us to change client application, which I am not sure they accept. |
This should be transperent to the application whatever language it's written in. These are environmental constructs, even if they're wedded to MQCONNX for some bizarre reason. It's not a big change to move from MQCONNX to MQCONN and it is a change for the better.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Sep 24, 2007 4:18 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr Saper : the MQ cluster can have some message trapped on some queue, whilst HACMP does not . Is that "ALL" the diference ? I think the switching time can be important also .... How long does it take HACMP to "detect" a failure and switch to the other node ?
(aprox, just the range ... N x 10 seconds ?)
You say "they will go for HA" - if it is Windows platform, does that mean
"MSCS" ? ( the truth is I do NOT know "VCS" )
mr Vitor : "not using Java all your problems are over" means
"AMQCLCHL.TAB" is the solution ?
Cheers ! |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 24, 2007 4:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
| the MQ cluster can have some message trapped on some queue, whilst HACMP does not . |
But you were talking about the gateway as a single point of failure for the clients. Because the client connection is syncronous messages cannot be trapped. If you want to use the cluster for HA as well as workload then that's a different situation.
| sebastia wrote: |
mr Vitor : "not using Java all your problems are over" means
"AMQCLCHL.TAB" is the solution ?
|
It's almost certainly the solution in every language if you're using v6 and fjb_saper is correct (as I'm sure he is). What I meant was that if you're using non-Java I can be confident it works because I've done it myself!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Sep 24, 2007 5:55 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
*** final entry, I hope ****
OK - we shall try to use "AMQCLCHL.TAB" - thanks
Can you explain a ltitle bit more
...
"client connection is synchronous, so messages cannot be trapped"
As I see it, client does "MQ_CONN()" so we reach a Queue Manager.
A MQ_OPEN(queue_name) must follow.
Then application does "MQ_PUT(message)" and receives MQRC=0.
Message has been accepted by MQ, so it's gonna work to deliver it.
Application can go CLOSE() and DISC().
But message can still be on Transmit Queue, so a queue manager failure
is possible. What shall the application do ? I guess ...
a) set an Expiry in the message, similar to application's timeout
b) re-send the message is an acknowledge from destination application is not received back
Am I correct, more or less ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Sep 24, 2007 6:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
[quote="sebastia "client connection is synchronous, so messages cannot be trapped"
[/quote]
I was highlighting that messages can't be stuck on the gateway because client connections are syncronous. I apologise for my lack of clarity.
As to how to deal with the other issues, there are a number of strategies and they've been discussed in here. The search button is your friend.
It all depends on your architecture, how you deal with messages, their durability, SLA, etc, etc, etc.
But whatever you end up doing will be easier than playing with some esoteric router configuration!! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
