Cisco Cisco IP Contact Center Release 4.6.1 Leaflet
3-39
Cisco Unified Contact Center Enterprise 7.5 SRND
Chapter 3 Design Considerations for High Availability
Peripheral Gateway Design Considerations
Unified CCE Scenarios for Clustering over the WAN
Unified CCE can also be overlaid with the Unified CM design model for clustering over the WAN, which
allows for high availability of Unified CM resources across multiple locations and data center locations.
There are a number of specific design requirements for Unified CM to support this deployment model,
and Unified CCE adds its own specific requirements and new failover considerations to the model.
allows for high availability of Unified CM resources across multiple locations and data center locations.
There are a number of specific design requirements for Unified CM to support this deployment model,
and Unified CCE adds its own specific requirements and new failover considerations to the model.
Specific testing has been performed to identify the design requirements and failover scenarios. The
success of this design model relies on specific network configuration and setup, and the network must
be monitored and maintained. The component failure scenarios noted previously (see
success of this design model relies on specific network configuration and setup, and the network must
be monitored and maintained. The component failure scenarios noted previously (see
) are still valid in this model, and the additional failure scenarios for this
model include:
•
•
•
•
Note
The terms public network and visible network are used interchangeably throughout this document.
Scenario 1: Unified ICM Central Controller or Peripheral Gateway Private Network Failure
In clustering over the WAN with Unified CCE, there should be a separate private network connection
between the geographically distributed Central Controller (Call Router/Logger) and the split Peripheral
Gateway pair to maintain state and synchronization between the sides of the system.
between the geographically distributed Central Controller (Call Router/Logger) and the split Peripheral
Gateway pair to maintain state and synchronization between the sides of the system.
To understand this scenario fully, a brief review of the ICM Fault Tolerant architecture is warranted. On
each call router, there is a process known as the Message Delivery Service (MDS), which delivers
messages to and from local processes such as router.exe and which handles synchronization of messages
to both call routers. For example, if a route request comes from the carrier or any routing client to side A,
MDS ensures that both call routers receive the request. MDS also handles the duplicate output messages.
each call router, there is a process known as the Message Delivery Service (MDS), which delivers
messages to and from local processes such as router.exe and which handles synchronization of messages
to both call routers. For example, if a route request comes from the carrier or any routing client to side A,
MDS ensures that both call routers receive the request. MDS also handles the duplicate output messages.
The MDS process ensures that duplex ICM sides are functioning in a synchronized execution, fault
tolerance method. Both routers are executing everything in lockstep, based on input the router receives
from MDS. Because of this synchronized execution method, the MDS processes must always be in
communication with each other over the private network. They use TCP keep-alive messages generated
every 100 ms to ensure the health of the redundant mate or the other side. Missing five consecutive TCP
keep-alive messages indicates to Unified ICM that the link or the remote partner system might have
failed.
tolerance method. Both routers are executing everything in lockstep, based on input the router receives
from MDS. Because of this synchronized execution method, the MDS processes must always be in
communication with each other over the private network. They use TCP keep-alive messages generated
every 100 ms to ensure the health of the redundant mate or the other side. Missing five consecutive TCP
keep-alive messages indicates to Unified ICM that the link or the remote partner system might have
failed.
When running duplexed ICM sides as recommended for all production system, one MDS will be the
enabled synchronizer and will be in a paired-enabled state. Its partner will be the disabled synchronizer
and is said to be paired-disabled. Whenever the sides are running synchronized, the side A MDS will be
the enabled synchronizer in paired-enabled state. Its partner, side B, will be the disabled synchronizer
and paired-disabled state. The enabled synchronizer sets the ordering of input messages to the router and
also maintains the master clock for the ICM system.
enabled synchronizer and will be in a paired-enabled state. Its partner will be the disabled synchronizer
and is said to be paired-disabled. Whenever the sides are running synchronized, the side A MDS will be
the enabled synchronizer in paired-enabled state. Its partner, side B, will be the disabled synchronizer
and paired-disabled state. The enabled synchronizer sets the ordering of input messages to the router and
also maintains the master clock for the ICM system.
If the private network fails between the Unified ICM Central Controllers, the following conditions
apply:
apply:
•
The Call Routers detects the failure by missing five consecutive TCP keep-alive messages. The
currently enabled side (side A in most cases) transitions to an isolated-enabled state and continues
to function as long as it is in communication with at least half of the PGs configured in the system.
currently enabled side (side A in most cases) transitions to an isolated-enabled state and continues
to function as long as it is in communication with at least half of the PGs configured in the system.