{{ note | The 2500 user VM configuration with one vcpu may exhibit performance issues during CPU/IO-intensive operations (such as installs, upgrades, backups and CDR writes), or if your deployment has certain characteristics such as a large quantity of TFTP files. Changing the VM config to 2 vcpu is recommended as a prevention strategy. Otherwise you may deploy with one vcpu and be TAC-supported, but note that if the root cause of performance issues is found to be insufficient vcpu, Cisco TAC will ask that you change this to 2 vcpu. If your deployment is not experiencing any issues you are not required to change to 2 vcpu and may remain on 1 vcpu. }}<br>

+

{{ note | The 2500 user VM configuration with one vcpu may exhibit performance issues during CPU/IO-intensive operations (such as installs, upgrades, backups and CDR writes), or if your deployment has certain characteristics such as a large quantity of TFTP files. Changing the VM config to 2 vcpu is recommended as a prevention strategy. Otherwise you may deploy with one vcpu and be TAC-supported, but note that if the root cause of performance issues is found to be insufficient vcpu, Cisco TAC will ask that you change this to 2 vcpu. If your deployment is not experiencing any issues you are not required to change to 2 vcpu and may remain on 1 vcpu. }}

This section provides the IOPS data for a Cisco Unified Communications Manager system under load. These values are per active VM. Which VMs are active, and how many are active simultaneously, depends on how the CUCM cluster nodes are setup with respect to service activation, redundancy groups, etc. (see www.cisco.com/go/ucsrnd for details).

This section provides the IOPS data for a Cisco Unified Communications Manager system under load. These values are per active VM. Which VMs are active, and how many are active simultaneously, depends on how the CUCM cluster nodes are setup with respect to service activation, redundancy groups, etc. (see www.cisco.com/go/ucsrnd for details).

-

CUCM storage access is on average 93-98% sequential writes with an IO block size of 4 kilobytes.

+

93-98% ot total IO is "sequential writes" with an IO block size of 4 kilobytes.

*Active call processing: As a reference, the following steady state IOPS were observed at various loads (expressed in Busy Hour Call Attempts):

*Active call processing: As a reference, the following steady state IOPS were observed at various loads (expressed in Busy Hour Call Attempts):

Notes on 2500 user VM configurations

Note:

The 2500 user VM configuration with one vcpu may exhibit performance issues during CPU/IO-intensive operations (such as installs, upgrades, backups and CDR writes), or if your deployment has certain characteristics such as a large quantity of TFTP files. Changing the VM config to 2 vcpu is recommended as a prevention strategy. Otherwise you may deploy with one vcpu and be TAC-supported, but note that if the root cause of performance issues is found to be insufficient vcpu, Cisco TAC will ask that you change this to 2 vcpu. If your deployment is not experiencing any issues you are not required to change to 2 vcpu and may remain on 1 vcpu.

IOPS and Storage System Performance Requirements

This section provides the IOPS data for a Cisco Unified Communications Manager system under load. These values are per active VM. Which VMs are active, and how many are active simultaneously, depends on how the CUCM cluster nodes are setup with respect to service activation, redundancy groups, etc. (see www.cisco.com/go/ucsrnd for details).

93-98% ot total IO is "sequential writes" with an IO block size of 4 kilobytes.

Active call processing: As a reference, the following steady state IOPS were observed at various loads (expressed in Busy Hour Call Attempts):

10K BHCA produces ~ 35 IOPS

25K BHCA produces ~ 50 IOPS

50K BHCA produces ~ 100 IOPS

100K BHCA produces ~ 150 IOPS

Software upgrades during business hours generate 800 to 1200 IOPS in addition to steady state IOPS.

CDR/CMR via CDR Analysis and Reporting (CAR)

CUCM sending CDR/CMR to the external billing server does not incur any additional IOPS.

Enabling CAR continuous loading results in around 300 IOPS average on the system.

Scheduled uploads are around 250 IOPS for Publisher's VM only.

Trace collection is 100 IOPS (occurs on all VMs for which tracing is enabled).