|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Moving clusters |
« View previous topic :: View next topic » |
Author |
Message
|
TJo |
Posted: Tue Jul 27, 2004 3:27 am Post subject: Moving clusters |
|
|
 Novice
Joined: 26 Jul 2004 Posts: 18 Location: Gothenburg Sweden
|
Hello everybody!
I am currently planning the MQ-part of a large transition to new hardware/location. One part of this is to move a couple of MQ-clusters.
The new MQ-setup must keep all the old names and be activated (for testing) before the old ones are shutdown.
A picture says more than my babbling, someone claimed, so here we go.
Code: |
current state
We have the old nodes A, B and C with cluster CL containing the qms QM1, QM2 and QM3, as well as the new hardware, node a, b and c.
OldNodes NewNodes
A QM1 CLo a
B QM2 CLo b
C QM3 CLo c
step 1
I install MQ and setup QM1-3 on a, b and c with new IP.
Now I have two clusters named CL, the old one on ABC and the new one on abc. Now application people can test on abc. Note that the "n" and "o" are just identifiers in this example. The cluster name is CL in both cases.
OldNodes NewNodes
A QM1 CLo a QM1 CLn
B QM2 CLo b QM2 CLn
C QM3 CLo c QM3 CLn
step 2a
Testing is finished and production is to be moved from "A" to "a" so I remove QM1 from the new cluster on abc.
OldNodes NewNodes
A QM1 CLo a QM1
B QM2 CLo b QM2 CLn
C QM3 CLo c QM3 CLn
Step 2b
Production is stopped on A.
Remove QM1 on "A" from the old cluster. Shutdown QM1 on A
OldNodes NewNodes
A a QM1
B QM2 CLo b QM2 CLn
C QM3 CLo c QM3 CLn
Step 2c
Add QM1 on "a" to the old cluster. After that production is resumed on nodes aBC.
OldNodes NewNodes
A a QM1 CLo
B QM2 CLo b QM2 CLn
C QM3 CLo c QM3 CLn
Step 3
Repeat step 2 with the QM2 qms.
OldNodes NewNodes
A a QM1 CLo
B b QM2 CLo
C QM3 CLo c QM3 CLn
Step 4
Repeat step 2 with the QM2 qms.
OldNodes NewNodes
A a QM1 CLo
B b QM2 CLo
C c QM3 CLo
Step 5
Start breathing again.
Move all qms on ABC to /dev/null. The thought of them accidentally started again.....
Relax.
|
A few of the things that I am unsure of.
As I create a new qm with the name of one of the old. How will the cluster react when (in step2-4c) I make the new qm with the old name a member of the old cluster? After all, the new one will have a new QM_ID.
Am I thinking correct here or am I on the path to bewildred madness?
Any tips and pointer on how to move clusters will be appreciated.
Thanks in advance.
TJo |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jul 27, 2004 7:10 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Quote: |
Am I thinking correct here or am I on the path to bewildred madness?
|
Bewildered madness if you have 2 QMs with the same name in the same cluster. Don't do it man, you're gonna hate life!!! I think you will be OK if you only ever have one QM1 in a particular cluster at a time. At Step 2C, you are going to have an old QM1 and a new QM1 in the cluster.
EDIT>>>Both won't be active at the same time, so you will be OK.
You can use the RESET command to force the old QM1 out, although technically it is not required.
Quote: |
Any tips and pointer on how to move clusters will be appreciated.
|
Have you read the Cluster Manual? See Problem #4 in the Resolving Problems section. And see Symptom - DISPLAY CLUSQMGR, shows a QM twice.
I really hope you have a LAB environment to test this in. I ***think*** you will be OK. I would feel very iffy if the first place I had to do this was in PROD.
Does the new CLuster -HAVE- to be named the same? The apps don't care. If it were me, I would avoid all the potential grief and in step 2c onward, add the QMs to a new ClusterName. Please explain why you can't do this. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
OmPat |
Posted: Tue Jul 27, 2004 7:37 am Post subject: |
|
|
Apprentice
Joined: 20 Jul 2004 Posts: 33 Location: Charlotte
|
I fully agree with peter.
Dont have two qmgrs of the same name on the cluster even though they might not be active at the same time. Dont make life difficult for yourself.
Njoy.... _________________ IBM Certified WMQ V5.3 System Administrator
IBM Certified WMQ V5.3 Solutions Designer
Brainbench Certified MQ Expert
IBM Certified WMQI V2.1 Solutions Expert
IBM Certified WMQI V2.1 Specialist |
|
Back to top |
|
 |
TJo |
Posted: Tue Jul 27, 2004 10:01 am Post subject: |
|
|
 Novice
Joined: 26 Jul 2004 Posts: 18 Location: Gothenburg Sweden
|
PeterPotkay wrote: |
EDIT>>>Both won't be active at the same time, so you will be OK.
You can use the RESET command to force the old QM1 out, although technically it is not required.
Have you read the Cluster Manual? See Problem #4 in the Resolving Problems section. And see Symptom - DISPLAY CLUSQMGR, shows a QM twice.
I really hope you have a LAB environment to test this in. I ***think*** you will be OK. I would feel very iffy if the first place I had to do this was in PROD.
Does the new CLuster -HAVE- to be named the same? The apps don't care. If it were me, I would avoid all the potential grief and in step 2c onward, add the QMs to a new ClusterName. Please explain why you can't do this.
|
Replying: second go. Tip: Do not try Emacs keybindings while editing in a web browser. Ctrl-w is NOT "cut region", its "close page", in Opera.
Thanks for the fast reply. Within 4h!! I wish I could see such snappy responses around here as well...
I read the manual alright, but failed to see the trouble shooting examples you mentioned. They do give some qlues.
You are right about the cluster name of course. I will use a different one on the temporary cluster on the target nodes.
But I have to keep the old one as all production takes place there. The transition will be in several steps with days and weeks between each node. Thus it must work all the time, except for a few hours during transition times.
So the following might work?
Set up the testenvironement on the target nodes in a cluster with a new name. Configs from the old qms will be used after editing IP and cluster name.
When a transition from one of the old nodes to a new one is to take place:
* Remove the testqm on the target node from the test cluster.
* Save the configuration.
* Wipe the testqm from the system completely.
* Make any necessery change in the configuration file. IP and such.
* On the production node, remove the prodqm from the prod cluster and shut down the prodqm.
All this must be done before IP/DNS from old node are transfered to target node.
* Set up a new qm on the target node using the config file.
* Add new qm to prod cluster thus making it the prodqm.
This way the test cluster will gradually disapper as the application on the old nodes are transfered into the new target nodes. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Jul 27, 2004 11:17 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Quote: |
All this must be done before IP/DNS from old node are transfered to target node.
|
You didn't mention that originally. That adds more complexity to this, doesn't it?
Quote: |
When a transition from one of the old nodes to a new one is to take place:
* Remove the testqm on the target node from the test cluster.
* Save the configuration.
* Wipe the testqm from the system completely.
* Make any necessery change in the configuration file. IP and such.
* On the production node, remove the prodqm from the prod cluster and shut down the prodqm.
All this must be done before IP/DNS from old node are transfered to target node.
* Set up a new qm on the target node using the config file.
* Add new qm to prod cluster thus making it the prodqm.
|
You should be OK. You will still find yourself with 2 QMs listed in the Full Repository with the same name, but different QMIDs, the old one and the new one. The manual says this should be OK, and MQ will be smart enough to handle it, since the old QMID will be recognized as gone. Which leads me to this point : Make sure you follow to the letter the procedures for removing a QM from the cluster as you take out the old QMs from the cluster (Task 5 in the manual). I would add one step that they don't list, and that is when you are ready to start removing the QM from the old cluster, before you do anything else, remove the cluster attribute fromall the queues on that QM. This will publish the fact that all the queues this QM hosted are no longer clustered. Then remove the QM itself from the cluster. Maybe not 100% required, but neater and more explicit in my opinion.
Some people rail against using Default QMs. I personally like them, if used properly. If your apps were coded to connect to the default QM, you would have been able to create new QMs with new names, and the apps would not have cared, and your life would have been a wee bit easier. But I digress.... _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
TJo |
Posted: Wed Jul 28, 2004 1:53 am Post subject: |
|
|
 Novice
Joined: 26 Jul 2004 Posts: 18 Location: Gothenburg Sweden
|
PeterPotkay wrote: |
Quote: |
All this must be done before IP/DNS from old node are transfered to target node.
|
You didn't mention that originally. That adds more complexity to this, doesn't it?
|
Sure does. It feels like step dancing on a lose wire. Careful planning should do the trick I hope. Parachute for sale, anyone?
PeterPotkay wrote: |
You should be OK. You will still find yourself with 2 QMs listed in the Full Repository with the same name, but different QMIDs, the old one and the new one. The manual says this should be OK, and MQ will be smart enough to handle it, since the old QMID will be recognized as gone.
|
Maybe if, before activating the moved qm, I force the repositories to refresh it will be avoided. All info about the removed qm should disappear. I hope I will get some lab environment ready for this soon.
PeterPotkay wrote: |
Which leads me to this point : Make sure you follow to the letter the procedures for removing a QM from the cluster as you take out the old QMs from the cluster (Task 5 in the manual). I would add one step that they don't list, and that is when you are ready to start removing the QM from the old cluster, before you do anything else, remove the cluster attribute fromall the queues on that QM. This will publish the fact that all the queues this QM hosted are no longer clustered. Then remove the QM itself from the cluster. Maybe not 100% required, but neater and more explicit in my opinion.
|
Ah! Sounds like very good advice to me. I will do that.
PeterPotkay wrote: |
Some people rail against using Default QMs. I personally like them, if used properly. If your apps were coded to connect to the default QM, you would have been able to create new QMs with new names, and the apps would not have cared, and your life would have been a wee bit easier. But I digress.... |
Sorry. Deaf ears all of a sudden.
I did burn myself on default qms once. Setup file with cluster definitions for the qm that is not the default + runmqsc + default qm exists + stupid MQ-guy = accident waiting to happen. Guess who the stupid MQ-guy was....
Default qms is a nice thing though. If not the tools like runmqsc used them I would feel safe using it.
Thanks a lot for all the help and good advice.
Tryggve |
|
Back to top |
|
 |
PeterPotkay |
Posted: Wed Jul 28, 2004 5:51 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Quote: |
You should be OK. You will still find yourself with 2 QMs listed in the Full Repository with the same name, but different QMIDs, the old one and the new one. The manual says this should be OK, and MQ will be smart enough to handle it, since the old QMID will be recognized as gone.
Maybe if, before activating the moved qm, I force the repositories to refresh it will be avoided. All info about the removed qm should disappear. I hope I will get some lab environment ready for this soon.
|
What you want to do is issue the RESET command from a Full Repository. The RESET command (only allowed on a FR) forces a QM out of a cluster. Always use the QMID option so you know exactly what your are forcing out.
The REFRESH Command (only allowed on a non-FR) cause the QM to "flush" its local cluster repository queue of all info, populate it with only its own cluster info, and the push only its own info out to the Full Repository. REFRESH does nothing more.
Quote: |
Some people rail against using Default QMs. I personally like them, if used properly. If your apps were coded to connect to the default QM, you would have been able to create new QMs with new names, and the apps would not have cared, and your life would have been a wee bit easier. But I digress....
Sorry. Deaf ears all of a sudden.
I did burn myself on default qms once. Setup file with cluster definitions for the qm that is not the default + runmqsc + default qm exists + stupid MQ-guy = accident waiting to happen. Guess who the stupid MQ-guy was....
Default qms is a nice thing though. If not the tools like runmqsc used them I would feel safe using it.
Thanks a lot for all the help and good advice.
|
One thing here that makes that less a problem is that 95% of my servers have only 1 QM. On the servers where I have multiple QMs, or if they are in MS Hardware clusters, I do not use Defaults. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|