I have only just started wrapping my mind around the UC on UCS model. So, I am not trying to come off as the definitive source of information for this solution. Actually, my intention is to share my thoughts (as a UC engineer) on the solution as I get a firmer understanding.
Initial Impression
The term “we are not in Kansas anymore” springs to mind. I imagine this echos the same thoughts shared by my legacy PBX colleagues when they started focusing attention on Voice Over IP (VoIP). Of course, the difference is that for me, this initial thought is immediately followed by: “Kansas? Who needs Kansas…”.
Back in My Day…
With respect to voice application solutions, I have always wondered “why so many boxes?”. This is true for Cisco, Avaya, Nortel, and other PBX manufacturers. Scaling was always achieved by growing horizontally (until you ran out of racks or data center space!). In addition, you always have different development teams developing and testing applications. For various reasons, these applications are always delivered to the consumer with the stipulation that you run one application on one server. Never mind the fact that the server itself is not running anywhere near 100% utilization (RAM/CPU/disk). Actually, this particular problem is the reason vmware has made such an impact in the first place.
“….Why so many boxes?”
With the Cisco UC solution you start asking this question when you find yourself looking at a diagram of your solution and you see voice messaging, ACD, and call processing servers just stacked up like an army. Now there have been, and continue to be, solutions for consolidating services:
- There was the Infamous Communication System (ICS) (forgive the jab, I was never a fan myself, for either the first or second attempt)
- The ability to run a scaled down version of CRS on CM
- Unity with the message store “on box”
- CUCM-BE (Business Edition)
Now, these products are/were geared toward smaller and/or less complicated deployments. They also weren’t developed as consolidation solutions but as solutions that provided a lower cost entry point to the Cisco portfolio. As soon as you start trying to scale these solutions you run into limitations quickly and have to start stacking boxes and/or migrate to the “enterprise” class solutions.
So, What’s Different?
Well, nothing and everything at the same time. You still have to run as many different servers as you would in a non-virtualized UC environment. The servers are just, well, virtual and you can do it with less hardware. Much less hardware.
First, let’s identify the UC apps that can run in a virtual environment:
- Cisco Unified Communications Manager (CUCM)
- Cisco Unity
- Cisco Unity Connection (CUC)
- Cisco Unified Presence Server (CUPS)
- Cisco Unified Contact Center Express (UCCX)
- Cisco Unified Contact Center Enterprise (UCCE)
Since you would be running these applications virtually, there are definitely some differences in the standard operating procedure:
- Licensing. With 8x there is a new process for activating licenses for the UC application suite. A combination of values are used to generate a “License Mac” that is used to activate the license.
- Storage. SAN, ’nuff said for now.
- Operations. You need to incorporate the virtual infrastructure into your fault monitoring, event correlation, and escalation model.
- Politics. Yeah, I said it. Everyone will have their hands in this one. You have the systems folks, the SAN folks, the network folks, and the telecommunication folks. This is nothing new to those of us that have been deploying Cisco voice solutions for a while.
There are other differences to be sure, but there are more things that are the same. These are still independent applications running on independent servers. The servers are just virtual.
Software Releases
With respect to software releases the CUC, CUCM, CUPS, and UCCX solutions must be running the 8.x major release or later. Unity began supporting VMWare with release 7.x. Interestingly enough, that is not all that is different between Unity and the rest of the applications.
Platform Support
CUC, CUCM, CUPS, and UCCX are only supported on the Cisco UCS platform today. Further, these applications are only supported with the ESXi hypervisor (4.0). Unity, on the other hand, does not stipulate which hardware platform is required and it supports the ESX or ESXi hypervisors (3.5 or later).
On the initial release, the UC on UCS solution is supported on the UCS-B series. The server blade must be the half-width B-200 blade with the Intel E5540 CPU or greater. On the initial release, over-subscription of resources is not supported. Cisco also supports the UCS-C 210 M1 servers. Though they are only supporting a single application and guest OS on the C series servers at this time.
There are some key points I think should be touched on here. The ESXi hypervisor does not support USB devices. So, if you are leveraging a USB device (like a music on hold audio translator) then you will need to think about alternatives. On the UCS-B platform, over-subscription of vCPU, memory, or network interfaces is not supported. This limits the number of virtual machines you can run on the blade server between 2 and 4 vm’s.
On the UCS-C series, you can only run one VM at this time. Cisco has plans on expanding the number of vm’s supported on the C-series server in the very near future. If you are looking at this platform, I recommend getting roadmap dates from your account manager. Clearly, if you are making a purchasing decision in the near term the choice to procure the UCS-C series is a strategic decision and you should ensure you are well informed.
Storage
To use the UCS-B series, you are required to leverage a SAN for the guest operating systems. You cannot use the local hard disks in the B-200 blade. On the UCS-C series, the directly attached storage is supported. There are plenty of requirements around the SAN allocation that I won’t go into here. This will likely be discussed in a later blog.
VMWare Features
Cisco has their own management tool for the UCS (called UCS Manager or UCSM). I just started looking into this tool and getting a feel for how it plays with the UC side of the equation. I’ll have to table a deep dive on that particular topic until later. For now, it is worth knowing which VMWare features are supported for UC on UCS:
- VMWare Consolidated Backup: yes
- VMWare High Availability (HA): yes
- VMWare Site Recovery Manager: yes
- VMWare Snapshots: Only Unity supports this feature
- vCenter Update Manager: limited support. Apparently there is some compatibility issue with the standalone CSA (so, if you don’t use CSA you can use vCenter). Also, it should be noted that application upgrades and engineering specials are not delivered through vCenter Update Manager. I’ll let you draw your own conclusions here.
- vMotion: not supported. Cisco has tested this and found that while active calls are not dropped as part of the switchover, calls could experience quality degradation.
What About “Real Servers”? Are they no longer en vogue?
Cisco still supports running the 8.x software on real servers. You can still run the applications on Cisco MCS (or equivalent servers). If you order directly from Cisco, these will be IBM servers. I believe that all UC software released in 2010 will come with platform install disks that successfully detect HP servers and will allow installs to these servers. TAC will also support HP installs if the platform is compatible. (see this matrix for more information)
Further, you can mix and match real and virtual servers in a UC solution. You can even have real and virtual servers in a CUCM cluster.
Conclusions
Well, I am not done yet! I have just started scratching the surface myself. My only conclusion thus far is that if Cisco does this correctly, it will be a real positive solution for many customers. If the solution fits into the data center model embraced by the customer, it will have a positive affect on maintenance and operational costs. I also think that expanding support for running multiple VMs (UC and non-UC) on the UCS C-series is a no brainer and I hope Cisco supports this soon. Having a solution that supports DAS is needed and will open up a lot of solutions for Cisco customers. Again, if it is done correctly I am all for Mainframe version 2.0 😉
Links
There are a few links that are worth checking out:
The DocWiki is a great resource for information on this solution.