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

Unanswered Question

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.3 (3 ratings)
Loading.
Chris Deren Mon, 04/30/2007 - 12:52
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

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

Chris Deren Mon, 04/30/2007 - 13:08
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

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


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


Chris

Chris Deren Mon, 04/30/2007 - 13:20
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

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

Chris Deren Mon, 04/30/2007 - 13:39
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,
  • Cisco Designated VIP,

    2017 IP Telephony, Contact Center, Unified Communications

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

Actions

This Discussion