| Author |
Message
|
| bbking |
 Posted: Thu Oct 07, 2004 8:05 am Post subject: Is there truly FAIL-OVER??? |
 |
|
Newbie
Joined: 07 Oct 2004
Posts: 1
Location: Cleveland, Ohio
|
My client is new to MQ, I am not. I've been programming to mq for the last ten years. But being just a dumb code cruncher, I haven't set up a cluster.
My client is seeking high availablility.
To acheive this, can we:
set up mq on two separate Windows servers.
Then cluster together the queue managers of the same name with the same queues both as fully repositors.
(Can both queue managers be designated the cluster manager??)
I assume that an mqput from outside the cluster goes to either queue manager.
If one machine goes down, what happens.??
Is an mqput from outside the cluster merely sent to the queue manager of the machine that is still up?
Thans |
|
| Back to top |
|
 |
| siliconfish |
| Posted: Thu Oct 07, 2004 8:11 am Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
Yes, what you hve mentioned is exactly right.
You can set up a clustered queue with the same name in both the cluster queue managers and make them full repositories also.
but you need a geatway queue manager on which you have to put the messages to the clustered queue which is clustered with both the queue managers .
so if one of the queue managers goes down, the gateway queue manager sends the messages to the clustered queue on the other queue manager.
but for the question "is this truly a Failover?" - NO its not.
_________________
siliconfish |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 07, 2004 8:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
But NEVER put two Queue Managers with the same NAME on the same network.
It's bad in very subtle ways.
MQ Clustered queue managers have different names.
OS clustered queue managers have the same name, because they are never running both at the same time.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Oct 07, 2004 3:02 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
And you have to realize that if you do set up a Gateway MQManager that MQManager will represent a single point of failure for any applications that use that Gateway.
Some people call this load balancing but if all the messages from the Clients have to pass through the Gateway MQManager...........
Seems kinda pointess to me.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Oct 07, 2004 3:07 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A gateway queue manager is a single point of failure in the same way that a U-Joint on your automobile is a single point of failure between the engine and your tires.
A proper gateway queue manager does not have any applications reading from it, and is on a box of it's own. The only work it does is acting as a gateway.
A single queue manager, on a single box, merely routing messages between channels, is going to be very very robust. Even on a relatively cheap piece of hardware!
Unless the hardware or OS is bad.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| siliconfish |
| Posted: Thu Oct 07, 2004 3:18 pm Post subject: |
|
|
Master
Joined: 12 Aug 2002
Posts: 203
Location: USA
|
The Gateway Queue Manager, can be set up for failover using hardware clustering.
I mentioned the Gateway queue manager in terms of Load Balancing using clustering.
_________________
siliconfish |
|
| Back to top |
|
|
| hguapluas |
| Posted: Fri Oct 08, 2004 9:36 am Post subject: |
|
|
Centurion
Joined: 05 Aug 2004
Posts: 105
Location: San Diego
|
You should create a (clustered) queue alias (ex: ANY.QM) that can put to either of the clustered queues in the cluster. It's documented in the Queue Manager Cluster manual and it works. Granted, any queue using that alias becomes dependent on that Queue as the "single point of failure". You don't necessarily have to setup a singe gateway to get into the cluster. Using these alias' you can potentially set up multiple entry points into the cluster that can transmit to either (and your not limited to two queues either) of the queues in the event the other one is down or unavailable.
The real question which will impact configuration is; are you combining distributed queues with clustered queues, or are you a pure clustered environment? If you are a pure clustered environment, then it is somewhat mute. It's when you are combining distributed queues with a clustered queue that this really becomes important.
If one of the queues goes down, then what should happen is that the messages will get delivered to the other queue. But I have seen it where the messages have occasionally backed up at the gateway waiting for the downed queue to come back up. It's an oddity that can likely be explained by other external factors (such as dependencies). |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Sat Oct 09, 2004 3:29 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Besides the examples in MQ Cluster manual, I tried to describe some different connection scenarios here:
http://mrmq.dk/cluster_qma_2.htm
More or less complicated scenarios using MQ clustering for workload balancing.
One thing you should be aware of is: when MQ cluster detects a failure, it might "freze" the message it's trying to send to the failing qmgr. This message will be "frozen" until the filaing qmgr returns into operation.
The real way to gain real HA is using MQ under a HA hardware like SHARED queues on z/OS, HACMP on AIX or MS-clustering on windows, which take care of recovering the failing qmgr on another box.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Oct 22, 2004 1:32 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
One way to do this would be to create a normal cluster with two MQMGR Participants and build an AMQCLCHL.TAB file for the applications to use instead of setting the MQSERVER environment variable. Define a CLNTCONN channel entry for each Partcipant.
Then if QM01 fails the MQManager will send the traffic to QM02 in the cluster. However it will not load balance because the application will look a the .TAB file and use the first available channel it finds in alphabetical order.
That would give you true failover.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Oct 22, 2004 2:09 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| csmith28 wrote: |
| That would give you true failover. |
Ture failover means no stranded messages, which means you need hardware clustering.
A channel table will allow the client app to connect to the remaining QM, but it won't be able to get to the messages that were on the QM that went down.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| csmith28 |
| Posted: Fri Oct 22, 2004 2:26 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Yes but, assuming the messages were persistent when the failed MQManager was restored the stranded messages would be processed.
This is also assuming no catastrophic damage to the sever or the MQManager.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| seanb |
| Posted: Sun Oct 24, 2004 10:56 pm Post subject: |
|
|
Apprentice
Joined: 02 Aug 2003
Posts: 39
|
I think what Peter means when he talks about stranded messages is, a message is stranded if it cannot be processed until the failing queue manager or server is restored, which could be some hours (or perhaps even days) later.
With failover, this would not be the case. You would expect the message to be processed almost immediately. Of course it may take a short while for technologies such as HACMP to failover, but we would be talking 10's of seconds or minutes and not the time it would take for, say, the help desk to contact you something was wrong (at 3am in the morning), for you to try to log onto the server and find its hard disk had crashed, ...)
Regards,
Sean. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Tue Oct 26, 2004 8:40 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
Yes and this whole conversation stems from people who want to make MQSeries perform in ways that it was not designed to perform.
In reference to jefflowery's ascertation that a Gateway MQManager robust. Well, it still represents a single point of failure. Hardware fails.
The original message in this thread did not mention the use of a Failover Tool like HACMP so unless the application developers are prepared to write code that will write to one MQManager and then the other in round robin, then incase of failure on one PUT to the other.......
| Quote: |
| Is an mqput from outside the cluster merely sent to the queue manager of the machine that is still up? |
No, applications that connect in Client mode can not put a message to a cluster. A Client application can put a message to a member of a cluster but it has to specify an MQManager name, a channel name, a destination Queue and a Server.
Applications can only take full advantage of MQCluster features in Binding mode. Applications can only connect in Binding Mode if the application is on the same server as the MQManager.
MQ is not a failover tool. MQ is not a load balancing tool. MQ is a Message delivery tool.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Oct 27, 2004 5:16 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| csmith28 wrote: |
| Applications can only take full advantage of MQCluster features in Binding mode. |
I can't think of any MQ Cluster features that are available to apps connected in bindings mode that are not available to apps connected in client mode.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Oct 28, 2004 6:24 pm Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
| PeterPotkay wrote: |
| I can't think of any MQ Cluster features that are available to apps connected in bindings mode that are not available to apps connected in client mode. |
Using only MQSeries an application connecting as a Client (local or remote) can't take advantage of the load balancing features of Clustering without a single point of failure unless Load balancing intelligence is built in to the application. As in APPX connects to QM1, QM2 and QM3 as a client in round robin unless one of or two of the three QM's fails to respond.
Then APPX sends it's traffic to the QM's that have not failed.
But then if the programmers were smart enough to code load balancing intelligence of this nature into their app, they would not need a Cluster. They could just as well use Distributed MQ.
I have been lead to believe that an application using BINDING mode can PUT a messages to a Cluster without specifying a QManager name. Binding mode can only be used by an application that is local, as in the application resides on the same server as the MQManager (FR or PR).
Finally, like I said, "Failover" is not feature of MQSeries. MQSeries is not a load balancing tool nor is it a high availability tool.
If I am mistaken, please do correct me. Tell me how a remote or even a local Application using client mode can take advantage of the Load Balancing features or Clustering without using a "Gateway" MQManager which represents a Single Point Of Failure or HA software.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
|
|
