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

Cisco Unified Communications Manager 7.x/8. x : Решите Резервную Проблему

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Резервирование Cisco Unified Communications Manager не работает требуемым образом. Все службы платформы восстановления после отказа (DRF) не работают, а просмотреть новые устройства, списки или состояния из консоли DRF невозможно. В этом документе обсуждается способ устранения данной проблемы.

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

Требования

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

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

Сведения в этом документе основываются на Cisco Unified Communications Manager 7.1 (3)/8. x .

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

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

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

Проблема

Резервирование Cisco Unified Communications Manager не работает требуемым образом. Все службы платформы восстановления после отказа (DRF) не работают, а просмотреть новые устройства, списки или состояния из консоли DRF невозможно. Кроме того, при доступе к страницам администратора DRF это сообщение об ошибках получено:

Status:  Local Agent is not responding. 
This may be due to Master or Local Agent being down.

http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unified-communications-manager-version-71/111796-cucm-drf-01.gif

Это предупреждение RTMT получено во время резервного сбоя:

CiscoDRFFailure Reason : Master Agent was unable to send a 
backup/restore request to the local agent. 
Node [ELS-PUB1] is not connected. 
AppID : Cisco DRF Master 
ClusterID : NodeID: ELS-pub1 .
The alarm is generated on Tue Nov 24 02:00:04 PST 2009

Решение

Во-первых, проверьте, присутствует ли Серийный номер сертификата в keystore Издателя в Базе доверенных сертификатов всех Абонентов. Выполните следующие действия:

  1. Войдите в систему Страница администрирования операционной системы CUCM Сервера публикаций кластерной настройки. Выберите Security> Certificate Management. Показы окна Certificate List.

  2. Можно использовать средства управления за Находкой для фильтрации сертификата.

  3. Щелкните по ipsec.pem файлу и проверьте серийный номер сертификата.

  4. Войдите в систему Страница администрирования операционной системы CUCM каждого узла кластера. Выберите Security> Certificate Management. Показы окна Certificate List.

  5. Можно использовать средства управления за Находкой для фильтрации сертификата.

  6. Щелкните по файлу ipsec-trust.pem с именем файла имени хоста издателя и проверьте серийный номер сертификата.

  7. Серийный номер сертификата должен быть тем же на всех узлах кластера. Если Серийному номеру какого-либо узла не соответствуют, выполните эти шаги.

    1. Войдите в систему Страница администратора ОС CUCM узла, на который влияют.

    2. Выберите Security> Certificate Management. Показы окна Certificate List.

    3. Можно использовать средства управления за Находкой для фильтрации сертификата.

    4. Щелкните по ipsec.pem файлу и загрузите тот сертификат.

    5. Найдите существующее доверие ipsec с именем файла имени хоста издателя, щелкните по имени файла и Удалите.

    6. Загрузите загруженный ipsec.pem файл с доверием ipsec заголовка.

    7. Перезапустите Основного агента (MA) DRF / локальный агент (LA) DRF.

Ошибка: не Может записать: Сломанный канал

Резервная копия DRF отказала с этим сообщением об ошибках:

/bin/tar: -: Cannot write: Broken pipe
/bin/tar: Error is not recoverable: exiting now
CCMDB Backup failed, unable to tar data to master agent
Restoring CAR services ...

Эта проблема задокументирована в идентификатор ошибки Cisco CSCte62205 (только зарегистрированные клиенты)

Как попытка обходного пути один из этих шагов:

  1. Отключите клиентские сообщения ALIVE на Открытом сервере SSH

  2. Установите ClientAliveCountMax и ClientAliveInterval к достаточно высокому количеству / интервал, таким образом, сервер не делает таймаута соединение с CUCM во время резервной копии.

  3. Перезапустите Основного агента (MA) DRF / локальный агент (LA) DRF.

DRS "зависает" во время резервной копии CCMDB

Проблема

Если существует большое число файлов CDR/CMR, накопленных в папке Preserve, DRS "зависает" во время резервной копии CCMDB. Эта проблема задокументирована в идентификатор ошибки Cisco CSCsl16967 (только зарегистрированные клиенты).

Примечание: При остановке сервиса CAR он не останавливает накопление плоских файлов CDR.

Решение

Для устранения указанной неполадки выполните следующие действия:

  1. Выполните эти шаги для очистки файлов CDR временно так, чтобы мог продолжиться DRS:

    1. Остановите сервис Агента CDR на всех серверах в кластере, так, чтобы никакие новые файлы CDR не были выдвинуты к издателю.

    2. Выполните эту команду, чтобы проверить, что все файлы были выдвинуты к серверу (серверам) составления счетов:

      file list activelog /cm/cdr_repository/destination/*
      
  2. Выполните эти шаги, чтобы проверить, что нет никаких символических ссылок ни в одной из подпапок:

    1. Остановите Диспетчера репозитория CDR, Планировщика CAR и веб-сервис CAR на издателе.

    2. Используйте эту команду для удаления всех файлов под/var/log/active/cm/cdr_repository/preserve / <дата>, которые были накоплены:

      file delete activelog /cm/cdr_repository/preserve/* noconfirm
      
    3. Используйте эту команду для удаления всех символических ссылок под/var/log/active/cm/cdr_repository/car / <дата>:

      file delete activelog /cm/cdr_repository/car/* noconfirm
      
    4. Диспетчер репозитория CDR перезапуска, Планировщик CAR и веб-сервисы CAR на издателе.

  3. Выполните эти шаги для остановки дальнейшего накопления файлов CDR:

    Примечание: Для остановки дальнейшего накопления файлов CDR необходимо запустить Службу расписаний CAR, заставить загрузчик планировать непрерывную загрузку и CDR загрузки только.

    1. Если это еще не создано, создайте учетную запись ccmadmin в управлении группы пользователей на странице ccmadmin.

    2. Войдите к CAR и перейдите к Системе> Планировщик> Загрузка CDR.

    3. Проверьте Непрерывную Загрузку 24/7 и CDR Загрузки только флажки и нажмите Update.

    4. Выберите System> Database> Configure Automatic Database Purge.

    5. Войдите 1 для Возраста Min Подробных записей о вызовах и Максимального возраста Подробных записей о вызовах, и нажмите Update.

    6. Выберите Report Config> Automatic Generation / Предупреждение.

    7. Для каждого отчёта выберите Disabled и нажмите Update.

  4. Перезапустите сервис Агента CDR на всех серверах.

Ошибка: система в настоящее время блокируется другим процессом. Please try again later"

Резервные копии DRS останавливаются для выполнения автоматически и когда вы делаете попытку ручной резервной копии, вы получаете сообщение об ошибках Backup operation currently in progress. Please wait and try after sometime. Когда вы пытаетесь установить новую версию или файл COP, вы получаете сообщение об ошибках The system is currently locked by another process. Please try again later. Если DRF планируется для создания копии сервера CUCM автоматически, эта проблема происходит. Это задокументировано идентификатором ошибки Cisco CSCsr87199 (только зарегистрированные клиенты).

Решение

Основной агент DRF сброса для решения вопроса.

Резервные сбои с ошибкой WinSock

С CUCM 8.x, резервная копия отказала с сообщением об ошибках Winsock Error 10054/10035/10053.

Решение

Удостоверьтесь, что межсетевой экран отключен на удаленном устройстве резервного копирования, и выполните резервную копию снова.

Резервная копия DRF не резервирует сертификаты

С CUCM 8.x, на обновлении моста восстановленный сервер, файл ITL не имеет допустимого подписывающего лица. Если издатель является сервером TFTP, телефоны не имеют сервисов https. На миграции к UCS или любых новых аппаратных средствах, где резервная копия и восстановление выполнены, телефоны не принимают файлы конфигурации и отличия от нового кластера без ручного удаления существующего ITL с телефонов.

Когда вы восстанавливаете от ситуации восстановления после отказа, телефоны больше не распознают свою конфигурацию или файлы ITL после восстановления DRS, если восстановленный сервер был сервером TFTP. Телефоны могут не распознать изменения конфигурации или обновления, пока их существующий ITL не удален и заменен недавно генерируемым ITL.

Кроме того, при запуске команды CLI покажите itl на серверах это сообщение об ошибках появляется:

This etoken was not used to sign the ITL file.
Verification of the ITL file failed.
Error parsing the ITL file

Эта проблема задокументирована идентификатором ошибки Cisco CSCtn50405 (только зарегистрированные клиенты).

Решение

После восстановления после отказа или ситуации с миграцией аппаратного обеспечения, выполните эти шаги.

  1. Восстановите файл CallManager.pem (только на восстановленном сервере) для синхронизации файла CallManager.pem на файловой системе к той в базе данных.

  2. TVS перезапуска и TFTP.

  3. Для кластера одного узла или только одного сервера TFTP, удаляют файл ITL вручную из всех телефонов в кластере.

  4. Для Много кластера узла телефоны должны автоматически использовать TVS альтернативных Серверов Группы CallManager для аутентификации нового файла ITL. Альтернативно телефоны могут быть указаны к другому серверу TFTP в кластере.

После обновления моста выполните эти шаги.

  1. Восстановите файл CallManager.pem (только на восстановленном сервере) для синхронизации файла CallManager.pem на файловой системе к той в базе данных.

  2. TVS перезапуска и TFTP.

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

: плохо дешифруйте 16404:error

С CUCM 8.x, DRS восстанавливают сбои для компонентов TFTP с этим сообщением об ошибках

error:06065064:digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Решение

Это сообщение об ошибках является индикацией относительно Несоответствия IP-адреса или имени хоста. Удостоверьтесь, что сервер CUCM имеет тот же IP-адрес и Имя хоста как на серверах MCS от того, где расположена резервная копия. Если имя хоста не является тем же как сервером резервного копирования, необходимо модифицировать имя хоста, чтобы совпасть с сервером резервного копирования и выполнить восстановление снова.

Ошибка на резервной странице на CUCM

Проблема

Когда вы перешли к резервной странице, сообщение об ошибках Local Agent is not responding. This may be due to Master or Local Agent being down появляется. В то время как вы пытаетесь добавить устройство резервного копирования, это также происходит.

Решение

Для устранения указанной неполадки выполните следующие действия:

  1. Вход в систему к Странице администратора ОС CUCM.

  2. Выберите Security> Certificate Management.

  3. Проверьте серийный номер для ipsec.pem файла.

  4. Гарантируйте, что серийный номер совпадает с файлом ipsec-trust.pem для абонентов.

  5. Перезапустите Ведущее устройство DRF Cisco и Локальный сервис DRF в Издателе.

  6. Активируйте Сервис TFTP.

Неспособный добавить устройство резервного копирования

Проблема

Вы неспособны добавить Устройство резервного копирования на странице CUCM DRS.

Решение

Для решения этого вопроса необходимо добавить рекомендуемый Cisco сервер SFTP как Устройство резервного копирования. Можно использовать любой из этих серверов SFTP:

  • Открытый SSH — для систем UNIX

  • Cygwin leavingcisco.com

  • Титан leavingcisco.com

  • Сервер GlobalSCAPE EFT — раньше известный как Безопасный Сервер FTP GlobalSCAPE

Cisco рекомендует продукты SFTP, которые сертифицируются с Cisco через Программу для партнеров Разработчика Cisco Technology (CTDP).

См. Настраивают Сервер резервного копирования для Cisco Unified Communications Manager для получения дополнительной информации.

Неспособный восстановить CUCM 8.x сервер

Проблема

Когда вы пытаетесь восстановить CUCM 8.5, это сообщение об ошибках появляется:

digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Решение

Эта ошибка происходит, если DNS был настроен, когда резервная копия была взята, но это не было настроено, когда делается восстановление. Для решения этого вопроса выполните шаги:

  1. Настройте DNS перед выполнением восстановления.

  2. Гарантируйте, что FQDN сервера разрешим DNS.

    Примечание: Это задокументировано в идентификатор ошибки Cisco CSCtk05743 (только зарегистрированные клиенты)

Неспособный восстановить CUCM 8.5

Проблема

Неспособный восстановить 8.5. сервер, давая ошибку слежения:

digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Решение

Если существует какое-либо несоответствие IP / Имя хоста / Надежный пароль, эта проблема может произойти. Однако в этом случае со всеми совпадают.

Проблема относительно DNS / Информация домена, не настраиваемая на сервере для соответствия. Это произойдет, если DNS был настроен, когда резервная копия была взята, но это не было настроено, когда делается восстановление.

Для решения этого вопроса настраивают DNS прежде, чем выполнить восстановление. Гарантируйте, что FQDN сервера разрешим DNS.

Примечание: Это задокументировано в идентификатор ошибки Cisco: CSCtk05743 (только зарегистрированные клиенты)


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


Document ID: 111796