Contenu

Introduction

Scénario 1 : Utilisation élevée du CPU en raison d'un problème d'attente d'E/S

Symptômes

Comment vérifier

Exemple de sortie

Solution

Scénario 2 : Redémarrage périodique de CUCM

Symptômes

Comment vérifier

Exemple de sortie CIMC (Integrated Management Controller) de Cisco

Solution

Scénario 3 : plantages CUCM

Symptômes

Comment vérifier

Solution de contournement

Scénario 4 : blocages CUCM

Symptômes

Comment vérifier

Solution de contournement

Scénario 5 : CUCM est en mode lecture seule

Symptômes

Comment vérifier

Solution

Collecte des journaux UCS

Comment collecter les journaux CIMC : Afficher les technologies

Comment collecter les journaux ESXI : Journaux système

Exemple de sortie CLI CIMC

Exemple de sortie de l’interface graphique du CIMC

Introduction

Ce document décrit comment dépanner cinq scénarios de problèmes courants rencontrés avec Cisco Unified Communications Manager (CUCM) sur la plate-forme Unified Computing System (UCS).

- Scénario 1 : Utilisation élevée du CPU en raison d'un problème d'attente d'E/S

- Scénario 2 : Redémarrage périodique de CUCM

- Scénario 3 : plantages CUCM

- Scénario 4 : blocages CUCM

- Scénario 5 : CUCM est en mode lecture seule

Les causes les plus courantes sont les suivantes :

- Défaillance du disque dur

- Panne du contrôleur RAID (Redundant Array of Independent Disks)

- Panne de l'unité de sauvegarde de la batterie (BBU)

Scénario 1 : Utilisation élevée du CPU en raison d'un problème d'attente d'E/S

Symptômes

Les services Cisco Call Manager (CCM) et CTI (Computer Telephony Integration) redémarrent en raison du coeur CTI de CCM.

Comment vérifier

Traces CUCM

Utilisez ces commandes CLI afin de collecter les traces CUCM :

- show process using-most cpu

- show status

- liste active principale utils

- résultat de l’analyse du coeur de l’outil <dernière, deux dernières sorties>

Examinez ces journaux RTMT (Real-Time Monitoring Tool) :

- CCM détaillé

- CTI détaillé

- PerfMonLogs du collecteur de données RIS (Real-time Information Server)

- Journaux d'application de l'Observateur d'événements

- Journaux système de l'observateur d'événements

Exemple de sortie

Voici un exemple de résultat :

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

====================================

À partir du collecteur de données RIS PerfMonLogs, vous pouvez voir des E/S de disque élevé pendant la durée du coeur de réseau.

Le backtrace correspond à l'ID de bogue Cisco CSCua79544 : Coeurs de processus CCM fréquents en raison d'E/S de disque élevé. Ce bogue décrit un problème matériel et explique comment isoler le problème.

Activer les rapports d'E/S de fichier (FIOR) :

Utilisez ces commandes afin d'activer FIOR :

utils fior start

utils fior enable

Ensuite, attendez la prochaine occurrence. Voici la commande CLI pour collecter les résultats : fichier get activelog platform/io-stats. Entrez ces commandes afin de désactiver FIOR :

utils fior stop

utils fior disable

Voici un exemple de sortie de journal 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.

Solution

L'attente d'E/S pose généralement un problème avec la plate-forme UCS et son stockage.

Le journal UCS est nécessaire pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Scénario 2 : Redémarrage périodique de CUCM

Symptômes

CUCM redémarre en raison d'une panne ESXI, mais le problème sous-jacent est que la machine UCS perd de l'énergie.

Comment vérifier

Examinez les traces CUCM suivantes :

- PerfMonLog du collecteur de données Cisco RIS

- Observateur d'événements - Journal d'applications

- Observateur d'événements - Journal système

- CCM détaillé

Il n'y a rien de pertinent dans les traces de CUCM. Le CUCM s'arrête avant l'incident et est suivi d'un redémarrage normal du service. Cela élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS sur laquelle CUCM s'exécute présente le problème. La plate-forme UCS comporte de nombreuses instances de machine virtuelle (VM) qui s'y exécutent. Si une machine virtuelle rencontre une erreur, elle apparaît dans les journaux UCS.

Le journal UCS est requis pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Exemple de sortie CIMC (Integrated Management Controller) de Cisco

Voici un exemple de résultat :

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

Solution

Lorsque vous rencontrez cette erreur, Pilot2SrvPower.c:466:Blade Power a été remplacé par : [ OFF ] - Problème d'alimentation, cela signifie que l'ordinateur UCS perd de l'alimentation. Par conséquent, vous devez vous assurer que la machine UCS est suffisamment alimentée.

Scénario 3 : plantages CUCM

Symptômes

La machine virtuelle CUCM plante mais répond toujours aux requêtes ping. L'écran de la console vSphere affiche les informations suivantes :

*ERROR* %No Memory Available

*ERROR* %No Memory Available

Comment vérifier

Examinez les traces CUCM suivantes :

- PerfMonLog du collecteur de données Cisco RIS

- Observateur d'événements - Journal d'applications

- Observateur d'événements - Journal système

- CCM détaillé

Il n'y a rien de pertinent dans les traces de CUCM. Le CUCM s'arrête avant l'incident et est suivi d'un redémarrage normal du service. Cela élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS sur laquelle CUCM s'exécute présente le problème. La plate-forme UCS comporte de nombreuses instances de VM qui s'exécutent sur elle. Si une machine virtuelle rencontre une erreur, elle apparaît dans les journaux UCS.

Le journal UCS est requis pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Solution de contournement

Mettez la machine virtuelle hors tension et redémarrez-la. Après le redémarrage, le système fonctionne correctement.

Scénario 4 : blocages CUCM

Symptômes

Le serveur CUCM passe à l'état où il se trouve.

Comment vérifier

Examinez les traces CUCM suivantes :

- PerfMonLog du collecteur de données Cisco RIS

- Observateur d'événements - Journal d'applications

- Observateur d'événements - Journal système

- CCM détaillé

Il n'y a rien de pertinent dans les traces de CUCM. Le CUCM s'arrête avant l'incident et est suivi d'un redémarrage normal du service. Cela élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS sur laquelle CUCM s'exécute présente le problème. La plate-forme UCS comporte de nombreuses instances de VM qui s'exécutent sur elle. Si une machine virtuelle rencontre une erreur, elle apparaît dans les journaux UCS.

Le journal UCS est requis pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Solution de contournement

Essayez un redémarrage manuel pour voir s'il aide.

Scénario 5 : CUCM est en mode lecture seule

Symptômes

Vous recevez cette erreur :

The /common file system is mounted read only.

Please use Recovery Disk to check the file system using fsck.

Comment vérifier

Le serveur de publication (PUB) et un abonné (SUB) installés sur la même machine UCS affichent l'erreur de mode en lecture seule. Le disque de récupération ne résout pas le problème.

Il n'y a rien de pertinent dans les traces de CUCM. Le CUCM s'arrête avant l'incident et est suivi d'un redémarrage normal du service. Cela élimine CUCM et indique que la cause se trouve ailleurs.

La plate-forme UCS sur laquelle CUCM s'exécute présente le problème. La plate-forme UCS comporte de nombreuses instances de VM qui s'exécutent sur elle. Si une machine virtuelle rencontre une erreur, elle apparaît dans les journaux UCS.

Le journal UCS est requis pour isoler l'emplacement de la cause. Reportez-vous à la section Comment collecter les journaux UCS pour obtenir des instructions sur la collecte des traces.

Solution

Après le remplacement du matériel, reconstruisez les noeuds problématiques.

Collecte des journaux UCS

Cette section décrit comment collecter les traces nécessaires pour identifier le problème ou fournit des liens vers des articles qui fournissent cette information.

Comment collecter les journaux CIMC : Afficher les technologies

Reportez-vous aux articles suivants pour obtenir des informations sur la collecte des journaux CICM :

Utilisation de l'interface utilisateur graphique de Cisco CIMC pour collecter des informations sur show-tech

Guide visuel pour collecter des fichiers d'assistance technique (séries B et C)

Comment collecter les journaux ESXI : Journaux système

Reportez-vous à cet article pour plus d'informations sur la collecte des journaux ESXI :

Obtention d'informations de diagnostic pour les hôtes ESXi 5.x à l'aide du client vSphere

Exemple de sortie CLI CIMC

Voici un exemple de sortie CLI CIMC d'une défaillance de disque dur :

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

Voici un exemple de sortie CLI CICM issue d'une défaillance du contrôleur RAID :

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

Exemple de sortie de l’interface graphique du CIMC

Voici un exemple de sortie de l'interface utilisateur graphique CIMC d'une défaillance de disque dur :

Voici un exemple de sortie de l'interface utilisateur graphique CIMC à partir d'une erreur d'écran violet :

(défaillance du contrôleur RAID) | Défaut : CSCuh86924 ESXi PSOD PF exception 14 - contrôleur RAID LSI 9266-8i )

Voici un exemple de sortie de l'interface utilisateur graphique CIMC d'une défaillance BBU :