Table Of Contents
Cisco Business Edition 6000 Co-residency Policy Requirements
Published: June 06, 2013
In addition to Cisco Unified Communications (UC) applications sold with Cisco Business Edition 6000 (BE 6000), Cisco now allows the installation of a broader range of Cisco and third-party virtualized applications on the BE 6000 server, subject to the conditions that are detailed in this document. This change of policy applies for all new and previously supplied BE 6000 servers.
For the purposes of this document, the following definitions apply:
•BE 6000 UC means the UC applications that are explicitly included in the BE 6000 Solution. (See Table 1 for a list of BE 6000 UC applications.)
•Non-BE 6000 UC means any of the following:
–Other Cisco UC applications (such as MediaSense) that are not explicitly part of the BE 6000 solution.
–Virtualized third-party UC applications that are included in the Cisco Developer Network, Marketplace Solutions Catalog for Collaboration. List of all permitted third-party UC applications can be found here. (Note:- Third-party applications that are not part of CDN may not be used with the BE 6000).
–Virtualized third-party applications that are offered through the Cisco SolutionsPlus Program described at http://www.cisco.com/web/partners/pr46/solutions_plus/index.html.
•Coresident means "running BE 6000 UC applications and non-BE 6000 UC applications in dedicated virtual machines on the same BE 6000 ESXi host."
* One vCPU should be reserved for ESXi scheduler if Cisco Unity Connection is deployed in a VM.
Up to three third-party applications may run on each BE 6000 host in a deployment. Where two or more BE 6000 ESXi hosts are present in a deployment, a maximum of six third-party applications may be installed.
The coresidency policy that is defined in this document applies for deployments on any Business Edition 6000 Server running Virtualization Hypervisor version 5.x.
Not all UC applications support coresidency, or they may have limited support of coresidency. See http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines#Application_Co-residency_Support_Policy for details.
All other general UC virtualization rules apply—for example, VMware feature support and supported ESXi versions. See www.cisco.com/go/uc-virtualized.
All non-BE 6000 UC applications must be VMware certified or supported and must not require anything beyond the vSphere ESXi requirements that is outlined at http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements.
All applications must support ESXi 5.0 as a minimum and align with supported versions of the other BE 6000 UC applications.
Customers that run a coresident deployment must agree to temporarily reduce the number of virtual machines that are running on a host if Cisco deems it necessary for debugging purposes.
Customers must permanently reduce the number of virtual machines that are running on a host if Cisco determines that the host is overloaded.
If a customer is unwilling to agree to these requirements, Cisco TAC will not support the coresident deployment.
Support for third-party applications is provided by the vendor of the individual application.
When planning a coresident deployment, you must consider four areas: CPU, RAM, storage and network.
For details on virtual to physical sizing rules in a coresidency context, see http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines.
The sizing rules refer to the "Tested Reference Configuration" hardware support approach, described here: http://docwiki.cisco.com/wiki/UC_Virtualization_Supported_Hardware.
To ensure no oversubscription of memory, you must set up all coresident virtual machines with a physical memory reservation equivalent to it's vRAM setting. For example, if a virtual machine is configured with 4GB of vRAM, you must assign a physical memory reservation of 4GB.
To ensure that you have enough physical RAM on the host to run the virtual machines you plan to run, you must have 2 GB of additional RAM beyond the sum of the vRAM reservations for the virtual machines. This additional RAM is required for the ESXi host and the overhead it incurs with each virtual machine that it runs.
To virtualize a BE 6000 physical host, the hypervisor requires up to 2GB of physical RAM. When you plan a coresident deployment, you must account for this overhead . For example, if the BE 6000 host has 32GB of physical RAM, only 30GB of this is available to virtual machines. See Understanding Memory Overhead for further details.
A BE 6000 deployment must have a one-to-one allocation of vCPUs to physical cores. For example, if you have a host with 16 physical cores, you can deploy any combination of virtual machines with a combined requirement of no more than 16 vCPUs. There is a special case if one or more of the virtual machines are running Cisco Unity Connection. In this case, you can deploy any combination of virtual machines with a combined requirement of no more than 15 vCPUs.
Because the number of vCPUs must not exceed the number of physical cores, you do not have to configure CPU reservations or limits. Under no circumstances may a physical core be oversubscribed.
Note: Some processors support Hyperthreading, which allows a hypervisor to see a physical core as two logical processors. Logical processors must not be used for coresidency planning.
For more details, see the "No Hardware Oversubscription" section at http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines.
Disk Space and Storage Performance
The Direct Attached Storage (DAS) must supply the combined disk space and IOPS (Input Output Operations per Second) capacity for the virtual machines that will run on the host, while maintaining a minimum performance level.
It is unlikely that the latency requirements of the BE 6000 UC applications will limit third-party applications. However, you must understand the latency and load requirements of the non-BE 6000 UC applications before installation.
The DAS and RAID are fixed, and no field changes are allowed to the BE 6000 Unified Computing System Tested Reference Configuration (TRC). The BE 6000 TRC is designed to meet the storage requirement for all Cisco BE 6000 UC Applications listed in Table 1. The disk latency requirement must be less than 20 ms.
Cisco recommends that deployments that include non-BE 6000 UC applications be verified such that the kernel command latency does not exceed 3 ms and the physical device command latency does not exceed 20 ms under any conditions. See Sizing Shared Storage for more details.
For example, when you test a TRC with DAS, all UC applications that are designed to run on the TRC are loaded with full traffic and software upgrades are run simultaneously on all virtual machines. This generates the highest IOPS load possible on the host, and if this test passes, it is very likely the DAS array can handle the I/O load of the specific set of virtual machines.
To summarize the requirements, the disk subsystem must supply the disk space that is required for all the applications and support the aggregate IOPS load that the virtual machines generate, while not impacting the latency requirements of the UC applications. Otherwise, some virtual machines must be removed.
The aggregate networking load of the coresident virtual machines must not exceed the capacity of the physical networking interfaces. Generally, the I/O capacity of the physical network resources on any modern server is more than adequate to meet the needs of the virtual machines that are being hosted. For UC applications, see the QOS design considerations. You must understand the networking requirements of the virtual machines that are deployed on the host and how to set up the host networking hardware to meet those needs. If Cisco determines that application performance problems are due to networking congestion within the host, then some VMs must be moved off the host.
Under certain conditions, Cisco allows coresident deployments with a mix of BE 6000 UC and non-BE 6000 UC applications. The requirements that are listed in this document provide the basis for a successful coresident deployment, but due to the unpredictable behavior of non-BE 6000 UC applications and the inability to test every possible combination of applications that could be deployed, Cisco cannot guarantee that following these guidelines alone will be sufficient.
A key principal of virtualization is based on sharing hardware resources among multiple virtual machines. When deploying only BE 6000 UC applications on a host server, Cisco can guarantee levels of performance, because the applications are thoroughly tested and their behavior understood. Deploying coresident third-party applications introduces a degree of unpredictability that can be mitigated by following general principals of virtualization and the specific requirements in this document.
Ultimately, Cisco cannot guarantee that by following these guidelines alone, the virtual machines on a host will never be starved for resources. However, if this does occur, the only recourse will be to remove some of the virtual machines on the host such that the host can handle the load. This can be done by moving some of the virtual machines to another host, or by moving all the virtual machines to a more powerful host.