Häufige CUCM-Probleme auf der UCS-Plattform: Core, hohe CPU - E/A, Hung State

Download-Optionen

  • PDF     (455.8 KB)
    Mit Adobe Reader auf verschiedenen Geräten anzeigen
  • ePub     (298.1 KB)
    In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
  • Mobi (Kindle)     (265.3 KB)
    Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen
Aktualisiert:6. Januar 2015
Dokument-ID:118702

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Einführung

In diesem Dokument wird beschrieben, wie fünf häufige Problemszenarien, die bei Cisco Unified Communications Manager (CUCM) auf der Unified Computing System (UCS)-Plattform aufgetreten sind, behoben werden.

Einige der häufigsten Ursachen sind:

  • Festplattenfehler
  • RAID-Controller-Fehler (Redundant Array of Independent Disks)
  • Ausfall der Akku-Sicherungseinheit (BBU)

Szenario 1: Hohe CPU-Auslastung aufgrund von E/A-Warteproblemen

Symptome

Neustart von Cisco Call Manager (CCM)- und Computer Telefony Integration (CTI)-Services über den CCM CTI-Core

Überprüfung

CUCM-Ablaufverfolgungen

Verwenden Sie die folgenden CLI-Befehle, um CUCM-Ablaufverfolgungen zu erfassen:

  • Anzeigeprozess mit der meisten CPU
  • Anzeigestatus
  • utils Core Active List
  • util core analyze output <last, last two output>

Überprüfen Sie die RTMT-Protokolle (Real-Time Monitoring Tool):

  • Detaillierter CCM
  • Detaillierte CTI
  • Real-Time Information Server (RIS) Data Collector PerfMonLogs
  • Ereignisanzeige-Anwendungsprotokolle
  • Ereignisanzeige-Systemprotokolle

Beispielausgabe

Hier einige Beispielausgabe:

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

Aus dem RIS Data Collector PerfMonLogs können Sie während der Kernzeit hohe Festplatten-E/A sehen.

Der Backtrace stimmt mit der Cisco Bug-ID CSCua79544 überein: Häufige CCM-Prozesskerne aufgrund hoher Festplatten-E/A Dieser Fehler beschreibt ein Hardwareproblem und erklärt, wie das Problem weiter isoliert werden kann.

Aktivieren Sie File I/O Reporting (FIOR):

Verwenden Sie diese Befehle, um FIOR zu aktivieren:

utils fior start
utils fior enable

Warten Sie dann auf das nächste Vorkommen. Der folgende CLI-Befehl dient zum Erfassen der Ausgabe: file get activelog platform/io-stats. Geben Sie die folgenden Befehle ein, um FIOR zu deaktivieren:

utils fior stop
utils fior disable

Hier einige Beispiele für die FIOR-Protokollausgabe:

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.

Lösung

E/A-WAIT ist in der Regel ein Problem mit der UCS-Plattform und deren Speicherung.

Das UCS-Protokoll ist erforderlich, um den Speicherort der Ursache zu isolieren. Anweisungen zum Erfassen der Ablaufverfolgungen finden Sie im Abschnitt UCS-Protokolle sammeln.

Szenario 2: Regelmäßiger Neustart des CUCM

Symptome

Der CUCM wird aufgrund eines ESXI-Absturzes neu gestartet, aber das zugrunde liegende Problem besteht darin, dass der UCS-Computer an Strom verliert.

Überprüfung

Untersuchen Sie die folgenden CUCM-Ablaufverfolgungen:

  • Cisco RIS Data Collector PerfMonLog
  • Ereignisanzeige - Anwendungsprotokoll
  • Ereignisanzeige - Systemprotokoll
  • Detaillierter CCM

Die CUCM-Spuren enthalten keine relevanten Informationen. Der CUCM wird vor dem Vorfall angehalten, und es wird ein normaler Service-Neustart durchgeführt. Dadurch wird CUCM eliminiert, und die Ursache liegt anderswo.

Das Problem liegt bei der UCS-Plattform, auf der der CUCM ausgeführt wird. Die UCS-Plattform verfügt über zahlreiche VM-Instanzen (Virtual Machine), die auf ihr ausgeführt werden. Wenn bei einer VM ein Fehler auftritt, wird dieser in den UCS-Protokollen angezeigt.

Das UCS-Protokoll ist erforderlich, um den Speicherort der Ursache zu isolieren. Anweisungen zum Erfassen der Ablaufverfolgungen finden Sie im Abschnitt UCS-Protokolle sammeln.

Beispiel für eine Ausgabe des Cisco Integrated Management Controller (CIMC)

Hier einige Beispielausgabe:

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

Lösung

Wenn dieser Fehler auftritt, wird Pilot2SrvPower.c:466:Blade-Leistung geändert in: [ AUS ] - Stromversorgungsproblem bedeutet, dass der UCS-Computer an Strom verliert. Daher sollten Sie sicherstellen, dass das UCS-System über ausreichend Leistung verfügt.

Szenario 3: CUCM-Abstürze

Symptome

Die CUCM-VM stürzt ab, reagiert jedoch weiterhin auf Pings. Auf dem Bildschirm der vSphere-Konsole werden folgende Informationen angezeigt:

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

Überprüfung

Untersuchen Sie die folgenden CUCM-Ablaufverfolgungen:

  • Cisco RIS Data Collector PerfMonLog
  • Ereignisanzeige - Anwendungsprotokoll
  • Ereignisanzeige - Systemprotokoll
  • Detaillierter CCM

Die CUCM-Spuren enthalten keine relevanten Informationen. Der CUCM wird vor dem Incident beendet und anschließend ein normaler Service-Neustart durchgeführt. Dadurch wird CUCM eliminiert, und die Ursache liegt anderswo.

Das Problem liegt bei der UCS-Plattform, auf der der CUCM ausgeführt wird. Auf der UCS-Plattform werden zahlreiche VM-Instanzen ausgeführt. Wenn bei einer VM ein Fehler auftritt, wird dieser in den UCS-Protokollen angezeigt.

Das UCS-Protokoll ist erforderlich, um den Speicherort der Ursache zu isolieren. Anweisungen zum Erfassen der Ablaufverfolgungen finden Sie im Abschnitt UCS-Protokolle sammeln.

Problemumgehung

Schalten Sie das virtuelle System aus, und starten Sie es neu. Nach dem Neustart funktioniert das System einwandfrei.

Szenario 4: CUCM reagiert nicht mehr

Symptome

Der CUCM-Server wechselt zu einem Status, an dem er aufgelegt wird.

Überprüfung

Untersuchen Sie die folgenden CUCM-Ablaufverfolgungen:

  • Cisco RIS Data Collector PerfMonLog
  • Ereignisanzeige - Anwendungsprotokoll
  • Ereignisanzeige - Systemprotokoll
  • Detaillierter CCM

Die CUCM-Spuren enthalten keine relevanten Informationen. Der CUCM wird vor dem Incident beendet und anschließend ein normaler Service-Neustart durchgeführt. Dadurch wird CUCM eliminiert, und die Ursache liegt anderswo.

Das Problem liegt bei der UCS-Plattform, auf der der CUCM ausgeführt wird. Auf der UCS-Plattform werden zahlreiche VM-Instanzen ausgeführt. Wenn bei einer VM ein Fehler auftritt, wird dieser in den UCS-Protokollen angezeigt.

Das UCS-Protokoll ist erforderlich, um den Speicherort der Ursache zu isolieren. Anweisungen zum Erfassen der Ablaufverfolgungen finden Sie im Abschnitt UCS-Protokolle sammeln.

Problemumgehung

Versuchen Sie einen manuellen Neustart, um festzustellen, ob er hilft.

Szenario 5: CUCM befindet sich im schreibgeschützten Modus

Symptome

Sie erhalten die folgende Fehlermeldung:

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

Überprüfung 

Der Publisher (PUB) und ein Subscriber (SUB), die auf demselben UCS-System installiert sind, zeigen den Schreibschutzmodus-Fehler an. Das Problem wird vom Wiederherstellungsdatenträger nicht behoben.

Die CUCM-Spuren enthalten keine relevanten Informationen. Der CUCM wird vor dem Incident beendet und anschließend ein normaler Service-Neustart durchgeführt. Dadurch wird CUCM eliminiert, und die Ursache liegt anderswo.

Das Problem liegt bei der UCS-Plattform, auf der der CUCM ausgeführt wird. Auf der UCS-Plattform werden zahlreiche VM-Instanzen ausgeführt. Wenn bei einer VM ein Fehler auftritt, wird dieser in den UCS-Protokollen angezeigt.

Das UCS-Protokoll ist erforderlich, um den Speicherort der Ursache zu isolieren. Anweisungen zum Erfassen der Ablaufverfolgungen finden Sie im Abschnitt UCS-Protokolle sammeln.

Lösung

Erstellen Sie nach dem Hardware-Ersatz die problematischen Knoten neu.

Sammeln von UCS-Protokollen

In diesem Abschnitt wird beschrieben, wie Sie die zur Identifizierung des Problems erforderlichen Spuren sammeln, oder es werden Links zu Artikeln bereitgestellt, die diese Informationen bereitstellen.

Sammeln von CIMC-Protokollen: Technik anzeigen

In diesen Artikeln finden Sie Informationen zum Erfassen von CICM-Protokollen:

Erfassung von Details zu Showtech mithilfe der Cisco CIMC-GUI

Visual Guide zum Sammeln von Dateien des technischen Supports (Serien B und C)

Sammeln von ESXI-Protokollen: Systemprotokolle

In diesem Artikel finden Sie Informationen zum Sammeln von ESXI-Protokollen:

Abrufen von Diagnoseinformationen für ESXi 5.x-Hosts mit dem vSphere-Client

CIMC CLI-Beispielausgabe

Im Folgenden finden Sie einige Beispiele für CIMC CLI-Ausgaben bei einem Festplattenfehler:

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

Nachfolgend finden Sie einige Beispiele für die CICM-CLI-Ausgabe beim Ausfall eines RAID-Controllers:

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

Beispielausgabe der CIMC GUI

Hier sehen Sie einige Beispiele für die CIMC-GUI-Ausgabe bei einem Festplattenfehler:

Hier sehen Sie einige Beispiele für die CIMC-GUI-Ausgabe bei einem Purple-Screen-Fehler:

( RAID-Controller-Ausfall | Fehler: CSCuh86924 ESXi PSOD, PF-Ausnahme 14 - LSI RAID-Controller 9266-8i)

Hier sehen Sie einige Beispiele für die CIMC-GUI-Ausgabe bei einem BBU-Fehler:

TAC Authored

Beiträge von Cisco Ingenieuren

  • Sivakumar Shanmugam
    Cisco TAC-Techniker

War dieses Dokument hilfreich?

FeedbackFeedback

Cisco kontaktieren

Dieses Dokument gilt für folgende Produkte.