Голосовая связь и система унифицированных коммуникаций : Cisco Unified Communications Manager (CallManager)

Устранение причин сбоев Cisco CallManager

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Отзыв


Содержание


Введение

Этот документ предоставляет сведения о катастрофическом отказе Сisco CallManager и как определить известные ошибки.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

Данный документ не ограничен отдельными версиями программного или аппаратного обеспечения.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

Описание катастрофического отказа Сisco CallManager

Когда Отказы сервиса Cisco CallManager, это сообщение появляется в журнале Системного события:

The Cisco CallManager service terminated unexpectedly.
It has done this 1 time. The following corrective action
will be taken in 60000 ms. Restart the service.

В это время устройства, такие как Cisco IP Phone и шлюзы, которые зарегистрированы к Сisco CallManager, отменены регистрацию. Сервис Cisco CallManager может завершиться катастрофическим отказом из-за одной из этих причин:

  • Непредвиденное событие происходит в Сервисе Cisco CallManager. Этот катастрофический отказ генерирует журнал Dr.Watson и файл User.dmp в папке C:\Documents and Settings\All Users\Documents\DrWatson.

  • Сервис Cisco CallManager не имеет достаточного количества ресурсов, таких как ЦПУ или память, для функционирования. Обычно загрузка ЦПУ в сервере в 100 процентах в то время.

Этот документ обсуждает только те ситуации, в которых катастрофический отказ происходит из-за непредвиденного события.

Чтение журнала Dr.Watson

Каждый раз, когда существует сбой приложения, журнал Dr.Watson добавлен. Откройтесь Dr.Watson входят в Блокнот, переходят к нижней части файла и ищут Application exception occurred. Это показывает последний катастрофический отказ:

Application exception occurred:
        App:  (pid=680)
        When: 3/8/2003 @ 14:01:06.978
        Exception number: e06d7363

Сравните дату и времю с Сообщением журнала регистрации событий, чтобы гарантировать, что упомянутый катастрофический отказ имеет то же время. Выходные данные предыдущего примера указывают, что приложение, которое завершилось катастрофическим отказом, имело идентификатор процесса (PID) 680. Этот след перечисляет весь из PIDs:

PID  PROCESS
   8 System.exe
 212 SMSS.exe
 240 CSRSS.exe
 264 WINLOGON.exe
 292 SERVICES.exe
 304 LSASS.exe
 424 termsrv.exe
 520 svchost.exe
 560 msdtc.exe
 696 DLLHOST.exe
 736 Ipvmsapp.exe
 752 DLLHOST.exe
 824 AudioTranslator.exe
 848 RisDC.exe
 860 LogoutService.E.exe
 884 DCX500.exe
 936 svchost.exe
 980 LLSSRV.exe
1028 sqlservr.exe
1112 ntpd.exe
1140 rcmdsvc.exe
1172 regsvc.exe
1176 mstask.exe
1204 SNMP.exe
1244 WinMgmt.exe
1260 cpqnimgt.exe
1284 cqmgserv.exe
1296 cqmgstor.exe
1308 sysdown.exe
1372 cqmghost.exe
1524 aupair.exe
1552 sqlagent.exe
 276 svchost.exe
2400 inetinfo.exe
2412 explorer.exe
2752 sqlmangr.exe
2700 taskmgr.exe
2704 mmc.exe
 680 ccm.exe
 868 DRWTSN32.exe

PID (680) является ccm.exe, который является Сервисом Cisco CallManager. После того, как вы проверяете дату и времю в конечном счете Средство просмотра и подтверждаете, что катастрофический отказ вызван ccm.exe, ищите слово FAULT в журнале Dr.Watson. Это показывает местоположение, которое фактически вызвало катастрофический отказ:

function: RaiseException
        77eab2d4 85c9          test    ecx,ecx
        77eab2d6 740e          jz      GetVolumePathNameA+0x7e (77eb3fe6)
        77eab2d8 8d4801        lea     ecx,[eax+0x1]         ds:0751c41a=????????
        77eab2db 8d7dc4        lea     edi,[ebp+0xc4]        ss:0751c46a=????????
        77eab2de f3a5          rep  movsd ds:06cfeed8=06cfeef4 es:06cfee68=00000000
        77eab2e0 eb04          jmp     SetVolumeMountPointA+0x172 (77eb35e6)
        77eab2e2 8365c000      and  dword ptr [ebp+0xc0],0x0 ss:0751c46a=????????
        77eab2e6 8d45b0        lea     eax,[ebp+0xb0]        ss:0751c46a=????????
        77eab2e9 50            push    eax
        77eab2ea ff156414e877  call    dword ptr [77e81464]  ds:77e81464=77fb1130
FAULT ->77eab2f0 5f            pop     edi
        77eab2f1 5e            pop     esi
        77eab2f2 c9            leave
        77eab2f3 c21000        ret     0x10

FAULT уникален для различных типов сбоев. Первый столбец является местом в памяти, которое может варьироваться. В данном примере отказ находится в 77eab2f0. Однако остаток линии, 5f pop edi, всегда является тем же для этого типа аварии.

Сервер Издателя Cisco CallManager не Может Start Services: DBL ошибки

Сервер Издателя Cisco CallManager не может запустить сервисы, так как нельзя обратиться к базе данных. Сервис Монитора уровня базы данных также не может обратиться к базе данных.

DBL ошибочное решение

Монитор уровня базы данных обращается к DB через серию файлов DLL. Для решения этой проблемы отмените регистрацию и затем повторно регистрируйте DLL доступа к базе данных от операционной системы Microsoft Windows. Это позволяет, что базовые приложения для совершения вызовов базы данных снова через Cisco предоставили DLL.

Сервисы Cisco CallManager не запускаются после Перебоя в питании

Когда существует две сетевых интерфейсных платы включенные (NIC) и поэтому два назначенные IP-адреса, сервисы Cisco CallManager иногда не запускаются после перезагрузки сервера или перебоя в питании. Гарантируйте, что вам только включили один NIC на сервере за один раз. Двойные NIC не поддерживаются. Рекомендация состоит в том, чтобы иметь два NIC и использовать тот в качестве отказоустойчивости, но только один в рабочем состоянии за один раз. Сбой для отключения второго NIC может привести к двум IP-адресам, которые назначены на Cisco CallManager server. Когда два IP-адреса назначены на Cisco CallManager server, он может вызвать прерывание обслуживания. У вас должен быть только один включенный NIC (тот, который настроен). Отключите тот, который не используется для решения вопроса.

Список известных сбоев и исправляет

Этот раздел перечисляет известные сбои с кодами FAULT и доступными исправлениями. Если исправление доступно в Engineering Special (ES), откройте случай с технической поддержкой Cisco с Инструментом запросов службы технической поддержки (TAC) (только зарегистрированные клиенты) для получения исправления.

Идентификатор ошибки Cisco CSCdx42096

Идентификатор ошибки Cisco CSCdx42096 (только зарегистрированные клиенты) включает катастрофический отказ Сisco CallManager из-за плохо отформатированных сообщений Протокола MGCP от шлюзов MGCP.

Это показывает отказ в журнале Dr.Watson:

77eab2e9 50               push   eax
        77eab2ea ff156414e877    call    dword ptr [77e81464] ds:77e81464=77fb1130
FAULT ->77eab2f0 5f              pop     edi
        77eab2f1 5e              pop     esi
        77eab2f2 c9              leave

Эта проблема устранена в этих Версиях Cisco CallManager:

  • 3.3 (2) SpC

  • 3.2 (2c) ES64

Идентификатор ошибки Cisco CSCdx32456

В то время как вызов H.323 обработан, CSCdx32456 идентификатора ошибки Cisco (только зарегистрированные клиенты) включает сбои Сisco CallManager.

Это показывает четыре возможных отказа в журнале Dr.Watson, который может вызвать катастрофический отказ:

FAULT ->005783e7 f3a5
FAULT ->005777ea 8b00
FAULT ->0057784a 8b00
FAULT ->005790c7 8b5004

Эта проблема устранена в этих Версиях Cisco CallManager:

  • 3.2 (2c)

  • 3.3 (2)

Идентификатор ошибки Cisco CSCdz69051

CSCdz69051 идентификатора ошибки Cisco (только зарегистрированные клиенты) включает катастрофический отказ Сisco CallManager, потому что массив выходит за пределы.

Это показывает отказ в журнале Dr.Watson:

77e989ca 50               push  eax
        77e989cb ff156414e877   call    dword ptr [77e81464]   ds:77e81464=77fb0f18
FAULT ->77e989d1 e978f80100     jmp     SetThreadContext+0x46 (77eb824e)
        77e989d6 8b4510         mov     eax,[ebp+0x10]         ss:06629f32=????????
        77e989d9 83f80f         cmp     eax,0xf

Эта проблема устранена в этих Версиях Cisco CallManager:

  • 3.2 (2c) ES47

  • 3.3 (2) SpB

Идентификатор ошибки Cisco CSCea45057

Идентификатор ошибки Cisco CSCea45057 (только зарегистрированные клиенты) включает перезапуск Сisco CallManager на неожиданном сигнале H.225.

Это показывает отказ в журнале Dr.Watson:

00b7d363 8b45fc           mov   eax,[ebp+0xfc]                 ss:06d8839e=????????
        00b7d366 8b4d08         mov     ecx,[ebp+0x8]          ss:06d8839e=????????
FAULT ->00b7d369 894810         mov     [eax+0x10],ecx         ds:0081d5d2=208d8b52
        00b7d36c 8be5           mov     esp,ebp
        00b7d36e 5d             pop     ebp

Эта проблема устранена в этих Версиях Cisco CallManager:

  • 3.2 (2c) ES66

  • 3.2 (3) ES01

  • 3.3 (2) SpC

Идентификатор ошибки Cisco CSCdz25416

CSCdz25416 идентификатора ошибки Cisco (только зарегистрированные клиенты) включает катастрофический отказ Сisco CallManager, потому что внутренние таблицы не убраны должным образом.

Это показывает отказ в журнале Dr.Watson:

00b598b6 8b45fc           mov   eax,[ebp+0xfc]                 ss:0576ca9e=00000000
        00b598b9 8b4d08         mov     ecx,[ebp+0x8]          ss:0576ca9e=00000000
FAULT ->00b598bc 8b5004         mov     edx,[eax+0x4]          ds:0081d5d6=fe808d8d
        00b598bf 3b5104         cmp     edx,[ecx+0x4]          ds:0576cb12=00000000
        00b598c2 753f           jnz     00b62403

Эта проблема устранена в этих Версиях Cisco CallManager:

  • 3.1 (4b) SpD

  • 3.2 (2c) SpH

  • 3.3 (2)

Идентификатор ошибки Cisco CSCea52097

CSCea52097 идентификатора ошибки Cisco (только зарегистрированные клиенты) включает катастрофический отказ Сisco CallManager, который происходит, когда поле Unexpected в Сторожевом устройстве расцепляет.

Это показывает отказ в журнале Dr.Watson:

00b53dd7 b916000000       mov   ecx,0x16
        00b53ddc 8d7530         lea     esi,[ebp+0x30]         ss:0656bece=????????
FAULT ->00b53ddf f3a5           rep movsd ds:05d4e92c=00000008 es:00000010=????????
        00b53de1 8b8d88000000   mov     ecx,[ebp+0x88]         ss:05d4e984=00000002
        00b53de7 51             push    ecx

Эта проблема устранена в этих Версиях Cisco CallManager:

  • 3.2 (2c) ES67

  • 3.3 (2) SpC

Идентификатор ошибки Cisco CSCdy19452

Идентификатор ошибки Cisco CSCdy19452 (только зарегистрированные клиенты) включает перезапуск Сisco CallManager из-за исключения массива в StationOutputSetRinger.

Это показывает отказ в журнале Dr.Watson:

77e989ca 50               push  eax
        77e989cb ff156414e877   call    dword ptr [77e81464]   ds:77e81464=77fb0f18
FAULT ->77e989d1 e978f80100     jmp     SetThreadContext+0x46 (77eb824e)
        77e989d6 8b4510         mov     eax,[ebp+0x10]         ss:0576bfba=????????
        77e989d9 83f80f         cmp     eax,0xf

Эта проблема устранена в этих Версиях Cisco CallManager:

  • 3.1 (4b) SpA

  • 3.2 (2c) SpC

  • 3.3 (2)

Идентификатор ошибки Cisco CSCtg41510

Сервер Cisco Unified Communications Manager может завершиться катастрофическим отказом из-за паники ядра. Эта ошибка наблюдается относительно консоли.

<0>Fatal exception: panic in 5 seconds

Эта проблема может влиять на версию 7.1.3 CUCM и версию 8.0 CUCM.

Попробуйте эти обходные пути:

  • Отключите Неподвижный Источник аудиосигнала MOH. Это позволяет сервисам IPVMS работать, но конечно исправленный MOH не можно выбрать как источник звука.

  • Включите устройства MOH USB к каждому серверу в кластере, который Исправил включенный Источник аудиосигнала MOH.

  • Выключите MOH выполненный флаг для серверов MOH, которые не имеют неподвижного устройства MOH USB. Это позволяет другим сервисам IPVMS, таким как MTP, CFB и ANN работать, как требуется, тогда как MOH только работает на сервере с неподвижным устройством MOH USB.

Идентификатор ошибки Cisco CSCts29293

Код HuntListCdrc вводит бесконечный цикл, который приводит к срыву резьбы Маршрутизатора SDL и возможному ядру CCM.

Эта линия могла бы быть распечатана в файле трассировки в течение некоторого периода, который ведет до ядра:

12:29:49.199 |HuntListCdrc::SendCcNotifyReq with 
   transactioId=84180720|5,100,49,1.130009640

Примечание: transactioId не увеличивается, поскольку он приводит к состоянию бесконечного цикла.

Если сервер работает на Платформе UCS, отключите LRO и обновите программные средства VMware. Однако проблема наблюдалась относительно систем CUCM, которые имеют отключенный LRO. Следовательно, никакой подтвержденный обходной путь не доступен.

На платформе MCS нет никакого обходного пути.

Новый катастрофический отказ

Если с катастрофическим отказом встречаются, и он не совпадает ни с одним из ранее описанных отказов, открывается, случай с технической поддержкой Cisco с Инструментом запросов службы технической поддержки (TAC) (только зарегистрированные клиенты) несомненно предоставят эту информацию:

  1. Трассировки Cisco CallManager с 15 минут прежде и после катастрофического отказа.

    Можно найти эти следы в C:\Program Files\cisco\trace\ccm.

  2. Signal Distribution Layer (SDL) отслеживает с 15 минут прежде и после катастрофического отказа.

    Можно найти эти следы в C:\Program Files\cisco\trace\sdl\ccm.

  3. Системные файлы и Файлы регистрации событий приложений.

    Можно найти их в Пуске> Программы> Средства администрирования> Просмотр событий.

  4. Журнал Dr.Watson.

    Можно найти этот журнал в C:\Documents and Settings\All Users\Documents\DrWatson\Drwtsn32.log.

  5. Файл User.dmp.

    Можно найти этот файл в C:\Documents and Settings\All Users\Documents\DrWatson.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения