UCM and IMP Caveated Support for VMware CPU Reservations

NOTE: Caveated support for VMware CPU reservations and Distributed Resource Scheduler is limited to the following applications:
• Cisco Unified Communications Manager (CUCM) 11.5(1) or greater
• Cisco Unified Communications Manager - IM & Presence (CUCM IM&P) 11.5(1) or greater
• Cisco Unity Connection (CUC) 11.5(1) or greater

NOTE: Support for a deployment leveraging this CPU Reservations policy is granted only following the successful review of a detailed design, including the submission of sizing results from the Cisco Collaboration Sizing Tool and VM placement from Cisco VM Placement Tool. For more information about these tools and the sizing of Unified CM clusters, see the Cisco Collaboration Solution Reference Design Guides. Customers who wish to pursue such a deployment must engage either their Cisco Account Team, Cisco Advanced Services, or their certified Cisco Partner to submit the design review request. CPU Reservations design reviews leverage the same team and process used for UCM megaclusters.

• Recall Cisco Collaboration workloads are resource-intensive and latency-sensitive because they process real-time signaling and media for voice, video, messaging and other forms of live communication. Compared to traditional workloads this introduces restrictions on design, deployment, management and operations to ensure real-time software will perform properly and stably under load.
• Using VMware's terminology (see vSphere Resource Management Guide in Technical References), Cisco is defining "Reservations", not "Limits" or "Shares" (which are not used or supported).
• Caveated support for CPU Reservations is intended for virtualized Collaboration installed base customers with datacenter-centric deployments , skilled/experienced VMware/compute admins and extensive baselining of their deployment's CPU utilization (during both steady-state and spike situations such as group bootup, BHCA, upgrades, backups and CDR writes). Not recommended for greenfield deployments (where no baseline exists), deployments having admins with low VMware/compute skillsets or deployments of Business Edition 6000/7000 appliances (since not tested with CPU Reservations and if post-sales hardware changes ever needed, would not be supported).
• NOTE: Cisco does NOT test VMware CPU Reservations. Cisco Business Edition 6000/7000 appliances and UConUCS TRCs are only tested with the "1vcpu:1pcore" sizing approach as described in the Collaboration Virtualization Sizing. Customers own any required testing of CPU Reservations in their environment.
• NOTE: Cisco does NOT provide prescriptive guidance for CPU Reservations other than the Required CPU Reservation described later in this policy. Cisco Collaboration Sizing Tool and Virtual Machine Placement Tool are still expressed in terms of fixed-configuration VMs using the "1vcpu:1pcore" sizing approach described in the Collaboration Virtualization Sizing.
• For minimum required CPU pcore speeds, this new policy only affects supported applications. Required minimum CPU pcore speed for all other Collab apps is UNCHANGED.
• Caveated support for CPU Reservations does NOT relax sizing rules for other hardware such as Memory, Storage GB / latency / IOPS, network access, etc. Be careful not to use CPU Reservations to place so many VMs on a host that one of these other resources becomes overcommitted.
• Conservative designs are encouraged. Resist the temptation to over-consolidate VMs, which makes change management more complex, creates single points of failure and thwarts redundancy.
• When using CPU reservations with these applications, TAC support for committed real-time performance is only achieved when all VMs are at the Required CPU Reservation, Cisco Collaboration Sizing Tool rules are followed and hardware meets TRC requirements. If ANY are not met, the deployment is treated as Specs-based (see TAC support clarifications in TAC TechNote #115955).

  

• Physical CPUs models must be on the supported specs-based list and are restricted to Intel Xeon E5v1 or later and Intel Xeon E7v2 or later on that list.
• Physical CPU speed ("Base Frequency") must be 2.50 GHz or higher. For UCM and IM&P only, if a slower Base Frequency is desired, customer must work with their channel partner, advanced services team, or account team to model their deployment in Cisco Collaboration Sizing Tool. If the "Call Processing Capacity Utilized per Call Processing VM" on "Solution Sizing Summary" is ≤ 40%, then for supported application VMs only, the Base Frequency may be as low as 2.00 GHz. Customers who choose to run production on a slower base frequency should frequently re-assess their "as-built" deployment vs. "Call Processing Capacity Utilized per Call Processing VM".

  Restricted UC Performance CPUs", with pcores of 2.30 GHz.

• #vcpu ≤ #pcores
• Using CPU reservations. Customer's account team, partner or advanced services consults Cisco Collaboration Sizing Tool to verify deployment's CPU load is low enough for a 2.30 GHz pcore.
• If 2.30 GHz pcore ok, calculate Reduced CPU Reservation = (2vcpu) * (24.78 GHz * 90%) / (12 pcores) = 3.717 GHz. Customer consults their baseline to double check that this Reduced CPU Reservation makes sense.

• NOTE: Unless specifically indicated, "DRS" in this document refers to VMware Distributed Resource Scheduler and not Cisco Disaster Recovery Solution.
• Cisco does NOT test VMware DRS with its applications. Cisco Business Edition 6000/7000 appliances and UConUCS TRCs are only tested with static VM placement (see VM Placement Tool and Collaboration Virtualization Sizing). Customers own any required testing of DRS in their environment.
• Use of DRS with supported application VMs has the same caveats as using vMotion with the same VMs because DRS's live migration also temporarily freezes the live VM to move it to a new host. Freezing a live real-time communications VM can have variable, unpredictable and unpreventable adverse effects, so use of DRS for live migration is NOT advised during business hours (particularly during your busy-hour when BHCA occurs).

Use of VMware DRS for Caveated Applications Virtual Machines

• Supported application VMs must use CPU Reservations, and all caveats and pre-requisites for supported applications' CPU Reservations apply to use of DRS with applications. Including source and destination ESXi hosts following usable capacity rules in Max GHz capacity of an ESXi host / physical server.
• VMware licensing must entitle the DRS feature. NOTE: Collaboration embedded OEM virtualization licenses do NOT entitle DRS.
• Use of DRS must meet all of VMware's DRS+HA+vMotion pre-requisites (see vSphere Resource Mgmt Guide in Technical Resources).
• Customer owns their DRS configuration. Cisco is not responsible for consulting or debugging the DRS configuration with respect to Collaboration applications. Cisco TAC not obligated to root-cause these application issues isolated to DRS.
• VM migration via DRS must NOT result in the following:
  • Overcommitment of host hardware, particularly exceeding Total Capacity for CPU Reservations as described in Max GHz capacity of an ESXi host / physical server.
  • Violation of Cisco Collaboration virtualization support policy rules at www.cisco.com/go/virtualized-collaboration.
  • Violation of Cisco Collaboration application design guidelines (e.g. www.cisco.com/go/ucsrnd).
• Allowed DRS settings:
  • DRS Mode / Automation Level (at both host and VM levels) = Manual and Partially Automated for all supported applications. Fully Automated for UCM and IMP only.
  • DRS Migration Threshold = all options allowed but "Conservative" is recommended.
  • Dynamic Power Mgmt = not supported (frequently implies CPU throttling to conserve power).
  • DRS Affinity & Anti-affinity rules = allowed to help customers comply with SRND rules, but customer's responsibility to setup and debug.

• Performance Best Practices for VMware vSphere 6.0
• vSphere Resource Management: ESXi 6.0, vCenter 6.0
• Best Practices for Performance Tuning of Latency-Sensitive Workloads in vSphere VMs
• Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5