Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ICM- Avaya architecture 1

Status
Not open for further replies.

Banexx

Programmer
Jun 23, 2005
21
NL
Hello,

Our company is planning to have a second site. We are looking for the best architecture knowing that we are going to use an avaya CM 3.1 and ICM 7. The main point is that the second site must be autonomous in case of network failure on both site. It's ok on avaya side but i would like to know how the PG's on 2nde site will become active when they duplication is broke.
Anyone have an idea of architecture for this.
many thanks in advance
 
Depends how the PGs are installed, if you have split the Avaya across two data centres ICM 7.x allows you to spilt a pair of PG e.g. 1a & 1b across the same site - however you need a dedicated private connection between the PGs.

In this environment if the PG 1a loses connectivity with the Avaya it will check the other side via. this private connection to see if PG 1b can talk to the Avaya, if it can it will fail over and PG 1b will become active. If the site becomes isolated the ICM Router will attempt pretty much the same process with the idle side.

You may experience two minor delays a) the failover itself and b) the newly active PG synchronizing it's data with the Avaya i.e. agent states.

Two other points 1) make sure the private connection adheres to Cisco's design guidance (don't use things like auto-QoS) any problems with the private connection your going to have operational issues in DR scenarios and 2) it's not clear if you are pre or post routing.
 
Thank you adminto for your reply

To answer your question, we will be in post routing mode.
What about splitting rogger and PG on both sites. As we'll be using Avaya S8700 with ESS (One server on each site and one is active while the other is on stanby; configuration is automatically duplicated on the second server. IN DR mode each server takes control of each site)
What I would like is that in case of DR (the WAN between both site is down) the PG on each site registered with the Avaya server on the same site. We'll be then for both site in an simplex ICM mode till the link comes up.
In order to be in that configuration do I need to make a special configuration in the second site such as a secondary PG (specially configured to communicate with the DR S8700 in teh second site )which will be manually actived ?
 
ICM works in a different way to the Ayava at the Rogger there isn't really a concept of passive /active both router processes are active in that they are both reviewing real time data and any db script/config changes you make. This means if the side routing calls goes down there is minimal delay to failover because the other router already has the config running, this presents an issue with what you want to do but not a huge one.

If the WAN is down and both sides of ICM carry on routing calls the loggers will go out of sync, IIRC it's call spilt-brain mode. This means that they may have issues automatically syncing their records when the routers come up. I've not tested it but I assume you would have to stop one Rogger before you brought the WAN back up to stop you hitting this problem, then use the ICMDBA tool to synchronize one side of the logger with the other. The problem with this is you are likely to lose some reporting on whichever site is overwritten, you'll also drop all config. changes made on one site. Your HDSs will have similar issues if you have two distributors set up.

I suspect like most ACD/ICM integrations you pretty much use the ACD reporting rather than webview. So you'll just have to be carefully about the recovery process.

You'll also need to make sure you don't have an issue with the majority PG rule. Whoever is integrating your ICM should be familiar with this.

In this scenario is would probably be wise to put each logger in DB maintenance mode - which stops people making config changes.



 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top