| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| WebSphere MQ 5.3 DR question |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Fri Sep 29, 2006 2:58 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
In an active - active mode you are running 2 different qmgrs (A and B) -- one on each node.
So in case of failover, the qmgr on the failed node is moved to the remaining active node (now running 2 qmgrs(A and B) on the same node).
The standard active/passive mode is running a single qmgr that gets moved to the active node in case of failover.
/var/mqm is shared in both cases. However in the active / active scenario the contention is avoided as each node uses a different qmgr as the active one.
I hope this clears up some of the confusion
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| SAFraser |
| Posted: Fri Sep 29, 2006 1:29 pm Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
Jeff,
Re: high-availability queue managers. I understand how this works to assure day-to-day business continuity, but I'm not understanding how it works for disaster recovery. A DR machine *should* be physically far away from the active server, and they should not be sharing disk. I'm thinking now of a disaster that takes out an entire physical data center which would include the MQ server as well as its storage.
In that case, a cold spare as described by sroach76 makes a lot of sense, doesn't it? Perhaps I am missing the point here!
Sroach76,
Have you considered the actual risk of data loss compared to the actual cost of continously replicating queue and log files? When we looked at our own operation, we found that there were only a couple of heavy volume times per month when we had any appreciable queue depths. Those particular data sets could easily be identified and requeued at their source. So we decided to do circular logs and not try to "save" any data in the event of a disaster failover. Instead we keep a cold spare just as you describe, an exact replica of production.
Part of our disaster procedure is to contact the various app teams to see if they have outstanding transactions to be requeued.
Just my two cents.
Shirley |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat Sep 30, 2006 6:04 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Shirley -
Yes, but. 
I guess I wasn't a hundred percent clear on the whole of my thinking. I would use the third party disk replication stuff to replicate the shared disk space between main and DR site. And then have the DR site mount up the replicated disk.
The very nice thing about the HA configuration is that it does everything that is needed to assemble everything that needs to be replicated into one or two easily identifiable pieces. And the HA support packs include scripts that will build the queue managers to use these pieces. So you don't have to go through and figure out which folders under /var/mqm/ need to be replicated. I mean, one could look at the HA support packs, see what they move to shared disk, and then just use that to replicate... but then you're still essentially rewriting the scripts.
With a well-thought out and executed HA environment, where all the shared disk for all the queue managers is on the same sharepoint on a SAN, one can configure the entire sharepoint to be replicated to DR.
No reason to re-invent the wheel.
On the subject of circular vs. linear logging - from a recovery planning viewpoint the only time when circular logging is acceptable is in a case like yours where there are never more than one or two messages on a queue anywhere. Otherwise, if the queue file gets damaged then the messages that were stored in it are entirely lost with circular logging.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Sun Oct 01, 2006 6:54 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
Jeff,
Thanks for that clarification, now I understand where you were going with your points. Using the HA scheme as a guide to replication is very efficient.
And, yes, that is exactly what I meant by assessing the risk of data loss, circular vs. linear, and so forth. I think sometimes that a lot of resources are devoted to protecting a very tiny amount of data, and the payback just isn't there.
Now about the HA.... In our world, I have only one production MQ server. (It's a very small MQ world here, as most of it was outsourced last year. A different story for another time.) I don't think a production HA cluster in the main data center is justifiable because there is so little data resident on the MQ server at any time. PLUS I have been unable to get the developers to understand the concept of connection retries in their client apps, so client apps must be bounced if the qmgr connection is broken.
Anyway, I have another server in a different data center that is used for stress testing. In the event of either 1) loss of the primary MQ server or 2) loss of the primary data center, I am to quiesce stress testing and bring up production in the second data center. I keep an exact replica of the production queue manager on the stress test server, but not running. A failover exercise requires some manual intervention, but not a whole lot. Reset & restart channel (there's only one set left), reconfigure IP, reset & restart remote mainframe channels, reconfigure & bounce client connections.
Now this type of setup is TOTALLY unacceptable where there is risk of data loss and/or a real MQ environment. I guess the point I was trying to make to the original post is: Assess your actual need and design a solution from there.
I sure wrote a lot of words to say that, didn't I? 
Shirley |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Oct 01, 2006 9:06 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
You sure did Shirley but we love you for the clarity of your argument and your prose...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
