UC virtualization – Co-residency of 3rd party apps with Cisco UC VMs is now supported!

Customers have been asking for co-residency of 3rd party non-UC applications on the same VMware host / physical server with our UC apps for a very long time. Virtualization has matured, and is common practice in any IT organization. Although it still makes sense to “isolate” virtualized UC applications on dedicated hardware, customers now get the flexibility to mix and match our applications and 3rd party as they prefer. The server industry, including our own UCS portfolio, can nowadays scale servers to 10s of CPU cores, hundreds of gigabytes of RAM and virtually unlimited storage capacity. Customers wanting to maximize and optimize resource utilization and consolidate many servers to limit the server hardware footprint and cost of operation can now also include our UC apps in there…

Not sure if the example is relevant, but basically this means that a customer can now run Cisco Unified Communications Manager, file and print services and a mail server on the same box / VMware host.

The biggest challenge for Cisco was how to guarantee that our apps would get the required resources when they are co-located with others on the same physical server. Getting it working is one, but how can you define a design that you can actually fully support while there are so many things outside of your control… It’s possible,

All relevant details can be found on the following url:

http://docwiki.cisco.com/wiki/Unified_Communications_Virtualization_Sizing_Guidelines#General_Rules_for_Co-residency_and_Physical.2FVirtual_Hardware_Sizing  (see topic 2.2)

In summary, this is a short overview of the rules we have set forward for “full co-residency”:

-UC on UCS rules apply with 3rd party VMs (no oversubscription for vCPU, vRAM, vDisks, etc…)

– Not allowed with BE6k

– Not allowed with Cisco UC Virtualization Foundation or Cisco UC Virtualization Hypervisor

– Cisco cannot guarantee the VMs will never starved for resources. If this occurs, Cisco could require to power off or relocated all 3rd party applications

TAC has defined the criteria that need to be met to get their support in an application note that can be found at:

http://www.cisco.com/en/US/products/ps6884/products_tech_note09186a0080bbd913.shtml

Specifications-Based Hardware Support – VMware considerations

Since a while we support UC virtualization on Cisco, HP and IBM servers apart from the Cisco validated UCS configurations (Tested Reference Configurations or TRCs). This is referred to as “specs-based” hardware support. For these configurations we will not provide sizing guidelines as we do with the TRCs.  The configuration is supported as long as the requirements in term of CPU (vCPU and CPU type), memory and storage capacity and performance are respected. Although this looks very interesting, there are some considerations you should be aware of when going for a specs-based deployment over a Cisco TRC-based installation. In order to be able to support such a deployment that has not been thoroughly tested, TAC will need to be able to use some advanced VMware management tools to debug and analyze the virtual environment. This requires VMware vCenter, which is therefore mandatory for specs-based systems. This has an important influence on the cost of the VMware licenses.  In any doubt about the sizing of the WMware hosts and the number of application they can run, or whenever the pricing of the required VMware licenses is a potential issue, we recommend using the Cisco validated UCS TRCs.  In terms of VMware you are even allowed to use the free edition of vSphere as the hypervisor for them.  For any information on UC on UCS please visit www.cisco.com/go/uc-virtualized.

%d bloggers like this: