Cisco Cisco Customer Response Solution Downloads Design Guide
2-15
Cisco Unified Contact Center Express Solution Reference Network Design, Release 4.1
Chapter 2 Cisco Unified Contact Center Express Solution Architecture
Unified CCX Fault Tolerance
All ACD, IVR and desktop services will failover within 5 seconds. Any incoming call arriving at Cisco
Unified CallManager destined for CRS route points can be accepted by the CRS engine and all CRS call
treatment and ACD routing services are operational. Automatically logging on large numbers of agents
may take up to 1 minute. For a given agent, the ACD is not able to route calls to agents until the automatic
login process completes and the agent manually sets the state to 'ready.' Agents on Unified CCX routed
calls will see those calls survive and CAD will automatically relog agents back in within one minute,
and they will see a visual indicator that a fail over has occurred. After being logged back in, agents will
have to set the state to ‘ready’ when they are ready to begin receiving calls. Agents using IPPA will need
to manually relogin to the new master CRS Engine server.
Unified CallManager destined for CRS route points can be accepted by the CRS engine and all CRS call
treatment and ACD routing services are operational. Automatically logging on large numbers of agents
may take up to 1 minute. For a given agent, the ACD is not able to route calls to agents until the automatic
login process completes and the agent manually sets the state to 'ready.' Agents on Unified CCX routed
calls will see those calls survive and CAD will automatically relog agents back in within one minute,
and they will see a visual indicator that a fail over has occurred. After being logged back in, agents will
have to set the state to ‘ready’ when they are ready to begin receiving calls. Agents using IPPA will need
to manually relogin to the new master CRS Engine server.
Note
Historical Report generation is done by giving preference to non-Engine master node so that generation
of Historical Reports does not impact the CRS Engine performance. In a two-node scenario where the
CRS Engine and the Database are collocated and the Engine master is on the Database Publisher node,
the Historical Reports are generated on the Database Subscriber node. If the Engine master fails over to
the Database Subscriber node, then the Historical Reports are generated on the Database Publisher node.
of Historical Reports does not impact the CRS Engine performance. In a two-node scenario where the
CRS Engine and the Database are collocated and the Engine master is on the Database Publisher node,
the Historical Reports are generated on the Database Subscriber node. If the Engine master fails over to
the Database Subscriber node, then the Historical Reports are generated on the Database Publisher node.
Database Redundancy
When deploying with High Availability, for Historical Data store, Agent Data store, and Repository Data
store, the two servers running the Database components are set up with one being the Publisher and one
being the Subscriber. These roles do not change in the event of a failure. If both the Publisher and the
Subscriber are up and running, then the server running the Publisher Database component is given DB
mastership, where data is written to and read from. If the server running the Publisher Database
component is down (or any of the SQL Services such as MSSQL$CRSSQL, Distributed Transaction
Coordinator or SQL Agent$CRSSQL on the server with the Publisher Database is down) then the
Subscriber is given the DB mastership, where data is written to and read from. SQL Merge Replication
replicates the data between the Publisher and Subscriber. If the Subscriber or Publisher is down for less
than the retention period (default is 4 days for Hardware with more than 18GB Hard Drive, and it is 2
days for Hardware with smaller 18GB Hard Drive), replication will automatically kick-in to sync data
from the Publisher when the Subscriber comes back in service and vice versa. If the Subscriber is down
for more than the retention period, the Subscriber has to be reinitialized at off-peak hours from the CRS
Administration Datastore Control Center page.
store, the two servers running the Database components are set up with one being the Publisher and one
being the Subscriber. These roles do not change in the event of a failure. If both the Publisher and the
Subscriber are up and running, then the server running the Publisher Database component is given DB
mastership, where data is written to and read from. If the server running the Publisher Database
component is down (or any of the SQL Services such as MSSQL$CRSSQL, Distributed Transaction
Coordinator or SQL Agent$CRSSQL on the server with the Publisher Database is down) then the
Subscriber is given the DB mastership, where data is written to and read from. SQL Merge Replication
replicates the data between the Publisher and Subscriber. If the Subscriber or Publisher is down for less
than the retention period (default is 4 days for Hardware with more than 18GB Hard Drive, and it is 2
days for Hardware with smaller 18GB Hard Drive), replication will automatically kick-in to sync data
from the Publisher when the Subscriber comes back in service and vice versa. If the Subscriber is down
for more than the retention period, the Subscriber has to be reinitialized at off-peak hours from the CRS
Administration Datastore Control Center page.
Under normal call load volume, a latency of 1 to 3 minutes for SQL Merge Replication is expected; this
could be higher for higher call load. The impact could be more when Historical Reports are running as
it impacts the SQL processing. Due to replication latency, the Historical Reports which get generated
from a Subscriber, might not have the latest call records; the Historical Reports will be generated up to
the last replicated time.
could be higher for higher call load. The impact could be more when Historical Reports are running as
it impacts the SQL processing. Due to replication latency, the Historical Reports which get generated
from a Subscriber, might not have the latest call records; the Historical Reports will be generated up to
the last replicated time.
SQL Server “linked server” technique is used to replicate configuration data store data in High
Availability deployments. The way it works is that when both servers with Databases components are
operational, configuration data store changes, such as skills and resource groups, are written to both the
servers with Database components. If one server with a Database component is down, then configuration
data store changes are not possible. However, configurations can be read in CRS Administration; that is,
no configuration data store data writes are possible, but data reads are possible when one server with a
Database component is down. However, call processing, historical data writing, and call activity
reporting can continue even when one Database component is down.
Availability deployments. The way it works is that when both servers with Databases components are
operational, configuration data store changes, such as skills and resource groups, are written to both the
servers with Database components. If one server with a Database component is down, then configuration
data store changes are not possible. However, configurations can be read in CRS Administration; that is,
no configuration data store data writes are possible, but data reads are possible when one server with a
Database component is down. However, call processing, historical data writing, and call activity
reporting can continue even when one Database component is down.
In the case when one of the Database servers is not operational and configuration data store changes are
required, you can temporarily "deactivate" the configuration data store component on the off-line
Database component server using CRS Administration. After that, you can make configuration data store
required, you can temporarily "deactivate" the configuration data store component on the off-line
Database component server using CRS Administration. After that, you can make configuration data store