Cisco Cisco IPCC Web Option Maintenance Manual
Logger Recovery
When a single Logger process fails, the system software continues to operate with the Logger
on the other side. The remaining Logger ensures that output messages continue to reach PGs
and Administration & Data Servers. The Unified ICM’s Message Delivery Service detects the
failure of the Logger and notifies the PGs and Administration & Data Servers, which switch
their active communication paths to the on-line Logger. At this point, both CallRouters are in
service, but only one Logger is available.
on the other side. The remaining Logger ensures that output messages continue to reach PGs
and Administration & Data Servers. The Unified ICM’s Message Delivery Service detects the
failure of the Logger and notifies the PGs and Administration & Data Servers, which switch
their active communication paths to the on-line Logger. At this point, both CallRouters are in
service, but only one Logger is available.
For a single-customer Unified ICM, when the Node Manager detects that the Logger has gone
off-line, it initiates a shutdown and reboot of the machine. In a Cisco Unified Intelligent Contact
Management Hosted environment, the Node Manager does not restart the machine. In this case,
manual intervention is needed to restart the failed Logger.
off-line, it initiates a shutdown and reboot of the machine. In a Cisco Unified Intelligent Contact
Management Hosted environment, the Node Manager does not restart the machine. In this case,
manual intervention is needed to restart the failed Logger.
The Logger’s Node Manager automatically restarts when the machine reboots. Next, the SQL
Server service starts automatically as part of the reboot. SQL Server automatic recovery runs
to ensure that the returning database is consistent and that all transactions committed before the
failure are recorded on disk. Once automatic recovery is completed, the Logger can then go
through the application synchronization and state transfer process. If configuration data in the
on-line database has changed, the state transfer also updates the configuration data in the returning
database. However, in most cases configuration data will not have changed during the failure.
Server service starts automatically as part of the reboot. SQL Server automatic recovery runs
to ensure that the returning database is consistent and that all transactions committed before the
failure are recorded on disk. Once automatic recovery is completed, the Logger can then go
through the application synchronization and state transfer process. If configuration data in the
on-line database has changed, the state transfer also updates the configuration data in the returning
database. However, in most cases configuration data will not have changed during the failure.
Once the two Loggers are returned to synchronized execution, the system software might need
to recover historical data that was accumulated during the off-line period. This process, referred
to as Recovery, is described in the "Database Fault Tolerance" section.
to recover historical data that was accumulated during the off-line period. This process, referred
to as Recovery, is described in the "Database Fault Tolerance" section.
In a double Logger failure (both Loggers are off-line), the CallRouter continues to route calls.
This is possible, even if it is the configuration Loggers that have failed, because the CallRouter
loads configuration data in its program memory at system initialization. In a double Logger
failure scenario, all messages and data that the CallRouter sends to an off-line Logger are
discarded until a Logger is completely recovered.
This is possible, even if it is the configuration Loggers that have failed, because the CallRouter
loads configuration data in its program memory at system initialization. In a double Logger
failure scenario, all messages and data that the CallRouter sends to an off-line Logger are
discarded until a Logger is completely recovered.
Database Fault Tolerance
The Central Controller database provides two major Unified ICM functions:
•
Permanent storage of the data that describes a call routing configuration.
•
Permanent storage for the historical data that is gathered by the Unified ICM system.
Each time a CallRouter starts, it loads configuration data from the central database into its
program memory. Once the configuration data is loaded, the CallRouter can begin to route calls
(even when the central database is not available). Therefore, when a CallRouter fails and restarts,
at least one configuration Logger and central database must be available so that the CallRouter
can load the configuration data into memory.
program memory. Once the configuration data is loaded, the CallRouter can begin to route calls
(even when the central database is not available). Therefore, when a CallRouter fails and restarts,
at least one configuration Logger and central database must be available so that the CallRouter
can load the configuration data into memory.
Administration Guide for Cisco Unified ICM/Contact Center Enterprise & Hosted Release 8.x
25
Chapter 2: Fault Tolerance
Database Fault Tolerance