Introduction
This document clarifies some aspects of the support policy for application co-residency defined in the Application Co-residency Support Policy as part of the support policy for virtualized Cisco Unified Communications (UC)/Collaboration applications defined at Cisco Collaboration Virtualization. This tech note is applicable to all UC on Unified Computing System (UCS) and other virtualization hardware options that include UCS Tested Reference Configuration, UCS Specs-based, and 3rd-party-server Specs-based.
Prerequisites
Requirements
Cisco recommends that you have knowledge of these topics:
-
UC on UCS solution
-
UCS Tested Reference Configuration hardware
-
Specs-based hardware (UCS, HP or IBM)
-
Virtualization of Cisco Collaboration applications
-
VMware vSphere software
-
Cisco Unified Computing System hardware
Note: See the "Related Information" section of this document for web page links.
Components Used
The information in this document is based on these software and hardware versions:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Co-residency and “Quality of Service”
A key principal of both network convergence and virtualization is the sharing of hardware resources.
-
A converged IP network shares network hardware among multiple traffic streams (voice, video, storage access, and other data).
-
A virtualized server (or virtualization host) shares compute, storage, and network hardware among multiple application virtual machines (VMs).
In both cases, quality of service is required to protect UC from non-UC applications when hardware resources are finite, as such:
-
Quality of Service (QoS) in routing and switching network hardware in order to ensure voice/video network traffic gets the needed bandwidth and protection from delay and jitter.
-
Adherence to UC virtualization rules (for example, physical/virtual hardware sizing, co-residency policy, and so on) in order to ensure UC VMs get the needed CPU, memory, storage capacity, and storage/network performance.
It is impossible for Cisco to test every combination of hardware and application for VM co-residency, particularly for 3rd-party application VMs whose behavior might be unpredictable or not clearly defined. Therefore, real-time performance of Cisco UC applications is only committed when installed on a UCS Tested Reference Configuration and then only when all conditions in the co-residency policy are followed (see Collaboration Virtualization Sizing, and for applications that support CPU Reservations like UCM and IMP, there might be other considerations).
For other environments, uncertainty can be reduced by pre-deployment testing, baselining, following general principles of virtualization, and following the rules of Cisco UC virtualization (at Cisco Collaboration Virtualization). However, Cisco cannot guarantee that VMs will never be starved for resources and never have performance problems.
Key Support Considerations for Non-UC and 3rd-party Virtual Machines
In order to enable Cisco TAC to effectively provide support when you run Cisco UC VMs co-resident with non-UC/3rd-party app VMs, customers must ensure either of these:
-
Non-UC/3rd-party VMs are non-critical and are able to be temporarily powered-down if required to facilitate troubleshooting.
-
If no VMs are non-critical, then spare capacity must be provisioned on virtualization hosts or physical servers for relocation (temporary or permanent) of VMs as solutions to application performance problems. Spare capacity is already a recommended design best practice for redundancy or to provide temporary staging of VMs when maintenance is required on hardware or software. Examples of “spare capacity” are extra “empty” physical servers (to provide “hot-standby” or temporary staging), or existing blade/rack-mount servers not fully utilized.
In order to enable Cisco TAC to effectively provide support when you run Cisco UC VMs co-resident with non-UC/3rd-party app VMs, Cisco might require these activities from the customer for problem diagnosis or resolution:
-
Changes to either the software workload or the physical hardware, in order to troubleshoot or resolve application performance problems. Examples of when these changes might be required are UC VM receiving insufficient CPU, memory, network, disk capacity or storage input/output operations per second (IOPS) from the hardware.
-
Examples of what these changes look like in an actual deployment are listed here.
-
Software: temporary power-down of non-critical VMs in order to facilitate performance troubleshooting
-
Software: move critical VMs and/or non-critical VMs in order to alternate virtualization host/physical server as temporary or permanent solution.
-
Temporarily reduce the number of virtual machines that run on a host if Cisco deems necessary for troubleshooting purposes.
-
Permanently reduce the number of virtual machines that run on a host if Cisco determines the host is overloaded.
-
Splitting a dense UC app VM into multiple less-dense VMs, then moving those less-dense VMs to alternate host. For example, splitting a CUCM 10K user OVA into multiple CUCM 7.5K user OVAs, then relocating some of those CUCM 7.5K user OVAs.
-
These approaches allow reduction of the software workload on an overloaded virtualization host/physical server, so that the workload is no longer starved for hardware resources.
-
Hardware: additions/upgrades to "fix" an overloaded host as an alternative to powering-down VMs or moving VMs.
-
For example, addition of more physical disks to increase storage capacity and/or provide IOPS.
-
For example, addition of more physical memory or more physical CPU cores.
-
For example, addition of physical NIC interfaces to address LAN congestion.
-
These approaches allow "upgrading" the overloaded hardware to accommodate the resource-starved software workload.
Cisco's provision of support is contingent upon the customer maintaining a current and fully paid support contract with Cisco.
Related Information
Feedback