| Author |
Message
|
| kalam475 |
 Posted: Wed Nov 30, 2016 10:32 pm Post subject: Architecture Design for HA |
 |
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
Hi
We have a requirement for one our client they want the HA for IBM MQ and don't want HACMP and in Redhat environment.
What I am gonna propose is Multi instance queue manager with compatible shared disk with ACTIVE\PASSIVE Scenario.
Along with this to counter the switching process time lapse we are proposing a out of network queue manager with the same name as multi instance queue manager.
When client applications connect to queue manger they will connect through the CCDT file which has client defination of the out of network queue manager.
When active queue mangaer goes down passive will take over as active and while switching if any application tries to put message it will connect to out of network queue manager.
will same scenario will work if both active and passive queue manager goes down?
Is there anythhing I am missing here we are going with 8.0.0.5 version redhat 6.5 and NFSv4 as shared disk. any suggestions will be greatly appriciated. this forum has never let me down hope now also the same case. (come up with this after reading lots and lots of post available) |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Nov 30, 2016 11:47 pm Post subject: Re: Architecture Design for HA |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| kalam475 wrote: |
Along with this to counter the switching process time lapse we are proposing a out of network queue manager with the same name as multi instance queue manager.
|
By 'out of network' I assume you mean firewalled?
DO NOT DO THIS. Having multiple QMGRS in your environment with the same name is just asking for trouble. The backend QMGR really should have a different name. As th clients can't connect to it why do you need it to be the same name?
| Quote: |
When client applications connect to queue manger they will connect through the CCDT file which has client defination of the out of network queue manager.
When active queue mangaer goes down passive will take over as active and while switching if any application tries to put message it will connect to out of network queue manager.
will same scenario will work if both active and passive queue manager goes down?
|
What do YOU think will happen?
You say you have read up a lot so you should have formed some opinion.
| Quote: |
Is there anythhing I am missing here we are going with 8.0.0.5 version redhat 6.5 and NFSv4 as shared disk. any suggestions will be greatly appriciated. this forum has never let me down hope now also the same case. (come up with this after reading lots and lots of post available) |
You are proposing using a Gateway QMGR. There are plenty of posts here about this.
But with an Active/Passive setup, I'm not sure of the advantages of using a GW QMGR.
What happens if the GW QMGR goes down?
Do your client apps know how to reconnect?
You also have a single point of failure. That is not good especially when you have an HA backend.
I think you need to go back and think again.
To moderators,
Can someone please move this to the appropriate forum? This does not seem to have much to do with Java/JMS
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kalam475 |
| Posted: Thu Dec 01, 2016 2:25 am Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
I am not suggesting the gateway queue manager what I was thinking is the client application by default would connect directly to multi-instance queue manager.
If any of the multi instance queue managers are not available then there should be a queue manager that should accept the client connections.
so I am creating a client connection channels in multi instance queue manager one channel pointing to multi instance queue manager itself by pointing conname as (XXXX(1414),XXXX(1414) and another client connection channel for normal queue manager with conname XXXX(1413) .
so if i put normal queue manager name same as multi instance queue manager name and properties such as AFFINITY(PREFERED) WEIGHT(0) my application will connect to channel in alphabetical order which will be MULINSTQMGR.
if both of the queue manager goes down it will connect to second client connection channel. since in my programing i am using MQCONNX as *QMGRNAME. applications are now connecting to normal queue manager.
If my normal queu manager name is different from MULINSTQMGR the applciations are not able to connect to normal queue manager.
Please suggest me .... |
|
| Back to top |
|
|
| kalam475 |
| Posted: Thu Dec 01, 2016 2:33 am Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
multi instance queu manager name (QMA)
normal queue manager name (QMA)
CCDT are
SVRCONN1 CONNAME(mq1.tec.com(1414),mq2.tec.com(1414) QMGRNAME(QM1)
SVRCINN2 CONNAME(mq3.tec.com(1413) QMGRNAME(QM1)
for both channels AFFINITY(PREFERED) WEIGHT(0)
Now my applcations will connect to mq1.tec.com ideally if mq1.tec.com is down they are connecting to mq2.tec.com and if both are down they are connection to mq3.tec.com
I know you are not supposed to use same queue manager name but is there any way in my scenario that i can change the QMGR name in mq3.tec.com still my applications be able to connect to this qmgr when my multi instance queue manager's are down?
Thanks |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Dec 01, 2016 3:55 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
I think you are getting a little confused here.
If you want an active/passive solution then you ONLY need to configure one connection destination. This is because part of the Active/Passive setup is to have an IP address that fails over so that is always points to the ACTIVE server.
If you have two connections (as you showed) then the second one would be this 'other' QMGR.
But I say again, having two entirely separate QMGRS with the same name active at the same time is just asking for trouble.
Why do you want this third QMGR? Many of us have run/are running with an Active/Passive solution. I know of one such system that has not been totally shutdown in almost 6 years apart from when it was needed to for upgraded etc.
I can't help but think that you are over thinking this and ending up with something that is overly complex.
I am sure that some others will be along shortly with their thoughts.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 01, 2016 5:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| smdavies99 wrote: |
| I think you are getting a little confused here. |
I certainly am.
| smdavies99 wrote: |
| I can't help but think that you are over thinking this and ending up with something that is overly complex. |
So do I.
You certainly seem to be mixing / melding / mashing HA & DR. If both active and passive nodes on an HA solution fail, that's a disaster and should be handled differently.
I certainly wouldn't want to try and administer the set up you describe, especially as you start to scale the topology with multiple queue managers, all of which need the same availability.
Why have you discounted some of the more traditional HA / DR solutions in favor of this more complex and unusual one? What are the requirements your client has that are dictating this? A desire not to use HACMP doesn't predicate why you're suggesting.
Also, moved this thread as suggested.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kalam475 |
| Posted: Fri Dec 02, 2016 9:05 am Post subject: |
|
|
Acolyte
Joined: 16 Jan 2015
Posts: 63
|
Is there any way my client applications could know which queue manager to connect in an multi instance queue manager scenario with out using the CCDT and connection namelist.
if so please let me know and also is using CCDT file in your client application is bad idea?
By passing the topic here also i have another question does my persistance messages can be stored in db rather than file system. some architechture guy says there is a configuration we can do so that MQ stores the messages in db rather than file system.
I have searched everywhere there is no such kind of configuration may be we can write a MDB to store but it is no point storing the messages in db but still is there a possibility.
Thanks for your help !!!!!! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Dec 02, 2016 9:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you want your client to connect to a multi-instance qmgr, you have two choices:
- configure the hostname and port in the connection to be two hostnames and ports - ala a:1414,b:1414
- put a VIP in front of the qmgrs, such that the client only knows about c:1414, and the VIP will know about a:1414 and b:1414
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 02, 2016 9:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kalam475 wrote: |
some architechture guy says there is a configuration we can do so that MQ stores the messages in db rather than file system.
I have searched everywhere there is no such kind of configuration |
Well you're asking some random strangers on the Internet if some architecture guy is right, so you're unlikely to get any definitive answer ... 
... except the one in the InfoCenter about where you can store queue files.
(you can't store messages in a db rather than a file system)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Dec 04, 2016 4:46 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
[quote="Vitor"]
| kalam475 wrote: |
| some architechture guy says there is a configuration we can do so that MQ stores the messages in db rather than file system. I have searched everywhere there is no such kind of configuration |
MQ does not currently have any features to directly store messages in a DB. It would be very easy to write an app to do this, MQGET DB INSERT in a loop. At this point the integrity and recoverability of the message data is passed from the MQ queue manager to the DB manager.
_________________
Glenn |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 05, 2016 5:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gbaddeley wrote: |
| kalam475 wrote: |
| some architechture guy says there is a configuration we can do so that MQ stores the messages in db rather than file system. I have searched everywhere there is no such kind of configuration |
MQ does not currently have any features to directly store messages in a DB. It would be very easy to write an app to do this, MQGET DB INSERT in a loop. At this point the integrity and recoverability of the message data is passed from the MQ queue manager to the DB manager. |
On the understanding you'd then need some kind of synchronization application to remove messages from the db once they'd been read from the queue, and another application to recover them in the event of a failure.
I'm not saying what you're suggesting is impossible, or even a bad idea. Just pointing out (especially for the benefit of less experienced future readers) that it's a bit more involved.
I stand by my basic point - you can't change just a configuration on the queue manager and make it use a database instead of a file system for queue message storage.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 05, 2016 5:53 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| kalam475 wrote: |
| some architechture guy says there is a configuration we can do so that MQ stores the messages in db rather than file system. I have searched everywhere there is no such kind of configuration |
I think you are getting confused here. This feature is available on the WebSphere Application Server Messaging Bus. Not on WebSphere MQ.
Even though both products may talk to each other, they are still quite different messaging systems, and are certainly not interchangeable!
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Dec 12, 2016 5:58 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
|
|
