Cluster Redundancy Designs

Because the IP telephony network is critical to business operation, you should never configure a single Cisco CallManager to support any organization. You should maintain at least two Cisco CallManager servers for the voice network to support the network should one server fail. Smaller organizations (240 users or less) might decide to use Cisco CallManager Express, which operates on an IOS-based router platform. The number of Cisco CallManager servers you use typically depends on the server platform you purchase and your cluster design strategy. Chapter 1, "Introduction to Cisco Unified Communications and Cisco Unified CallManager," discussed the server platforms and the number of phones that each server model supports. This section discusses the proper way to use those server platforms to build a Cisco CallManager cluster.

1:1 Redundancy Design

In a 1:1 Cisco CallManager redundancy deployment design, you can have a dedicated backup server for each primary server. This design guarantees that Cisco IP Phone registrations will never overwhelm the backup servers, even if multiple primary servers fail. However, the 1:1 redundancy design considerably limits the maximum cluster size and can be cost-intensive for the initial Cisco CallManager deployment.

Each cluster must also have a designated TFTP server. Depending on the number of devices that a server is supporting, you can combine this TFTP server functionality with the publisher or subscriber Cisco CallManager servers, or you can deploy the TFTP functionality on a separate, standalone server. The TFTP server is responsible for delivering IP Phone configuration files to each telephone, along with streamed media files, such as music on hold (MOH) and ring files; therefore, the TFTP server can experience a considerable network and processor load.

In the example shown in Figure 2-1, a Cisco 7835 Media Convergence Server (MCS) is used because each Cisco CallManager server installed on that platform supports a maximum of 2500 Cisco IP Phones.

Figure 2-1. 1:1 Server Redundancy Design

The shading in the figure divides up the functions performed within a cluster. The lighter shading (outside the Primary/Backup server area) represents the server that is not participating in call processing. This is the SQL publisher server, which is also acting as a TFTP server. In cluster environments with less than 1000 IP Phones, the SQL publisher can also participate in the call-processing functions. However, in clusters larger than 1000 devices, you should isolate the SQL publisher because it will be quite busy handling updates to the SQL database and TFTP requests.

The darker shaded box (containing the Primary/Backup servers) represents Cisco CallManager servers handling the call-processing functions (intracluster run-time data) of the cluster. In the example showing cluster design for 2500 IP Phones, a single Cisco CallManager is the primary server, with a secondary server acting as a dedicated backup. The primary or backup server can also serve as the Microsoft SQL publisher and the TFTP server in smaller IP telephony deployments.

Tip

Be sure you understand how the two types of intracluster communication apply to the Cisco CallManager cluster design. The publisher and subscriber relationship relates to the SQL database replication. The Primary and Secondary server roles (shown in Figure 2-1 as Primary and Backup) relate to the intracluster run-time relationship and device registration. The Primary and Backup servers will be SQL subscribers if you isolate the SQL publisher from call-processing functions.

When you increase the number of IP Phones, you must increase the number of Cisco CallManager servers that are required to support the telephones. Some network engineers might consider the 1:1 redundancy design excessive because a well-designed network is unlikely to lose more than one primary server at a time. With the low possibility of server loss and the increased server cost, many network engineers elect to use a 2:1 redundancy design. However, other engineers choose to deploy the 1:1 redundancy to ensure maximum uptime of the IPT network. In addition, you can load-balance your IP Phones between the primary and backup servers in a 1:1 redundancy design. If any one server fails, only half of the phones must failover to the backup server (which provides a faster failover process).

2:1 Redundancy Design

In a 2:1 Cisco CallManager redundancy deployment design, you have a backup server shared between every two primary servers, as shown in Figure 2-2. Although this design offers some redundancy, there is the risk of overwhelming the backup server if multiple primary servers fail. In addition, upgrading the Cisco CallManager servers can cause a temporary loss of service because you must reboot the Cisco CallManager servers after the upgrade is complete.

Figure 2-2. 1:2 Server Redundancy Design

Note

Figure 2-2 assumes that each Cisco CallManager server can support a maximum of 2500 IP Phones.

Network administrators use this 2:1 redundancy model in most IP telephony deployments because of the reduced server costs. If you are using a Cisco MCS 7835 (shown in the figure), that server is equipped with redundant, hot-swappable power supplies and hard drives. When you properly connect and configure these servers, it is unlikely that multiple primary servers will fail at the same time, which makes the 2:1 redundancy model a viable option for most businesses.

Because of tight budgets, some network administrators are forced into 3:1 and even 4:1 redundancy designs (three or four primary servers supported by a single backup server). Cisco does not support these designs because of the high risk involved.

Tip

The Cisco CallManager architecture limits a cluster to nine servers (one publisher and eight subscribers) that have access to the SQL database. Only these servers can participate in call-processing functions. The redundancy model and server platform you choose has a huge impact on the total size of your Cisco CallManager cluster. Although it might be possible to create a cluster capable of supporting a tremendous amount of IP Phones by minimizing redundancy, Cisco TAC only supports a maximum cluster size of 30,000 IP Phones. If you reach this maximum cluster size, you will need to divide your network into multiple clusters.