| Author |
Message
|
| PeterPotkay |
 Posted: Wed Apr 06, 2005 2:06 pm Post subject: Configuration Manager HA and/or DR? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Do any of you guys make your Config Manager HA/DR? If no, what is the plan if the server that runs the config manager goes away (fire, flood, Godzilla)?
How do you get your deploys going again if the Brokers are "registered" to the original Config Manager that is gone?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Apr 06, 2005 3:21 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Particularly these days, when the ConfigMgr is not also a source control repository, I recommend only making db backups of the ConfigMgr DB - or making the DB HA/DR. If the box dies, recreate the ConfigMgr, and then overwrite the database. (Or is that the other way around?)
But, as always, the manuals should cover backup/recovery situations.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 06, 2005 3:24 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I haven't been able to find anything in the manuals.
Hmmm, if we copy all the Config Manager (called CNFGMGR1) DBs from Server1, we should be able to create CNFGBR1 on Server2, overlay all the DBs, repoint the SNDR channels from the Brokers, and be good to go?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 06, 2005 3:32 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Yes.
But again, it might be that you create/restore the database, and then build the configmgr.
Yeah, it looks like they have completely removed all useful administrative documentation other than "These are the commands".
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed Apr 06, 2005 11:33 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
I can confirm I have used the procedure to restore the configmanager db's on another machine, then create the configmanager using those db's and off you go.
(the db's hold the UUID of the broker so you won't have a problem re-connecting)
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Apr 07, 2005 4:21 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If you back up the Config Manager DBs on Day 1, do deploys on Days 2, 3 and 4, and the server is gone on Day 5, is the backup from Day 1 still good to use? Or do deploys write something to those DBs everytime that must also be restored if you hope to be back up and running on the second Config Manager server? In other words, how often do I need to back up those Config Manager DBs? After every deploy? Or just once after the initial creation?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqmatt |
| Posted: Fri Apr 08, 2005 12:59 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
Whenever the CM receives deploy responses or start/stop messages from the broker, its database is updated with the state reported.
So ideally you would need to back up the CM database after every deploy, and (arguably) when flows are started and stopped! Otherwise, if you have to restore the CM database the tools will not immediately report the correct state.
In this case, a redeploy of the affected artefacts and/or waiting till the next state change message from the broker will fix things.
-Matt |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Apr 08, 2005 1:53 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| mqmatt wrote: |
In this case, a redeploy of the affected artefacts and/or waiting till the next state change message from the broker will fix things.
-Matt |
So waiting for this State Change message from my brokers would insure the ToolKits connected to the Config Manager after we recreated it and overlayed the DBs with the backups taken last would leave us in a full functional state?
How long before the Brokers do that?
Would a deploy of a test flow to a dummy Execution Group speed it up?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqmatt |
| Posted: Fri Apr 08, 2005 6:05 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
| Quote: |
So waiting for this State Change message from my brokers would insure the ToolKits connected to the Config Manager after we recreated it and overlayed the DBs with the backups taken last would leave us in a full functional state?
How long before the Brokers do that?
Would a deploy of a test flow to a dummy Execution Group speed it up? |
Unfortunately only the affected resources are updated in these broker notifications.
So if you restored a Config database that contained, say, incorrect run state of some message flows, then only when each message flow is subsequently started or stopped will its status begin getting reported correctly again ...as you'd kind of expect. So a stop and start of your domain objects will usually sort things out.
If you've deployed new message flows since the backup was taken, the best approach is to remove the deployed children in the affected brokers or execution groups and redeploy. 
HTH
-Matt |
|
| Back to top |
|
|
| anderc1 |
| Posted: Fri Apr 08, 2005 7:32 am Post subject: Restoring CM & MR database |
|
|
Acolyte
Joined: 11 Sep 2002
Posts: 55
Location: Research Triangle Park, NC
|
| You guys are on the subject I'm dealing with and I hope you don't mind me jumping off into something basic, which is backing up and restoring the ConfigMgr databases. I am not a dba but since I have to support WMQI I get to deal with db2 by default. Using db2 Control Center I can back up the CM and MR databases to local or remote systems and restore to the same ConfigMgr db's with no problem. What I can't do is take a backup of the MR or CM databases and restore them to a system that contains db's with the same names. That is take production system backups and restore them to a DR box. The restore balks on having an existing db with the same name or it balks with the backup I'm trying to use, wrong date and time stamp. I guess a switch to just overwrite the database or a switch to use the backup I want you to use is too simple. Tried using the command line using replace existing and it balked on the backup date and time stamp. I know the history file is screwing with me but don't know how to deal with that either. How do you guys backup and restore the db's for DR purposes? db2 v7.2 w/fixpack 11. |
|
| Back to top |
|
|
| Tibor |
| Posted: Sat Apr 09, 2005 1:10 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
Peter,
We planned a simple but powerful  model for DR: we use virtual machines inside VMWare GSX. In this case we have:
- 1 windows 2000 server with vmware and db2 server
- 4 virtual windows 2000 workstation, each one is running: configmgr + mq + db2 client.
Every midnight a scheduled task stops all of virtual hosts and starts a backup for the image files and db2 databases. This is not a local backup that's why when we would process a disaster recovery the prerequisites only these: vmware and db2 (on windows or linux platform).
Tibor |
|
| Back to top |
|
|
| mqmatt |
| Posted: Sat Apr 09, 2005 1:51 am Post subject: |
|
|
Grand Master
Joined: 04 Aug 2004
Posts: 1213
Location: Hursley, UK
|
And of course, VMWare also allows you to have multiple Config Managers per machine, and to host the Config Manager on a machine other than Windows 
-Matt |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Apr 09, 2005 4:01 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Well now, as luck would have it, my Config Managers are on VMWare images.
Someone on the list serve mentioned the same thing. Don't mess with backing up the DBs only, backup the whole image to DVD. This satisfys DR. We get HA because if the primary host VMWare server has a problem, VMotion will move the OS instantly to the secondary host server in the same Data Center. VMotion cannot fly the guest OS to our back up dtata center automatically, the distance is to great.
If this backup of the entire image works, it would be ideal. So then we are back to the problem of how often.
Tibor, you do it every night, which is doable for us. Or we could just do it manually after every deploy - we only deploy every couple of weeks at the most. Not 100% clear on what you do. You have 4 workstations with 4 different config managers. At Midnight, you back up the entire image - and put it where? If you are backing up the entire image, why do you also back up the DB2? Isn't it included in the VMwAre image?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Tibor |
| Posted: Sun Apr 10, 2005 6:52 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
| Quote: |
| Tibor, you do it every night, which is doable for us. Or we could just do it manually after every deploy - we only deploy every couple of weeks at the most. |
This is fully automatic at every midnight, becaue I'm a lazy guy
| Quote: |
| Not 100% clear on what you do. You have 4 workstations with 4 different config managers. At Midnight, you back up the entire image - and put it where? If you are backing up the entire image, why do you also back up the DB2? Isn't it included in the VMwAre image? |
DB2 server is not included the vmware, because in we have no DB2 knowledge and this is effectively simpler than managing 4 databases server.
Tibor |
|
| Back to top |
|
|
|
|
