目錄

簡介

案例 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

- 顯示狀態

- utils core active list

- 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。

回溯與思科錯誤ID CSCua79544相符：由於高磁碟I/O而導致CCM進程核心頻繁出現。此錯誤說明一個硬體問題，並說明如何進一步隔離問題。

啟用檔案I/O報告(FIOR):

使用以下命令以啟用FIOR:

utils fior start

utils fior enable

然後，等待下一次發生。以下是用於收集輸出的CLI命令：file get activelog platform/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資料收集器PerfMonLog

- 事件檢視器 — 應用程式日誌

- 事件檢視器 — 系統日誌

- 詳細的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:Blade Power Changed to:[ OFF ] — 電源問題，這意味著UCS電腦斷電。因此，您應該確保UCS機器獲得足夠的功率。

場景3:CUCM崩潰

症狀

CUCM VM崩潰但仍響應ping。vSphere控制檯螢幕顯示以下資訊：

*ERROR* %No Memory Available

*ERROR* %No Memory Available

如何驗證

檢查以下CUCM跟蹤：

- Cisco RIS資料收集器PerfMonLog

- 事件檢視器 — 應用程式日誌

- 事件檢視器 — 系統日誌

- 詳細的CCM

CUCM跟蹤中沒有任何相關內容。CUCM在事件之前停止，然後正常服務重新啟動。這將消除CUCM並表明原因位於其他位置。

運行CUCM的UCS平台存在問題。UCS平台上有許多VM例項在其上運行。如果任何VM遇到錯誤，則會在UCS日誌中看到它。

需要UCS日誌才能確定原因的位置。有關如何收集跟蹤的說明，請參閱如何收集UCS日誌部分。

因應措施

關閉VM並重新啟動。重新引導後，系統工作正常。

場景4:CUCM掛起

症狀

CUCM伺服器進入掛起狀態。

如何驗證

檢查以下CUCM跟蹤：

- Cisco 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日誌：顯示技術

有關如何收集CICM日誌的資訊，請參閱以下文章：

使用Cisco CIMC GUI收集show-tech詳細資訊

收集技術支援檔案（B和C系列）的可視指南

如何收集ESXI日誌：系統記錄

有關如何收集ESXI日誌的資訊，請參閱以下文章：

使用vSphere客戶端獲取ESXi 5.x主機的診斷資訊

CIMC CLI輸出示例

以下是「Hard Disk Failure（硬碟故障）」的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輸出示例

以下是「Hard Disk Failure（硬碟故障）」的CIMC GUI輸出示例：

以下是紫屏錯誤的一些CIMC GUI輸出示例：

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

以下是BBU故障產生的一些CIMC GUI輸出示例：