| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Rebuilding a config manager |
« View previous topic :: View next topic » |
| Author |
Message
|
| pjaffe |
 Posted: Fri Sep 03, 2004 11:59 am Post subject: Rebuilding a config manager |
 |
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
Based on info from IBM and the documentation for WBIMB 5.0, is anyone actually successful at recovering a dead config manager? We have tested this several ways without luck. I will readily admit that our testing is somewhat flawed in that I am running the broker and the config manager on the same physical Windows 2000 server. That being said, I don't think that the location of the broker should have much impact onth succes of the recovery. This was my test plan.
1. MQSIstop ConfigMgr
2. UDB backup of the WMQICMDB database (config manager database)
3. mqsideleteconfigmgr (I had to stop an MQ channel system.brk.queue ?)
4. db2 drop db WMQICMDB
5. db2 create db WMQICMDB
6. db2 restore ....
7. mqsicreateconfigmgr ...
8. mqsistart ConfigMgr
The config manager starts fine. I then open my Eclipse toolkit and connect to the config manager. It shows what was running when the backup was taken. While all this was happening, I was running a test message continuously through the broker and it has continued to flow without a problem.
I now try to stop the flow or delete the execution group and it doesn't happen. I do get messages in the WBIMB event log with BIP2056 and BIP4040 but then I get:
"BIP1536S: Configuration Manager unable to register for internal subscriptions with broker NTMC.
Although the preceding deploy operation was successful, a subsequent attempt by the Configuration Manager to register for internal subscriptions with broker NTMC was not successful. This means that the Message Brokers Toolkit may not reliably show the correct status of the resources assigned to broker NTMC. The Configuration Manager also writes this message to the system event log, accompanied by other messages giving details of the problem. "
This leads me to believe that the config manager registered the change but was not able to actually deploy it on the broker.
I suspect that I will actually need to rebuild the broker and redeploy everything. I hope there is a way to this without destroying the broker since I plan to have more than 5 brokers (separate servers) running against a single config manager.
Has anyone had success with recovering a config manager while maintaing the brokers under windows 2000 and WBIMB 5.0? |
|
| Back to top |
|
 |
| PGoodhart |
| Posted: Tue Sep 07, 2004 7:03 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
FYI:
In version 5 the configuration manager does not store any information. So basically you just set up the configuration manager and associate it with your broker. (We aren't even planing to back up the configuration manager filesystem, just reinstall it and recreate via script.) The basic database should be backed up so you have the DB structure.
Now your other issue is due to the way the broker is controled. You are having issues because there is information stored in the toolkit now. You may need to consider backing up the toolkit information which is completely seperate from your configuration manager.
toolkit (Contains development information on your workstation, used only to issue commands to the configuration manager)
|
configuration manager (contains no real information, used only to configure the broker, like a remote control or a terminal)
|
broker (Stores configuration information in a database)
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| pjaffe |
| Posted: Tue Sep 07, 2004 7:15 am Post subject: understanding role of config mgr |
|
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
I am not completely in agreement as to what is stored in config manager. If I recreate a lost config manager by restoring it's database and then open the toolkit and create a connection to it, I can see what was deployed and the execution groups for each broker in the domain. This info must be coming from the config manager because I tried this with a rebuilt broker (simulating a lost config mgr and broker but without restoring the broker database) and all the info came back. My problem is that it is not functional so from that perspective you are correct. There is no really "useful" info in the config manager.
I would love to hear how you handle recovering from a lost config manager or broker or both. |
|
| Back to top |
|
|
| PGoodhart |
| Posted: Tue Sep 07, 2004 9:03 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
That information you think is stored is being passed over from the broker to the configuration manager to your toolkit. The old data is cached in your toolkit, it only refreshes the data every so often.
Try stopping an execution group on the broker and see if it is reflected in the toolkit. (it is) Same thing happens if you delete an execution group on the broker. Of course your configuration manager and broker have to be working.
We have the following in our backup/recovery package for the configuration manager:
1. A complete filesystem backup of the configuration manager from a fresh install (this is basically the same as installing the configuration manager/queue manager from scratch, but all the database connections, user ids and other OS level setup is done this way. We use a product called ghost. The configuration manager/queue manager is not created only installed.) We only do this because it's a little faster then running the installs.
2. A script to create the configuration manager for that box.
3. A script to create the queue manager/queue manager objects for that box. Since our configuration managers are dedicated machines this is really pretty simple. We don't run the broker on the same machine.
To recover from a configuration manager loss we:
1. Restore the filesystem.
2. Run the queue manager scripts.
3. Run the configuration manager scripts.
This results in a working configuration manager every time for us. We do not backup the data in the configuration manager database, only the empty structure. We don't even power up our configuration manager in production enviroments unless we are going to do a deploy.
(Best security practice, no power - no hackers)
On the broker we keep copies of everything we deploy (bar files). We have procedures in place to specify one bar file one execution group. We keep scripts to create all the objects, queue managers, and brokers. We back up the queue manager logs as per IBM (persistent messages). We have the database structures backed up for recovery as well. We also have file system backups of all the folders of importance (the ones that contain the users, setup, configuration, operating system, and custom scripts).
Basically we had to be set up to recover on similar hardware anywhere in the world.
The problem you are having may be due to permissions...
I seem to recall seeing that when the configuration manager user id didn't have the right permissions.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| Back to top |
|
|
| pjaffe |
| Posted: Tue Sep 07, 2004 10:26 am Post subject: scripts sound key |
|
|
Novice
Joined: 03 Sep 2004
Posts: 13
|
I don't think that what I tried was that different from what you suggest. I can use some clarification on a couple points.
1. It sounds like you run one flow per execution group. If so, how many flows do you have in production (under a decent volume load - > 1 per second)
2. If you lose your broker and need to recreate - do you use your ghost copy and then run the scripts to create execution groups and deploy the bar files? Are the scripts run at the broker or config manager?
3. If you lose the config manager, how do re-connect the brokers to it so that it is aware of the entire domain? I would think that it should at least be aware of the topology.
4. Is there any chance you can share some of snippets of your scripts for execution groups and BAR deployments? |
|
| Back to top |
|
|
| PGoodhart |
| Posted: Tue Sep 07, 2004 11:13 am Post subject: |
|
|
Master
Joined: 17 Jun 2004
Posts: 278
Location: Harrisburg PA
|
1. We run multiple flows per execution group (One execution group, one primary function, however many flows we need.). We just make sure that we have complete bar packages. (We remove all deployed children before we deploy as a standard practice. So what's in the bar had better have everything in it for that execution group.)
2. We restore the ghost, run the creation scripts, create the execution groups and deploy the bars using the toolkit. You can script more of this... We just don't right now since this way we get confirmation of the recovery. The broker scripts run on the broker. If you script the deploy that runs from the configuration manager.
3. By doing it this way your configuration manager is automatically aware of the broker, after all you just told it what it was going to manage. The topology is automatically updated from the broker....
4. Look at mqsideploy in the broker administration manual. It does what most of what you are looking for... FYI - You can't script the execution group creation, yet.
_________________
Patrick Goodhart
MQ Admin/Web Developer/Consultant
WebSphere Application Server Admin |
|
| 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
|
|
|
|
