| Author |
Message
|
| jefflowrey |
 Posted: Tue Dec 04, 2007 4:15 pm Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| fjb_saper wrote: |
I'm a little bit confused...
How did you get to have 2 qmgrs with the same name up and running at the same time in the cluster??? |
It's easy to create two qmgrs with the same name. It's easy to add them to the same cluster. They end up with different qmids, and everything is all higgeldy-piggeldy, but it's easy to do.
If nothing else (although, again, crtmqm won't care what you do), consider restoring a full backup of an mq server to another machine.
| fjb_saper wrote: |
| If your DR was active/active you should have been notified in advance and foreseen the problem... |
If it were active/active then everything would have been bad from day one, yes.
| fjb_saper wrote: |
| If the DR exercise was to simulate DR then it was done poorly as both sites were up at the same time... |
Even if they weren't up at the same time, things still are a mess. The "live" qmgr goes down. The DR qmgr comes up, with entirely different channel sync info. Everything falls over. Or it comes up with a new qmid, and now you have duplicate qmgrs (different qmids) in the cluster... and everything is all higgeldy-piggeldy.
I'm with Peter here.
Also, remember *never* do DR testing on a production cluster network. If you do, be assured that you will get real live production data comingled with test data on that DR qmgr.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| thindk00 |
| Posted: Wed Dec 05, 2007 1:31 am Post subject: |
|
|
Voyager
Joined: 16 May 2001
Posts: 75
Location: UK
|
The applications DR model is poor, that is a fair comment. It has not been thought through properly and requires some work. The two applications run in two datacentre separated by almost a 1000 miles so synchronous replication is out of the question.
We're likely to have a manual process in place that will involve removing the original queue manager from the cluster and joining the second queue manager in with the same queue manager name as and when required, accepting possible message loss. The need to have the same queue manager name is not mandatory but highly desireable as the queue manager name is referenced in about 50+ locations.
We had this situation arise when we had both queue managers joined to the cluster with the same name as the manual process did not remove one of the queue managers from the cluster first and both were running at the same time. This is learnings that we will take on board and ensure do not happen again in the future.
Thanks again for your input. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Dec 05, 2007 1:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Note that the original subject of this thread (preventing queue managers joining the cluster) will put a crimp in your DR plan if implemented!
Sounds like you need some kind of aliasing mechanism so you can have 2 queue managers with differing names, but one reference for these 50+ locations that you can switch over.
Or a proper software-driven DR solution! 
(Though such things are not always as simple as they sound. Budget and so forth).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Dec 05, 2007 4:27 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| thindk00 wrote: |
The need to have the same queue manager name is not mandatory but highly desireable as the queue manager name is referenced in about 50+ locations.
|
Eh. There is no need for remote apps to have a QM name hard coded. Anywhere. Ever. And here's a classic example why.
| thindk00 wrote: |
| We're likely to have a manual process in place that will involve removing the original queue manager from the cluster and joining the second queue manager in with the same queue manager name as and when required, accepting possible message loss. |
| PeterPotkay wrote: |
| Create a 2nd QM (with a unique but similiar name) on a 2nd DR server (with a unique but similiar name) and just add it to the cluster on Day 1, but leave all the queues unclustered. When DR strikes, cluster the queues and you're back in business. |
If you do this you will *know* ahead of time all the channels are working and that the QM is clustered properly. Its much more trivial to cluster some additional queues versus joining in a whole QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Dec 05, 2007 5:15 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You can also run the DR in the cluster in suspended mode (suspend qmgr cluster(MYCLUSTER) mode(quiesce)). Queues are clustered, and everything but the qmgr name and receiving chl matches the active qmgr.
When the disaster strikes and the active qmgr is down messages get automatically sent to the DR as it is the only destination available in the cluster, regardless of the fact that it is "suspended" (only available destination clause)...
As soon as the normal qmgr comes back up the messages will switch back as you now have another available destination in the cluster. If all destinations are "suspended" they will be load balanced... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| thindk00 |
| Posted: Wed Dec 05, 2007 11:34 pm Post subject: |
|
|
Voyager
Joined: 16 May 2001
Posts: 75
Location: UK
|
| PeterPotkay wrote: |
| thindk00 wrote: |
The need to have the same queue manager name is not mandatory but highly desireable as the queue manager name is referenced in about 50+ locations.
|
Eh. There is no need for remote apps to have a QM name hard coded. Anywhere. Ever. And here's a classic example why.
|
Interested in learning more about what you mean here. We have adapters that need to put messages onto remote queues on a queue manager to allow them to be sent to Middleware. The queue manager on the machine may not be the only one and therefore we wouldn't be using a default queue manager. How would you look to achieve this?
Regarding joining queue managers in and having them suspended etc and allowing WMQ to load balance etc, well this may cause us just as much headaches and require our application team to be extra careful for example when they do scheduled maintenance etc. We want to be in total control of when the DR machine is used and therefore are likely to keep this in our control. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 06, 2007 1:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| thindk00 wrote: |
The queue manager on the machine may not be the only one and therefore we wouldn't be using a default queue manager. How would you look to achieve this?
|
Well here are 2 utterly off the cuff methods:
1) A database table contains application id type data (app name, machine name, system name, etc in any combination or permutation you like) and the name of the queue manager associated with that combination;
2) All the applications client onto a queue manager called "MYQMGR" and are provided with a client table which maps MYQMGR onto the queue manager it's intended they use.
Many, many other solutions are possible, many of these are better than these simplistic examples I've offered simply to illustrate the point.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| thindk00 |
| Posted: Thu Dec 06, 2007 1:40 am Post subject: |
|
|
Voyager
Joined: 16 May 2001
Posts: 75
Location: UK
|
| OK, I understood. I was hoping there may be a WMQ configuration option. At the moment the QM name is configured in configuration files and we would need to update those. Unfortunately there are lots of files that need to be maintained. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 06, 2007 2:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| thindk00 wrote: |
| Unfortunately there are lots of files that need to be maintained. |
And of course you have an existing mechanism to maintain / control these. Or one of the proprietory software solutions. Or in extremis a home-brew piece of script.
I think this ties back to previous points on poorly thought-out DR solutions; it sounds like you (the corporate you) need to put some thought into control issues as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Dec 06, 2007 9:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| thindk00 wrote: |
| PeterPotkay wrote: |
| thindk00 wrote: |
The need to have the same queue manager name is not mandatory but highly desireable as the queue manager name is referenced in about 50+ locations.
|
Eh. There is no need for remote apps to have a QM name hard coded. Anywhere. Ever. And here's a classic example why.
|
Interested in learning more about what you mean here. We have adapters that need to put messages onto remote queues on a queue manager to allow them to be sent to Middleware. The queue manager on the machine may not be the only one and therefore we wouldn't be using a default queue manager. How would you look to achieve this?
|
You said you have apps in 50+ locations. If they need to get to QM1 they are connecting to their local QM which has remote q defs to get to QM1. So they never need to know about QM1.
If they are in a cluster where their QM is in the same MQ cluster as QM1, again, they do not need to hard code QM1. The messages will get to QM1 if QM1 hosts the q they need to get to.
If they are MQClients all conecting into QM1, the QM name is not needed for MQ Clients. A hostname and port # uniquely identify a QM to a client.
But if you have more than 1 QM on a server (I avoid that for lots of reasons this being one of them) and the apps are running locally then yes, you do have to code the name. I didn't understand that to be your topology though when you said "50+ locations".
Designing an MQ system that forces the apps to know the QM name makes it more difficult to migrate the app between environments, be it DEV--->QA--->PROD, or PROD--->DR.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| thindk00 |
| Posted: Thu Dec 06, 2007 10:30 pm Post subject: |
|
|
Voyager
Joined: 16 May 2001
Posts: 75
Location: UK
|
| Let me clarify. The one local QM is referenced by the different application adapter instances in about 50 places (files, database entries, etc). This is not hard coded in the code anywhere, it is kept configurable but in a lot of places. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 07, 2007 4:01 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| thindk00 wrote: |
| Let me clarify. The one local QM is referenced by the different application adapter instances in about 50 places (files, database entries, etc). This is not hard coded in the code anywhere, it is kept configurable but in a lot of places. |
You should probably review some of your overall design.
Only enter the setup of the qmgr info into one file. If need be to referenced somewhere else use a simlink. Change information once and all apps benefit from the change (at least on restart)...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
