语音和统一通信 : Cisco Unified Communications Manager (CallManager)

升级 Cisco CallManager 集群

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 22 日) | 反馈


目录


简介

本文打算为如何升级Cisco CallManager集群提供一些高层次建议。随附于Cisco CallManager软件的安装说明提供所有关于安装步骤的详细信息。本文,然而,讨论集群升级提交的某些其他问题。

先决条件

要求

在您开始升级前,请验证这些项目:

  • 运行最新的OS/BIOS补丁程序。

    参考的Cisco IP电话BIOS和操作系统版本规划图关于如何保持您的Cisco IP电话服务器的信息最新状态。

  • 验证MSSQL服务运作。否则,请验证SQLsvc密码。

    参考恢复SQLsvc帐户密码

  • 查看IP电话解决方案兼容性信息的Cisco Unified Communications Manager软件兼容表

  • 验证在您的集群的所有服务器使用同样DB在START > RUN > REGEDIT > HKEY_LOCAL_MACHINE \软件\ Cisco系统下, Inc \ DBL

    验证DBConnection0 (在SERVER=Publisher名称和DATABASE=CCM030X下)是最新一个在发布服务器,而DBConnection 1应该指向注册用户的名字最新的Cisco CallManager数据库。

  • 验证复制是好的在使用Microsoft SQL企业管理器的所有服务器。这查找在Start > Programs > Microsoft SQL Server 7.0 >企业管理器

  • 禁用所有思科审批的反病毒和入侵检测服务。

  • 您有超过可用空间1 Gig。推荐这。

    注意: 确保禁用Callmanager跟踪和删除未使用文件例如跟踪文件为了释放空间。

  • 因为不支持,请勿使用终端服务它。反而,请使用支持的虚拟网络计算(VNC)。

注意: 如果有一个袭击控制器,带一张磁盘出去,在您升级并且确保您有最后版本的备份前。万一升级发生故障,这使您回到上一个工作配置。

使用的组件

本文档不限于特定的软件和硬件版本。

规则

有关文档规则的详细信息,请参阅 Cisco 技术提示规则

升级发行商

因为Cisco CallManager集群在发行商/用户数据库关系附近根据,首先升级发行商是重要的。当升级发生时,一个新的数据库在发行商创建,并且从旧有数据库的数据被迁移到它。这启用其中任一对容易地被处理的数据库模式的新的更改。当用户被添加时,他们订阅对在发行商的新的数据库。所以发行商必须首先升级。用户不能订阅到不存在的数据库。此图表说明发行商/用户关系,以及呼叫信令关系。

注意: 有CTI ID= 1的CallManager服务器可以识别作为发布服务器。为了查找CTI ID,请去CCM Admin网页>System > Cisco CallManager,从搜索结果请点击服务器并且检查CTI ID

/image/gif/paws/7426/40784.gif

是否必须为升级减少所有思科CallManager ?

不能。在一个大校园,它能纳税在动态主机配置协议(DHCP)服务器收到从千位的IP地址请求电话两三个小时。或者,它也许是不理想的为了所有电话服务能发生故障在延长的升级时间。当应该在几小时之后时执行升级,保持集群运行的部分在升级期间,在许多情况下是可能的。这可以由使用Cisco CallManager冗余组完成。本质上,而一个服务器升级,支助所有电话。本文讨论三个标准的部署模型。

推荐的集群配置

2,500 个电话 - 总共三个服务器

2500个用户的Cisco CallManager集群:

  • 服务器A是一个专用的数据库发布者和简单文件传输协议(TFTP)服务器。

  • 服务器B是所有注册的设备的主Cisco CallManager。

  • 服务器C是所有注册的设备的备用Cisco CallManager。

在此配置中,仅一个Cisco CallManager冗余组为服务器B和C要求。

  1. 因为发行商是将升级的第一个,这是进程开始的地方。发行商A是仅数据库服务器,因此可以升级和重新启动。

  2. 升级能为Cisco CallManager C开始。因为Cisco CallManager C是备份并且没有设备注册对它,没有中断呼叫处理。另外,如果在主Cisco CallManager前升级备用Cisco CallManager,这保证设备只需要升级他们的固件一次。

  3. 主Cisco CallManager B可以升级。当升级开始时, Cisco CallManager服务被终止和对备用Cisco CallManager C的设备故障切换。当设备注册并且接收固件更新时,有一个轻微的中断在使用中。

  4. 升级进程的最后一步将重新启动所有在集群的服务器。开始通过重新启动发行商A。一旦重新启动完成,请重新启动Cisco CallManager B。当服务器在线路时回来,请等允许设备的5到10分钟开始Failback进程。最后,重新启动Cisco CallManager C。集群升级当前完成。

5,000 个电话 - 总共四个服务器

5000个用户的Cisco CallManager集群:

  • 服务器A是专用的数据库发布者和TFTP server。

  • 服务器B是IP电话的1至2500主Cisco CallManager。

  • 服务器C是IP电话的2501至5000主Cisco CallManager。

  • 服务器D是所有注册的设备的备用Cisco CallManager。

在此配置中,两个Cisco CallManager冗余组要求。一是为服务器B和D,并且其他是为服务器C和D。

在此方案中,有与一个备份的两主Cisco CallManager。如果每主要的有2,500个电话,您不能中断两主服务器为升级目的。备份将最终获得5,000个设备,将违犯2,500限制。

  1. 发行商A首先升级。然后,应该升级Cisco CallManager D。至此点,未中断呼叫处理。

  2. 一旦Cisco CallManager D再是UP,请开始在Cisco CallManager B的升级。一旦升级开始,对Cisco CallManager D.的设备故障切换。因为设备注册并且接收固件更新,有服务的一个轻微的中断。当Cisco CallManager B在线路时回来,为设备请等5到10分钟对Failback。

  3. 升级Cisco CallManager C。因为设备向Cisco CallManager D登记并且接收固件更新,有服务的一个轻微的中断。

  4. 为了完成升级进程,必须重新启动在集群的所有服务器。重新启动发行商首先A。当重新启动完成时,请重新启动Cisco CallManager B。当B在线路时回来,为设备请等5到10分钟对Failback。其次,重新启动Cisco CallManager C和等待直到服务器在线路回来。最后,重新启动Cisco CallManager D。集群升级当前完成。此情况造成半电话发生故障在第二主要的升级的时期。当这不是理想的时,最小化多少个电话发生故障,并且他们多久发生故障为。

10,000 个电话 - 总共八个服务器

10,000个用户的Cisco CallManager集群:

  • 服务器A是专用的数据库发布者。

  • 服务器B是专用TFTP服务器。

  • 服务器C是IP电话的1至2500主Cisco CallManager。

  • 服务器D是IP电话的2501至5000主Cisco CallManager。

  • 服务器E是IP电话的1至5000备用Cisco CallManager。

  • 服务器F是IP电话的5001至7500主Cisco CallManager。

  • 服务器G是IP电话的7501至10,000主Cisco CallManager。

  • 服务器H是IP电话的5001至10,000备用Cisco CallManager。

在此配置中,四个Cisco CallManager冗余组为服务器CE、DE、FH和GH要求。此图表说明此配置:

/image/gif/paws/7426/42657.gif

  1. 升级发行商。

  2. 升级TFTP server。

    这时,全部六个Cisco CallManager服务器仍然和未影响由升级负责。此方案是正如在5,000个电话方案描述的那个。唯一的差异是有两套与备份的两主要。主Cisco CallManager是C、D、F和G。备份是E和H. Primary C和D失败对E. Primary F和G失败对H。

  3. 应该其次升级备用Cisco CallManager E和H。当升级完成时,请等待服务器重新启动和回来在线路。

  4. 现在思科CallManager C and F准备升级。当升级开始时,设备注册对这些思科CallManager故障切换对备份。当设备注册并且接收固件更新时,有服务的一个轻微的中断。等待设备的5到10分钟对Failback。

  5. 其次,思科CallManager D和G升级。正如在步骤4,有一个轻微的中断在使用中。当升级完成时,请等待服务器重新启动和回来在线路。

  6. 为了完成升级,必须重新启动所有在集群的服务器。确保每重新启动进程完成,在您开始下一组前。通过重新启动发行商开始A。其次,重新启动TFTP B。当B是回到在线路时,请重新启动思科CallManager C and F。等待设备的5到10分钟对Failback然后重新启动思科CallManager D和G。最后,重新启动思科CallManager E和H。集群升级当前完成。

复核:Cisco CallManager升级的规则

当您升级Cisco CallManager时,请遵从这些规则:

  • 首先总是请升级发行商和独立TFTP server (如果存在)。

  • 其次升级备用Cisco CallManager。

  • 升级主Cisco CallManager持续。

  • 在所有思科CallManager升级后,必须重新启动所有服务器。

  • 确保,当SA和管理员密码设置他们是相同的为在集群的所有服务器。

当安装/升级发生失败时,该做什么?

Cisco CallManager 3.1 和 3.2

采集这些日志:

  • C:\ *.log

  • C:\ *.txt

  • C:\Winnt\sti *.*

  • C:\dcdsrvr\log\ *.* (如果问题是DCD)

  • C:\Install\DBInstall\ *.*

在安装/升级期间, StiSetup.log提供不同的阶段的概述。Dbinstall000.log在什么更改提供一概述在数据库级别上完成。

Cisco CallManager 3.3

采集这些日志:

  • 所有*.txt & *.log文件在根目录C:\

  • 在C的所有文件:\程序文件\普通文件\思科\日志目录

  • 在STI_DATA分区的所有文件

  • 在C:\DCDSrvr\log (如果问题是DCD)目录的)所有文件

在安装/升级期间, CCMInst<date><time>.log提供不同的阶段的概述。CCMDBSetup<date><time>.log在什么更改提供一概述在数据库级别上完成。

Cisco CallManager 4.x

得到并且查看所有日志文件(*.log和*.txt)从这些目录:

  • 在C:\Program Files\Common文件\思科\日志的所有文件

  • 在C:\Program Files\Common文件\思科\目录的所有文件

  • 在C:\Install\DBInstall的所有文件

  • 在C:\Dcdsrvr\log的所有文件

不是在日志文件显示的所有的错误消息是灾难的。MSI由于许多原因生成在日志文件的错误消息。例如,尝试访问Cisco CallManager不使用的服务。

参考升级Cisco CallManager 4.x欲知更多信息。

注意: 仅请使用管理程序在发行商为了解决密码同步问题。

事件查看器:应用程序和系统登录.evt格式

注意: 不是所有的错误与真正的问题关连。在您开有思科技术支持的前,一个Case总是请验证。

参考CallManager事件日志欲知更多信息。本文频繁地更新。

您聚集是有用的为了TAC工程师能调查详细您的问题的日志。所以,总是请更新有这些日志的TAC案例,这加速问题解决进程。

相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


相关信息


Document ID: 7426