Вы здесь

Архивирование и восстановление Cisco Call Manager CUCM

Про Disaster Recovery вспоминают не часто, но запоминается надолго..
Сбой телефонии сам по себе чувствителен для организации, а потеря всех настроек настоящая катастрофа.
В системе Cisco CUCM настроить автоматическую архивацию очень не сложно - уделите 30 минут своего времени. Вы даже можете не пробовать тестовое восстановление - благо сам процесс не так заморочен как например у Microsoft. Вы всегда можете воспользоваться статьёй по восстановлению или сходив на cisco.com наконец, но ежедневные и месячные бэкапы иметь под рукой надо, а также регулярно проверять их статус.

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

Для архивации в CUCM используется Disaster Recovery System (DRS), - компонент, который настраивается и запускается непосредственно из админки.
DRS позволяет производить автоматические и ручные бэкапы.
DRS производит бэкапы cluster-level, что означает что в бэкапе будет находиться вся информация со всех серверов кластера.

DRS включает в себя два основных компонента:
- Master Agent (MA). Обеспечивает централизованные функции, например запуск scheduled tasks. Запущен как сервис на всех нодах, но реально функционирует только на Publisher.
- Local Agent (LA). Непосредственно осуществляет архивацию и восстановление. Запущен и функционирует на всех нодах.

Настройка архивирования через freesshd.exe

В качестве сервера для архивирования используем Windows2003

Создаем на сервере директории:
arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_directories_ciscomaster.ru.jpg

Устанавливаем на Backup-сервер приложение freesshd.exe
- выставляем директорию в SFTP
- выставляем локального пользователя в Users: Если это standalone server, можно выбрать тип юзера "password stored in sha1" или "NT auth". В случае контроллера, проходит "password stored in sha1".
arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_freesshd_setup_ciscomaster.ru.jpg
Для apply перезапускаем сервис

Настройка архивирования на SCP Server от Solarwinds

Исходный файл: SftpServerInstaller.msi

После установки при первом запуске мы увидим следующее окно:
juniper_i_server_scp_01_ciscomaster.ru.jpg

Выставляем рабочую директорию:
File > Configure > General > SFTP_Root
Вообще при установке такая папка уже должна была создаться, либо можно выбрать какую-то свою.
juniper_i_server_scp_02_ciscomaster.ru.jpg

Создаём пользователя для работы с SCP:
File > Configure > General > Users > New user
Нужно задать лишь имя и пароль.
juniper_i_server_scp_03_ciscomaster.ru.jpg

Запускаем сервис:
juniper_i_server_scp_04_ciscomaster.ru.jpg

Настройка архивирования на CUCM

Далее идем в «Система восстановления после сбоев»
Backup -> Bakup Device
Создаем для двух типов бэкапа:
arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_backup_device_ciscomaster.ru_0.jpg

arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_backup_device_daily_ciscomaster.ru.jpg

arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_backup_device_monthly_ciscomaster.ru.jpg

Создаем два Scheduler для ежедневных и ежемесячных копирований
arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_backup_schedullers_ciscomaster.ru.jpg

И, конечно, мы всегда можем сделать ручное архивирование, выбрав:
Backup -> Manual Backup

Проверка статуса архива

Откройте файл *_drfComponent.xml:
praktika06_polnoe_vosstanovlenie_klastera_cucm_8.6_iz_arhiva_02_ciscomaster.ru.jpg
Ннас интересует раздел Status. Если мы видим SUCCESS, то с данным архивом всё в порядке.

Рекомендация

При восстановлении нужно чтобы совпадал ряд параметров:
- hostname
- IP address
- Product version (имеется в виду Windows или Linux)
- deployment type (publisher/subsriber)

Также нужно будет вводить и другие. Чтобы было меньше вопросов в стрессовой ситуации, рекомендуется снять эти параметрыс живой системы и сохранить скриншотом:
Чтобы узнать все нам нужные параметры, на каждом ноде достаточно дать следующие команды:
show status
show network eth0
show timezone config
utils ntp config

praktika06_polnoe_vosstanovlenie_klastera_cucm_8.6_iz_arhiva_03_ciscomaster.ru.jpg

praktika06_polnoe_vosstanovlenie_klastera_cucm_8.6_iz_arhiva_04_ciscomaster.ru.jpg

praktika06_polnoe_vosstanovlenie_klastera_cucm_8.6_iz_arhiva_05_ciscomaster.ru.jpg

praktika06_polnoe_vosstanovlenie_klastera_cucm_8.6_iz_arhiva_06_ciscomaster.ru.jpg

Восстановление

В данной статье восстановление рассматривает лишь вскользь.
Подробный материал смотрите Настройка Cisco Unified Comunications с нуля. Практика07: Полное восстановление кластера CUCM 8.6 из архива
Для восстановления нужно знать cluster security password (или System security password), см. Пошаговая начальная установка CUCM 8.x на ESXi 5.1

Для успешного восстановления у CUCM и бэкапа должно совпадать:

- hostname
- IP address
- Product version (имеется в виду Windows или Linux)
- deployment type (publisher/subsriber)

Сверка версий бэкапа и CUCM

Бэкап выглядит следующим образом:
arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_cucmbackup_files_ciscomaster.ru.jpg

Для определения версии бэкапа
Откройте файл *_drfComponent.xml, там есть строчка 7.1.5.33900-10
arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_drfcomponent_ciscomaster.ru.jpg

Для определения версии CUCM
идем на первую страницу, или выбрав:
CUCM Administration > Help > About
arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_version_ciscomaster.ru.jpg

Для определения hostname CUCM, IP address, deployment type

Зайти на:
Cisco unified OS administration > Show > Cluster
arhivirovanie_i_vosstanovlenie_cisco_call_manager_cucm_hostname_and_ip_ciscomaster.ru_0.jpg
Здесь только нужно иметь в виду что hostname - это Alias, т.е. в нашем случае hostname - cucm861, а ciscomaster.ru - DNS домен

В документации восстановление описывается по следующим сценариям:
- Restoring a Node or Cluster to a Last Known Good Configuration (No Rebuild)
- Restoring the First Node only (Rebuilding the Publisher Alone)
- Restoring the Entire Cluster
- Restoring Subsequent Cluster Nodes (With or Without Rebuild)

мы же попробуем рассмотреть жизненные ситуации:

Откат кластера

Это в доументации называется Restoring a Node or Cluster to a Last Known Good Configuration (No Rebuild)
Данное восстановление практикуется в случаях, когда "наконфигурячили" в настройках и нужно откатиться назад, т.е. сами сервера "живые" но система в целом работает неудовлетворительно из-за ошибок в конфигурировании, а вспомнить "а что ты делал час назад" или "верни все как было" не получается.

- Идем в Disaster Recovery System > Restore > Restore Wizard
Для логина следует использовать учетку Operating System Administrator
- Выбираем Backup device (после нажатия next система полезет в папку за бэкапами)
- Выбираем один из доступных архивов.
- Выбираем integrity check, а также Publisher node
- Жмем Restore

При этом надо понимать, что выбор Publisher node влечет за собой восстановление всего кластера.

В ходе восстановления можно следить за его статусом через:
Disaster Recovery System > Restore > Status

После восстановления следует перезагрузить весь кластер, причем сначала следует перегрузить Subscribers, и только после Publisher
Cisco Unified OS Administration > Settings > Version > Restart

После перезагрузки кластера проверьте статус репликации:
Определение статуса Call Manager CUCM

Комментарии

Спасибо большое за статьи и огромный труд!!!!

Можно вас еще попросить сделат mvfyefk по настройке кластера и требования к кластер серверу. Слышал что нужно (по рекомендациям Cisco) купить такой же сервер, на котором стоит версия CallManager. Но можно ли поднять кластер на виртуальном сервере дтетьего производителя?

Добрый день,
Определённо можно на VMWare начиная с версии 7.1.
8-я версия поддерживает виртуализацию официально. По требованиям - существуют ova-teamplates которые можно скачать с сайта циски.
Как ориентир 4Гб ОЗУ, 80Гб диск, два ядра CPU.
Но надо понимать, что при восстановлении на другое железо слетят лицензии и понадобится всё реактивировать . этот вопрос нужно решать с вашим поставщиком.

Также см. http://docwiki.cisco.com/wiki/Main_Page

Спасибо за статью!
Пытаюсь сделать бэкап, но на шаге "идем в «Система восстановления после сбоев» Backup -> Bakup Device", у меня, при нажатии на кнопку "Backup" ничего не происходит, выпадающее меню не выпадает.
Не знаете, в чем может быть проблема?

Разобрался. С другого компа, почему-то всё открылось. Хотя у меня не стоит запретов никаких, раньше на моём компе проблем не было.

Подскажите пожалуйста, после восстановления из бэкапа (DRS) publisher на НОВОЕ железо, все лицензии останутся на месте? Если нет, то как быть в таком случае?

Добрый день,
да, бэкап включает в себя лицензии. В случае если они отвалятся у вас будет 60 дней, чтобы их восстановить через cisco.
license@cisco.com

Здравствуйте! Странная ситуация получилась. У меня железячный publisher CUCM 8.6(2) и виртуальный subscriber. Попробовал снять бэкап с publisher. Дошло только до 87%, но при этому сказал, что всё хорошо, бэкап сделан успешно. Постмотрел в статусе, там некоторые позиции пропуски (прочерки), но не ошибки. Может из-за этого получилось 87%. Не знаю.
Далее. Установил новый виртуальный publisher CUCM 8.6(2) и подтянул в него сделанный бэкап. Он проверил его, сказал что все нормально и можно восстанавливать. После восстановления предложил перезагрузиться и обещал, что после перезагрузки будет все работать.
После перезагрузки лицензии не подтянулись (режим демо на 150 телефонов), настройки и базы данных тоже никакие не подтянулись.
Что я делаю не так? Ошибок никаких не было.
Есть одна возможная причина. Я заведомо прописал другой ip-адрес на восстанавливаемом сервере, нежели на оригинальном. Сделать такой же, не представлялось возможность, что бы не было конфликтов.
Есть сомнения, что этот факт мог послужить причиной невосстановления из бэкапа.
Еще что-то могло повлиять или я что-то делаю не так?

Кажется нашёл проблемку. При создании бэкапа предлагается две галочки UCM & CDR_CAR. А при восстановлении только CDR_CAR! Почему-то не предлагает UCM.

Добрый день,
нужно делать всё идентично. Восстанавливать нужно в изолированной среде. Лицензии привязаны в том числе к IP, поэтому слетают

Дело в том, что даже когда я восстанавливаю бэкап на оригинальный publisher (с которого слил бэкап), он предлагает мне для восстановления только CDR_CAR. Хотя при создании бэкапа, я ставил галочки UCM и CDR_CAR.
У меня при создании бэкапа, процесс доходит до 87% и говорит, что УСПЕШНО закончил делать бэкап.
В некоторых позициях в статусе компонентов бэкапа прочерки (может быть какие-то невключенные сервисы).
Но ошибок никаких не выдаёт.
Не знаете почему так может быть, встречались с подобным?

Добавить комментарий

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Допустимые HTML-теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и абзацы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и абзацы переносятся автоматически.
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.
Target Image