IPT Clustering over the WAN

Unanswered Question
Nov 17th, 2008

Guys

i just wanted to get an idea of what you guys do for this. basically we have three sites each with thier own Pub and Sub at the moment. we would like to redesign to have all in one cluster. Simply put, we would like all sites to be able to still communicate with each other even though one of the main sites goes down.

my question is more from a WAN prospective. to enable this to happen im assuming that you need multiple paths from either the router to router end or from the carrier end, more like a mesh network.

what do carriers normally provide for this type of situation? would a MPLS type carrier infrastruture fit the requirement ( i know thats a bit general)

any pointers with respect to this would be great

PS presently have a Hub and Spoke topology

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Rob Huffman Mon, 11/17/2008 - 06:34

Hey Arvind,

MPLS (with proper QOS) is an excellent choice here. There are some general recommendations and considerations from the CCM SRND below;

Clustering over the WAN can support two types of deployments:

•Local Failover Deployment Model

Local failover requires that you place the Cisco Unified CallManager subscriber and backup servers at the same site, with no WAN between them. This deployment model is ideal for two to four sites with Cisco Unified CallManager

•***Remote Failover Deployment Model

Remote failover allows you to deploy the backup servers over the WAN. Using this deployment model, you may have up to eight sites with Cisco Unified CallManager subscribers being backed up by Cisco Unified CallManager subscribers at another site.

You can also use a combination of the two deployment models to satisfy specific site requirements. For example, two main sites may each have primary and backup subscribers, with another two sites containing only a primary server each and utilizing either shared backups or dedicated backups at the two main sites.

The key advantages of clustering over the WAN are:

•Single point of administration for users for all sites within the cluster

•Feature transparency

•Shared line appearances

•Extension mobility within the cluster

•Unified dial plan

These features make this solution ideal as a disaster recovery plan for business continuance sites or as a single solution for up to eight small or medium sites.

For clustering over the WAN to be successful, you must carefully plan, design, and implement various characteristics of the WAN itself. The Intra-Cluster Communication Signaling (ICCS) between Cisco Unified CallManager servers consists of many traffic types. The following design guidelines apply to the indicated WAN characteristics:

•Delay

The maximum one-way delay between any Cisco Unified CallManager servers for all priority ICCS traffic should not exceed 20 ms, or 40 ms round-trip time (RTT).

•Jitter

Jitter is the varying delay that packets incur through the network due to processing, queue, buffer, congestion, or path variation delay. Jitter for the IP Precedence 3 ICCS traffic must be minimized using Quality of Service (QoS) features.

•Packet loss and errors

The network should be engineered to provide sufficient prioritized bandwidth for all ICCS traffic, especially the priority ICCS traffic. Standard QoS mechanisms must be implemented to avoid congestion and packet loss. If packets are lost due to line errors or other "real world" conditions, the ICCS packet will be retransmitted because it uses the TCP protocol for reliable transmission. The retransmission might result in a call being delayed during setup, disconnect (teardown), or other supplementary services during the call.

•Bandwidth

Provision the correct amount of bandwidth between each server for the expected call volume, type of devices, and number of devices. This bandwidth is in addition to any other bandwidth for other applications sharing the network, including voice and video traffic between the sites. The bandwidth provisioned must have QoS enabled to provide the prioritization and scheduling for the different classes of traffic. The general rule of thumb for bandwidth is to over-provision and under-subscribe.

•Quality of Service

The network infrastructure relies on QoS engineering to provide consistent and predictable end-to-end levels of service for traffic. Neither QoS nor bandwidth alone is the solution; rather, QoS-enabled bandwidth must be engineered into the network infrastructure.

From this excellent SRND reference;

Clustering Over the IP WAN

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/4x/42models.html#wp1045846

Hope this helps!

Rob

a.gooding Mon, 11/17/2008 - 06:49

Rob

thanks again as usual

so just to be clear with a transition of Hub/Spoke to MPLS the topology would now change from the previous to a "ring" with all locations being "independent" of each other from a WAN prospective. I.E. there wouldnt be any Main site that every location depends upon now but a series of sites that all other sites can reach.

Also from a strictly IPT propsective. we are looking at Three Main sites but locations connecting to either of the three sites are a total of 20 sites. im seeing that there are some limitations with respect to the amount of locations.

basically, we would have three "main sites" that are in one cluster. then 20 branch sites with SRST configured to register with any available of the three sites.

farouqtaj Mon, 11/17/2008 - 16:10

What version of Communication Manager are you running? and how far apart are these three sites?

Based on your initial description you have 3 clusters at present.

Ideally you should run a distributed cluster interconnected using an MPLS WAN. In this topology you can place the publisher on one site plus a subscriber server at each of the remote sites.

If your running version 6.1 of Communication Manager the round trip latency between servers can be upto 80ms. This will limit the geographic spread of the cluster.

The MPLS provider will be able to offer a Service Level Agreement covering latency, packet loss and jitter so make sure these meet the minimum requirements. Packet loss should be less than 1% and jitter less than 30ms.

a.gooding Mon, 11/17/2008 - 19:04

thats correct, three clusters at present and all are running 6.1.

Actions

This Discussion