Specification-Based Hardware Support
Specs-Based Hardware Requirements for running Cisco Unified Communications on Supported Versions of VMware vSphere ESXi
Cisco supports running UC applications on certain versions of VMware vSphere ESXi. Customers may choose one of two different support models for compute, network and storage hardware.
- Tested Reference Configurations (TRC):
Select hardware configurations tested and documented for specific guaranteed performance, capacity and application co-residency scenarios running "full-load" UC VMs. Intended for customers who want a packaged solution from Cisco that is pre-engineered for a specific deployment scenario and/or customers who are not sufficiently experienced with hardware virtualization. See Tested Reference Configurations (TRC) for more information.
- Specs-Based VMware Hardware Support:
A flexible support policy described in the remainder of this document. Intended for customers with extensive expertise in virtualization and server/storage sizing who wish to use their own hardware standards. This hardware has not been directly tested or documented by Cisco UC, but meets certain specifications for which UC applications are supported. Performance is not guaranteed, but the Tested Reference Configurations may be used for guidance when sizing hardware. Important: Customers who choose this option are responsible for sufficiently sizing hardware to meet UC VM performance needs at the level of load deployed. Customers are also responsible for resolving performance problems by adjusting either the hardware configuration or the VM deployment model. Cisco is not responsible for performance problems resulting from use of specs-based support when the problem can be resolved by deployment changes such as migrating the virtual machine to a faster hardware platform, powering off or migrating some of the other virtual machines to a different physical server, or splitting up a dense UC VM into multiple less dense UC VMs on different physical servers. It is recommended to use the Tested Reference Configurations for guidelines on hardware sizing. Deploying specs better than TRC "should" provide better performance, but should be verified as not guaranteed. Deploying specs worse than TRC "should" provide worse performance, but is not guaranteed. Use of a processor with slower speed than the Tested Reference Configurations is not supported as the deployment will have unknown and unspecified reduction in capacity/performance.
Customers who require maximum flexibility and are proficient with virtualization, including the above support implications, should use Specs-based VMware Hardware support. Customers who require a simplified solution with guaranteed performance, and who lack experience with virtualization, should use Tested Reference Configurations.
The following are identical regardless of the support model chosen:
- Virtual machine (OVA) requirements
- VMware product, version and feature support
- VMware configuration requirements for UC
- Application/VM Co-residency policy (specifically regarding application mix, 3rd-party support, reservations, oversubscription). Max VM count per server with specs-based depends on the physical server configuration and the OVAs deployed. E.g. UCS C210 M2 TRC#1 deployed with multiple CUCM 7.5K user OVAs can support 4:1. If specs-based was used with a supported dual 6-core CPU and appropriate increases in memory and storage, the same server model running multiple CUCM 7.5K user OVAs could support 6:1.
The remainder of this document defines the requirements of the specs-based policy.
VMware vSphere and vCenter Requirements
Supported VMware products, versions and features under this specs-based policy are the same as with the TRCs (Tested Reference Configurations), and are detailed here.
VMware vCenter is a required component in any deployment using this specs-based policy.
Configuring vCenter to capture detailed logs, as shown in Figure 1 below, is strongly recommended. If not configured by default, Cisco TAC may request enabling these settings in order to troubleshoot problems. It is a requirement that the customer deployment of vCenter be able to capture Statistics Level 4 for all statistics levels for the maximum duration at each level.
The only supported server vendors are:
- Cisco Unified Computing System
The following are NOT supported:
- Cisco MCS 7800
- Cisco UCS Express on ISR/SRE-V hardware
- Any other 3rd-party server vendor, such as Dell, Fujitsu, Oracle/Sun
Server Models and Generations
Any model/generation of any form factor (rack, blade) may be used as long as it complies with the following:
- The server is from one of the supported vendors above
- The server is on the VMware Hardware Compatibility List for the version of VMware vSphere ESXi required by UC.
- The server uses a processor supported by UC (described later in this document). Note that your server model choices may be artificially limited by server's processor options vs. the list of what processors UC supports, i.e. not because of the model itself but because of the CPU.
- The server's configuration satisfies all other criteria of this policy.
With this specs-based policy, support is not about the server model per se, but rather the server vendor and the processor used.
The following processor models are supported:
- Intel Xeon 5600 family with minimum physical core speed of 2.53 GHz
- Intel Xeon 7500 family with minimum physical core speed of 2.53 GHz
- CPU models in these families with slower physical core speeds are not supported due to undefined capacity/performance relative to Tested Reference Configurations. UC is sensitive to both the CPU speed and the CPU architecture. Most industry CPU benchmarks do not correlate well with UC application behavior, so "newer" or "faster" does not guarantee "better for UC".
The following processors are NOT supported:
- Intel processor families not on the above list, such as Intel Xeon 6500 or Intel Xeon E7-2800/4800/8800. These are not supported at this time.
- Other processor vendors such as AMD are not supported.
Total physical core count required is based on the sum of UC virtual machine core requirements and the co-residency support policy. Per these policies, recall that physical CPU cores may not be over-subscribed for UC VMs (one physical CPU core = one VM vCPU core).
Cisco TAC will not troubleshoot performance problems in deployments with insufficient physical processor cores or speed.
Minimum physical RAM required is 2GB for ESXi plus the sum of UC virtual machines' vRAM.
Recall that physical memory may not be over-subscribed for UC VMs. UC therefore does not require a minimum DIMM speed.
UC does not mandate memory hardware module size, density, speed or quantity - follow server vendor requirements for memory hardware configuration (here is an example for Cisco UCS: http://www.cisco.com/en/US/docs/unified_computing/ucs/hw/chassis/install/blade.html#wp1035302).
Cisco TAC will not troubleshoot performance problems in deployments with insufficient physical RAM.
IO Adapters, Controllers and Devices for LAN Access and Storage Access
All adapters used must be on the VMware Hardware Compatibility List for the version of vSphere ESXi required by UC.
Only the following I/O Devices are supported:
- FC – 2Gbps or faster
- Ethernet – 1Gbps or faster
- NFS and iSCSI are supported for network storage access - 10Gbps or faster, plus see requirements below
- Cisco VIC or 3rd-party Converged Network Adapter
- FCoE supported for converged Ethernet and network storage access - 10Gbps or faster, plus see requirements below
- RAID Controllers for DAS
- SAS SATA Combo
The customer is also responsible for configuring redundant devices on the server (e.g. redundant NIC, CNA, HBA or VIC adapters).
There are no UC restrictions on hardware vendors for I/O Devices other than that VMware and the server vendor/model must be compatible with them and support them
Cisco TAC will not troubleshoot performance problems in a deployment designed with insufficient or overloaded I/O devices.
Storage Hardware and Performance
- The kernel disk command latency must not be greater than 2-3 ms and the physical device command latency must not be greater than 15-20 ms. When either of these metrics is not met, Cisco considers the storage system inadequate to serve the UC virtual machines. Cisco will not troubleshoot performance problems in an environment where either metric is not being met.
- Additionally, each UC VM OVA has a published IOPS and virtual disk space requirement. It is the responsibility of the customer to provide a storage system that exceeds total vDisk (see Unified Communications Virtualization Downloads (including OVA/OVF Templates) and average IOPS requirements (see IO Operations Per Second (IOPS)) of the UC virtual machines they will be running on that storage system. It is not necessary to configure the storage system for peak simultaneous IOPS of every virtual machine, but the customer should be aware of excess capacity to avoid over-extending the system (e.g. by upgrading every virtual machine at the same time causing an IOPS spike).
- The storage solution must follow all storage capacity, performance and QoS requirements in Shared Storage Considerations here.
- Otherwise the following are supported: DAS, NAS, SAN and boot from SAN (diskless) with NFS, FC, iSCSI and FCoE transport options. Note that diskless servers are only supported if all UC apps on the physical server / ESXi host support both vSphere ESXi 4.1 and the VMware "boot from SAN" feature (see the VMware Requirements page).
- See the Shared Storage Considerations for an illustration of a best practices SAN/NAS array configuration for UC (using five 300-450 GB 15K rpm SAS or FC drives in a RAID 5 configuration, LUN size of 500 GB to 1.5 TB, <8-10 UC VMs per LUN).
Cisco TAC will not troubleshoot performance problems in a deployment designed with insufficient or overloaded storage hardware.
Mechanical & Environmental Components
UC apps have no dependencies on form factor, rack mounting hardware, cable management hardware or power supplies. Redundant power supplies are strongly recommended for high availability.
|Back to: Unified Communications in a Virtualized Environment|