Cisco Unified Contact Center Enterprise Solution Reference Network Design, Release 9.x
Sizing Cisco Unified Communications Manager Servers
Downloads: This chapterpdf (PDF - 1.51MB) The complete bookPDF (PDF - 12.21MB) | The complete bookePub (ePub - 7.08MB) | Feedback

Sizing Cisco Unified Communications Manager Servers

Sizing Cisco Unified Communications Manager Servers

This chapter discusses the concepts, provisioning, and configuration of Cisco Unified Communications Manager (Unified CM) clusters when used in a Unified CCE deployment. Unified CM clusters provide a mechanism for distributing call processing across a converged IP network infrastructure to support Cisco Unified Communications, facilitate redundancy, and provide feature transparency and scalability.

This chapter covers only the Unified CCE operation with Unified CM clusters and proposes reference designs for implementation.

The information in this chapter builds on the concepts presented in the Cisco Unified Communications SRND. Some duplication of information is necessary to clarify concepts relating to Unified CCE as an application supported by the Unified CM call processing architecture. However, the foundational concepts are not duplicated here; become familiar with them before continuing with this chapter.

This chapter documents general best practices and scalability considerations for sizing the Unified CM servers used with your Unified CCE deployments. Within the context of this document, scalability refers to Unified CM Server and/or cluster capacity when used in a Unified CCE deployment. For information about sizing and choosing a gateway, see the gateway information in the latest version of the Cisco Unified Communications SRND.

Cluster Sizing Concepts

Before attempting to size a Unified Communications Manager cluster for a Unified CCE deployment, perform the following design tasks:
  • Determine the different types of call flows.
  • Determine the required deployment model (single site, centralized, distributed, clustering over the WAN, or remote branches within centralized or distributed deployments).
  • Determine whether Unified CVP or IP IVR is used for call treatment, self service, and queuing.
  • Determine the protocols to be used.
  • Determine redundancy requirements.
  • Determine all other customer requirements for Cisco Unified Communications that will share a Unified Communications Manager cluster with a Unified CCE deployment (such as Cisco Unified IP Phones, applications that are not part of Unified CCE, route patterns, and so forth).
After you complete these tasks, you can begin to accurately size the necessary Unified Communications Manager clusters. Many factors impact the sizing of a Unified Communications Manager cluster, and the following list mentions some of those factors:
  • Number of office phones and the busy hour call attempt (BHCA) rate per phone
  • Number of inbound agent phones and the BHCA rate per phone
  • Number of CTI ports and the BHCA rate on those VoIP endpoints (can be zero if Unified CVP is used for call treatment, self service, and queuing)
  • Number of Voice Gateway ports and the BHCA rate on those VoIP endpoints
  • Type of outbound dialer (SCCP or SIP Dialer)
  • Number of outbound agent phones, outbound dialing mode, and BHCA rate per phone
  • Number of outbound dialer ports, number of IVR ports for outbound campaigns, and the BHCA rate per port for both
  • Number of mobile agents and the BHCA rate per mobile agent
  • Number of voicemail ports and the BHCA rate to those VoIP endpoints
  • Signaling protocols used by the VoIP endpoints
  • Percent of agent call transfers and conferences
  • Dial plan size and complexity, including the number of dialed numbers, lines, partitions, calling search spaces, locations, regions, route patterns, translations, route groups, hunt groups, pickup groups, route lists, and so forth
  • Amount of media resources needed for functions such as transcoding, conferences, encryption, and so forth
  • Co-resident applications and services such as CTI Manager, E-911, and Music on Hold
  • Unified Communications Manager release (sizing will vary per release)
  • Desired hardware server model (sizing will vary per hardware server model)

Other factors can affect cluster sizing, but the above list shows the most significant factors in terms of resource consumption.

The general process to sizing a Unified Communications Manager cluster is to estimate the resource consumption (CPU, memory, and I/O) for each of these factors and then to choose hardware that will satisfy the resource requirements. It is important to gather information with regard to the factors listed above before attempting to size a cluster with any accuracy.

The next section describes the tools for sizing Cisco Unified Communications Manager deployments.

Cisco Unified Communications Sizing Tool

To size Cisco Unified Contact Center Enterprise servers, use the Cisco Unified Communications Sizing Tool (Unified CST) available at http:/​/​tools.cisco.com/​cucst/​faces.

You can use the Unified CST to size large and complex Unified Communications Systems. This tool supports the sizing of many Unified Communications components, such as Unified Communications Manager, Unified CCE, Unified IP IVR, Unified CVP, and gateways.

The Unified CST is available to Cisco internal employees and Cisco partners, and proper login authentication is required. For detailed instructions, see the documentation for this tool.

Cluster Guidelines and Considerations

The following guidelines apply to all Unified CM clusters with Unified CCE.

  • A cluster may contain a mix of server platforms, but this is strongly discouraged except in migration or upgrade scenarios. All primary and fail-over (backup) server pairs must be of the same type. All servers in the cluster must run the same Unified CM software release and service pack.
  • Within a cluster, you may enable a maximum of eight servers with the Cisco Call Manager Service, including backup servers. Additional servers may be used for more dedicated functions such as TFTP, publisher, music on hold, and so forth.
  • In a deployment with IP IVR, each Unified CM cluster (four primary and four backup subscriber servers) can support up to approximately 2000 Unified CCE agents. This limit assumes that the BHCA call load and all configured devices are spread equally among the eight call processing servers with 1:1 redundancy. (See Unified CM Redundancy for redundancy schemes.) Each of the eight Unified CM servers (MCS-7845 High Performance Servers) would support a maximum of 250 agents. In a fail-over scenario, the primary server would support a maximum of 500 agents. These capacities can vary, depending on your specific deployment. All deployments must be sized by using the Cisco Unified CM Capacity Tool or the Unified Communications Sizing Tool. Some deployments with more than 500 agents per pair of subscriber nodes or 2000 agents per cluster might be supported, depending on the output of the Unified CM Capacity Tool or the Unified Communications Sizing Tool.
  • In a deployment with Unified CVP (no IP IVR), each Unified CM cluster (four primary and four backup subscriber servers) can support up to about 4000 Unified CCE agents. This limit assumes that the BHCA call load and all configured devices are spread equally among the eight call processing servers with 1:1 redundancy. (See Unified CM Redundancy for redundancy schemes.) Each of the eight Unified CM servers (MCS-7845-H2/I2 or later High Performance Servers) would support a maximum of 500 agents. In a fail-over scenario, the primary server would support a maximum of 1,000 agents. These capacities can vary, depending on your specific deployment. All deployments must be sized by using the Cisco Unified CM Capacity Tool or the Unified Communications Sizing Tool.

When sizing the Unified CM Cluster to support Contact Center solutions for the appropriate number of CTI resources, remember to also account for additional configured phones from non-logged in agents, additional applications like Call Recording, Attendant Console, PC-clients which remotely control the device, and other 3rd-Party applications which consume additional CTI resources. Multiple lines on the same device prior to Unified CM 7.1(3) also require additional CTI resources.

Unified CM 7.1(3) (or later) has been enhanced to support more CTI resources. Consider upgrading when multiple lines and/or multiple applications (e.g. Contact Center and Recording) is used concurrently. Those CTI resources follow the same CTI rules as described in theCisco Unified Communications Solution Reference Network Design (SRND) Guide at http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​tsd_​products_​support_​series_​home.html. All deployment must be sized by using the Cisco Unified Communications Sizing Tool.

  • Devices (including phones, music on hold, route points, gateway ports, CTI ports, JTAPI Users, and CTI Manager) must never reside or be registered on the publisher. Any administrative work on Unified CM will impact call processing and CTI Manager activities if there are any devices registered with the publisher.
  • Do not use a publisher as a fail-over or backup call processing server unless you have fewer than 150 agent phones and the installation is not mission critical or is not a production environment. The Cisco MCS-7825 server is the minimum server supported for Unified CCE deployments. (Refer to Table 1 for more details.) Any deviations will require review by Cisco Bid Assurance on a case-by-case basis.
  • Any deployment with more than 150 agent phones requires a minimum of two subscriber servers and a combined TFTP and publisher. The load-balancing option is not available when the publisher is a backup call processing subscriber.
  • If you require more than one primary subscriber to support your configuration, then distribute all agents equally among the subscriber nodes. This configuration assumes that the BHCA rate is uniform across all agents.
  • Similarly, distribute all gateway ports and Unified IP IVR CTI ports equally among the cluster nodes.
  • If you require more than one Unified CCE JTAPI user (CTI Manager) and more than one primary Unified CM subscriber, then group and configure all devices monitored by the same Unified CCE JTAPI User (third-party application provider), such as Unified CCE route points and agent devices, on the same server if possible.
  • Enable CTI Manager only on call processing subscribers, thus allowing for a maximum of eight CTI Managers in a cluster. To provide maximum resilience, performance, and redundancy, load-balance CTI applications across the various CTI Managers in the cluster. For additional CTI Manager best practices, see the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​tsd_​products_​support_​series_​home.html.
  • If you have a mixed cluster with Unified CCE 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 Unified CCE agents and their associated devices and resources (gateway ports, CTI ports, and so forth) are on one or more Unified CM servers, and all general office IP phones and their associated devices (such as gateway ports) are on other Unified CM servers, as long as cluster capacity allows. If you use the Cisco Unified CM Capacity Tool, you have to run it multiple times with the specific device configuration for each primary Unified CM Server Because the tool assumes all devices are equally balanced in a cluster. In this case, use the 1:1 redundancy scheme.
  • (See Unified CM Redundancy for details.) If you use the Unified Communications Sizing Tool instead, you do not have to run it multiple times because this tool supports deployments with dedicated Unified CM servers for agent phones or with a mixed cluster.
  • Use hardware-based conference resources whenever possible. Hardware conference resources provide a more cost-effective solution and allow better scalability within a Unified CM cluster.
  • Configure all CTI route points associated with the Unified CCE Peripheral Gateway (PG) JTAPI user to register with the subscriber node running the CTI Manager instance that is communicating with that Unified CCE PG.
  • The Cisco Unified CM Capacity Tool and the Unified Communications Sizing Tool do not currently measure CTI Manager impact on each server separately. However, CTI Manager does place an additional burden on the subscriber node running that process. The Cisco Unified CM Capacity Tool and the Unified Communications Sizing Tool report the resource consumption based on these nodes. The actual resource consumption on the other Cisco Unified CM nodes might be slightly lower.
  • Count devices that are associated with a Unified CCE PG JTAPI user, but are not used by a call center agent, as an agent device, because the PG will still be notified of all device state changes for that phone even though it is not being used by an agent. If a device is unlikely to be used regularly by a call center agent, do not associate the device with the Unified CCE PG JTAPI user to increase cluster scalability.
  • For deployments requiring large numbers of IVR ports, use Unified CVP instead of IP IVR. IP IVR ports place a significant call processing burden on Unified CM, while Unified CVP does not. Thus, Unified CCE deployments with Unified CVP will allow more agents and higher BHCA rates per cluster. Size all deployments by using the Unified Communications Sizing Tool.
  • In deployments with multiple IP IVRs, associate those servers with different CTI Managers on different subscriber nodes to better balance call processing across the cluster.
  • Unified CM CPU resource consumption varies, depending on the trace level enabled. Changing the trace level from Default to Full on Unified CM 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 configuration is not supported by Cisco Technical Assistance Center.
  • Under normal circumstances, place all servers from the Unified CM cluster within the same LAN or MAN. Do not place 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 IPT: Clustering Over the WAN in this guide and the section on Clustering over the IP WAN in the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​tsd_​products_​support_​series_​home.html.

For the most current information about Unified CM and Unified CCE supported releases, see the latest version of the Cisco Unified Communications Manager Compatibility Matrix.

Unified CM Servers

Unified CM clusters utilize various types of servers, depending on the scale, performance, and redundancy required. They range from non-redundant, single-processor servers to highly redundant, multiprocessor servers.

Unified CM is supported only on specific hardware platforms. For a list of the currently supported hardware configurations, see the documentation on Cisco MCS 7800 Series Unified CM appliances.

To size a Unified CM deployment, you must use the Cisco Unified CM Capacity Tool or the Unified Communications Sizing Tool, both of which indicate the number of Unified CM servers needed for each type of platform.

Avoid deploying only one Unified CM subscriber for mission-critical contact center deployments and for deployments with more than 150 agents. The table below lists the maximum number of agents in a system where only one Unified CM subscriber server is deployed, with the Unified CM publisher used as backup.

Table 1 Capacity When Deploying Only One Unified CM Subscriber Server

Server Type

Maximum Number of Agents

MCS-7825

100

MCS-7835 or MCS-7845

150

The Cisco MCS-7815 and MCS-7816 servers are not supported with Unified CCE deployments, but lab or demo setups can use these servers. They are, however, a supported Unified CM platform for Cisco Unified Communications deployments only.

Unified Communications Manager redundancy

With Unified Communications Manager, you can choose from the following redundancy schemes:
  • 2:1—For every two primary subscribers, there is one shared backup subscriber.
  • 1:1—For every primary subscriber, there is a backup subscriber.

Due to the higher phone usage in contact centers and the increased downtime required during upgrades, do not use the 2:1 redundancy scheme for Unified Communications Manager deployments with Unified CCE.

The following figure illustrates these options. This illustration shows only call processing subscribers and does not show publisher, TFTP, music on hold (MoH), or other servers. For details on additional cluster deployment and redundancy options, see the latest version of the Cisco Unified Communications Solution Reference Network Design (SRND) Guide at http:/​/​www.cisco.com/​en/​US/​products/​sw/​voicesw/​ps556/​tsd_​products_​support_​series_​home.html.

Figure 1. Basic redundancy schemes

In the following figure, the options shown all provide 1:1 subscriber redundancy. Option 1 is used for clusters supporting fewer than 150 Unified CCE agents on any supported version of Unified CM. Options 2 through 5 illustrate increasingly larger clusters. In this figure, for deployments with Unified Communications Manager 8.x and Unified CVP (not IP IVR), N is equal to 1000. For deployments with IP IVR, N is equal to 500. For other types of deployments, use the Cisco Unified Communications Manager Capacity Tool or the Unified Communications Sizing Tool. In all types of deployments, the exact number of servers depends on the hardware platforms chosen or required, as determined by the Cisco Unified Communications Manager Capacity Tool or the Unified Communications Sizing Tool.

Figure 2. Redundancy configuration options

Load Balancing for Unified CM

An additional benefit of using the 1:1 redundancy scheme is that it enables you to balance the devices over the primary and backup subscriber 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 Unified CM 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 must not exceed that of a single subscriber. For example, if deploying Unified CVP and Unified CM 8.0 or later releases, MCS-7845-H3 servers have a total server limit of 1000 Unified CCE agents. In a 1:1 redundancy pair, you can split the load between the two subscribers, configuring each subscriber with 500 agents. To provide for system fault tolerance, make sure that all capacity limits are observed so that Unified CCE agent phones, Unified IP phones, CTI limits, and so on, for the subscriber pair do not exceed the limits allowed for a subscriber server.

Distribute all devices and call volumes as equally as possible across all active subscribers. For instance, distributing the Unified CCE agents, CTI ports, gateways, trunks, voicemail ports, and other users and devices among all subscribers equally, minimizes the impact of any outage.

For additional information about general call processing topics such as secondary TFTP servers and gatekeeper considerations, see the Unified Communications System Solution Reference Network Design (SRND) at http:/​/​www.cisco.com/​en/​US/​docs/​voice_ip_comm/​uc_system/​design/​guides/​UCgoList.html.

Deployment of Agent PG in a Unified CM Cluster

Agent PGs can be deployed in a Unified CM cluster in either of the following ways:
  • The first method is to deploy an Agent PG for each pair of Cisco Unified CM subscriber nodes. In this case, each Unified CM subscriber node runs the CTI Manager service, and each Agent PG connects to a CTI Manager running on its corresponding Unified CM subscriber pair. The following diagram shows an example where four primary Unified CM subscribers are required and four backup Unified CM subscribers are deployed to provide 1:1 redundancy.
    Figure 3. Deploy Agent PG for Each Pair of Unified CM Subscriber Nodes

  • Another possible method is to deploy a single Agent PG for the entire Cisco Unified CM cluster. This type of deployment requires a single pair of Cisco Unified CM subscriber nodes running CTI Manager. Spread agent phone registration among all the Cisco Unified CM subscriber nodes, including the Unified CM subscribers running the CTI Manager service. The following diagram shows an example where four primary Unified CM subscribers are required and four backup Unified CM subscribers are deployed to provide 1:1 redundancy.
    Figure 4. Deploy Single Agent PG for Entire Unified CM Cluster

    One benefit of this model is the reduction of the server count for the PG. Another benefit is that there is a single PIM for the entire Unified CM cluster. This makes it possible to create teams that span across many Unified CM subscribers, thus allowing supervisors, for example, to monitor agent phones registered to any Unified CM subscriber node in the Unified CM cluster. However, the resource utilization on the Unified CM cluster might be slightly higher in this type of deployment. Use the Cisco Unified CM Capacity Tool or the Unified Communications Sizing Tool to size the Unified CM servers for a particular deployment. A variation of this type of deployment is available with Unified CM 8.0 or later releases, when Unified CVP only is deployed. (This model is not supported when IP IVR is deployed.) Up to 4000 agents can be supported in a single Unified CM cluster in this case. When deploying more than 2000 agents, a minimum of two CTI Manager pairs are required. One Agent PG with two PIMs can be deployed, with each PIM configured with a separate pair of Unified CM subscribers running the CTI Manager service and each PIM configured with up to 2000 agents. Spread agent phone registration among all the Cisco Unified CM subscriber nodes, including the Unified CM subscribers running the CTI Manager service. The following diagram shows an example where four primary Unified CM subscribers are required, and four backup Unified CM subscribers are deployed to provide 1:1 redundancy.
    Figure 5. Use Unified CVP for Unified CM 8.0 or later

Upgrading Unified CM

The 1:1 redundancy scheme allows upgrades with only the fail-over periods impacting the cluster. The 1:1 redundancy scheme enables you to upgrade the cluster using the following method:
  1. Upgrade the publisher server.
  2. Upgrade dedicated TFTP and music-on-hold (MoH) servers.
  3. Upgrade the backup subscribers one at a time. This step will affect some users if 50/50 load balancing is implemented.
  4. Fail-over the primary subscribers to their backups, and stop the Cisco Unified CM Service on the primaries. All users are on primaries and are moved to backup subscribers when the Cisco Unified CM 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.
  5. Upgrade the primaries, and then re-enable the Cisco Unified CM Service.

With this upgrade method, there is no period (except for the fail-over period) when devices are registered to subscriber servers that are running different versions of the Unified CM 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.

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 preferred scheme for Unified CCE deployments, although it is supported if it is a customer requirement and, if possible, outage of call processing is not a concern to the customer.

The 2:1 redundancy scheme enables you to upgrade the cluster using the following method. If the Cisco Unified CM Service does not run on the publisher database server, upgrade the servers in the following order:
  1. Upgrade the publisher database server.
  2. Upgrade the Cisco TFTP server if it exists separately from the publisher database server.
  3. Upgrade servers that have services related only to Unified CM (music on hold, Cisco IP Media Streaming Application, and so forth) running on them. Make sure that you upgrade only one Server at a time. Make sure that the Cisco Unified CM Service does not run on these servers.
  4. Upgrade each backup server, one Server at a time.

    Note


    Do not oversubscribe the backup server or servers during the upgrade. The number of agent phones registered to the backup server during the upgrade must not exceed the maximum capacity indicated by the Cisco Unified CM Capacity Tool or the Unified Communications Sizing Tool. Perform the upgrade during off-peak hours when the call volume is low.


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

Cisco Unified Mobile Agent

Unified Mobile Agent requires the use of two CTI ports per contact center call. One CTI port controls the caller endpoint, and the other CTI port controls the selected agent endpoint. The actual RTP stream is between the two endpoints and is not bridged through these two CTI ports. However, there is additional call processing activity on Unified CM when setting up calls to mobile agents through these two CTI ports (when compared with setting up calls to local Unified CCE agents).

While mobile agents may essentially log in from any location (by using the agent desktop) where they have a high-quality broadband connection and a PSTN phone, they will still be associated logically with a particular Unified CCE Peripheral and Unified Communications Manager cluster, even if the Voice Gateway used to call the mobile agent is registered with a different Unified Communications Manager cluster. The agent desktop is configured with the IP address of the PG and/or CTI server to which it is associated.

For specific Unified Communications Manager node and cluster sizing for Unified CCE deployments, the Cisco Unified Communications Manager Capacity Tool or the Unified Communications Sizing Tool must be used. When sizing the Unified Communications Manager cluster, input the maximum number of simultaneously logged-in mobile agents. In cases where the number of configured mobile agents is higher than the maximum number of simultaneous logged-in mobile agents, consider the pairs of CTI ports configured for mobile agents who are not logged in the Cisco Unified Communications Manager Capacity Tool by entering CTI ports type 1 with a BHCA and BHT of 0. This is similar to the method for taking into account local agent phones that are not logged in by using the CTI third-party controlled lines in the Cisco Unified Communications Manager Capacity Tool. As an alternative, or when using the Cisco Unified Communications Sizing Tool, you can input all mobile agents (logged-in and not logged-in) into the tool and adjust the BHCA and BHT per mobile agent accordingly. The total BHCA and BHT must remain the same as when considering simultaneous logged-in mobile agents with their actual BHCA and BHT.

For more details on Cisco Unified Mobile Agent architecture, deployment models, and Unified CCE sizing, see Cisco Unified Mobile Agent.