| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Miscellaneous Questions /observation |
« View previous topic :: View next topic » |
| Author |
Message
|
| jeevan |
 Posted: Sat Jan 12, 2008 9:18 pm Post subject: |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| fjb_saper wrote: |
open a PMR  |
We have a plan to upgrade to 6.0.2. In fact, we already started planning from this week. Also, this is in TEST environment.
By the way, I am suggesting to automate the migration as much possible. I have thinking using silent installation in MQ. However, I have never done it. Anu suggestion? |
|
| Back to top |
|
 |
| SAFraser |
| Posted: Tue Jan 15, 2008 10:08 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
The Windows processes.... which ones are you wondering about?
amqsvc is the service manager, which launches amqmsrvn (the Windows DCOM server).
http://www-1.ibm.com/support/docview.wss?uid=swg21182193
amqmtbrn is just the tray icon.
Are these what you are curious about? Or something else?
Shirley |
|
| Back to top |
|
|
| jeevan |
| Posted: Tue Jan 15, 2008 2:50 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| SAFraser wrote: |
The Windows processes.... which ones are you wondering about?
amqsvc is the service manager, which launches amqmsrvn (the Windows DCOM server).
http://www-1.ibm.com/support/docview.wss?uid=swg21182193
amqmtbrn is just the tray icon.
Are these what you are curious about? Or something else?
Shirley |
This is useful information but this was not my question.
We are rebuilding the machine itself( seems funny but we are using the old machine). Therefore, the migration is painful. We have to do a lot of things in one night - for one machine).
All of our queue managers are in mq53. So we are plannign like this:
Take one of the FR and rebuild on mq60
Take next FR and rebuild on mq60
migrate the all other PRs
In order to do this, what we need to do is like this:
make one of the PR to RF ( say C)
suspect one of the FR ( say A)
stop the queue manager (A)
delete this queue manager ( or we can leave as this machine will be rebuild from OS poing of view ( fr0m 2k to 2k3)
install mq ( trying silently)
install FP ( siliently)
build mqgr A
create mq objects ( run the runmqsc against the script generated by savwqmgr)
varify ( manually - looking some way to do this too automatically)
add the newly rebuild qmgr to cluster as FR
done
Note: The third qmgr will be take out of as FR while working on it.
In this course, I am testing different stuff for automating the process as much as possible. One of the thing is collecting mq objects and sec settings remotely. Secondly, I would like to run the mq command remotely like runmqsc -w ( I am failing) to do things like adding third queue manager as new FR, suspending qmgr A etc. All has to be done ( including OS one one night ( 12-6am).
what my question was that sharing any experiences/the issues you have faced in automating these kinds of activiteis and using tools like saveqmgrc /oamd /runmqsc remotely etc.
Thank you very much,
Last edited by jeevan on Tue Jan 15, 2008 3:04 pm; edited 2 times in total |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 15, 2008 2:56 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If you're going to delete, rather than migrate, any cluster qmgrs...
You need to do *more* than suspend them. You need to properly and carefully remove them from the cluster entirely: unshare all queues, delete manual clussdrs, etc... as laid out in Cluster manual.
You won't be able to use runmqsc "remotely" via an intermediate qmgr... if the destination qmgr is stopped.
You won't be able to use saveqmgr, either the server or client version, if the qmgr is stopped.
It's entirely possible to automate what you want to do... but you should expect to spend some time in a test environment debugging it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jeevan |
| Posted: Tue Jan 15, 2008 3:45 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
Sorry for reposting. I am doing this for some clarity and typo.
=======================================
All of our queue managers are in mq53. So we are plannign like this:
1. Take one of the FR and rebuild it on mq 6.0.2.2 ( latest fp) ( lets say this as qmgr A)
2. Take next FR and rebuild mq 6.0.2.2 ( latest fp) ( lets say this as qmgr B)
3. Migrate one PR ( ( lets say this as qmgr C)
4. Repeat step 3 until there is production qmgr manager in mq v 53.
Note: The only difference in step 3 and rest of the PR will be this. In qmgr C, it will be repository so need to take out
from the cluster. But case in case of other qmgrs,taking clusrcvr and clussdr channel out will be suffice
In order to accomplish this, we need to carry out:
1. make one of the PR to FR ( say C)
2. suspect one of the FR ( say A)
3. stop the queue manager (A)
4. delete the queue manager A( or we can leave as this machine will be rebuild from OS poing of view ( from Win 2k to 2k3)
5. install mq v 6.0.( trying silently)
6. install FP latest 6.0.2.2( siliently)
7. build mqgr A
8. create mq objects ( run the runmqsc command against the script file generated by saveqmgr)
9. add the newly rebuild qmgr to cluster as FR
10. start sdr/rcvr channels
11. verify the object creation and joining the qmgr as full repository( manually - looking some way to do this too automatically)
done
Note: The third qmgr will be taken out as FR while working on it.
In this course, I am testing different stuff for automating the process as much as possible. One of the thing is collecting mq objects and sec settings remotely. Secondly, I would like to run the mq command remotely like runmqsc -w ( I am failing) to do things like adding third queue manager as new FR, suspending qmgr A etc. All has to be done ( including OS one one night ( 12-6am).
what my question was that sharing any experiences/the issues you have faced in automating these kinds of activiteis and using tools like saveqmgrc /oamd /runmqsc remotely etc.
Thank you very much, |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 15, 2008 4:02 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jeevan wrote: |
2. suspect one of the FR ( say A)
3. stop the queue manager (A)
4. delete the queue manager A( or we can leave as this machine will be rebuild from OS poing of view ( from Win 2k to 2k3) |
Again, if you are going to do these steps, you have to do a lot more steps instead! You have to remove A from the cluster properly and in the right order.
Or you might as well just delete your entire cluster first, or plan on taking a while to run a full full REFRESH cluster on every machine after the upgrade is complete - during which time the cluster will be only somewhat available.
The rest of my other points still apply, but I won't repeat them.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jeevan |
| Posted: Tue Jan 15, 2008 4:29 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| jefflowrey wrote: |
| jeevan wrote: |
2. suspect one of the FR ( say A)
3. stop the queue manager (A)
4. delete the queue manager A( or we can leave as this machine will be rebuild from OS poing of view ( from Win 2k to 2k3) |
Again, if you are going to do these steps, you have to do a lot more steps instead! You have to remove A from the cluster properly and in the right order.
Or you might as well just delete your entire cluster first, or plan on taking a while to run a full full REFRESH cluster on every machine after the upgrade is complete - during which time the cluster will be only somewhat available.
The rest of my other points still apply, but I won't repeat them. |
I understand what you mean. The process laid out in cluster redbook is for taking out a qmgr from a cluster. Our case is different. As the new qmgr name will be same, so I am thinking suspending, and resuming. I am not on the process but I will be follwoing the steps:
1. Suspend the queue manager
2. Alter the CLUSRCVR channels to have CLUSTER(’ ’),
3. Stop and delete the CLUSRCVR channels
4. Stop and delete the CLUSSDR channels
These are the steps laid out in MQ Queue manager cluster redbook.
I am stil not sure, when I rebuld the qmgr, do I need to resume? or I can reset the cluster at the beginning and refresh from another queue manager and when I rebuild, join the qmgr to the cluster( by adding repos and clus rcvr and sdr channel) and once running issue REFRESH command. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jan 15, 2008 5:11 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
NO.
The qmgr is in the cluster using the QM ID, not the QM NAME.
You can not use suspend like this.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 15, 2008 6:52 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
jeevan, its like local User IDs on Windows. When you create a User Id called "JEEVAN" on Server1, Windows sores that ID as a SID, i.e. 123456789. When you apply security to "JEEVAN" you are really applying it to 123456789. If you delete JEEVAN and immediately recreate the ID again, to you it looks exactly the same, JEEVAN. You think its the same ID. Its not. When you recreated the ID Windows gave it a unique SID again, this time maybe 456789123. All the authorities you granted previously now fail.
Same thing with MQ clustering. Using the above example, instead of User IDs you have QM names. Instead of SIDs you have QMIDs.
You can't delete your QM and then recreate it with the exact name and expect the cluster to work as the QM IDs will be different. You'll end up with 2 QMIDs for the same QM. This is why you must properly remove the QM from the cluster first. That will remove the original QMID as well, and set you up to recreate the QM again with the same name.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jeevan |
| Posted: Wed Jan 16, 2008 11:32 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| PeterPotkay wrote: |
jeevan, its like local User IDs on Windows. When you create a User Id called "JEEVAN" on Server1, Windows sores that ID as a SID, i.e. 123456789. When you apply security to "JEEVAN" you are really applying it to 123456789. If you delete JEEVAN and immediately recreate the ID again, to you it looks exactly the same, JEEVAN. You think its the same ID. Its not. When you recreated the ID Windows gave it a unique SID again, this time maybe 456789123. All the authorities you granted previously now fail.
Same thing with MQ clustering. Using the above example, instead of User IDs you have QM names. Instead of SIDs you have QMIDs.
You can't delete your QM and then recreate it with the exact name and expect the cluster to work as the QM IDs will be different. You'll end up with 2 QMIDs for the same QM. This is why you must properly remove the QM from the cluster first. That will remove the original QMID as well, and set you up to recreate the QM again with the same name. |
Waht about using the follwoing pari of command to forcely take out the queue manager out of cluster and when it joins
From a FR. issue the following command
RESET CLUSTER(clustername) QMID(qmid) ACTION(FORCEREMOVE) QUEUES(NO)
build the qmgr
add to cluster
when finsihed, from FR, issue the follwoing Command
REFRESH CLUSTER( CLUSTERNAME) repos(no)
Thank you very much, |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jan 16, 2008 12:26 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Make the FR a PR.
Properly uncluster the QM as suggested by Jeff and detailed in the cluster manual.
Delete the QM.
.
.
Do whatever you have to do that is the whole purpose of this
.
.
recreate the QM
recluster it
No need for resets, no need for refreshes.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
