-
Cisco CallManager System Guide, Release 3.1(2)
-
Index
-
Preface
-
Introduction
-
Cisco IP Telephony Overview
-
System Configuration Overview
-
System-Level Configuration Settings
-
Clustering
-
Redundancy
-
Call Admission Control
-
Cisco TFTP
-
Device Support
-
Services
-
Auto-Registration
-
Partitions and Calling Search Spaces
-
Understanding Route Plans
-
Understanding the LDAP Directory
-
Managing User Directory Information
-
Media Resource Management
-
Conference Bridges
-
Transcoders
-
Music On Hold
-
Media Termination Points
-
Catalyst DSP Resources for Transcoding and Conferencing
-
SMDI Voice Mail Integration
-
Cisco Unity Messaging Integration
-
Cisco uOne Voice Messaging Integration
-
Cisco DPA Integration
-
Call Park
-
Call Pickup and Group Call Pickup
-
Cisco IP Phone Services
-
Extension Mobility and Phone Login Features
-
Understanding Cisco WebAttendant
-
Custom Phone Rings
-
Understanding Voice Gateways
-
Cisco IP Phones
-
Computer Telephony Integration
-
Administrative Tools Overview
-
Administrative Accounts and Passwords
-
FeedbackTable Of Contents
Cluster Configuration Checklist
Where to Find More Information
Clustering
The clustering feature of Cisco CallManager provides a mechanism for seamlessly distributing call processing across the infrastructure of a converged IP network. Clustering facilitates redundancy, provides transparent sharing of resources and features, and enables system scalability.
This section covers the following topics:
•
Cluster Configuration Checklist
•
Clusters
A cluster consists of a set of Cisco CallManager servers that share the same database and resources. You can configure the servers in a cluster in various ways to perform the following functions:
•
•
•
•
•
When you install the Cisco CallManager software on servers, you specify which servers and which Cisco CallManagers belong to the same cluster. You also specify which server performs which function for the cluster. You can dedicate a particular server to one function or combine several functions on one server, depending on the size of your system and the level of redundancy you want.
Each cluster can have only one database publisher and one TFTP server (either separate or combined). Other servers in the cluster subscribe to the publisher database maintain their own local copies of it. Figure 5-1 illustrates a simple cluster containing three Cisco CallManagers.
For details on cluster size and recommended configurations, refer to the Cisco IP Telephony Network Design Guide.
Figure 5-1 A Cluster with Three Cisco CallManagers
Intracluster Communication
Two primary types of communication occur within a Cisco CallManager cluster. The first type of intracluster communication provides a mechanism for distributing the database that contains all the device configuration information. When you make configuration changes in Cisco CallManager Administration, the publisher server initially stores those changes in its local database. The publisher then sends the new data to all the subscriber servers in the cluster, so that they can update their local copies of the database. This mechanism ensures that the configuration database remains consistent across all servers in the cluster. It also provides database redundancy because the subscriber servers can continue to operate from their local copies of the database even if the publisher becomes unavailable for any reason.
The second type of intracluster communication involves the propagation and replication of run-time data such as registration of IP phones, gateways, and digital signal processor (DSP) resources. All servers in the cluster share this run-time data, thus ensuring optimum routing of calls between members of the cluster and associated gateways.
Redundancy
Clusters facilitate two types of redundancy in the IP telephony network:
•
•
As already mentioned, database redundancy involves the replication of the publisher database across all servers in the cluster. Servers can continue to operate from their own local copies of the database even if they lose communication with the publisher.
The failover and failback mechanism in Cisco CallManager provides call-processing redundancy for devices such as IP phones and gateways. You can configure your system for the level of redundancy you want by using Cisco CallManager groups. A group designates a prioritized list of up to three Cisco CallManagers: a primary, a secondary, and a tertiary. You also configure device pools to assign specific devices to one of the Cisco CallManager groups in a cluster.
During normal operation, each device registers with the primary Cisco CallManager in its assigned group. If the primary Cisco CallManager fails for any reason, all devices in the group failover to the secondary Cisco CallManager for that group. If the secondary Cisco CallManager also fails, the devices failover to the tertiary one. When normal operation resumes, the devices fail back to the primary Cisco CallManager.
You can configure Cisco CallManager groups and device pools in various ways to provide the level of redundancy and load balancing you want in a cluster. For examples and recommendations on redundancy configurations, refer to the Cisco IP Telephony Network Design Guide.
Intercluster Communication
In large systems, you might have to configure more than one cluster to handle the call processing load. Communication between the clusters occurs by means of intercluster trunks using H.323 protocol. Most large systems use one of three main types of multicluster configurations:
•
•
•
Because intercluster trunks in a MAN usually have sufficient bandwidth, they do not require any call admission control mechanism. Multisite WANs with distributed call processing typically use gatekeeper technology for call admission control. Multisite WANs with centralized call processing can use the locations feature in Cisco CallManager to implement call admission control.
Most features of Cisco CallManager do not extend beyond a single cluster, but the following features do exist between clusters:
•
•
•
•
•
•
•
For more information about intercluster communication and call admission control, refer to the Cisco IP Telephony Network Design Guide.
Balanced Call Processing
After installing the Cisco CallManagers that form a cluster, you can balance the call processing load across the system by distributing the devices (such as phones and gateways) among the various Cisco CallManagers in the cluster. To distribute the devices, you configure Cisco CallManager groups and device pools and then assign the devices to the device pools in a way that achieves the type of load balancing you want.
Cisco CallManager groups and device pools are logical groupings of devices that you can arrange in any way you want. For ease of administration, make sure all the devices in a group or pool share a common and easily identified characteristic, such as their physical location on the network.
You can also use Cisco CallManager groups to establish redundancy (backup call processors) for the primary Cisco CallManager in the group. A Cisco CallManager group is an ordered list of up to three Cisco CallManager servers. During normal operation, the first (primary) Cisco CallManager in the group controls all device pools and devices assigned to that group. If the primary Cisco CallManager in a group fails, control of the device pools and devices registered with the primary Cisco CallManager transfers to the next Cisco CallManager in the group list.
For example, assume a simplified system consisting of three Cisco CallManagers in a cluster, with 300 existing Cisco IP phones and provisions to auto-register new phones as they are added later. Figure 5-2 shows one possible way to configure the Cisco CallManager groups and device pools to distribute the call processing load for this system.
•
•
•
•
Figure 5-2 represents a balanced system because each Cisco CallManager in the cluster handles only a portion of the call processing load for the entire system. The system in Figure 5-2 also balances redundancy by splitting the call processing load of a primary Cisco CallManager between two redundancy groups. For example, if CCM1 fails, all the devices in device pool DP1 failover to CCM2, and the devices in DP2 failover to CCM3.
Figure 5-2 Cisco CallManager Groups and Device Pools
Cluster Configuration Checklist
Table 5-1 provides an overview of the steps required to install and configure a Cisco CallManager cluster.
Table 5-1 Cluster Configuration Checklist
Step 1
Install the servers and other hardware required for the cluster.
Refer to the installation documentation for the hardware components you are installing.
Step 2
Gather the information you need to install Cisco CallManager and any other software applications on the servers. Also, determine how you will allocate the servers in the cluster.
Cisco IP Telephony Network Design Guide
Installing Cisco CallManager Release 3.1
Cisco IP IVR Installation Guide
Step 3
Install Cisco CallManager and any additional software applications on the servers.
Installing Cisco CallManager Release 3.1
Cisco IP IVR Installation Guide
Step 4
Configure Cisco CallManager groups to provide the desired level of redundancy for device failover and failback.
Cisco CallManager Group Configuration, Cisco CallManager Administration Guide
Step 5
Configure device pools and use them to assign specific devices to a Cisco CallManager group.
Device Pool Configuration, Cisco CallManager Administration Guide
Step 6
If you are using an intercluster trunk, install and configure it as an H.323 device.
Cisco IP Telephony Network Design Guide
Adding a Cisco IOS H.323 Gateway or Intercluster Trunk
H.323 Gateway and Intercluster Trunk Configuration Settings, Cisco CallManager Administration Guide
Step 7
If you want to provide call admission control for an intercluster trunk, configure either a gatekeeper or Cisco CallManager locations.
Cisco IP Telephony Network Design Guide
Gatekeeper Configuration, Cisco CallManager Administration Guide
Location Configuration, Cisco CallManager Administration Guide
Where to Find More Information
Related Topics
•
•
•
•
•
Additional Cisco Documentation
•
•
•
