| Author |
Message
|
| John89011 |
 Posted: Wed Sep 23, 2009 8:41 am Post subject: suspend and remove or just suspend? |
 |
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
I've might asked this before but would just confirmation.
We're forklifting our existing server from one DC and mounting it at a new DC locatoin.
For the MQ cluster setup, do I just suspend ourselves from the cluster or do I suspend, remove and once it's powered up at the new location we rejoin?
I am confused about the removing part, I checked the manual and I don't see it anywhere talk about removing.
This is for MQ 6.0.2.4 on Solaris.
Thanks in advance |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Sep 23, 2009 8:43 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
If the IP address is the same at the new location as at the old, then suspension will do.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| John89011 |
| Posted: Wed Sep 23, 2009 8:58 am Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| Thanks for the reply! Same server but IP/host name will change. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 23, 2009 9:01 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Remove it entirely.
Move it.
Add it anew. |
|
| Back to top |
|
|
| John89011 |
| Posted: Wed Sep 23, 2009 9:02 am Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 23, 2009 9:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| John89011 wrote: |
| Thanks for the reply! Same server but IP/host name will change. |
Then, following my previous post, suspension will not do.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| John89011 |
| Posted: Mon Oct 05, 2009 8:02 pm Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
One more question...
App1=full repository (some app)
App2=partial repository (my app)
Here are steps that I am taking...
1. App1 & App2: alter cluster queues cluster name to "blank", App1 checks cluster queues are gone from repository.
2. App2: SUSPEND QMGR CLUSNL(my name list) or one CLUSTER
3. App1 & App2: DIS CLUSQMGR(XXXX) SUSPEND
4. App2: ALTER CHANNEL(TO.APP2) CHLTYPE(CLUSRCVR) CLUSTER(' ') or alter the namelist to remove the clusters.
5. App1 & App2: STOP CHANNEL(TO.App2). App1 checks if dynamic CLUSSDRA channels disappear.
6. App2: Stop CLUSSDRs
STOP CHANNEL(XXX)
On some other QMGR we're the full repository, does the other app have to do the above on their end?
According to IBM:
Since the full respository is where the change is manifested I recommend the following:
1. Remove the full repository out of the cluster(read WMQ version 6 Queue Manager Clusters manual, Chapter 9 Advanced Tasks, Task 10 Removing a queue manager from a cluster.
2. Modify the ip address of the cluster receiver channel, move the queue manager and restart it.
3. Rejoin the cluster(may occur automatically when restarting the queue manager in step 2).
4. Modify the ip address of the partial repositories' cluster senders.
5. Issue a Refresh Cluster(cluster name) REPOS(Yes) from each partial repository where the ip address of the cluster sender was modified.
-----------------------------------------------------
.
The steps above should keep the cluster cache clean and accurate (without erroneous information) through the transition.
It seems to me that the above is true if I was going to move the QMGR but that's not what I am doing. It just seems like an overkill, can't I just bring down the QMGR gracefully, change the receiver channel to point to new ip/host and start it up on the new IP?
Sorry for the long post, any input will be appreciated. |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Oct 05, 2009 11:11 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Follow mqjeff's advice because while it's a pain in terms of procedure, it will save a lot of time and heartache. Move one of the FR's in the first tranche by demoting one in the old DC and promoting one of the PR's in the new DC so there is an FR in each until all servers are moved, and take down the FR in the old DC last is the only other advice I offer.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 06, 2009 1:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| exerk wrote: |
| Follow mqjeff's advice because while it's a pain in terms of procedure, it will save a lot of time and heartache. Move one of the FR's in the first tranche by demoting one in the old DC and promoting one of the PR's in the new DC so there is an FR in each until all servers are moved, and take down the FR in the old DC last is the only other advice I offer. |
 (that may be a bit self-serving..)
I'd suggest that any institution using clusters should have a separate script to add the cluster to an existing qmgr (full of alter qmgr and alter q commands), and likewise the similar to remove the cluster from an existing qmgr.
Especially now that one can do fun things like "dis ql(*) where".... |
|
| Back to top |
|
|
| John89011 |
| Posted: Tue Oct 06, 2009 11:12 am Post subject: |
|
|
Voyager
Joined: 15 Apr 2009
Posts: 94
|
| exerk wrote: |
| Follow mqjeff's advice because while it's a pain in terms of procedure, it will save a lot of time and heartache. Move one of the FR's in the first tranche by demoting one in the old DC and promoting one of the PR's in the new DC so there is an FR in each until all servers are moved, and take down the FR in the old DC last is the only other advice I offer. |
Problem is that nothing will be running in the new DC because we first need to move the server from the old DC to the new DC. We're using the same server, just different location. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 06, 2009 11:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Demote one FR to a PR.
Remove it entirely from the cluster.
Move it.
Add it back to the cluster.
Promote it to an FR.
Repeat remove/move/re-add for the rest of the PRs, saving the other FR for the last.
Demote, remove, move, re-add, promote. |
|
| Back to top |
|
|
|
|
