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

CUCM发行商从用户数据库的节点恢复没有前期备份或根访问权限

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

简介

本文描述如何恢复从用户数据库(DB)的Cisco Unified Communications Manager (CUCM)发行商节点,不用前期备份或根访问权限。

贡献用亚当Frankel, Cisco TAC工程师。

背景

在CUCM中更早版本,发行商节点被认为结构化查询语言(SQL) DB的唯一的授权来源。结果,如果发行商节点丢失的归结于硬件故障或文件系统损坏,恢复它的唯一方法是重新安装和恢复从灾难恢复系统(DR)备份的DB。

一些客户没有保留是过时的适当的备份,也没有备份,因此唯一选择是重建和重新配置发布服务器节点。 

在CUCM版本8.6(1),新特性介绍为了恢复从用户数据库的发行商DB。本文描述如何利用此功能为了顺利地恢复从用户的发行商DB。

思科强烈建议您保留整个集群的一个全双工灾难恢复框架(DRF)备份。因为此进程只恢复CUCM DB配置,其他数据,例如证书, Music on Hold (MoH)和TFTP文件,没有被恢复。为了避免这些问题,请保留一个全双工集群DRF备份。 

注意:思科建议您查看并且熟悉在本文描述的整个过程,在您开始前。  

聚集团星数据

在您重新安装发行商前,非常重要的是您采集关于上一个发行商的有关详细信息。这些详细信息必须匹配原始发行商安装:

  • IP 地址
  • 主机名
  • 域名
  • 安全密码短语
  • 确切的CUCM版本
  • 已安装思科选项包(COPS)文件

为了获取在列表的前三个项目,请进入show network cluster命令在当前用户节点CLI :

admin:show network cluster
172.18.172.213 cucm911ccnasub1 Subscriber authenticated
172.18.172.212 cucm911ccnapub Publisher not authenticated - INITIATOR
 since Tue Dec 3 12:43:24 2013
172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
 Sun Dec 1 17:14:58 2013

在这种情况下, IP地址是172.18.172.212,主机名是cucm911ccnapub,并且没有为发行商配置的域名。   

安全密码短语(在列表的第四个项目)从站点文档获取。如果对安全密码短语是不确定的,请做一个最佳效果猜测,并且您能尝试验证和更正它当必要时根据CUCM版本。如果安全密码短语不正确,则集群中断要求为了校正情况。 

为了检索确切的CUCM版本和已安装COPS文件(在列表的最后两个项目),请采集从active命令的show version的系统产出量:

admin:show version active
Active Master Version: 9.1.2.10000-28
Active Version Installed Software Options:
No Installed Software Options Found.

在这种情况下,版本9.1.2.10000-28安装没有添加COPS文件。 

注意:很可能,一些COPS文件在发行商以前安装,但是未安装在用户,反之亦然。请使用此输出作为仅指南。

终止在所有用户的复制

当发行商安装时,非常重要的是复制不设置并且删除当前用户Dbs。为了防止此,请输入使用情况dbreplication stop命令在所有用户:

admin:utils dbreplication stop
********************************************************************************
This command will delete the marker file(s) so that automatic replication setup
is stopped
It will also stop any replication setup currently executing
********************************************************************************

Deleted the marker file, auto replication setup is stopped

Service Manager is running
Commanded Out of Service
A Cisco DB Replicator[NOTRUNNING]
Service Manager is running
A Cisco DB Replicator[STARTED]

Completed replication process cleanup

Please run the command 'utils dbreplication runtimestate' and make sure all nodes
are RPC reachable before a replication reset is executed

安装CUCM发行商

采集适当的版本的可启动的镜像,并且执行安装与升级对适当的版本。

注意:多数CUCM Engineering Special (ES)版本已经是可启动的。

安装发行商并且指定以前被提及的IP地址、主机名、域名和安全密码短语的正确值。 

更新在发行商的Processnode值

注意:发行商一定知道至少一用户服务器为了恢复从该用户的DB。思科建议您添加所有用户。 

为了获取节点列表,请输入运行SQL挑选名称,说明,从processnode at命令的nodeid一个当前用户的CLI。命名值可以是主机名、IP地址或者完全合格的域名(FQDN)。

如果运行CUCM版本10.5(2)或以上, disaster_recovery准备恢复pub_from_sub命令的使用情况在发行商CLI必须运行,在您能继续添加节点到System > Server前

在您接收节点列表后,请导航对System > Server并且添加所有命名值除EnterpriseWideData之外到发布服务器统一的CM管理页面。命名值必须对应于主机名/IP地址字段System > Server菜单。

admin:run sql select name,description,nodeid from processnode
name description nodeid
================== =============== ======
EnterpriseWideData 1
172.18.172.212 CUCM901CCNAPub 2
172.18.172.213 CUCM901CCNASub1 3
172.18.172.214 CUCM901CCNASub2 4

注意:默认安装添加发行商主机名到processnode表。如果名称列列出发行商的,一个IP地址您也许必须更改它到IP地址。在这种情况下,请勿删除发行商条目,然而打开并且修改当前主机名/IP地址字段。 

重新启动发行商节点

为了重新启动发行商,在processnode更改完成后,请输入使用情况系统重新启动命令:

admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes

Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...
 \Service Manager shutting down services... Please Wait

Broadcast message from root (Tue Dec 3 14:29:09 2013):

The system is going down for reboot NOW!
Waiting .

Operation succeeded

验证团星验证

在发行商重新启动,如果正确地后做了变动,并且安全密码短语正确,集群应该在已验证状态。为了验证此,请进入cluster命令的show network

admin:show network cluster
172.18.172.212 cucm911ccnapub Publisher authenticated
172.18.172.213 cucm911ccnasub1 Subscriber authenticated using TCP since
 Tue Dec 3 14:24:20 2013
172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
 Tue Dec 3 14:25:09 2013

注意:如果用户没出现如验证,参考本文的Troubleshoot部分为了解决此问题,在您继续前。

执行新的备份

如果上一个备份不是可用的,请执行在DR页的一个集群备份。

注意:虽然您能使用用户DB恢复,备份仍然要求为了恢复非DB组件。

如果备份不是可用的,则请执行新的;如果备份已经存在,则您能跳过此部分。 

添加备份设备

请使用导航菜单为了导航到灾难恢复系统,并且添加备份设备。

开始手动备份

在备份设备被添加后,请开始一个手动备份。

注意:非常重要的是发行商节点有注册的CCMDB组件。

从用户DB的发行商恢复

在灾难恢复系统页,请导航恢复>恢复向导。如果一个当前备份是可用的,并且跳过了前面部分,请检查所有在挑选特征部分的功能复选框:企业许可证管理器(榆木)若有, CDR_CAR和统一通信管理器(UCM)。如果使用在前面部分被执行的一个备份,请检查仅UCM复选框:

单击 Next。检查发行商Node复选框(CUCM911CCNAPUB),并且选择恢复发生的用户DB。然后,请点击恢复

恢复状态

当恢复到达CCMDB组件时,状态文本应该出版作为恢复从用户备份端口:的发行商

进行在发行商DB的健全性检查

在您重新启动并且设置复制前,它是良好的做法验证恢复是成功的,并且发行商DB包含必填信息。保证这些查询返回在发布服务器和用户节点的同样值,在您继续前:

  • 从设备运行SQL挑选计数(*)
  • 从最终用户运行SQL挑选计数(*)

重新启动团星

在恢复完成后,请输入使用情况系统重新启动on命令每个节点。从每个用户跟随的发行商开始。

admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes

Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...
 \ Service Manager shutting down services... Please Wait

Broadcast message from root (Tue Dec 3 14:29:09 2013):

The system is going down for reboot NOW!
Waiting .

Operation succeeded

验证复制设置需求

导航对报告页的Cisco Unified并且生成一份Unified CM数据库状态状态报告。很可能复制也许没有设置,但是请注意Unified CM主机,统一CM Rhosts,并且统一的CM Sqlhosts文件匹配发行商。如果他们不,不配比的那些节点将需要再重新启动。如果这些文件不配比,请勿继续对下一步也请勿重置复制。

复制设置

从属在版本,复制也许不自动地设置。为了检查此,等待所有服务开始和输入使用情况dbreplication runtimestate命令。状态值为0表明设置进展中,而值为2表明复制为该节点成功设置。

此输出表明复制设置进展中(状态出现作为0两的节点) :

此输出表明复制成功设置:

如果任何节点显现状态值为4,或者,如果复制不在几个小时之后成功设置,请输入使用情况dbreplication reset all命令从发行商节点。如果复制继续发生故障,参考在Linux设备型号Cisco条款的故障排除CUCM数据库复制关于如何排除故障问题的更多信息。 

波斯特恢复

因为DB恢复不恢复所有上一个组件,必须手工安装或恢复许多服务器级别项目。

启动服务

DRF恢复不启动任何服务。导航对Tools > Service激活,并且根据从Unified维护性页的站点文档启动发行商应该管理的所有必要的服务, :

安装未恢复的数据

如果完全备份不是可用的,您必须再生产某些手动配置。特别,介入证书并且TFTP功能的那些配置:

  • MoH文件
  • 设备装箱
  • 拨号计划(非北部美国编号方案(NANP)正在拨号)
  • 区域设置
  • 任何其他其他COPS文件
  • 手工以前上传给发行商的任何文件(如果它是TFTP server)
  • 简单网络管理协议(SNMP)社区字符串
  • Extension Mobility交叉团星(EMCC),簇之间位置带宽管理器(LBM)和簇之间查找服务的(ILS)大批证书出口
  • 证书交换为巩固中继、网关和会议桥

注意:对于mixed-mode集群,您必须再运行证书信任列表(CTL)客户端。

故障排除

此部分描述也许造成此步骤发生故障的多种方案。

团星不验证

如果集群不验证,两个多数常见原因是不匹配的安全passphrases和连通性问题在TCP端口8500。

为了验证集群安全passphrases配比,请输入使用情况Create报告平台at命令两节点CLI,并且检查Hash值从platformConfig.xml文件。这些在发布服务器和用户节点应该配比。

  <IPSecSecurityPwCrypt>
<ParamNameText>Security PW for this node</ParamNameText>
<ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
12812AB2825C831812812AB2825C
</ParamValue>
</IPSecSecurityPwCrypt>

如果这些配比,请验证在端口8500的TCP连接。如果他们不配比,也许有困难,当您尝试修复密码短语由于包围步骤在CUCM代码时的几个缺陷:

  • Cisco Bug ID CSCtn79868 -重置仅sftpuser密码的pwrecovery工具
  • Cisco Bug ID CSCug92142 - pwrecovery工具不更新内部用户密码
  • Cisco Bug ID CSCug97360 -在pwrecovery工具的selinux否认
  • Cisco Bug ID CSCts10778 -为安全密码恢复流程投掷的否认
  • Cisco Bug ID CSCua09290 - CLI “set password用户安全”没有设置正确apps密码
  • Cisco Bug ID CSCtx45528 - pwd重置好cli的回归,但是不更改密码
  • Cisco Bug ID CSCup30002 - DB服务发生故障,在更改在CUCM 10.5的安全密码以后
  • Cisco Bug ID CSCus13276 - CUCM 10.5.2安全密码恢复开始的原因DB在重新启动

如果CUCM版本包含所有的修正这些问题,最容易的解决方案将完成在Cisco Unified通信操作系统的管理指南选派的密码恢复流程,发布10.0(1)在所有节点。如果CUCM版本不包含这些问题的修正,则Cisco技术支持中心(TAC)也许有能力执行应急方案,从属在情况。 

恢复不处理CCMDB组件

如果恢复不列出DB组件,则很可能,备份不包含DB组件。保证发行商DB运行,并且能接受查询,并且执行一个新的备份。

复制失败

参考在Linux设备型号Cisco条款的故障排除CUCM数据库复制为了排除故障复制失败。

电话不注册也不无法访问服务

因为DB恢复不恢复任何证书,如果发行商是主要的TFTP server,签署人不同的。如果电话信任用户托拉斯验证服务(TV)证书和TCP端口2445是开放的在电话和TV服务器之间,应该自动地解决问题。为此,思科建议您维护全双工集群DRF备份。 

在版本8.6之前的CUCM版本也许也有证书问题,与一个上一个成功的备份,由于Cisco Bug ID CSCtn50405

注意:参考通信管理器安全默认情况下和ITL操作和故障排除Cisco条款关于如何排除故障最初的托拉斯列表(ITL)文件的更多信息。


相关的思科支持社区讨论

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


Document ID: 116946