The Two Sides of the Cisco Unified CallManager Cluster

Table of contents:

As a network administrator, you are accustomed to quite a bit of fiscal responsibility riding on your shoulders. Under the Cisco Unified Communications architecture, that responsibility has grown exponentially. Not only are you responsible for the operation of the data environment; you are now responsible for the company's voice network, which rides on top of this infrastructure. This voice network is critical to day-to-day business operations. Because of this, you should approach it just like any key network service: the more redundancy, the better.

A Cisco CallManager cluster is two or more servers grouped together to support a Cisco IP telephony network. The cluster relationship between Cisco CallManager servers provides redundancy and load balancing for the voice network. Cisco defines this cluster relationship in two ways: the SQL database structure and the intracluster run-time data.

The SQL Database Cluster

As discussed in Chapter 1, Cisco CallManager relies on Microsoft SQL 2000 as an information store for the data of the voice network. This data includes the phone extensions on the network, calling restrictions, route plan information, and so on. The database replication capability provided by Microsoft SQL Server makes clustering possible by allowing the same database to be on multiple machines. Database replication makes it appear as if a single machine is handling call processing along with other functions of the voice network and ensures that standby processors (Cisco CallManager servers) can seamlessly step in and fulfill the functions if the primary processor fails. This SQL database replication also ensures that all clustered Cisco CallManager servers have access to the same information.

You must have at least two Cisco CallManager servers to obtain this redundancy, and one of these servers must be a publisher database server. The publisher database server manages the only writable copy of the Microsoft SQL Server 2000 database. The subscriber database servers maintain read-only copies of the database. You can have only one publisher server and up to eight subscriber servers per cluster. It is these database servers that are able to actively participate in the call-processing functions of the Cisco voice network. This SQL limitation is also a key factor in determining the maximum size of a cluster, which is covered later in this chapter.

When you make changes to the Cisco CallManager configuration, these changes are made directly to the publisher server database. The publisher then replicates these changes to the subscriber servers. When the publisher server is offline, the Microsoft SQL Server 2000 database automatically locks, and thus prevents any database changes. The IP telephony network continues to operate, but you will not be able to add or configure any devices that are managed by Cisco CallManager. The only exception to this rule is the Call Detail Records (CDRs), which record information regarding the calls occurring within the cluster. When the publisher is down, the subscribers store CDRs until the publisher comes back online, and then the subscribers update the publisher with the CDRs.

In Cisco CallManager Release 3.3 and later, a single cluster is capable of handling approximately 30,000 Cisco IP Phones. This cluster limitation does not restrict the size of the voice over IP (VoIP) network. By creating additional clusters, you can increase the network size. However, the more clusters you create in a network, the more management the network requires to operate.


The 30,000 IP Phone maximum cluster size is only possible if you are using the MCS-7845 servers throughout your cluster deployment.


Intracluster Run-Time Data

The second communication method that defines the cluster relationship between Cisco CallManager servers is the intracluster run-time data, which is also called Intra-Cluster Communication Signaling (ICCS). This type of communication encompasses the "happenings" of the cluster. For example, when a new Cisco IP Phone connects to the network, it registers with its primary Cisco CallManager. That primary Cisco CallManager tells all the other servers in the cluster, "Hey everyone, a new phone just registered with me! I've given it the extension 4003." (IP address in this example). All the other servers now know to send calls directed at extension 4003 to the Cisco CallManager at the IP address, which, in turn, makes the Cisco IP Phone ring.

After the initial phone registration, the Cisco IP Phone sends keepalive messages to the primary Cisco CallManager server every 30 seconds and sends a TCP connect message (which is technically a TCP three-way handshake) to its secondary Cisco CallManager server to ensure it is online and ready to accept a device failover, if necessary. When the Cisco IP Phone detects the failure of its TCP keepalive messages with the primary Cisco CallManager, the device attempts to register with a secondary Cisco CallManager server. The secondary Cisco CallManager server accepts the registration from the device and announces the new registration (using intracluster run-time data) to all of the Cisco CallManager servers in the cluster.


If the Cisco CallManager service is ever stopped manually (through the Services Windows 2000 Control Panel or a system shutdown), the Cisco CallManager server will clear all of its active TCP connections with the IP Phones. This causes them to failover immediately to their backup server rather than wait for the keepalive failure.

Cisco IP Phone registration is just one example of intracluster run-time data. You will discover many other types of intracluster communication as this book introduces new concepts in upcoming chapters.

Cluster Redundancy Designs

Part I: Cisco CallManager Fundamentals

Introduction to Cisco Unified Communications and Cisco Unified CallManager

Cisco Unified CallManager Clustering and Deployment Options

Cisco Unified CallManager Installation and Upgrades

Part II: IPT Devices and Users

Cisco IP Phones and Other User Devices

Configuring Cisco Unified CallManager to Support IP Phones

Cisco IP Telephony Users

Cisco Bulk Administration Tool

Part III: IPT Network Integration and Route Plan

Cisco Catalyst Switches

Configuring Cisco Gateways and Trunks

Cisco Unified CallManager Route Plan Basics

Cisco Unified CallManager Advanced Route Plans

Configuring Hunt Groups and Call Coverage

Implementing Telephony Call Restrictions and Control

Implementing Multiple-Site Deployments

Part IV: VoIP Features

Media Resources

Configuring User Features, Part 1

Configuring User Features, Part 2

Configuring Cisco Unified CallManager Attendant Console

Configuring Cisco IP Manager Assistant

Part V: IPT Security

Securing the Windows Operating System

Securing Cisco Unified CallManager Administration

Preventing Toll Fraud

Hardening the IP Phone

Understanding Cryptographic Fundamentals

Understanding the Public Key Infrastructure

Understanding Cisco IP Telephony Authentication and Encryption Fundamentals

Configuring Cisco IP Telephony Authentication and Encryption

Part VI: IP Video

Introducing IP Video Telephony

Configuring Cisco VT Advantage

Part VII: IPT Management

Introducing Database Tools and Cisco Unified CallManager Serviceability

Monitoring Performance

Configuring Alarms and Traces

Configuring CAR

Using Additional Management and Monitoring Tools

Part VIII: Appendix

Appendix A. Answers to Review Questions


Authorized Self-Study Guide Cisco IP Telephony (CIPT)
Cisco IP Telephony (CIPT) (Authorized Self-Study) (2nd Edition)
ISBN: 158705261X
EAN: 2147483647
Year: 2004
Pages: 329 © 2008-2020.
If you may any questions please contact us: