2.5 跨越IP WAN的集群部署模型
实施Cisco统一通信管理器（CIPT1）
Cisco支持跨越WAN部署CUCM集群。这种模型拥有以下特点。
- 同一集群的应用和CUCM服务器通过IP WAN分布在各个站点中。
I- P WAN负责承载集群内部服务器之间的通信与信令。 - 站点的数量存在以下限制。
- 若部署的是本地故障倒换（Failover），则只能部署2～4个站点（每个站点部署2台CUCM服务器）。
- 若通过IP WAN实现远程故障倒换（Failover），则最多部署8个站点（每个站点部署1台CUCM服务器）。
如果客户所需要的功能，比SRST所能提供的那几个特性集更加丰富，那么这类客户，就不妨使用这种部署方式，如图2-4所示。另外，在主用CUCM连接断开的情况下，这种部署方式所支持的IP电话数量也多于SRST。
部署跨越WAN的CUCM集群模型的指导方针如下。
- 同一集群内两台CUCM之间的最大往返延迟时间（RTT）不得大于40 ms。由于数据库复制需求就是严格的40 ms，因此这种部署方式只适合在高速站点之间实施。打个比方说，这两个站点不能分别位于美国的东西海岸，因为光速也无法实现纽约和加州之间的往返40 ms的通信（转发延迟过大）。与严格的RTT数据库需求相比，高质量语音通信的指导方针也显得小巫见大巫，因为它只要求单向端到端的延迟不超过150 ms。
- 集群中每10000次忙时试呼（BHCA），就会占用900 kbit/s的WAN带宽来实现集群内的实时通信。BHCA表示在网络最繁忙的时间段内，用户所发起的呼叫尝试次数。
- 远程故障倒换部署模型只支持最多8个小型站点，每个站点一台服务器，也就是每个集群最多8台呼叫处理服务器。在CUCM故障倒换时，IP电话就会通过WAN注册到另一台服务器上。在这种部署模型中，不需要使用SRST。远程故障倒换的设计方式所需要的带宽可能会非常大，所需带宽的多寡取决于各站点的电话数量。
注意：
在CUCM的早期版本中，集群中的Sub服务器是使用Pub的数据库来进行读/写访问的，在Pub数据库不可用的情况下，它们只能使用自己的本地数据库进行只读操作。
而在CUCM 6.x版本中，集群中的Sub服务器可以读取它们的本地数据库，还可以对本地数据库进行修改（对于一些特殊的应用，如面向用户特性）。集群中的多台服务器使用IBM Informix动态服务器（IDS）数据库复制功能进行同步。因此，如果WAN链路断开了一段时间，那么在错误恢复后，CUCM数据库必须将断开期间实施的所有修改都进行同步。当链路重新连接起来并接管低带宽链路来传输流量之后，这个过程就会自动产生。在很罕见的情况下，也有可能需要管理员手动去修复集群中服务之间的数据库复制。管理员可以在命令行界面（CLI）中使用命令utils dbreplication repair all和utils dbreplication reset al来执行这个重置/修复行为。不过，在远程Sub上输入CLI命令来通过WAN修复或重置数据库复制的行为，可能会导致集群中所有CUCM的数据库重新进行同步，在这种情况下，数据库重新同步行为有可能会占用链路上超过1.544 Mbit/s的带宽。在重置/修复完成之后，低带宽的链路就会被替换掉。
尽管这种部署模型在设计上存在着严格的要求，但它仍具有以下优势。
- 可以单点管理同一个集群中的所有站点中的所有用户。
- 特性的透明性。
- 共享线路的显示。
- 集群内的EM（移动分机）特性。
- 统一的拨号计划。
有些客户希望将这种部署模型的快速恢复优势与各站点的本地呼叫处理代理所提供的优势结合起来，跨越WAN的CUCM集群模型就可以满足这种需求。它可以使集群内信令保持在集群内，而WAN链路的失效也不会影响到语音网络的功能。另外，在WAN断开的情况下，这种网络设计方式所支持的Cisco IP电话也多于SRST。
上述这些特性使得跨越WAN的CUCM集群模型成为了一个理想的灾难恢复方案，它可以保证站点间业务的连续性，确保它们之间的业务不会出现中断，也可以把不超过8个中小型站点的部署环境当作一个单独的解决方案。