Inhalt

Einführung

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

Symptome

Überprüfung

Beispielausgabe

Lösung

Szenario 2: Regelmäßiger Neustart des CUCM

Symptome

Überprüfung

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

Lösung

Szenario 3: CUCM-Abstürze

Symptome

Überprüfung

Problemumgehung

Szenario 4: CUCM reagiert nicht mehr

Symptome

Überprüfung

Problemumgehung

Szenario 5: CUCM befindet sich im schreibgeschützten Modus

Symptome

Überprüfung

Lösung

Sammeln von UCS-Protokollen

Sammeln von CIMC-Protokollen: Technik anzeigen

Sammeln von ESXI-Protokollen: Systemprotokolle

CIMC CLI-Beispielausgabe

Beispielausgabe der CIMC GUI

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.

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

- Szenario 2: Regelmäßiger Neustart des CUCM

- Szenario 3: CUCM-Abstürze

- Szenario 4: CUCM reagiert nicht mehr

- Szenario 5: CUCM befindet sich im schreibgeschützten Modus

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: