| Author |
Message
|
| Senthamizh |
 Posted: Wed Dec 19, 2012 2:55 am Post subject: Move Message broker from one server to another |
 |
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
AIX MB-6.1.0.10
Existing Topology
Server1 -> ConfigMgr1 , Broker1 & related components like QM and DB's
Server2 -> ConfigMgr2, Broker2 & related components like QM & DB's
Target Topology
Server1 -> ConfigMgr1, Broker1 , Broker2 and related components for them
We would like to remove a server and move the broker in that server to another server which already has another broker running.
Important objective is the bar files will not be deployed again. Whatever running in Broker2 will have to be moved as it is to Server1.
I thought about this approach (Server1 CPU, memory and other capacity needs will be addressed)
1) Create a QM in server1 as existed in Server2 and run the queue dump(no system queues)
2) Create a Broker DB and DSN (the BrokerDB backed up on Server2 will be restored in Server 1)
3) Create a Broker with the same name as existed in Server2 on the new QM created
I thought the brokerDB would be sufficient to get back the flows, but not sure if there are other broker related information in ConfigDB that i miss here.
Looking for the experts views on this.. |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Wed Dec 19, 2012 3:19 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
You seem to be missing all the shell (csh,ksh or bash) scripts that should be in your source control system.
you know the ones that
- create the Queue Manager and all its artifacts
- creates the broker, execution groups, and other things like setting SOAP Ports and configurable services
- deploys all the bar files that you also have saved in the SCS.
If you don't have them now would be a good time to develop them and make sure they get maintained.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Dec 19, 2012 5:03 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Upgrade to WMB 7 and use mqsibackupbroker.
The QM part is easy with support pac MS03. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 19, 2012 5:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
Upgrade to WMB 7 and use mqsibackupbroker.
The QM part is easy with support pac MS03. |
Although if you upgrade to v8, you can use MQ 7.1 or 7.5 and dmpmqcfg instead of a supportPac. |
|
| Back to top |
|
|
| Senthamizh |
| Posted: Wed Dec 19, 2012 8:00 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
| smdavies99 wrote: |
If you don't have them now would be a good time to develop them and make sure they get maintained. |
Sources are maintained well, but they are partially automated with jenkins. The concern would be the involvement of many business teams to provide their latest sources, and the effort spent. My organization structure is greatly different and has multiple complexities..
Here, i want to discuss on the technical possibilities of achieving the solution than the process oriented way.
@mqjeff. zpat
MQ7.5 upgrade is ongoing, and WMB8 will be there by next year... But any possibilities with WMB6.1 ? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Dec 19, 2012 8:12 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Senthamizh wrote: |
Sources are maintained well, but they are partially automated with jenkins. The concern would be the involvement of many business teams to provide their latest sources, and the effort spent. |
That is good to know. don't forget that as you develop the procedures and document it having the latest versions of any delpoyable object is not really needed. Unless major changes are going on just a viable snapshot of the deployable bits are needed.
It sounds like you are halfway there if you are using Jenkins. However, I have found that the key bits of building the broker in the first place are often missing/not documented.
you do need to do a complete audit of the broker configuration. Then when you build the new one you can compare the outputs of an audit of the new one.
Finally, when you are building the new broker don't try to change things on the running new broker. Just edit the build scripts and delete the old one and build it from scratch again. This way you can be sure that the end result can be built using the scrips.
When you move to V8, I suggest that your first build is done using the updated scripts. don't rty to implement anything like libraries etc until you have a viable working V8 configuration.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kash3338 |
| Posted: Wed Dec 19, 2012 8:55 am Post subject: |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| Senthamizh wrote: |
| But any possibilities with WMB6.1 ? |
I guess the simple answer for your question, with the step by step approach you had suggested and the version of Broker you are running on, would be NO.
| Senthamizh wrote: |
3) Create a Broker with the same name as existed in Server2 on the new QM created
I thought the brokerDB would be sufficient to get back the flows, but not sure if there are other broker related information in ConfigDB that i miss here. |
I guess there are some unique identifiers which gets created during a Broker creation which would not allow you to do the above.
But not sure though. Also since there are no direct answers from the experts here, and mostly its the advice on migrating to a latest version and about maintaining the artifacts in CM, I don't think there is a possibility to do this without re-deploying again.
| Senthamizh wrote: |
| MQ7.5 upgrade is ongoing, and WMB8 will be there by next year |
But given that you have planned to migrate to the latest version and the work has already started, why do you really need to do this now? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Dec 19, 2012 9:19 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| zpat |
| Posted: Thu Dec 20, 2012 12:35 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
WMB 6.1 is almost out of support and needs a database (hassle to install) - so it's a good time to move to WMB 7 during your server migration. You don't need to upgrade MQ to do this.
WMB 8 / WMQ 7.5 are still a little new and quite a lot of APARs are coming out - personally I would wait for the next fixpack before migrating to them.
With WMB 6.1 you will just have to list out any configurable services, look at the registry for DSN credentials and reapply these to a newly created broker.
There might be other customisations such as JVM parameters - you can list all these with the mqsireportbroker command.
It's fairly easy to create a broker, create the same EGs as before and re-deploy your bar files. Unless it was truly huge I wouldn't look for short cuts. |
|
| Back to top |
|
|
| Senthamizh |
| Posted: Thu Dec 20, 2012 5:53 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
| mqjeff wrote: |
| http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fan20141_.htm |
I had a look on this earlier, but this more of restoring the configmanager and broker on the same system using some informations like Broker UUID from registry.. Don't really want to play with registry setup's in prod 
Thanks all for your inputs
Well, I agree with the current situation, this should be done during migration. But i am just another person in the organization who does, what the management wants..
| kash3338 wrote: |
| I don't think there is a possibility to do this without re-deploying again |
Probably instead of backing up the broker db, drill deep and get those tables which has flow info's, exe info's etc.. But before you reply, i agree that its not a conventional method and the effort spent can actually be spent of redeploying everything.
| zpat wrote: |
| so it's a good time to move to WMB 7 during your server migration. WMB 8 / WMQ 7.5 are still a little new and quite a lot of APARs are coming out |
We did the same with MB5 to MB6.1 migration. We migrated to MB6.1 even when MB7 was out thinking that it need to get stabilized... But the turnover time for the next migration becomes very less and we are forced to migrate once in 3-4 years, than the standard software life of 5 years.. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 20, 2012 5:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Senthamizh wrote: |
| mqjeff wrote: |
| http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fan20141_.htm |
I had a look on this earlier, but this more of restoring the configmanager and broker on the same system using some informations like Broker UUID from registry.. Don't really want to play with registry setup's in prod |
No, it is not for restoring the broker ON THE SAME SYSTEM.
Read it again.
Your comment about messing with the registry on a prod system is confusing.
You are already trying to mess with a prod system. Messing with the registry is a) completely necessary to accomplish the task you want to accomplish, b) not in any way riskier than what you're already proposing to do.
Also, really. You shouldn't do any of this on a prod system. You should back up *both* brokers and the configmgr and then restore them to a *new* machine. Then once it works, make *that* the prod system. |
|
| Back to top |
|
|
| Senthamizh |
| Posted: Thu Dec 20, 2012 6:33 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2009
Posts: 47
|
Got it. Thanks
Will work out . I was more of in a mind set with one configMgr and 2 brokers. but with this one, I will have to check how it comes out, may end up with 2 configMgr and 2 brokers sharing a common workpath. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Dec 20, 2012 7:57 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| I believe a CM can adopt a broker it didn't know about... Search the IC on "Adopt a broker". One CM is possible. |
|
| Back to top |
|
|
|
|
