Backup strategy for CCM 4.1

Unanswered Question
Jun 18th, 2008
User Badges:

What is the best solution for increase fault tolerance solution for CCM, if I have the topology, like this. But every CCM cluster is situated only in HeadOffice#1. I have 1 Publisher and 1 Subscriber. Should I place Subscriber to HeadOffice#2 for more efficient fault tolerance, of should I place new one Subscriber for HeadOffice#2

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Rob Huffman Thu, 06/19/2008 - 04:54
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hi Alexandr,

If you can meet the requirements for installing the "Cluster over Wan" I would recommend deploying a new Subscriber at Head Office # 2 (***Remote Failover Deployment Model).

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:


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 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.


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

Hope this helps!



This Discussion