Clustering over the IP WAN

Cisco supports CUCM clusters over a WAN. Characteristics include the following:

■ Applications and CUCM of the same cluster distributed over the IP WAN.

■ IP WAN carries intracluster server communication and signaling.

■ Limited number of sites:

—Two to four sites for local failover (two CUCM servers per site)

—Up to eight sites for remote failover across the IP WAN (one CUCM server per site)

The cluster design, as illustrated in Figure 2-4, is useful for customers who require more functionality than the limited feature set offered by SRST. This network design also allows remote offices to support more IP phones than SRST in the event that the connection to the primary CUCM is lost.

Cluster Cisco Cucm Wan

The design guidelines for clustering over the IP WAN are as follows:

■ Two CUCM servers in a cluster must have a maximum round-trip time (RTT) delay of 40 ms between them. Because of the strict 40-ms database replication requirement, this design can be used only between high-speed locations. The sites cannot be located on separate coasts of the United States, for example, because the speed of light is not capable of communicating between New York and California (propagation delay). In comparison to this strict RTT database requirement, high-quality voice guidelines dictate that one-way end-to-end delay should not exceed 150 ms.

■ For every 10,000 busy hour call attempts (BHCA) within the cluster, an additional 900 kb/s of WAN bandwidth for intracluster runtime communication must be supported. The BHCA represents the number of call attempts made during the busiest hour of the day.

■ Up to eight small sites are supported using the Remote Failover deployment model. Remote failover allows one server per location with a maximum of eight call-processing servers supported in a cluster. In the event of CUCM failure, IP phones register to another server over the WAN. SRST is not required in this deployment model. The remote failover design may require significant additional bandwidth, depending on the number of telephones at each location.

NOTE In earlier versions of CUCM, subscriber servers in the cluster used the publisher's database for read/write access, and they used their local database for read access only when the publisher's database could not be reached.

With CUCM 6.x, subscriber servers in the cluster read their local database. Database modifications can occur in the local database (for special applications such as user-facing features). IBM Informix Dynamic Server (IDS) database replication is used to synchronize the databases on the various servers in the cluster. Therefore, when recovering from failure conditions such as the loss of WAN connectivity for an extended period of time, the CUCM databases must be synchronized with any changes that might have been made during the outage. This process happens automatically when database connectivity is restored and can take longer over low-bandwidth links.

In rare scenarios, manual reset or repair of the database replication between servers in the cluster might be required. This reset/repair is performed by using commands such as utils dbreplication repair all and utils dbreplication reset all at the command-line interface (CLI). Repair or reset of database replication using the CLI on remote subscribers over the WAN causes all CUCM databases in the cluster to be resynchronized, in which case additional bandwidth above 1.544 Mb/s might be required. Lower bandwidths can take longer for database replication repair or reset to complete.

Although there are stringent requirements, clustering over the IP WAN design offers these advantages:

■ 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

The clustering over IP WAN design is useful for customers who want to combine the resiliency advantages of this model with the benefits provided by a local call-processing agent at each site. Intrasite signaling is kept local, and WAN failures will not result in loss of functionality. This network design also allows remote offices to support more Cisco IP Phones than SRST in the event of WAN failure.

These features make clustering across the IP WAN ideal as a disaster recovery plan for business-continuance sites or as a single solution for up to eight small or medium sites.

Was this article helpful?

+3 -2

Post a comment