| Author |
Message
|
| JYama |
 Posted: Mon Nov 30, 2009 1:00 am Post subject: WMB v7 high availability |
 |
|
Master
Joined: 27 Mar 2002
Posts: 281
|
Hello,
Is there anybody who tried high availability configuration?
Since supportPac IC91 doesn't support WMB v7 so far, I'd like to know how I can achieve this.
For active-standby confituration, I think multiple instance queue manager, a new feature of MQ v7.0.1, can be a solution, but for active-active, I have no idea how I can configure the system.
Any ideas? 
Many thanks in advance,
Regards, |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Nov 30, 2009 2:48 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
WMQ v7 multi-instance, does not acquire the original QM's IP address on takeover.
I don't see how this can replace the HA/CMP function which does keep the same IP address for the QM after failover.
Our connecting applications and queue managers are dependent on the IP name for the queue manager working. We don't use a CCDT in most cases either.
We could manually perform a DNS change to the new IP address but it would be nice if WMQ v7 had some way of automating this. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Nov 30, 2009 3:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
MQ v7 doesn't change anything about Active-Active from MQ v6 configurations.
It might be possible to construct a service object that will handle a network layer switch over when the standby qmgr starts. But that's a random thought, not a tested idea. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 30, 2009 4:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| zpat |
| Posted: Mon Nov 30, 2009 5:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It may also assume the use of CCDTs by all connecting clients.
Doesn't solve the issue of other protocols arriving at the brokers IP address such as http, ftp, sftp.
Addressing a pure MQ solution ignores the brokers wider capability. |
|
| Back to top |
|
|
| JYama |
| Posted: Mon Nov 30, 2009 4:23 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
As you know, I think multi-instance QMgr is just one choice and can be a solution in a limited situation.
For example, it only takes over the QMgr and not database. Also it's only applicable for "active-standby" implementation of QMgr. (The license fee would be doubled at least for MQ with multi-instance QMgr because the standby QMgr is "half-active" in this case.)
Anyway, I understand muti-instance QMgr can't be a solution for "active-active" mutual take over case.
Since supportpac IC91 is not available for WMB v7 right now, we may need to design and develop some shell scripts from scratch, right?
Regards,
Last edited by JYama on Mon Nov 30, 2009 4:43 pm; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 30, 2009 4:39 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| JYama wrote: |
As you know, I think multi-instance QMgr is just one choice and can be a solution in a limited situation.
For example, it only takes over the QMgr and not database. |
WMB7 does not use a database. Although your message flows may need to connect to application DBs, but I don't see why they would need to failover with the QM / Broker.
| JYama wrote: |
| (The license fee would be doubled at least for MQ with multi-instance QMgr because the standby QMgr is "half-active" in this case.) |
Your IBM Sales Rep verified this?
| JYama wrote: |
Since supportpac IC91 is not available for WMB v7 right now, we may need to design and develop some shell scripts from scratch, right?
|
I haven't looked at it yet, but I suspect the concepts IC91 talks about are still applicable for WMB 7.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Nov 30, 2009 4:45 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| zpat wrote: |
It may also assume the use of CCDTs by all connecting clients.
Doesn't solve the issue of other protocols arriving at the brokers IP address such as http, ftp, sftp.
Addressing a pure MQ solution ignores the brokers wider capability. |
That link I posted completely ignores how stuff is supposed to get to the Broker / QM once it fails over. 
I think a standard network load balancer could be set up to send non MQ traffic primariliy to Server 1 and only go to Server 2 once the Broker fails over. Eh. Not as elegant as a VIP that fails over with the Broker and QM in a classic H.A. solution.
For the MQ Clients I don't think you need a channel table, just an MQ 7.0.1 client (or QM) that allows for multiple destination hostnames in the conname paramter of the CLNTCONN, SNDR, CLUSRCVR, etc.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JYama |
| Posted: Mon Nov 30, 2009 5:17 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
| PeterPotkay wrote: |
| WMB7 does not use a database. Although your message flows may need to connect to application DBs, but I don't see why they would need to failover with the QM / Broker. |
I assumed a general architecture including multiple resoures such as DB, MQ, WMB, and maybe any other user resources. In this case, we may choose HACMP rather than multi-instance QMgr.
| PeterPotkay wrote: |
| Your IBM Sales Rep verified this? |
Yes, but it's for WMQ v7 users, not for WMB v7 users.
| PeterPotkay wrote: |
I haven't looked at it yet, but I suspect the concepts IC91 talks about are still applicable for WMB 7. |
I agree with you.
Thanks, |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Dec 01, 2009 12:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| PeterPotkay wrote: |
| For the MQ Clients I don't think you need a channel table, just an MQ 7.0.1 client (or QM) that allows for multiple destination hostnames in the conname paramter of the CLNTCONN, SNDR, CLUSRCVR, etc. |
Interesting, but still tricky with existing Java/JMS applications that specify only one connection name for the queue manager. Getting these all changed could be a challenge.
Still wouldn't solve the issue of inbound transactions to the broker using other transport protocols. Network load balancer is one possibililty I suppose. However it might not ensure that the traffic went to the same place as the MQ queue manager was located, depending how it failed. |
|
| Back to top |
|
|
| broker-rob |
| Posted: Tue Dec 01, 2009 7:17 am Post subject: |
|
|
Newbie
Joined: 28 Dec 2007
Posts: 5
Location: Hursley
|
While IC91 is not suitable for use with MB7 most of the concepts still hold when using MB7 with a HA Manager. As you say Multi-Instance QM/Broker does not solve the problem for all customer scenarios.
It is still possible to configure MQ/MB7 for use with a HA Manager such as HACMP/VCS.
In Summary the main points are...
Creation:
Mount the share folders onto node A and create the QM/Broker using the Multi-instance commands to put the shared data onto the shared filesystem i.e. mqsicreatebroker MyBroker -q MQ1 -e /MQHA/MyBroker/
Mount the shared folders onto node B and use the add-instance commands to create the required links on the 2nd node i.e. mqsiaddbrokerinstance MyBroker –e /MQHA/MyBroker/
Starting/Stopping
You will need to create some scripts for starting and stopping the broker. These will be very similar to those shipped in IC91. If you use them as a start and remove all the parts not applicable to MB7 i.e. starting the database etc.
Monitoring
Again you will need to create a script which is based on that provided in IC91 removing the parts that are not applicable.
Hopefully this will help you get started. Hopefully soon there will be further information with the product on how to configure such environments. |
|
| Back to top |
|
|
| broker_new |
| Posted: Tue Dec 01, 2009 10:35 am Post subject: |
|
|
Yatiri
Joined: 30 Nov 2006
Posts: 614
Location: Washington DC
|
I still see the same level of complexity for HA configuration for both MQ and Broker. Same concepts but little different.
I still see no solution for failing over the JMS connection to other queue manager on partner node. We are handling it in the code whenever we receive 2059 we connect to a different queue manager. |
|
| Back to top |
|
|
| JYama |
| Posted: Mon Dec 07, 2009 9:21 pm Post subject: |
|
|
Master
Joined: 27 Mar 2002
Posts: 281
|
I'd like to know more about how multi-instance brokers, a new feature in v7, interact with mutil-instance QMgrs, a new feature in v7.0.1.
In my understanding, the technology of multi-instance QMgrs is based on 'file lock' on the shared network storage.
When an active QMgr unlocks the storage due to unexpected reasons, process down for example, its stand-by QMgr grabs the storage and tries to start and become active.
Now, if these processes are done automatically, do you know how the associated broker interact with the QMgr?
The broker silently switches the brokerQMgr? or fails over together with the QMgr?
Are there commands we need to issue when a multi-instance broker fails over, such as endmqm or mqsistop, or also processes to monitor to trigger the fail over?
These are still black boxes for me.
Many thanks, in advance,
Regards,
Last edited by JYama on Mon Dec 07, 2009 10:38 pm; edited 2 times in total |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 07, 2009 9:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I would expect you to have a qmgr dependent service there.
However where it gets difficult is that normally you'd be using different service ids. Maybe sudo can help there...
WMB broker stop and start are done via mqsistop and mqsistart commands...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mgk |
| Posted: Tue Dec 08, 2009 3:18 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
Multi Instance Brokers are based on Multi Instance Queue Managers. The Broker will only fail over if it is an HA broker (with a standby instance running on the second machine) and the QM underneath it on machine one fails over to machine two. See topic be13650 in the docs for more details.
Regards,
MGK
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
|
|
