UC on UCS: Control, Support and Vendor Commitment

Posted By:  Dan Stephens, Director, Collaboration, Presidio South
Posted Date: 

“UC on UCS” is used to describe the placement of virtualized Cisco Unified Communications or Collaboration applications onto a Cisco Unified Compute System. Recently, a few clients have asked about the benefits of implementing UC on UCS, especially now that UC virtualization is also supported on other major Blade systems. The answer is simple: control, support and vendor commitment.

The value of virtualized Unified Communications applications is efficiency. You get reduced rack and floor space, reduced power and cooling, fewer physical servers to manage, reduced maintenance and support costs, increased portability and increased recovery capabilities. Cisco is now the third leading Compute provider. Cisco UCS also brings something unique - multiple compute domains managed by a single pane of glass, along with the benefit of being owned and developed by the same company that has shipped over 50 million IP phones. UC on UCS actually makes sense beyond the technical aspects of the manufacture compute systems.

First, in most enterprise organizations, the control of budget concerning telephony and servers is contained within multiple departments – much like voice was years ago with telephony and networks. However, as VoIP began to converge with the network, the legacy PBX’s went away and the Telco guys were absorbed into the network team which controlled the routers and switches. Today, in many cases, the telephony guys are the network guys and the network guys are the telephony guys.

During this same convergence period, the enterprise applications teams and the server teams began to blend. Huge data centers were being created to support enterprise applications such as Domain Controllers, SQL and Oracle databases, management software, CRM, ERM, Content management, etc. However, there was a limit to space, power and budget which heralded the age of the hypervisor. The ability to fit many virtual servers on a single physical platform became a legitimate challenge. Ultimately many organizations were left with one group that handled the network infrastructure, inclusive of communications services, and multiple groups that handled applications infrastructure and core builds. Basically, multiple budgets and multiple points of control.

For a long time, Cisco and other vendors of communications applications were reluctant to put real-time call processing on a virtual environment platform for fear of service degradation. As a result, a techno-political problem has evolved. The challenge lies in the legacy compute and storage environments that were determined by server teams, long before real-time communications (and the applications that support this) were a real factor. Now the legacy server teams have their own system application requirements and expectations, which aren’t necessarily configured to meet the real-time communication application’s needs being asked of them today.  Real-time communication applications do not always adapt well to the techniques previously deployed and this further challenges business continuity and disaster recovery capabilities provided by these new virtual environments. This problem is requiring additional resources and care outside of the normal server team’s process.

Now, network (voice) teams are dependent on the server teams to build a virtual environment that supports UC applications on an existing compute platform. The networking team must now learn and understand systems capabilities in order to intelligently request proper virtual networking configuration that supports QOS and firewall activities. Operationally the voice team is the same as any other business application owner, which would be fine with this one exception - dial tone is a right and not a privilege. Mission critical communications systems require configuration from the application layer down to the data-link layer.

To avert the loss of ownership many of my customers are actually treating UCS as a communications appliance. Large or small, they are using UC on UCS to maintain stability and control of the Voice and Video virtualized environment. By using B-Chassis in their data centers they are taking advantage of the shared storage, and supported business continuity features.  Using the C-Series they are extending the distributed call control out into the field and the larger sites where service from the data center does not provide the level of service required. The budget funding is coming from the legacy TDM switches that are being replaced and the collapse of appliance based UC applications onto a single virtualized environment. Fiscally they are taking advantage of the benefits of virtualization and politically they are avoiding internal team conflicts. Since Cisco is enhancing both products, they are positioning themselves for a single pane of glass management system from the network all the way through the Collaboration applications.

The net result is virtualization supported on all major compute systems. However, is it wise to cede ownership of the environment for real-time communications to a team that is normally focused on transactional based traffic? The goal with real-time communication traffic is good quality, jitter free and at least five 9’s of uptime. When the choice is Cisco Collaboration, then the choice of hardware does make a difference, if for no other reason than the support of the total solution.  Learn more about Presidio Collaboration Solutions or feel free to contact us