C H A P T E R

Sizing Cisco CallManager Servers For IPCC

This chapter discusses the concepts, provisioning, and configuration of Cisco CallManager clusters when used in an IPCC Enterprise environment. Cisco CallManager clusters provide a mechanism for distributing call processing across a converged IP network infrastructure to support IP telephony, facilitate redundancy, and provide feature transparency and scalability. This chapter covers only the IPCC Enterprise operation of clusters within both single and multiple campus environments and proposes reference designs for implementation. Before reading this chapter, Cisco recommends that you study the details about the operations of Cisco CallManager clusters presented in the Call Processing chapter of the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at http://www.cisco.com/go/srnd The information in this chapter builds upon the concepts presented in the Cisco IP Telephony SRND. Some duplication is necessary to clearly concepts relating to IPCC as an application supported by the Cisco CallManager call processing architecture. However, the foundational concepts are not duplicated here, and you should become familiar with them before continuing with this chapter. This chapter documents general best practices and scalability considerations for sizing the Cisco CallManager servers used with your IPCC Enterprise deployments. Within the context of this document, scalability refers to Cisco CallManager server and/or cluster capacity when used in the IPCC Enterprise environment.

Call Processing With IPCC Enterprise

Before applying the guidelines presented in this chapter, you should perform the following steps, which will have an impact on the Cisco CallManager cluster scalability:

Determine customer call center application requirements (IP IVR, ISN, outbound, multi-channel, and so forth). Determine the types of call center resources and devices used in IPCC Enterprise (route points, CTI ports, and so forth):
Number of required IPCC Enterprise agents Number of required IP IVR CTI ports or ISN ports (or sessions) Number of CTI route points (ICM route points and IVR route points) Number of PSTN trunks Estimated busy hour call attempts (BHCA) for all agents and devices mentioned above (Inbound

or outbound?)

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-1

Chapter 6 IPCC Clustering Guidelines

Sizing Cisco CallManager Servers For IPCC

Percent of conferenced and/or transferred calls

Determine the required deployment model (single site, centralized, distributed, clustering over the WAN, or remote branches within centralized or distributed deployments). Determine the placement of solution components in the network (gateways, agents, ISN, and so forth). Determine the different types of call flows and call disposition, such as:
Simple call flow (IVR self-service or direct agent transfer without any IVR call treatment)

Simple call flows are those that do not involve multiple call handling (for example, IVR self-service, incoming calls from a gateway directly to a phone, internal calls, and so forth).
Complex call flow (IVR call treatment or database lookup prior to agent transfer, call

redirection to a route point, CTI route point, CTI ports, agent-to-agent transfer and conference, or consultation or conference from an agent to a skill group) Complex call flows are those that involve multiple call redirects and call handling of the original call (for example, incoming calls to central route points redirected to CTI route points and then to IP IVR for call treatment, then transferred or redirected to another target such as an agent). These multiple call processing segments of the original call consume more CPU resources compared to simple call handling.

IPCC Clustering Guidelines

The following guidelines apply to all Cisco CallManager clusters with IPCC Enterprise.
Note

A cluster may contain a mix of server platforms, but all servers in the cluster must run the same Cisco CallManager software release and service pack. The publisher server should be of equal or higher capability than the subscriber servers. (See Table 6-2.)

Devices (including phones, music on hold, route points, gateway ports, CTI ports, JTAPI Users, and CTI Manager) should never reside or be registered on the publisher. Any administrative work on Cisco CallManager will impact call processing and CTI Manager activities if there are any devices registered with the publisher. Do not use a publisher as a failover or backup call processing server unless you have fewer than 50 agent phones and the installation is not mission critical or is not a production environment. The Cisco MCS-7825H-3000 is the minimum server required. Any deviations will require review by Cisco Bid Assurance on a case-by-case basis. Any deployment with more than 50 agent phones requires a minimum of two subscriber servers and a combined TFTP and publisher. If you require more than one primary subscriber to support your configuration, then distribute all agents equally among the cluster nodes. This assumes BHCA is uniform across all agents (average BHCA processed is about the same on all nodes). Similarly, distribute all gateway ports and IP IVR CTI ports equally among the cluster nodes. If you require more than one ICM JTAPI user (CTI Manager) and more than one primary subscriber, then group and configure all devices monitored by the same ICM JTAPI User (third-party application provider), such as ICM route points and agent devices, in the same server if possible.

Cisco IP Contact Center Enterprise Edition SRND

6-2

OL-7279-04

Chapter 6

Sizing Cisco CallManager Servers For IPCC IPCC Enterprise with Cisco CallManager Releases 3.1 and 3.2

If you have a mixed cluster with IPCC and general office IP phones, group and configure each type on a separate server if possible (unless you need only one subscriber server). For example, all IPCC agents and their associated devices and resources (gateway ports, CTI ports, and so forth) would be on one or more Cisco CallManager servers, and all general office IP phones and their associated devices (such as gateway ports) would be on other Cisco CallManager servers, as long as cluster capacity allows. In this case, the 1:1 redundancy scheme is strongly recommended. (See Call Processing Redundancy with IPCC, page 6-9, for details) Under normal circumstances, place all servers from the Cisco CallManager cluster within the same LAN or MAN. Cisco does not recommend placing all members of a cluster on the same VLAN or switch. If the cluster spans an IP WAN, you must follow the specific guidelines for clustering over the IP WAN as described in both the section on Clustering Over the WAN, page 2-15 in this guide, and the section on Clustering Over the IP WAN in the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at http://www.cisco.com/go/srnd

For additional Cisco CallManager clustering guidelines, refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide at http://www.cisco.com/go/srnd

IPCC Enterprise with Cisco CallManager Releases 3.1 and 3.2

The following guidelines apply to Cisco CallManager releases 3.1 and 3.2. For specific Cisco CallManager and IPCC supported releases, refer to the Cisco CallManager Compatibility Matrix, available at http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp.htm

Within a cluster, you may enable a maximum of 6 call processing servers (4 primary and 2 backup servers) with the Cisco CallManager Service. Other servers may be used for more dedicated functions such as Trivial File Transfer Protocol (TFTP), database publisher, music on hold, and so forth. You can configure a maximum of 800 Computer Telephony Integration (CTI) connections or associations per server, or a maximum of 3200 per cluster if they are equally balanced among the four primary servers. This maximum would include IPCC agent phones, IP IVR CTI ports, CTI route points, and other CTI devices. Each H.323 device can support up to 500 H.323 calls with Cisco CallManager Release 3.1 or 1000 calls with Cisco CallManager Release 3.2. The default trace setting for Cisco CallManager Release 3.1 or 3.2 is different than the setting for later releases (Cisco CallManager Release 3.3 and later) and typically has a lesser impact on disk I/O. When upgrading to Cisco CallManager Release 3.3 or later, ensure that the installed MCS-7800 Series server is able to handle the maximum rated agent capacity. Servers that do not have the capability to add the battery-backed write cache (BBWC) enabler kit typically are rated at half the capacity of the equivalent server with the BBWC installed. (This does not mean that you can double the agent capacity simply by installing the BBWC because the capacity might be limited by other server resources such as processor speed and memory. BBWC helps reduce disk I/O contention, thus allowing the CPU to process a higher transaction load.)

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-3

Chapter 6 IPCC Enterprise with Cisco CallManager Releases 3.3 and Later

Sizing Cisco CallManager Servers For IPCC

The default trace file location for the Cisco CallManager and signal distribution layer (SDL) is on the primary drive. This trace file should be redirected to the secondary F drive array, and the CTI default trace file location should be directed to the C drive array. This configuration will have the least impact on disk I/O resources.

IPCC Enterprise with Cisco CallManager Releases 3.3 and Later

The following guidelines apply to Cisco CallManager Release 3.3 and later:

Within a cluster, you may enable a maximum of 8 servers with the Cisco CallManager Service, including backup servers. Other (additional) servers may be used for more dedicated functions such as TFTP, publisher, music on hold, and so forth. You can configure a maximum of 800 CTI connections or associations per standard server that does not have battery-backed write cache (BBWC) installed (as defined in Table 6-2), or a maximum of 3200 per cluster, and a maximum of 2000 controlled devices per CTI application if they are equally balanced among all servers (Cisco MCS-7835 server required). You can configure a maximum of 2500 CTI connections or associations per MCS-7845H with battery-backed write cache (BBWC) or equivalent high-performance server (see Table 6-2), or a maximum 10,000 per cluster, and a maximum of 2500 controlled devices per CTI application if they are equally balanced among all servers. Again this maximum would include IPCC agent phones, IP IVR CTI ports, CTI route points, and other third-party application CTI devices configured in Cisco CallManager. Each Cisco CallManager cluster (four primary and four backup subscriber servers) can support up to 2,000 IPCC agents and no more than 60,000 BHCA. The BHCA would be spread equally among the eight call processing servers with 1:1 redundancy. (See Call Processing Redundancy with IPCC, page 6-9, for redundancy schemes.) Each of the eight Cisco CallManager servers (MCS-7845H High Performance Servers with BBWC installed) would support a maximum of 250 agents or 7,500 BHCA. In a failover scenario, the primary server would support a maximum of 500 agents and 15,000 BHCA. These capacities can vary, depending on your specific configuration (simple versus complex call flows), as determined by the Cisco CallManager Capacity Tool. (See Cisco CallManager Capacity Tool, page 6-5.)

Cisco CallManager Platform Capacity Planning with IPCC

Many types of devices can register with a Cisco CallManager, including IP phones, IP IVR ports, voicemail ports, CTI (TAPI/JTAPI) devices, gateways, and DSP resources such as transcoding and conferencing. Each of these devices requires resources from the server platform with which it is registered. The required resources can include memory, processor, and I/O. Each device then consumes additional server resources during transactions, which are normally in the form of calls. A device that handles only 6 calls per hour, such as a standard IP phone, consumes fewer resources than a device handling 30 calls per hour, such as an IPCC agent phone, a gateway port, or an IP IVR port. In prior Cisco CallManager software releases, Cisco has utilized various schemes to calculate the capacity of a system using device weights, BHCA multipliers, and dial plan weights. These simple schemes have been replaced by a capacity tool to allow for more accurate planning of the system. (See Cisco CallManager Capacity Tool, page 6-5.)

Cisco IP Contact Center Enterprise Edition SRND

6-4

OL-7279-04

Chapter 6

Sizing Cisco CallManager Servers For IPCC Cisco CallManager Capacity Tool

Note

If your system does not meet the guidelines in this document, or if you consider the system to be complex (IP Telephony and IPCC mixed with other applications), contact your Cisco Systems Engineer (SE) for proper sizing of the Cisco CallManager cluster.

Cisco CallManager Capacity Tool

The Cisco CallManager Capacity Tool (CCMCT) requires various pieces of information to provide a calculation of the minimum size and type of servers required for a system. The information includes the type and quantity of devices, such as IP phones, gateways, and media resources. For each device type, the Capacity Tool also requires the average bust hour call rate and the average busy hour traffic utilization. For example, if all IPCC phones make an average of 25 calls per hour and the average call lasts 2 minutes, then the BHCA is 25 and the utilization is 0.83. (25 calls of 2 minutes each equals 50 minutes per hour on the phone, which is 50/60 = 0.83 of an hour.) Table 6-1 shows an example of the input for the Capacity Tool.
Table 6-1 Sample Input for Cisco CallManager Capacity Tool

Device or Port
IP Telephony Input

Average Busy Hour Call Rate (BHCA) 4 20 8 8 100 8 20 4 20

Average Busy Hour Traffic Utilization 0.15 0.8 0.3 0.3 0.3 0.8 0.15 0.8 0.8

IP phone Unity connection port CTI port Type #1 (simple call, redirect) CTI port Type #2 (transfer, conference) CTI route point Third-party controlled line Intercluster trunk gateways Intercluster trunks H323 client (phone) H323 gateways H323 gateway DS0s (T1 CAS, T1 PRI, E1 PRI, Analog) MGCP gateways

MGCP gateway DS0s (T1 CAS, T1 PRI, E1 PRI, Analog) 20 MoH (Music on Hold) stream (coresident, maximum of 20 streams) Transcoder MTP resource (hardware, coresident software, or standalone software) Conference resource (hardware, coresident software, or standalone software) Dial plan Directory numbers or lines 20 20 6

0.8 0.8 0.8

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-5

Chapter 6 Cisco CallManager Capacity Tool

Sizing Cisco CallManager Servers For IPCC

Table 6-1

Sample Input for Cisco CallManager Capacity Tool (continued)

Device or Port Route patterns Translation patterns

IPCC Input

Average Busy Hour Call Rate (BHCA)

Average Busy Hour Traffic Utilization

IPCC agents ISN (prompt and collect or queueing) ISN (self-service) CTI ports or IP IVR (prompt and collect or queueing) CTI ports or IP IVR (self-service) CTI route points H323 gateways H323 gateway DS0s (T1 CAS, T1 PRI, E1 PRI, Analog) MGCP gateways

30

0.8

30 30

0.8 0.8

20

0.8 0.8

MGCP gateway DS0s (T1 CAS, T1 PRI, E1 PRI, Analog) 20 % Agent-to-agent transfer % Agent conference
IPCC Outbound

10% 10% 30 30 60 20 20 20 0.8 0.8 0.8 0.8 0.8 0.8

IPCC outbound predictive/preview agents IPCC outbound direct preview agents IPCC outbound dialer ports IPCC outbound IVR ports H.323 gateways H.323 gateway DS0s (T1 CAS, T1 PRI, E1 PRI, analog) MGCP gateways MGCP gateway DS0s (T1 CAS, T1 PRI, E1 PRI, analog)

In addition to the device information, the Cisco CallManager Capacity Tool also requires information regarding the dial plan, such as route patterns and translation patterns. The IPCC input includes entries for agents (inbound and outbound), Internet Service Node (ISN) or IP IVR ports for gateway ports, and percent of total calls that are transferred and/or conferenced. When all the details have been entered, the Cisco CallManager Capacity Tool calculates how many servers of the desired server type are required, as well as the number of clusters if the required capacity exceeds a single cluster. At this time, the Cisco CallManager Capacity Tool is available to all Cisco employees and partners at http://www.cisco.com/partner/WWChannels/technologies/resources/CallManager/

Cisco IP Contact Center Enterprise Edition SRND

6-6

OL-7279-04

Chapter 6

Sizing Cisco CallManager Servers For IPCC Supported Cisco CallManager Server Platforms for IPCC Enterprise

Supported Cisco CallManager Server Platforms for IPCC Enterprise

Table 6-2 lists the general types of servers you can use with IPCC Enterprise in a Cisco CallManager cluster, along with their main characteristics.
Table 6-2 Types of Cisco CallManager Servers that Support IPCC

Server Type Standard server: MCS-7825H

Characteristics

IPCC Enterprise Recommendation1 Up to a maximum of 100 agents (Not recommended for mission-critical call centers above 50 agents) Up to a maximum of 250 agents (Maximum of 125 agents without BBWC installed)

Single processor Single power supply (not hot-swap) Non-RAID hard disk (not hot-swap) Single processor Redundant power supplies (hot-swap) Redundant SCSI RAID hard disk array (hot-swap) Dual processors Redundant power supplies (hot-swap) Redundant SCSI RAID hard disk arrays

High-availability standard server: MCS-7835H with BBWC

High-performance server: MCS-7845H with BBWC

Recommended for all mission-critical contact centers up to a maximum of 500 agents (Maximum of 250 agents without BBWC installed)

1. Agent capacities are based on a maximum of 30 BHCA per agent in the busy hour.

The maximum number of IPCC Enterprise agents that a single Cisco CallManager server can support depends on the server platform, as indicated in Table 6-3.
Table 6-3 Maximum Number of IPCC Enterprise Agents per Cisco CallManager (Release 3.3 or Later) Server Platform

Cisco CallManager MCS Server Platform and Equivalent Server Characteristics1

Maximum IPCC High-Availability Agents per Server 2 Platform 3 Yes

High-Performance Server Yes 4

Cisco MCS-7845H-3000 (Dual Prestonia Xeon 3.06 GHz 500 or higher) 4 GB RAM HP DL380-G3 3.06 GHz 2-CPU 3 Cisco MCS-7845H-2400 (Dual Prestonia Xeon 2400 MHz) 4 GB RAM (With the addition of battery-backed write cache, BBWC, installed separately) HP DL380-G3 2400 MHz 2-CPU Cisco MCS-7845H-2400 (Dual Prestonia Xeon 2400 MHz) 4 GB RAM (Without BBWC) HP DL380-G3 2400 MHz 2-CPU Cisco MCS-7835H-3000 (Prestonia Xeon 3.06 GHz) 2 GB RAM (With the addition of battery-backed write cache, BBWC, installed separately) HP DL380-G3 3.06 GHz 1-CPU 250 250 500

Yes

Yes 5

Yes

Yes

Yes

No5

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-7

Chapter 6 Supported Cisco CallManager Server Platforms for IPCC Enterprise

Sizing Cisco CallManager Servers For IPCC

Table 6-3

Maximum Number of IPCC Enterprise Agents per Cisco CallManager (Release 3.3 or Later) Server Platform

Cisco CallManager MCS Server Platform and Equivalent Server Characteristics1

Maximum IPCC High-Availability Agents per Server 2 Platform 3 125 Yes

High-Performance Server No

Cisco MCS-7835H-3000 (Prestonia Xeon 3.06 GHz) 2 GB RAM (Without BBWC) HP DL380-G3 3.06 GHz 1-CPU Cisco MCS-7825H-3000 (Pentium 4, 3.06 GHz) 2 GB RAM HP DL320-G2 3.06 GHz6

100

No

No

1. For the latest information on server memory requirements, refer to Product Bulletin No. 2864, Physical Memory Recommendations for Cisco CallManager Version 4.0 and Later, available at http://www.cisco.com/en/US/products/sw/voicesw/ps556/prod_bulletin0900aecd80284099.html. 2. Agent capacities are based on a maximum of 30 BHCA per agent in the busy hour and failover scenario. 3. A high-availability server supports redundancy for both the power supplies and the hard disks. 4. This server has the battery-backed write cache kit (BBWC) installed. 5. This server does not have the battery-backed write cache kit (BBWC) installed. Without this kit, the capacity would be half the stated limit. The kit must be ordered and installed separately to achieve the maximum stated agent capacity. 6. The maximum number of IPCC agents supported on a single non-high-availability platform (such as the MCS-7825H) is 50 agents in a mission-critical call center. With a redundant configuration, this limit does not apply.

The following notes also apply to Table 6-3:

Agent capacities are based on Cisco CallManager Release 3.3 and later, in failover mode. The maximum number of IPCC agents is 500 with Cisco CallManager Release 3.3 or later, or 250 IPCC agents with Cisco CallManager Release 3.2 or earlier. A single non-high-availability platform supports a maximum of 50 IPCC agents. With a redundant server configuration, this limit does not apply. The Cisco MCS-7845I-3000 is not a supported MCS platform for Cisco CallManager. However, the IBM server equivalent (IBM x345, 3.06 GHz dual CPU) is supported for IPCC deployments as a software only-platform with OS 2000.2.6. The Cisco MCS-7815I-2000 server is a supported Cisco CallManager platform for Cisco IP Telephony deployments only. It is not supported with IPCC Enterprise deployments, but lab or demo setups can use this server. Newer MCS-7835H and MCS-7845H server platforms have the same capacities as shown in Table 6-3.

For the latest information on supported platforms and specific hardware configurations, refer to the online documentation at http://www.cisco.com/en/US/products/hw/voiceapp/ps378/prod_brochure_list.html The capacities outlined in this section provide a design guideline for ensuring an expected level of performance for normal operating configurations. Higher levels of performance can be achieved by disabling or reducing other functions that are not directly related to processing calls. Increasing some of these functions can also have an impact on the call processing capabilities of the system. Some of these functions include tracing, call detail recording, highly complex dial plans and call flows, and other services that are coresident on the server. Highly complex dial plans can include multiple line appearances, many partitions, calling search spaces, route patterns, translations, route groups, hunt groups, pickup groups, route lists, extensive use of Call Forward, coresident services, and other

Cisco IP Contact Center Enterprise Edition SRND

6-8

OL-7279-04

Chapter 6

Sizing Cisco CallManager Servers For IPCC Call Processing Redundancy with IPCC

coresident applications. All of these functions can consume additional memory resources within the Cisco CallManager server. To improve performance, you can install additional certified memory in the server, up to the maximum supported for the particular platform. A Cisco CallManager cluster with a very large dial plan containing many gateways, route patterns, translation patterns, and partitions can take an extended amount of time to initialize when the Cisco CallManager Service is first started. If the system does not initialize within the default time, there are service parameters that can be increased to allow additional time for the configuration to initialize. For details on the service parameters, refer to the online help for Service Parameters in Cisco CallManager Administration.

Call Processing Redundancy with IPCC

With all versions of Cisco CallManager and IPCC, you can choose from the following redundancy configurations:

2:1 For every two primary subscribers, there is one shared backup subscriber. 1:1 For every primary subscriber, there is a backup subscriber.

The 1:1 redundancy scheme allows upgrades with only the failover periods impacting the cluster. Cisco CallManager Release 3.3 and later supports up to eight subscribers (servers with the Cisco CallManager service enabled), so you may have as many as four primary and four backup subscribers in a cluster. The 1:1 redundancy scheme enables you to upgrade the cluster using the following method.
Step 1 Step 2 Step 3

Upgrade the publisher server. Upgrade dedicated TFTP and music on hold (MoH) servers. Upgrade all backup subscribers. This step will impact some users if 50/50 load balancing is implemented. During this step, the Cisco CallManager service is stopped in the backup subscriber, and the devices move to the primary subscriber. Fail-over the primary subscribers to their backups, and stop the Cisco CallManager service on the primaries. All users are on primaries and are moved to backup subscribers when the Cisco CallManager service is stopped. CTI Manager is also stopped, causing the Peripheral Gateway (PG) to switch sides and inducing a brief outage for agents on that particular node. Upgrade the primaries, and then re-enable the Cisco CallManager service.

Step 4

Step 5

With this upgrade method, there is no period (except for the failover period) when devices are registered to subscriber servers that are running different versions of the Cisco CallManager software. This factor can be important because the Intra-Cluster Communication Signaling (ICCS) protocol that communicates between subscribers can detect a different software version and shut down communications to that subscriber. This action could potentially partition a cluster for call processing, but SQL and LDAP replication would not be affected. The 2:1 redundancy scheme allows for fewer servers in a cluster, but it can potentially result in an outage during upgrades. This is not a recommended scheme for IPCC, although it is supported if it is a customer requirement and possible outage of call processing is not of concern to the customer.

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-9

Chapter 6 Cluster Configurations for Redundancy

Sizing Cisco CallManager Servers For IPCC

The 2:1 redundancy scheme enables you to upgrade the cluster using the following method. If the Cisco CallManager service does not run on the publisher database server, upgrade the servers in the following order:
Step 1 Step 2 Step 3

Upgrade the publisher database server. Upgrade the Cisco TFTP server if it exists separately from the publisher database server. Upgrade servers, one server at a time, that have only Cisco CallManager-related services (music on hold, Cisco IP Media Streaming Application, and so on) running on them. Make sure that you upgrade only one server at a time. Make sure that the Cisco CallManager service does not run on these servers. Upgrade each backup server, one server at a time.

Step 4

Note

Cisco does not recommend that you oversubscribe the backup server(s) during the upgrade. Cisco strongly recommends that you have no more than the maximum of 500 IPCC agents registered to the backup server during the upgrade. Cisco strongly recommends that you perform the upgrade during off-peak hours when low call volume occurs.

Step 5

Upgrade each primary server that has the Cisco CallManager service running on it. Remember to upgrade one server at a time. During the upgrade of the second primary subscriber, there will be some outage for users and agents subscribed on that server, until the server is upgraded. Similarly, when you upgrade the fourth primary subscriber, there will be some outage for users and agents subscribed on that server, until the server is upgraded.

Cluster Configurations for Redundancy

Figure 6-1 through Figure 6-5 illustrate typical cluster configurations to provide IPCC call processing redundancy with Cisco CallManager.
Figure 6-1 Basic Redundancy Schemes

2:1 REDUNDANCY SCHEME

1:1 REDUNDANCY SCHEME

Backup
M

M M

Backup Backup

M M

M M

Cost-efficient redundancy Degraded service during upgrades Not Recommended

High availability during upgrades Simplified configuration

126039

Cisco IP Contact Center Enterprise Edition SRND

6-10

OL-7279-04

Chapter 6

Sizing Cisco CallManager Servers For IPCC Cluster Configurations for Redundancy

Figure 6-2

1:1 Redundancy Configuration Options

1 MAX 50 AGENTS Publisher and Backup Subscriber Primary

M M

Publisher and TFTP Server(s) MAX 500 AGENTS Primary Backup

M M

Publisher and TFTP Server(s) MAX 1000 AGENTS Backup Backup

M M

Primary Primary

Publisher and TFTP Server(s) MAX 1500 AGENTS Backup Backup Backup
M M

Publisher and TFTP Server(s) MAX 2000 AGENTS Backup Backup Backup Backup
M M

Primary Primary Primary

Primary Primary Primary Primary

126040

Figure 6-3

2:1 Redundancy Configuration Options

1 MAX 50 AGENTS Publisher and Backup Subscriber Primary

M M

Publisher and TFTP Server(s) MAX 500 AGENTS Primary Backup

M

Publisher and TFTP Server(s) MAX 1000 AGENTS

M

Primary Primary

Backup
M

M M

Publisher and TFTP Server(s) MAX 1500 AGENTS

M

Publisher and TFTP Server(s) MAX 2000 AGENTS

M

Primary Primary Backup

M

Primary Primary Primary Primary

126041

Backup

Backup

Primary Backup
M

M M

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-11

Chapter 6 Cluster Configurations for Redundancy

Sizing Cisco CallManager Servers For IPCC

Figure 6-4

1:1 IPCC Enterprise Redundancy with Cisco CallManager Release 3.3 or Later, with 50/50 Load Balancing (High-Performance Server with BBWC Installed)

500 IPCC AGENTS Publisher and TFTP Server(s) 1 to 250: Primary 251 to 500: Backup 251 to 500: Primary 1 to 250: Backup

1000 IPCC AGENTS Publisher and TFTP Server(s) 251 to 500 751 to 1000 1 to 250 501 to 750

2000 IPCC AGENTS Publisher and TP Server(s) 251 to 500 751 to 1000 1250 to 1500 1750 to 2000
M

1 to 250 501 to 750 1001 to 1250

126042

1501 to 1750

Note

MCS-7845H-2.4 Advanced server does not come with BBWC installed; BBWC must be ordered separately.

Figure 6-5

1:1 Redundancy for Mixed Office and IPCC Phones with Cisco CallManager Release 3.3 or Later on MCS-7845H-3000 High-Performance Server with 50/50 Load Balancing

250 IPCC AGENTS AND 3750 PHONES Publisher and TFTP Server(s) IPCC Agents 250 Agents: Primary 3750 Phones: Backup Phones 3750 Phones: Primary 250 Agents: Backup
M

500 IPCC AGENTS AND 7500 PHONES Publisher and TFTP Server(s) IPCC Agents 251 to 500
M M

1000 IPCC AGENTS AND 15000 PHONES Publisher and TP Server(s) IPCC Agents

1 to 250

251 to 500 751 to 1000 3750 to 7500 11251 to 15000

1 to 250 501 to 750 1 to 3750

126043

Phones
M

3751 to 7500

1 to 3750

Phones
M M M M

7501 to 11250

Cisco IP Contact Center Enterprise Edition SRND

6-12

OL-7279-04

Chapter 6

Sizing Cisco CallManager Servers For IPCC Load Balancing With IPCC

Load Balancing With IPCC

An additional benefit of using the 1:1 redundancy scheme is that it enables you to balance the devices over the primary and backup server pairs. Normally (as in the 2:1 redundancy scheme) a backup server has no devices registered unless its primary is unavailable. With load balancing, you can move up to half of the device load from the primary to the secondary subscriber by using the Cisco CallManager redundancy groups and device pool settings. In this way, you can reduce by 50% the impact of any server becoming unavailable. To plan for 50/50 load balancing, calculate the capacity of a cluster without load balancing and then distribute the load across the primary and backup subscribers based on devices and call volume. To allow for failure of the primary or the backup, the total load on the primary and secondary subscribers should not exceed that of a single subscriber. For example, MCS-7845H-3000 servers have a total server limit of 500 IPCC agents. In a 1:1 redundancy pair, you can split the load between the two subscribers, configuring each subscriber with 250 agents. (See the configuration for 500 agents in Figure 6-2.). To provide for failover conditions when only one server is active, make sure that all capacity limits are observed so that IPCC agent phones, IP phones, CTI limits, and so on, for the redundant pair do not exceed the limits allowed for a single server. For additional information on general call processing topics such as secondary TFTP servers and gatekeeper considerations, refer to the Cisco IP Telephony Solution Reference Network Design (SRND) guide, available at http://www.cisco.com/go/srnd

Impact of IPCC Application on Cisco CallManager Performance and Scalability

Cisco CallManager system performance is influenced by many factors such as:

Software release versions The type and quantity of devices registered, such as:
CTI ports Gateway ports Agent phones Route points CTI Manager

The load (BHCA) processed by these devices. As the call rate increases, more CPU resources are consumed on the Cisco CallManager server. Average call duration Longer average call duration means a lower busy-hour call completion rate, which lowers CPU usage. Special Cisco CallManager configurations and services such as:
MOH Tracing levels

Cisco IP Contact Center Enterprise Edition SRND OL-7279-04

6-13

Chapter 6 Impact of IPCC Application on Cisco CallManager Performance and Scalability

Sizing Cisco CallManager Servers For IPCC

Server platform type:

Standard High-performance

Application call flow complexity (See the definitions of simple and complex call flows in the section on Call Processing With IPCC Enterprise, page 6-1.)
IVR self-service Call treatment Routing to agents Transfers and conferences

CPU consumption varies by type of call flow. For simple call flows, the CPU consumption is moderate, but CPU consumption for complex call flows is much higher.

Tests conducted with a complex call flow (call treatment then transfer to agents) using IP IVR with H323 gateways show an increase in CPU usage compared to the same call flow using ISN (H.323 gateway). This difference is due to the fact that ISN does not require calls to be routed to Cisco CallManager before call treatment; instead, Cisco CallManager is involved only when calls are transferred to agents (simple call handling). The trade-off is that ISN gateways have increased performance demands. (See Sizing ISN Components, page 4-20, for more information). Similarly, complex call flows using IP IVR with Media Gateway Control Protocol (MGCP) gateways show an increase in CPU usage compared to the same call flow using ISN (H.323 gateway). This difference is due to the way ISN routes the calls (as described in the preceding paragraph) and to the fact that the H.323 gateway protocol uses more CPU resources than MGCP does. ISN configurations, simple call flow configurations, and a lower call arrival rate (BHCA) might be able to support more than 2,000 agents per Cisco CallManager cluster. Please consult with your Cisco Systems Engineer for proper sizing of your system requirements. Trace level enabled Cisco CallManager CPU resource consumption varies, depending on the trace level enabled. Changing the trace level from Default to Full on Cisco CallManager can increase CPU consumption significantly under high loads. (Changing the tracing level from Default to No tracing can decrease CPU consumption significantly at high loads, but this is not a recommended configuration and is not supported by Cisco Technical Assistance Center.) CPU consumption due to Default traces will vary based on load, Cisco CallManager release, applications installed, call flow complexity, and so forth.

Memory consumption and disk I/O resources (battery-backed write cache) Phone authentication and encryption

It is important to balance all resources equally as much as possible if you are using more than one primary Cisco CallManager server. This balancing of resources will prevent overloading one server to benefit the others.

Cisco IP Contact Center Enterprise Edition SRND

6-14

OL-7279-04