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

在UCS平台的CUCM常见问题:核心,高CPU - I/O,挂起状态

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

简介

本文描述如何排除故障五个常见问题方案遇到与Cisco Unified Communications Manager (CUCM)统一计算系统(UCS)平台的。

某些常见原因是:

  • 硬盘故障
  • Redundant Array of Independent Disk (RAID)控制器故障
  • 备用电池单元(BBU)失败

贡献用Sivakumar Shanmugam, Cisco TAC工程师。

情形 1:高CPU利用率由于I/O等待问题

症状

Cisco Call Manager (CCM)和计算机电话集成(CTI)服务重新启动由于CCM CTI核心。

如何验证

CUCM跟踪

请使用这些CLI命令为了收集CUCM跟踪:

  • show process使用最cpu
  • show status
  • 使用情况核心活动列表
  • util核心分析<latest的输出,持续两output>

检查这些实时监控工具(RTMT)日志:

  • 详细的CCM
  • 详细的CTI
  • 实时信息服务器(RIS)数据收集器PerfMonLogs
  • 事件浏览器应用程序日志
  • 事件查看器系统日志

示例输出

这是若干输出示例: :

admin:utils core active list
Size Date Core File Name
===============================================
355732 KB 2014-X-X 11:27:29 core.XXX.X.ccm.XXXX
110164 KB 2014-X-X 11:27:25 core.XXX.X.CTIManager.XXXX
admin:util core analyze output 

====================================
CCM service backtrace
===================================
#0 0x00df6206 in raise () from /lib/libc.so.6
#1 0x00df7bd1 in abort () from /lib/libc.so.6
#2 0x084349cb in IntentionalAbort (reason=0xb0222f8 "CallManager unable to process
signals. This may be due to CPU or blocked function. Attempting to restart
CallManager.") at ProcessCMProcMon.cpp:80
#3 0x08434a8c in CMProcMon::monitorThread () at ProcessCMProcMon.cpp:530
#4 0x00a8fca7 in ACE_OS_Thread_Adapter::invoke (this=0xb2b04270) at OS_Thread_
Adapter.cpp:94
#5 0x00a45541 in ace_thread_adapter (args=0xb2b04270) at Base_Thread_Adapter.cpp:137
#6 0x004aa6e1 in start_thread () from /lib/libpthread.so.0
#7 0x00ea2d3e in clone () from /lib/libc.so.6
====================================
 
 
====================================
CTI Manager backtrace
===================================
#0 0x00b3e206 in raise () from /lib/libc.so.6
#1 0x00b3fbd1 in abort () from /lib/libc.so.6
#2 0x08497b11 in IntentionalAbort (reason=0x86fe488 "SDL Router Services declared
dead. This may be due to high CPU usage or blocked function. Attempting to restart
CTIManager.") at ProcessCTIProcMon.cpp:65
#3 0x08497c2c in CMProcMon::verifySdlTimerServices () at ProcessCTIProcMon.cpp:573
#4 0x084988d8 in CMProcMon::callManagerMonitorThread (cmProcMon=0x93c9638) at Process
CTIProcMon.cpp:330
#5 0x007bdca7 in ACE_OS_Thread_Adapter::invoke (this=0x992d710) at OS_Thread_
Adapter.cpp:94
#6 0x00773541 in ace_thread_adapter (args=0x992d710) at Base_Thread_Adapter.cpp:137
#7 0x0025d6e1 in start_thread () from /lib/libpthread.so.0
#8 0x00bead3e in clone () from /lib/li
====================================

在核心时间,从RIS数据收集器PerfMonLogs,您能看到高磁盘I/O。

backtrace匹配Cisco Bug ID CSCua79544 :常见的CCM进程核心由于高磁盘I/O。此bug描述硬件故障并且解释如何进一步隔离问题。

Enable (event)文件I/O报告(FIOR) :

请使用这些命令为了启用FIOR :

utils fior start
utils fior enable

然后,请等待下出现。这是CLI命令收集输出:文件获得activelog platform/io统计。输入这些命令为了禁用FIOR :

utils fior stop
utils fior disable

这是若干示例FIOR日志输出:

kern 4 kernel: fio_syscall_table address set to c0626500 based on user input
kern 4 kernel: fiostats: address of do_execve set to c048129a
kern 6 kernel: File IO statistics module version 0.99.1 loaded. 
kern 6 kernel: file reads > 265000 and writes > 51200 will be logged
kern 4 kernel: fiostats: enabled.
kern 4 kernel: fiostats[25487] started.

解决方案

I/O等待通常是一个问题用UCS平台和其存储设备。

UCS日志要求隔离原因的位置。参考如何收集UCS日志部分关于说明收集跟踪。

方案 2: CUCM周期地重新启动

症状

CUCM重新启动由于ESXI失败,但是基础问题是UCS计算机失去电源。

如何验证

检查这些CUCM跟踪:

  • 思科RIS数据收集器PerfMonLog
  • 事件浏览器应用程序日志
  • 事件查看器-系统日志
  • 详细的CCM

没什么相关在CUCM跟踪。CUCM在事件前终止,并且这被跟随正常服务重新启动。这排除CUCM并且表明原因在别处位于。

CUCM运行的UCS平台有问题。UCS平台有运行对此的许多虚拟机实例。如果任何VM遇到错误,则在UCS日志被看到。

UCS日志要求为了隔离原因的位置。参考如何收集UCS说明的日志部分关于如何收集跟踪。

示例(CIMC)输出的思科集成管理控制器

这是若干输出示例: :

5:2014 May 11 13:10:48:BMC:kernel:-:<5>[lpc_reset_isr_handler]:79:LPC Reset ISR ->
ResetState: 1
5:2014 May 11 13:10:48:BMC:kernel:-:<5>drivers/bmc/usb/usb1.1/se_pilot2_udc_usb1_1.c:
2288:USB FS: VDD Power WAKEUP- Power Good = OFF
5:2014 May 11 13:10:48:BMC:kernel:-:<5>[se_pilot2_wakeup_interrupt]:2561:USB HS:
VDD Power = OFF
5:2014 May 11 13:10:48:BMC:BIOSReader:1176: BIOSReader.c:752:File Close :
/var/nuova/BIOS/BiosTech.txt
5:2014 May 11 13:10:48:BMC:kernel:-:<5>[block_transfer_fetch_host_request_for_app]:
1720:block_transfer_fetch_host_request_for_app : BT_FILE_CLOSE : HostBTDescr = 27 :
FName = BiosTech.txt
5:2014 May 11 13:10:48:BMC:IPMI:1357: Pilot2SrvPower.c:466:Blade Power Changed To:
[ OFF ]
5:2014 May 11 13:10:49:BMC:lv_dimm:-: lv_dimm.c:126:[lpc_reset_seen]LPC Reset Count
is Different [0x1:0x2] Asserted LPC Reset Seen
 

解决方案

当您遇到此错误时, Pilot2SrvPower.c:466:Blade电源更改对:[OFF] -电源问题,意味着UCS计算机失去电源。因此,您应该保证那UCS计算机获得足够的功率。

情形 3: CUCM故障

症状

CUCM VM失败,但是仍然响应对ping。vSphere控制台屏幕显示此信息:

*ERROR* %No Memory Available*ERROR* %No Memory Available

如何验证

检查这些CUCM跟踪:

  • 思科RIS数据收集器PerfMonLog
  • 事件浏览器应用程序日志
  • 事件查看器-系统日志
  • 详细的CCM

没什么相关在CUCM跟踪。CUCM在事件前终止和由正常服务重新启动跟随。这排除CUCM并且表明原因在别处位于。

CUCM运行的UCS平台有问题。UCS平台有运行对此的许多VM实例。如果任何VM遇到错误,则在UCS日志被看到。

UCS日志要求为了隔离原因的位置。参考如何收集UCS说明的日志部分关于如何收集跟踪。

解决方法

停电VM和重新启动它。在重新启动,系统良好后工作。

场景 4: CUCM暂停

症状

CUCM服务器去暂停的状态。

如何验证

检查这些CUCM跟踪:

  • 思科RIS数据收集器PerfMonLog
  • 事件浏览器应用程序日志
  • 事件查看器-系统日志
  • 详细的CCM

没什么相关在CUCM跟踪。CUCM在事件前终止和由正常服务重新启动跟随。这排除CUCM并且表明原因在别处位于。

CUCM运行的UCS平台有问题。UCS平台有运行对此的许多VM实例。如果任何VM遇到错误,则在UCS日志被看到。

UCS日志要求为了隔离原因的位置。参考如何收集UCS说明的日志部分关于如何收集跟踪。

解决方法

设法手工的重新启动发现是否帮助。

场景 5: CUCM在只读模式

症状

您收到此错误:

The /common file system is mounted read only.Please use Recovery Disk to check
the file system using fsck.

如何验证 

在同样UCS计算机安装的发行商(PUB)和一个用户(SUB)显示只读模式错误。恢复磁盘不调整问题。

没什么相关在CUCM跟踪。CUCM在事件前终止和由正常服务重新启动跟随。这排除CUCM并且表明原因在别处位于。

CUCM运行的UCS平台有问题。UCS平台有运行对此的许多VM实例。如果任何VM遇到错误,则在UCS日志被看到。

UCS日志要求为了隔离原因的位置。参考如何收集UCS说明的日志部分关于如何收集跟踪。

解决方案

在硬件替换以后,请重建有问题的节点。

如何收集UCS日志

此部分描述如何收集必要的跟踪识别问题或提供链路给提供该信息的条款。

如何收集CIMC日志:Show tech

关于如何收集CICM日志的信息,参考这些条款:

使用收集思科CIMC的GUI show-tech详细信息

收集技术支持文件的视觉指南(B和C系列)

如何收集ESXI日志:系统日志

关于如何收集ESXI日志的信息,参考此条款:

获取使用vSphere客户端的ESXi 5.x主机的诊断信息 

示例CIMC CLI输出

这是从硬盘故障输出的某个示例CIMC CLI :

ucs-c220-m3 /chassis # show hdd
Name Status LocateLEDStatus
-------------------- -------------------- --------------------
HDD1_STATUS present TurnOFF
HDD2_STATUS present TurnOFF
HDD3_STATUS failed TurnOFF
HDD4_STATUS present TurnOFF
HDD5_STATUS absent TurnOFF
HDD6_STATUS absent TurnOFF
HDD7_STATUS absent TurnOFF
HDD8_STATUS absent TurnOFF
 
ucs-c220-m3 /chassis # show hdd-pid
Disk Controller Product ID Vendor Model
---- ----------- -------------------- ---------- ------------
1 SLOT-2 A03-D500GC3 ATA ST9500620NS
2 SLOT-2 A03-D500GC3 ATA ST9500620NS
3 SLOT-2 A03-D500GC3 ATA ST9500620NS
4 SLOT-2 A03-D500GC3 ATA ST9500620NS
 
 
ucs-c220-m3 /chassis/storageadapter # show physical-drive
Physical Drive Number Controller Health Status Manufacturer Model Predictive
Failure Count Drive Firmware Coerced Size Type
--------------------- ---------- -------------- ---------------------- ------
-------- -------------- ------------------------ -------------- -------------- -----
1 SLOT-2 Good Online ATA ST9500620NS 0 CC03 475883 MB HDD
2 SLOT-2 Good Online ATA ST9500620NS 0 CC03 475883 MB HDD
3 SLOT-2 Severe Fault Unconfigured Bad ATA ST9500620NS 0 CC03 0 MB HDD
4 SLOT-2 Good Online ATA ST9500620NS 0 CC03 475883 MB HDD

这是从RAID控制器故障输出的某个示例CICM CLI :

ucs-c220-m3 /chassis/storageadapter # show virtual-drive
Virtual Drive Health Status Name Size RAID Level Boot Drive
------------- -------------- -------------------- ---------------- ----------
---------- ----------
0 Moderate Fault Degraded 951766 MB RAID 10 true

示例CIMC GUI输出

这是从硬盘故障输出的某个示例CIMC GUI :

这是从一紫色屏幕Error:的若干示例CIMC GUI输出

(袭击控制器故障|缺陷:CSCuh86924 ESXi PSOD PF例外14 - LSI RAID控制器9266-8i)

这是从BBU失败输出的某个示例CIMC GUI :



Document ID: 118702