Nutanix and UC – Part 1: Introduction and Overview

I’ll be publishing a series of blog posts outlining Cisco Unified Communications on Nutanix. At the end of this series I hope to have addressed any potential concerns running Cisco UC and Nutanix and provided all the tools for a successful deployment. Your comments are welcome and encouraged. Let’s start at the beginning, a very good place to start.

Cisco UC Overview

Let’s start with an overview of Cisco Unified Communications just to make sure we’re all on the same page about the basics of the solution. UC is just a term used to describe all of the communications technologies that an enterprise might use to collaborate. This is really a series of different client and server technologies that might provide Voice, Video, Instant Messaging,  and Presence.

Clients use these server components to communicate with each other. They also use Gateway components to talk to the outside world. The gateway in the below image shows how we link into a phone service provider such as AT&T or Verizon to make calls to the rest of the world.

Each of the above components in the Cisco UC Virtual Machines provides a critical function to the clients along the bottom. In the past there may have been racks full of physical servers to accomplish these functions, but now this can be virtualized. Redundancy is still one of our NUMBER 1 concerns in a UC deployment, but scale is also important. When the phone system goes down and the CEO or CIO can’t dial into the quarterly earnings call there is huge potential for IT staff changes. Even more importantly, everyone relies on this system for Emergency 911 calls. The phone system MUST be up 100% of the time (or close to it).

Virtualization actually helps both in terms of scale AND redundancy on this front. Let’s look at each component of the UC system and see what it does for us as well as how it fits into a virtual environment.

Cisco Unified Communications Manager

Cisco Unified Communications Manager (CUCM) is the core building block of all Cisco UC environments. CUCM provides call control. All phones will register to the CUCM and all phone calls will go through the CUCM for call routing. Because the CUCM call control is such a critical function it is almost always deployed in a redundant full-mesh cluster of servers. A single cluster can support up to 40,000 users with just 11 VMs. Additional clusters can be added to scale beyond 40,000 users.

Once the size of the Cisco CUCM cluster is determined the next step is to deploy the VMs required. Each VM is deployed from an OVA which has a number of fixed values that cannot be changed. The number of vCPUs, the amount of RAM, and the size of the disks is completely determined by the Cisco OVA.

The Cisco DocWiki site lists various OVAs available to deploy a CUCM server. The size of the CUCM server OVA used depends on the number of endpoints the cluster will support.

Cisco Unity Connection

Cisco Unity Connection (CUC) provides Voice Message services, acting as the voice mailbox server for all incoming voice messages. CUC can also be used as an Interactive Voice Response server, playing a series of messages from a tree structure and branching based on user input. For redundancy each CUC cluster is deployed in and Active/Active pair that can support up to 20,000 voice mailboxes. Scaling beyond 20,000 users is just a matter of adding clusters.

The OVA for CUC can be found on the Cisco DocWiki site. Notice that these OVAs for CUC have much larger disk sizes.

Cisco Instant Messaging & Presence

Cisco IM&P is the primary UC component that provides service to Cisco Jabber endpoint Presence and Instant Messaging. Jabber clients will register to the IM&P server for all contact list functions and IM functions. The Jabber clients ALSO connect to the CUCM server for call control and CUC server for Voice Messaging.

IM&P servers are deployed in pairs called subclusters. Up to 3 subclusters (6 IM&P servers total) can be paired with a single CUCM cluster supporting up to 45,000 Jabber clients. The OVA templates for IM&P can be found on the DocWiki site. Each IM&P cluster is tied to a CUCM cluster. Adding more IM&P clusters will also mean adding more CUCM clusters.

Cisco Emergency Responder

911 emergency calls using a VoIP service often fall under special state laws requiring the exact location of the emergency call to be sent to the Emergency Public Service Answering Point (PSAP). The 911 operator needs this location to dispatch appropriate emergency services. VoIP makes this more complex because the concept of a phone now encompasses laptops and phones with wireless roaming capabilities which are often changing locations.

Cisco Emergency Responder (CER) is deployed in pairs of VMs (primary and secondary) to provide Emergency Location to the PSAP when a 911 call is placed. CER will use either SNMP discovery of switch ports, IP subnet based discovery, or user provided location to provide a location to the PSAP.

OVAs for CER can be found on the Cisco DocWiki.

Additional voice server components can be found on the DocWiki page. They follow a similar convention of describing the number of vCPUs, RAM, and Disk requirements for a specific platform size.

We’ll talk more about these individual components in the next part of this series, but for now it’s enough to just understand that each of these services will be provisioned from an OVA as a VM on top of VMware ESXi.

Nutanix Overview

Nutanix has been covered in great detail over at the Nutanix Bible. I won’t repeat all of the work because I’m sure I wouldn’t do it justice. I will however steal a few images and give a brief summary. For more info please head over to Steve’s page.

The first image is the most important for understanding what makes Nutanix so powerful. Below we see that the Nutanix Controller Virtual Machine (CVM) has direct control of the attached disks (SSD and HDD). The Hypervisor talks directly to the Nutanix CVM processes for all disk IO using NFS in the case of VMware ESXi. This allows Nutanix to abstract the storage layer and do some pretty cool things with it.

The Hypervisor could be VMware ESXi, Microsoft Hyper-V, or Nutanix AHV. We’ll focus on ESXi here because Cisco UC requires VMware ESXi for virtualization.

The great thing is that to User Virtual Machines such as Cisco Unified Communications this looks exactly like ANY OTHER virtual environment with network storage. There is no special work required to get a VM running on Nutanix. The same familiar hypervisor you know and love presents storage to the VMs.

Now we have the game changer up next. Because the CVM has control of the Direct Attached Storage, and because the CVM runs on every single ESXi host, we can easily scale out our storage layer by just adding nodes.

Each Hypervisor knows NOTHING about the physical disks, and believes that the entire storage pool is available for use. The CVM optimizes all data access and stores data locally in flash and memory for fast access. Data that is less frequently accessed can be moved to cold tier storage on spinning disks. Once local disks are exhausted the CVM has the ability to write to any other node in the Nutanix cluster. All writes are written once locally, and once on a remote node for redundancy.

Because all writes and reads will happen locally we can scale up while preserving performance.

Nutanix Distributed Filesystem requires at least 3 nodes to form a cluster. Lucky for us the most common “block” comes with space for 4 “nodes”. Here’s an inside view of the 4 nodes that make up the most common Nutanix block. The only shared components between the 4 nodes are the redundant power supplies (2). Each node has access to its own disks and 10GbE network ports.

Additional nodes can be easily added to the cluster 1 – 4 at a time using an auto discovery process.

Up Next – Cisco Requirements for Virtualization

Now that I’ve been at Nutanix for a few months I’ve had a chance to really wrap my head around the technology. I’ve been working on lab testing, customer sizing exercises, and documentation of UC Best Practices on Nutanix. One of the most amazing things is how well UC runs on Nutanix and how frictionless the setup is.

I had to do a lot of work to document all of the individual Cisco UC requirements for virtualization, but with that exercise completed the actual technology portion runs extremely well.

In the next blog post I’ll cover all of the special requirements that Cisco enforces on a non-Cisco hardware platform such as Nutanix. I’ll cover exactly how Nutanix meets these requirements.