| Author |
Message
|
| nosnhoj |
 Posted: Mon Apr 24, 2006 9:48 am Post subject: QMGR alias and failover |
 |
|
Apprentice
Joined: 07 Sep 2005
Posts: 40
Location: Markham On.
|
I think i'm missing someting here... i've read the intercommunications chapter 4 a few times now - and i'm still not getting it... and i've read all the 'search' posts i could get.
Here's what I have...
3 queue managers:
APPQM, QM1 and QM2
APPQM is connected to QM1 via an IP alias of QM1.tor.ca
App1 on APPQM puts messages to Q1 on QM1 and everything is good.
QM1 dies and we change the IP alias QM1.tor.ca to point to QM2 instead of QM1
App1 puts messages destined for QM1, but becuase of the IP alias change they are directed to QM2.
On QM2:
DEFINE QREMOTE ('QM1') -
RNAME ('') -
RQMNAME ('QM2')
Now APP1 on APPQM puts a message destined for Q1 on QM1, and due to the IP alias change it is routed to QM2, and the above definition exists on QM2
So what I want to achieve is when QM1 dies, we change the IP alias so everyting is routed to QM2. QM2 carries local queues identical to QM1. I don't want APP1 on APPQM to have to make any changes in the event of a failure of QM1... but since the put is still going to be Q1 on QM1 - well, I was hoping this is where the alias would kick in.
should it work? or did I miss the true functionality of qmgr aliases
(I know a cluster would solve that quite simply - I just want to know if that is my only option)
Thanks |
|
| Back to top |
|
 |
| vennela |
| Posted: Mon Apr 24, 2006 10:00 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
|
| Back to top |
|
|
| wschutz |
| Posted: Mon Apr 24, 2006 10:06 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
That should work. Hopefully, QM2 never needs to put a message to QM1.
and..I assume you would use the same channel (APPQM.QM1), which would need the seq numbers reset and hopefully nothing is in doubt.
Is App1 using a remote queue def to put to Q1 @ QM1? IMHO, it would be cleaner to change the qremote def on APPQM to point to Q1 @ QM2.
And you're correct, this is why clustering was invented.
EDIT: ven's right about the difficulty getting the channel going....
_________________
-wayne |
|
| Back to top |
|
|
| nosnhoj |
| Posted: Mon Apr 24, 2006 10:17 am Post subject: |
|
|
Apprentice
Joined: 07 Sep 2005
Posts: 40
Location: Markham On.
|
| I think i'll just 'cluster' the lot. Thanks for the replies. |
|
| Back to top |
|
|
| srindies |
| Posted: Tue Apr 25, 2006 12:14 am Post subject: |
|
|
Apprentice
Joined: 06 Jan 2006
Posts: 28
|
I am also involved in setting up similar environment for our production. Switching IP alias can be achieved by open source tool like Heartbeat. Clustering of MQ Servers is recommended for load balancing and not a good solution for High Availability.
In this scenario, we have 2 QMGRS, QM1 (Active) and QM2 (Standby) with similar objects. If QM1 fails, QM2 will take over and thus provides HA to the application. But, we cannot assure APPQM never fails. Here APPQM is also a single point of failure.
These messages in QM1 and QM2 should be picked up by other application for processing. If QM1 has 100 Messages and fails, these 100 messages will not be available to the processing application till it becomes active. QM2 is totally unaware those 100 messages. I would prefer to share the logs between QM1 and QM2.
Refer the following link for more information,
http://www-128.ibm.com/developerworks/library/l-halinux2/
Regards,
Sridhar H  |
|
| Back to top |
|
|
| vennela |
| Posted: Tue Apr 25, 2006 6:17 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
| In this scenario, we have 2 QMGRS, QM1 (Active) and QM2 (Standby) with similar objects. If QM1 fails, QM2 will take over and thus provides HA to the application. But, we cannot assure APPQM never fails. Here APPQM is also a single point of failure. |
Totally agree
| Quote: |
| These messages in QM1 and QM2 should be picked up by other application for processing. If QM1 has 100 Messages and fails, these 100 messages will not be available to the processing application till it becomes active. QM2 is totally unaware those 100 messages. |
How is this different from MQ Clustering
I looked at the thread you posted and I haven't seen two qmgrs.
It is just one qmgr all the way. It is regular HA (like HACMP or Veritas) but for Linux. |
|
| Back to top |
|
|
| srindies |
| Posted: Tue Apr 25, 2006 7:32 am Post subject: |
|
|
Apprentice
Joined: 06 Jan 2006
Posts: 28
|
Hi Vennela,
Correct me if wrong. My assumption is 'MQ Cluster' provides High Availability of Queue Managers for the MQ Applications (APP1) and sharing logs (as mentioned in my previous post) provides high availability of messages to message consumer (APP2).
I have to propose an environment that supports High Availability of Queue Managers for APP1 and messages for APP2.
I am planning to use shared logs for message HA and TSA (Tivoli System Automation) to identify failure and switch over of the system. In one of my other posting Jeff suggested me to ping channel to find its availability and switch over accordingly.
In the foreseen environment, I could have 2 QMgrs on totally isolated hardware system. One of them will be active and other will be in stand-by mode sharing 1 log directory. If active QManager fails, TSA sniffs it and bring up stand-by/backup QManager. I tried with NFS file system, but I will be on Shared Mainframe ESS for production.
Regards,
Sridhar H |
|
| Back to top |
|
|
| xxx |
| Posted: Tue Apr 25, 2006 9:43 am Post subject: |
|
|
Centurion
Joined: 13 Oct 2003
Posts: 137
|
'MQ Cluster' provides High Availability of Queue Managers
In the real sense MQ Cluster in not for HA, It is for Load Balancing,
For Ex: as you said if messages are stuck in QM1 and it is done , you have to wait till the QM1 is up,
HA cluster is OS dependent , and Each Qmanger will be failed to other server if there is any failure ! |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Wed Apr 26, 2006 4:00 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| xxx wrote: |
'MQ Cluster' provides High Availability of Queue Managers
In the real sense MQ Cluster in not for HA, It is for Load Balancing,
For Ex: as you said if messages are stuck in QM1 and it is done , you have to wait till the QM1 is up,
HA cluster is OS dependent , and Each Qmanger will be failed to other server if there is any failure ! |
The correct term is "business continuity", this means, your business will go on - when you have further queue instances.
_________________
Regards
Hubert |
|
| Back to top |
|
|
|
|
