目录

简介

情形 1：由于I/O等待问题导致CPU使用率较高

症状

如何验证

示例输出

解决方案

场景2:CUCM定期重新启动

症状

如何验证

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

解决方案

场景3:CUCM崩溃

症状

如何验证

解决方法

场景4:CUCM挂起

症状

如何验证

解决方法

场景5:CUCM处于只读模式

症状

如何验证

解决方案

如何收集UCS日志

如何收集CIMC日志：显示技术

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

CIMC CLI输出示例

CIMC GUI输出示例

简介

本文档介绍如何对统一计算系统(UCS)平台上的思科统一通信管理器(CUCM)遇到的五种常见问题场景进行故障排除。

- 情形 1：由于I/O等待问题导致CPU使用率较高

- 场景2:CUCM定期重新启动

- 场景3:CUCM崩溃

- 场景4:CUCM挂起

- 场景5:CUCM处于只读模式

一些常见原因包括：

- 硬盘故障

- 独立磁盘冗余阵列(RAID)控制器故障

- 电池备用单元(BBU)故障

情形 1：由于I/O等待问题导致CPU使用率较高

症状

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

如何验证

CUCM跟踪

使用以下CLI命令收集CUCM跟踪：

- show process using-most cpu

- show status

- utils核心活动列表

- util core analyze output <latest , last two 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。

回溯匹配Cisco Bug ID CSCua79544:因高磁盘I/O而频繁使用CCM进程核心。此Bug描述硬件问题并说明如何进一步隔离问题。

启用文件I/O报告(FIOR):

使用以下命令启用FIOR:

utils fior start

utils fior enable

然后，等待下次发生。以下是用于收集输出的CLI命令：文件获取activelog平台/io-stats。输入以下命令以禁用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 WAIT通常是UCS平台及其存储的问题。

需要UCS日志来查明原因的位置。有关收集跟踪的说明，请参阅如何收集UCS日志部分。

场景2:CUCM定期重新启动

症状

CUCM因ESXI故障重新启动，但根本问题是UCS计算机断电。

如何验证

检查以下CUCM跟踪：

- Cisco RIS数据收集器性能监控日志

- 事件查看器 — 应用日志

- 事件查看器 — 系统日志

- 详细CCM

CUCM跟踪中没有相关内容。CUCM在事故发生前停止，并在正常服务重新启动后停止。这会消除CUCM，并表明原因在其他地方。

运行CUCM的UCS平台存在问题。UCS平台上运行着许多虚拟机(VM)实例。如果任何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：刀片电源更改为：[关闭] — 电源问题，表示UCS计算机断电。因此，您应确保UCS计算机获得足够的电源。

场景3:CUCM崩溃

症状

CUCM VM崩溃，但仍对ping做出响应。vSphere控制台屏幕显示以下信息：

*ERROR* %No Memory Available

*ERROR* %No Memory Available

如何验证

检查以下CUCM跟踪：

- Cisco RIS数据收集器性能监控日志

- 事件查看器 — 应用日志

- 事件查看器 — 系统日志

- 详细CCM

CUCM跟踪中没有相关内容。CUCM在事故发生前停止，然后是正常服务重启。这会消除CUCM，并表明原因在其他地方。

运行CUCM的UCS平台存在问题。UCS平台上运行着许多VM实例。如果任何VM遇到错误，则在UCS日志中会看到。

要查明原因的位置，需要使用UCS日志。有关如何收集跟踪的说明，请参阅如何收集UCS日志部分。

解决方法

关闭VM并重新启动。重新启动后，系统工作正常。

场景4:CUCM挂起

症状

CUCM服务器进入挂起状态。

如何验证

检查以下CUCM跟踪：

- Cisco RIS数据收集器性能监控日志

- 事件查看器 — 应用日志

- 事件查看器 — 系统日志

- 详细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日志：显示技术

有关如何收集CICM日志的信息，请参阅以下文章：

使用Cisco 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输出示例：

以下是紫屏错误的CIMC GUI输出示例：

(RAID控制器故障 |缺陷：CSCuh86924 ESXi PSOD PF异常14 - LSI RAID控制器9266-8i)

以下是BBU故障的CIMC GUI输出示例：