Redundancy within a CallManager Cluster
There are two types of redundancy within a CallManager Cluster: database redundancy
and server failover. Database redundancy is achieved by the replication of the
publisher database using the Publisher/Subscriber relationship.This ensures that
the same database is held by all servers within a cluster, which means the database
is accessible even if a server is not operational. Server failover occurs when a
CallManager server being used by an IP Telephony device fails.The device then
uses a predefined alternative server to carry out the required tasks.When the preferred
server becomes available again, the device switches back to using it.
Redundancy is achieved by configuring CallManager redundancy groups, and
then assigning pools of devices to use these groups. A CallManager redundancy
group consists of up to three servers—a primary, secondary, and tertiary. If the
primary server fails, the secondary server is used by a device in an associated
pool, and if the secondary fails, then the tertiary is used. If at any time the primary
server becomes operational again, the devices revert back to using that
www.syngress.com
AVVID Clustering • Chapter 4 107
server. All members of a redundancy group must also be a member of the same
cluster. Figure 4.3 illustrates the relationship between devices in a device pool,
and CallManager servers within a redundancy group.