cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2309
Views
13
Helpful
11
Replies

How to verify the A side and the B side of ICM are in Sync

dtran
Level 6
Level 6

I am running IPCC enterprise 6.0 and I am about ready to move the B side of ICM to our DR location Tx. The B side consists of Rogger B and PG1B and the A side is located in Ca. The B side will be offline for about 10 days.

Can someone please advice what I need to be aware when I bring up the B side in Tx ? How do I verify that the A side and the B side are in sync ?

Any feedback on past experience is highly appreciated !!!!

Thank you very much !!!!

Danny

11 Replies 11

Chris Deren
Hall of Fame
Hall of Fame

Typically when DBs are out of sync side will not come up.

But, as a quick test I would suggest creating sample script or agent and access Logger A and B Database to make sure it present on both.

Chris

Hi Chris ! I appreciate your response !! Do you mean that if the DBs are out of sync then the B side will not come up ?

Do you know of any tools that I can run to resync the DB ?

Thank you very much !!!

Danny

On AW or Roggers, From Program Files --> Run --> icmdba

run this tool, which will allow you to synchronize the DBs.

Chris

Hi Chris ! I appreciate your quick response !!

Do I run ICMDBA on Rogger A or Rogger B ? and Can I run it during production hours ?

Do I need to do the same on the PGs ?

Thank you very much !!

Danny

You can run it from AW or either Rogger, within the tool you specify which DB should be synchronized with which one.

There is no DB on the PG servers, so no need for anything.

Chris

Thank you Chris !!

How do you tell if Rogger B does not come up ?

Danny

All the ICM services need to start, i.e. Router mdsproc, ccpaget, etc. You should see whole bunch of cmd icm services running on the server, if they keep flapping, or the server automitically reboots then they're not staying up.

Also, the pgagent processes on the PG servers should see one side active and the other Idle.

Chris

Few things...

1. Moving your Central Controllers isn't an incredibly complicated event, yet with that said there are a number of area's you can go wrong and since the central controller is the overlying brain for the entire system - that could be painful. Set services to manual before moving, ensure your private network is up and meets latency requirements, QoS is enabled, DNS is updated to new IP's, Hosts files updated, etc - probably another 20 or 25 little things that have to check out prior to bringing them live.

2. If all the planning is done appropriately - ICM will manage the database synch without any interaction. If the database synch doesn't work and your system is exceptionally busy a manual synch may be required but it's rather unlikely. Instead if you use ICMDBA to force a synch - I *highly* suggest doing a config export and backup before anything and checking to make 110% sure that your synchronizing with the right source and destination else you will overwrite your existing config and take a chance that all the updates you've done while the system was in transit would be lost. (why it's much better to let ICM manage the synch).

3. Splitting PG's over a wan has a whole other set of requirements primarily for the private network however it's not the brain of the IPCC system so is a little less of a concern. Since the PG gets it's config from the Call Router and there is no database to worry about it's much less of a concern.

4. To answer the original question - you can go into RTTest and use it to identify system health. If the state size on each side of the system is the 'same' (realizing that RTTest is a real time tool) then you're in sync. If RTTest shows both Routers and Loggers up and running then your ICM would be in Duplex mode and you can be almost certain that your database has synched.

5. Make sure to bring the system up duplex during off hourse just in case something happens that isn't expected. Understand this is common sense but would still put this out here just to cover the base since the last thing anyone wants is unplanned down time :)

Done right this can go very smoothly with no hiccups but it takes a significant amount of time in planning to get to that point.

Best of luck!

Skippy

Hello James ! I appreciate and thank you for such a well-explained response. Do you have any document on how to use the RTTest command or untility that you mentioned ?

Thanks again !!!

Danny

Few links to get you started:

The Cisco ICM rttest Utility

http://www.cisco.com/warp/public/78/45.html

Backing up the ICM Configuration Database using ICMDBA

http://www.ciscosystems.com/en/US/products/sw/custcosw/ps1001/products_tech_note09186a0080192690.shtml

Thanks James ! I appreciate all your help !!!

Danny

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: