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

Обновление кластера Cisco CallManager

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


Содержание


Введение

Этот документ предназначен для обеспечения некоторых предложений высокого уровня для того, как обновить Кластер Cisco CallManager. Примечания к установке, которые сопровождают Программное обеспечение Cisco СallManager, дают все подробные сведения относительно шагов установки. Этот документ, однако, решает некоторые из других проблем, которые представляет обновление кластера.

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

Требования

Проверьте эти элементы перед началом обновления:

  • Выполните последние исправления ОС/BIOS.

    Обратитесь к BIOS Cisco IP Telephony и Плану информации Версии операционной системы о том, как усовершенствовать серверы Cisco IP Telephony.

  • Проверьте, что выполняется сервис MSSQL. В противном случае проверьте пароль SQLSvc.

    Обратитесь к восстановлению пароля учетной записи SQLSvc.

  • Просмотрите Матрицу программной совместимости Cisco Unified Communications Manager для Информации о совместимости Решений IP-телефонии.

  • Проверьте, что все серверы в кластере используют тот же DB под ПУСКОМ> ВЫПОЛНИТЬ> REGEDIT> системы HKEY_LOCAL_MACHINE\Software\Cisco, inc\DBL.

    Проверьте, что DBConnection 0 (под названием SERVER=Publisher и DATABASE=CCM030X) является последним на сервере публикаций, тогда как DBConnection 1 должен указать к названию абонента и к последней Базе данных Cisco CallManager.

  • Проверьте, что репликация в порядке на всех серверах тот диспетчер организации Microsoft SQL использования. Это расположено в Пуске> Программы> Microsoft SQL Server 7.0> Диспетчер предприятия.

  • Отключите утвержденный анти-вирус всего Cisco и сервисы обнаружения несанкционированного доступа.

  • У вас есть больше чем 1 ГБ свободного места. Это рекомендуется.

    Примечание: Удостоверьтесь, что отключили Трассировки CallManager и удалили неиспользованные файлы, такие как файлы трассировки для освобождения пространства.

  • Не используйте Сервисы терминалов, поскольку это не поддерживается. Вместо этого используйте Virtual Network Computing (VNC), который поддерживается.

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

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

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

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

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

Обновите издателя

Так как Кластер Cisco CallManager основывается вокруг отношения издателя/базы данных подписчиков, важно обновить издателя сначала. Когда обновление происходит, новая база данных создана на издателе, и данные от старой базы данных перемещены на него. Это позволяет любым новым изменениям к схеме базы данных легко обрабатываться. Когда абоненты добавлены, они подписываются на новую базу данных по издателю. Именно поэтому издатель должен быть обновлен сначала. Абонент не может подписаться на базу данных, которая еще не существует. Эта схема иллюстрирует издателя/отношение абонента, а также отношение передачи вызовов.

Примечание: Сервер CallManager, который имеет ID CTI = 1, может быть определен как Сервер публикаций. Для обнаружения ID CTI перейдите к Веб-странице Admin CCM> Система>, Сisco CallManager, от результата поиска щелкают по серверу и проверяют ID CTI.

/image/gif/paws/7426/40784.gif

Требуется ли при обновлении убирать все Cisco CallManagers?

Нет. В большом кампусе это может быть налоговым на сервере протокола динамической конфигурации узла (DHCP) для получения запросов IP-адреса от тысяч телефонов в течение нескольких часов. Или, это мог бы быть нежелательный для всех телефонных служб, чтобы не работать в течение времени расширенного обновления версии. В то время как обновления должны быть выполнены после закрытия, возможно во многих случаях поддержать часть кластера, работающего во время обновления. Это может быть сделано путем использования групп резервирования Сisco CallManager. По существу, в то время как один сервер обновлен, резервная копия поддерживает все телефоны. Этот документ обсуждает три модели стандартного развертывания.

Рекомендуемые конфигурации кластеров

2500 телефонов – всего три сервера

Кластер Cisco CallManager максимум для 2500 пользователей:

  • Сервер A является преданным сервером публикаций баз данных и сервером упрощенного протокола передачи файлов (TFTP).

  • Сервер B является первичным Cisco CallManager для всех зарегистрированных устройств.

  • C сервера является резервным Cisco CallManager для всех зарегистрированных устройств.

В этой конфигурации только одиночная группа резервирования Сisco CallManager требуется для серверов B и C.

  1. Так как издатель является первым, чтобы быть обновленным, это - то, где начинается процесс. Издатель А является только сервером базы данных, таким образом, он может быть обновлен и перезагружен.

  2. Обновление может начаться для C Сisco CallManager. Так как C Сisco CallManager является резервной копией и не имеет никаких устройств, зарегистрированных к ней, обработка вызовов не прервана. Кроме того, при обновлении резервного Cisco CallManager перед первичным Cisco CallManager это гарантирует, что устройства только должны обновить свое микропрограммное обеспечение одно время.

  3. Первичный Cisco CallManager B может быть обновлен. Когда обновление запускается, Сервис Cisco CallManager остановлен и аварийное переключение устройств к C резервного Cisco CallManager. В то время как устройства регистрируют и получают обновления микропрограммного обеспечения, в обслуживании существует небольшое прерывание.

  4. Заключительный шаг процесса обновления должен перезагрузить все серверы в кластере. Запустите путем перезагрузки Издателя А. Как только перезагрузка завершена, Cisco CallManager B перезагрузки. Когда сервер возвратится на линии, ждите 5 - 10 минут, чтобы позволить устройствам начинать процесс отказовозвращения. Наконец, перезагрузка C Сisco CallManager. Обновление кластера теперь завершено.

5000 телефонов – итого четыре сервера

Кластер Cisco CallManager максимум для 5000 пользователей:

  • Сервер A является преданным сервером публикаций баз данных и TFTP server.

  • Сервер B является первичным Cisco CallManager для IP-телефонов 1 - 2500.

  • C сервера является первичным Cisco CallManager для IP-телефонов 2501 - 5000.

  • Сервер D является резервным Cisco CallManager для всех зарегистрированных устройств.

В этой конфигурации требуются две группы резервирования Сisco CallManager. Каждый для серверов B, и D и другой для C серверов и D.

В этом сценарии существует два основных Сisco CallManager с одной резервной копией. Если каждый основной имеет 2,500 телефонов, вы не можете остановить оба основных сервера в целях обновления. Резервная копия закончилась бы с 5,000 устройств, которые нарушат эти 2,500 пределов.

  1. Издатель А обновлен сначала. Затем Сisco CallManager D должен быть обновлен. До этой точки не была прервана обработка вызовов.

  2. Один раз Сisco CallManager D произошел снова, начните обновление на Cisco CallManager B. Как только обновление запускается, аварийное переключение устройств к Сisco CallManager D. Существует небольшое прерывание сервиса, поскольку устройства регистрируют и получают обновления микропрограммного обеспечения. Когда Cisco CallManager B возвратится на линии, ждите 5 - 10 минут устройств для возвращений к состоянию до сбоя.

  3. Обновите C Сisco CallManager. Существует небольшое прерывание сервиса, поскольку устройства регистрируются в Сisco CallManager D и получают обновления микропрограммного обеспечения.

  4. Для завершения процесса обновления все серверы в кластере должны быть перезагружены. Издатель перезагрузки первое. Когда перезагрузка завершает, Cisco CallManager B перезагрузки. Когда B возвратится на линии, ждите 5 - 10 минут устройств для возвращений к состоянию до сбоя. Затем, C Сisco CallManager перезагрузки и ждет, пока сервер не возвращается на линии. Наконец, перезагрузка Сisco CallManager D. Обновление кластера теперь завершено. Эта ситуация заставляет половину телефонов не работать в течение времени второго основного обновления. В то время как это не идеально, это действительно минимизирует, на сколько не работают телефоны и сколько времени они не работают для.

10 000 телефонов – всего восемь серверов

Кластер Cisco CallManager максимум для 10,000 пользователей:

  • Сервер A является преданным сервером публикаций баз данных.

  • Сервером B является специализированный TFTP server.

  • C сервера является первичным Cisco CallManager для IP-телефонов 1 - 2500.

  • Сервер D является первичным Cisco CallManager для IP-телефонов 2501 - 5000.

  • Сервер E является резервным Cisco CallManager для IP-телефонов 1 - 5000.

  • Сервер F является первичным Cisco CallManager для IP-телефонов 5001 - 7500.

  • Сервер G является первичным Cisco CallManager для IP-телефонов 7501 - 10,000.

  • Сервер H является резервным Cisco CallManager для IP-телефонов 5001 - 10,000.

В этой конфигурации четыре группы резервирования Сisco CallManager требуются для CE серверов, DE, FH и GH. Эта схема иллюстрирует эту конфигурацию:

/image/gif/paws/7426/42657.gif

  1. Обновите издателя.

  2. Обновите TFTP server.

    На этом этапе все шесть Cisco CallManager server все еще работают и не повлиялись обновлением. Этот сценарий точно так же, как тот описал в 5,000 сценариев Телефонов. Единственная разница - то, что существует два набора двух первичных выборов с резервной копией. Основные Сisco CallManager являются C, D, F, и G. Резервные копии являются E и H. Основной C и D отказывают к E. Основной F и G отказывают к H.

  3. Резервные Cisco CallManager E и H должны быть обновлены затем. Когда обновление завершит, ждите серверов к перезагрузке и возвратитесь на линии.

  4. Теперь C Сisco CallManager и F готовы быть обновленными. Когда обновление начинается, устройства, зарегистрированные к этим Сisco CallManager аварийное переключение к резервным копиям. В то время как устройства регистрируют и получают обновления микропрограммного обеспечения, существует небольшое прерывание сервиса. Ждите 5 - 10 минут устройств для возвращений к состоянию до сбоя.

  5. Затем, Сisco CallManager D и G обновлены. Как в шаге 4, в обслуживании существует небольшое прерывание. Когда обновление завершит, ждите серверов к перезагрузке и возвратитесь на линии.

  6. Для завершения обновления все серверы в кластере должны быть перезагружены. Удостоверьтесь, что каждый процесс перезагрузки завершен перед началом следующей группы. Начните путем перезагрузки Издателя А. Затем, TFTP перезагрузки B. Когда B вернулся на линии, перезагрузка C Сisco CallManager и F. Ждите 5 - 10 минут устройств, чтобы возвратиться к состоянию до сбоя и затем перезагрузить Сisco CallManager D и G. Наконец, перезагрузка Сisco CallManager E и H. Обновление кластера теперь завершено.

Анализ: правила обновления Cisco CallManager

Придерживайтесь этих правил при обновлении Сisco CallManager:

  • Всегда обновляйте издателя и автономного TFTP server (если существует), сначала.

  • Обновите вторые резервные Cisco CallManager.

  • Обновите основные Сisco CallManager в последний раз.

  • После того, как все Сisco CallManager обновлены, все серверы должны быть перезагружены.

  • Удостоверьтесь, что, когда SA и Пароли администратора установлены, они - то же для всех серверов в кластере.

Что делать, если происходит сбой установки/ обновления?

Cisco CallManager 3.1 и 3.2

Соберите эти журналы:

  • C : \*.log

  • C : \*.txt

  • C : \Winnt\sti*.*

  • C : \dcdsrvr\log\*.* (если проблема с DCD),

  • C : \Install\DBInstall\*.*

StiSetup.log предоставляет обзор других этапов во время установки/обновления. Dbinstall000.log предоставляет обзор того, какие изменения внесены на database level.

Cisco CallManager 3,3

Соберите эти журналы:

  • Весь *.txt и файлы *.log в корневом каталоге C:\

  • Все файлы в C: каталог Files\Common Files\Cisco\Logs \Program

  • Все файлы в секторе STI_DATA

  • Все файлы в C:\DCDSrvr\log (если проблемы с DCD) каталог),

CCMINST <дата> <время> .log предоставляет обзор других этапов во время установки/обновления. CCMDBSetup <дата> <время> .log предоставляет обзор того, какие изменения внесены на database level.

Сisco CallManager 4. x

Получите и рассмотрите все файлы журнала (*.log и *.txt) из этих каталогов:

  • Все файлы в C:\Program Files\Common Files\Cisco\Logs

  • Все файлы в C:\Program Files\Common Files\Cisco\Directory

  • Все файлы в C:\Install\DBInstall

  • Все файлы в C:\Dcdsrvr\log

Не все сообщения об ошибках, которые отображаются в файле журнала, являются катастрофическими. MSI генерирует сообщения об ошибках в файле журнала по многим причинам. Например, попытки обратиться к сервису, который не использует Сisco CallManager.

Обратитесь к Обновлению Сisco CallManager 4.x для получения дополнительной информации.

Примечание: Используйте Утилиту администратора только в Издателе для решения проблем Синхронизации пароля.

Просмотр событий: приложение и системные журналы в формате .evt

Примечание: Не все ошибки касаются реальных проблем. Всегда проверяйте перед открытием случая с технической поддержкой Cisco.

Обратитесь к Журналам событий CallManager для получения дополнительной информации. Этот документ часто обновляется.

Журналы, которые вы собираете, полезны для инженера TAC для исследования проблемы подробно. Поэтому всегда обновляйте кэйс ТАС (Центра технической поддержки) с этими журналами, поскольку это ускоряет процесс решения проблемы.

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

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


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