| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| HACMP or MQ Cluster |
« View previous topic :: View next topic » |
| Author |
Message
|
| Al Pacino |
 Posted: Tue Feb 10, 2009 6:03 am Post subject: HACMP or MQ Cluster |
 |
|
Centurion
Joined: 19 Aug 2005
Posts: 114
|
OK folks need an advice here , We are to implement HA for MQ on an AIX system. We have got 2 AIX servers , each has message broker installed and a one broker queue manager there. It is only one Queue manger which exists on both machines.
We have 2 choices to do :
1. Use HACMP and apply the support pack mc91. This will require using SAN and creating resource groups on the HACMP ... etc . Using that will not really require MQ clustering since we will have a high availability of the Queue manager.
2. Use MQ clustering and cluster both Broker Queue managers and just have the cluster itself control workload and the availability of the Queue manager.
I prefer option 2 , however , my concern is that , these Queue Managers are broker queue managers , so if we use clustering and let's say the Queue Manager on machine 1 goes down , how will the broker knows or learn about the other Queue Manager on the other server. "Isn't the Broker will be looking for its local queue manager?" What is the relationship between MB and MQ when we are using the MQ clustering.
Clustering does not get round the fundamental problem of getting a mesage into the cluster in the first place. A client (broker, WAS, any other prog) will open a connection to a q mgr
(using IP and port), the message gets sent then the clustering routes the message internally to the end queue. However, what happens if the q mgr that a client connects to is down? You
lose all cluster benefits 'cos you can't get the message into the cluster in the first place.
I hope I am being clear , if not feel free to ask me . Advice needed here.
Thanks
_________________
"We can't solve problems by using the same kind of thinking we used
when we created them." |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Feb 10, 2009 6:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
As discussed endlessly on the forum, WMQ clustering is not suitible for an HA solution.
In the scenario you describe, I'm confused why one broker would want or need to know about the other? If we assume the 2 queue managers on the 2 servers are clustered, each with it's broker sitting on it then when server A falls over (taking queue manager & broker with it), traffic will flow to server B where the other broker will process it in the traditional manner. Why would it want to know about server A?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 10, 2009 6:09 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you go for option 2, then there will be no failover of any kind.
If the qmgr for broker 1 goes down, then so does broker 1. |
|
| Back to top |
|
|
| KeeferG |
| Posted: Tue Feb 10, 2009 7:44 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
What are you trying to protect against?
Loss of service - Use MQ Clustering to workload balance noting that any in flight transactions may be at worst, lost or at best delayed. Scale as required by adding more queue managers and brokers.
Resilience of existing service - Use both HA and MQ clustering. Whilst one fails over the other should take up its workload. Then once the HA cluster has succefully failed over the workload should distribute evenly again. Make sure your MQ resource group is started before your broker.
This assumes that work is currently balanced between the two.
For your client connection make it put to an alias and allow the clustering to workload balance between the real queues.
If you primary client connection fails then use MQCONNX or the definition table to provide a back up connection to the remaining queue manager.
Of course it can get much more complicated than that but that should start you off.
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| Al Pacino |
| Posted: Wed Feb 11, 2009 2:04 am Post subject: |
|
|
Centurion
Joined: 19 Aug 2005
Posts: 114
|
Hi KeeferG,
Here are few questions :
1. My Client is a datapower which only contains mq client . How would mq client put into the cluster? . My understanding is that , we need to have a remote and a transmit queue on the client side so we can point to the Queue Manager gatway which then point it with aliases queues to the real queues. On datapower , I can't create remote or transmit "mq client".
2. If a client application is to put into a cluster , we have to point to an alias queue on a queue manager which work as a gateway. What if the queue managers in the cluster set on different machines , then do we need to have to create the aliases on each machine ?
3. What if we put a loadbalancer in between the datapower and the MQ , will that solve our issue ?
4. What about MQ binding ? will it work with cluster ?
Thanks
_________________
"We can't solve problems by using the same kind of thinking we used
when we created them." |
|
| Back to top |
|
|
| KeeferG |
| Posted: Wed Feb 11, 2009 5:10 am Post subject: |
|
|
Master
Joined: 15 Oct 2004
Posts: 215
Location: Basingstoke, UK
|
Hi.
1. To make our DataPower put messages into a cluster you follow the normal procedure. The queue manager you are connecting to must be a member of the cluster. On the queue manager you are connecting to you create an alias queue with the targq being the cluster queue you wish to access. DataPower will then put to the alias queue adn the queue manager can workload balance across the cluster queues. IF the queue manager you are connecting to is not in the cluster then you will need to set up a remote queue, transmit queue and channel to a queue manager that is in the cluster. Place the alias queue on the cluster queue manager and make your remote queue reference it.
To have a back up queue manager for your DataPower to connect to you can create an MQ Queue Manager Group to give you a list of pssible queue managers to use.
2. The alias queue should only be at the point you are connecting into the cluster.
3. Do not place a load balancer between DataPower and MQ. It should sit in front of the http handlers and not MQ handlers.
4. I do not understand this question in the context of DataPower.
Hope this helps
_________________
Keith Guttridge
-----------------
Using MQ since 1995 |
|
| Back to top |
|
|
| Al Pacino |
| Posted: Wed Feb 11, 2009 6:20 am Post subject: |
|
|
Centurion
Joined: 19 Aug 2005
Posts: 114
|
Thanks much for the help
_________________
"We can't solve problems by using the same kind of thinking we used
when we created them." |
|
| 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
|
|
|
|
