Cisco IT – Why So Many CUCM Clusters?

Last week, we looked at the question “How close to the phones does the CUCM cluster have to be?” There was no easy or set answer to this question, but we acknowledged right at the start that minimizing the number of clusters is probably a good idea. So why, then, does Cisco IT have so many clusters?

Cisco IT has a total of 38 clusters in 11 different locations. We have clusters for phones, voicemail, contact centers, TelePresence, conferencing and extranet services. (Note – to voicemail purists, the groups of Unity servers are called “nodes,” not clusters. Still, I added the 16 Unity voicemail nodes to the total set of 38 clusters anyway). There are four sets of clusters in North America, five sets of clusters in India, Japan, and Asia, and two more sets in EMEAR.

Here is a map of the Cisco IT cluster locations and their functions:

I asked our UC/Video architect, Jon Heaton, why we have so many clusters around the world, and told me the following.

There are actually three major reasons why we have so many clusters in our design:

1. Delay: The first is our old nemesis, Delay. Despite our being unable to truly nail down the distance limits, it’s still true that Johannesburg is so far away from our Amsterdam CUCM cluster that delay could become an issue. The same issue of delay is true for most of our AsiaPac sites, which are far enough from the main CUCM cluster in Sydney. Sydney was our first major CUCM hub in the AsiaPac region; however because of network delay and distance from this cluster, many Cisco locations in Asia and Japan have their own clusters.
2. Regulations: Several countries, India being most notable, have regulatory requirements that dictate dedicated infrastructures. In India, regulatory constraints forbid interconnecting VoIP and PSTN call routing, which means Cisco can carry only internal calls over its corporate network. All calls received from or sent to an external phone must be handed off to and carried by a local or long-distance service provider over the full length of the connection, with the applicable toll charges. This adds significant complexity to the call routing rules of the cluster and requires a unique cluster to handle them, described in a Cisco IT case study on Logical Partitioning.
3. Functions: While we keep the number of cluster locations to a minimum, given the above constraints, we have multiple clusters within each data center to support various functions. For example, we have to support our Core call control as well as Contact Center, and our Contact Centers’ needs are very different.  (For one, they have a near zero-downtime requirement, so we need different change management processes). This results in duplicate infrastructures for the same geographic regions. They are not always in the same Data Centers. We also have two large campuses with enough endpoints to require a separate cluster, in addition to the regional phone cluster in the same data center. As these clusters now run on virtual machines, and are no longer physically constrained, the notion of a “separate cluster” is now one of function rather than distinct location within the data center.

Despite the sheer number of clusters we support, the good news is that it requires fewer than 200 physical servers to support them. Here’s a table of our different functional clusters and the number of devices they support, along with the number of physical Cisco UCS servers required (adapted from the Cisco IT UC on UCS case study).

Thanks for your interest. And now, some questions for you today: Do you support multiple clusters, and if so, why? Are they split up because of distance, or size, or function? Or do you have other requirements that force you to build separate clusters?

Share