I spend quite a bit of time discussing Cisco’s Unified Communications Applications in a virtualized environment. There is a ton of information available for deploying and also support guidelines at the Wiki site below:
http://docwiki.cisco.com/wiki/Unified_Communications_in_a_Virtualized_Environment
So much information that it is hard to work out where to start. I thought I would break down what the options look like and help give a base level knowledge to folks in need. It took me quite a while to get around the site especially with trickier questions around CPU speed and changing CPU’s etc.but as you learn the different areas and requirements it makes a great reference to support guidelines. It is the definitive guide for virtualized Cisco UC applications. Actually for anyone doing a UC project the guidelines presented for Cisco can also be helpful to apply some of the same guidelines for any real-time application.
There are three main categories when it comes to the hardware that is supported when deploying Cisco UC applications in a virtual environment.
UC on Unified Computing System (UCS) Tested Reference Configurations (TRC) – This is probably the easiest way to buy, deploy and support Cisco UC applications on supported and tested models of UCS hardware. These are specific models of hardware that cover everything from CPU speed, RAM and hard drive size. Some models such as the Business edition 6000 and 7000 only require a single part number to purchase everything including the VMware licenses. Both servers are based on UCS TRC models. Currently there are nine different UCS models that fit into this category from rack mount to blade servers.
UC on UCS Spec-based – So what if you have UCS and it meets the minimum spec of your UC applications but doesn’t match the a TRC server build. CPU speed and or architecture is an example, this falls under UCS Spec-based guidelines. One thing to focus on when investigating whether your UCS box will support Cisco UC applications is the CPU architecture guidelines. If it doesn’t match the supported architectures than you may have to look at changing out your CPU or other hardware to meet the minimum specs.
UC on 3rd Party Spec-based – The guidelines for support are similar in certain aspect to UCS spec-based but of course Cisco does not validate, support or test the third party hardware. Also be aware that the customer must be responsible providing a licensed, supported version of VMware vCenter and vSphere ESXi.
So there are three major areas to watch for this category:
- VMware version support. UC application version support for VMWare ESXi can vary but the version of ESXi also needs to be support by VMware for your hardware : http://www.vmware.com/resources/compatibility/search.php
- CPU Architectures are specified and some CPU architectures my never be supported so this is a very important to ensure you have correct architecture per your UC applications.
- CPU speeds and total cores must match the minimum spec of your UC application.
This is really for customers that are comfortable self supporting their own hardware environment. As you can tell there are a few variables that affect the supportability of a platform so it will always be best to check with Cisco before you purchase or deploy on a third party spec box.
Third Party and UC VM Co-residency
Once you have picked your platform and decided what UC applications you want to deploy now you need to understand what can and can’t be deployed on the same VMware host.
There is a great document that goes into detail on what is and is not supported here. The basics are if a third party application is installed on your host and is deemed to be interfering with your UC applications it may need to be either removed, shut down or ported to another VM host so you can continue to troubleshoot with the TAC.
For some general guidelines here are some simple rules to follow:
- Don’t over subscribe your applications, it’s a one to one mapping between your VM and your hardware.
- Use OVA’s for your Cisco UC applications
- CPU guidelines must be followed (speed, core mapping and architecture)
- Don’t overload your network and ensure your looking at QoS design considerations for virtualization
This has a few moving pieces but VMware features are well documented as to what is and isn't supported. Probably the most common features are vMotion, cloning or copying virtual machines and Snapshots. Depending on your applications it may or may not be supported but there is a good table located here to help you decide what feature support is available.
Replacing a CPU in a VMware host
I recently had a case where a company needed to change CPU speeds. So if for some reason you need to upgrade your CPU’s in your VMware host server here are a few things to consider:
- According to VMware support guidelines ensure that the CPU remains the same manufacturing technology. If you are going to replace an Intel Xeon 5100 series CPU with a Xeon 5300 series CPU, even though the number of cores are different, but they are still under Intel Xeon 5000 series, there are no issues with replacing them. However, swapping CPUs between Intel Xeon 7000 series with 5000 series may cause ESX to function in an unexpected manner.
- Ensure the same CPU architecture per the UC application guidelines
- Ensure the minimum speed and core amounts are meet for your UC application for the amount of users you wish to support.
UC Placement Tool -http://tools.cisco.com/ucs
The virtual machine placement tools is very helpful in understanding how to map your virtual machines to the hardware.
The Cisco Collaboration Virtual Machine Placement tool (VMPT) is to be used AFTER design guides and sizing tools, and BEFORE creating a bill of materials, quote or configuration in Cisco Commerce Workspace.
It helps you visualize a deployment of virtualized Cisco Collaboration to simplify specifying the required physical servers and virtualization software. It is not intended to be used as a "design tool", "sizing tool" or "quote tool" that substitutes existing processes.
VoIPNorm