Maintenance Manual

2-11
Cisco ICM Enterprise Edition Administrator Guide Release 6.0(0)
Chapter 2 Fault Tolerance
Central Controller
(indicated by a dotted line). ICM software sends heartbeats (brief periodic
messages) over the idle path to ensure that it can still be used in the event that the
active path fails.
Synchronization and State Transfer
In synchronized execution, duplicated processes are always processing identical
input and generating identical output. If one process fails, the other continues to
operate without interrupting system operation. Once the failed process returns, it
is immediately updated with the current state of ICM processes running on its
peer.
In order to synchronize one peer with another after a failure, the system performs
a state transfer. The state transfer facility allows a synchronized process (for
example, a CallRouter) to copy the variables in its memory to its peer. The
recovering system receives the variables from the currently executing system and
is able to restart with a copy of the current state of ICM processes. For example,
as soon as a failure is detected on the Side A CallRouter, ICM software uses only
Side B. When the Side A CallRouter is restarted, ICM software invokes a state
transfer to immediately update the Central Controller Side A components with the
current state of their counterparts on Side B.
In order to better understand synchronization and state transfer, it might help to
take a closer look at CallRouter and Logger recovery.
CallRouter Recovery
When a single CallRouter process fails for any reason, ICM software continues to
operate without any loss of functions by using the other side of the Central
Controller. All attached devices (PGs, NICs, and Admin Workstations) switch
their active communications paths to the remaining side. This ensures that devices
such as PGs continue to receive CallRouter output through the active CallRouter
on the other side of the system.
As a consequence of the CallRouter failure, the entire side of the Central
Controller is removed from service. The Logger and Database Manager
associated with the failed CallRouter see no further inputs (and will not until the
failed CallRouter is restored to full operation). All components on the failed side