Вы здесь

Troubleshooting Database Replication

В большинстве инсталляций CUCM ставится в виде кластера. Кластер - это набор совместно функционирующих сетевых сервисов. Кластер CUCM состоит из одного Publisher и одного или более Subscriber.
Кластер дает несколько преимуществ, главные из которых:

  • Распределение нагрузки между нодами кластера
  • Обеспечивает Redundancy в случае сбоя сети или какого либо из нодов

Для нормальной работы кластера чрезвычайно важны вопросы успешной репликации.

Все настройки CUCM, необходимые для нормальной обработки звонков, хранятся в Базе Данных IBM Informix Dynamic Server.
Репликация БД между нодами является ключевой функцией внутри кластера CUCM, при этом у нодом могут быть следующие роли:

  • Publisher - Это сервер обладающий master copy of the database. Этот сервер в единственном числе.
  • Subscriber - Это сервер обладающий копией (репликой) БД от Publisher. Таких серверов может быть несколько

Почти вся информация в БД в кластере CUCM реплицируется по топологии star topology (один Publisher и несколько Subscriber).
Но для данных типа Dynamic Information используется репликация с топологией mesh topology (каждый с каждым).
Dynamic Information это данные такие как: regustered phones, gateway, ресурсы DSP, - т.е. та информация которая изменяется гораздо чаще и требует немедленной репликации между нодами.

Сама по себе IBM IDS достаточно надёжна, но проблемы с синхронизацией всё же могут возникнуть по следующим причинам:

  • Сбой в сетевом подключении между нодами
  • Репликация требует достаточной bandwidth
  • Проблемы с DNS
  • Недостаточное количество ресурсов CPU и Memory

Типичные проблемы с репликацией

Администратор меняет настройки телефона, далее после перезагрузки телефона, IP phone подключается к primary subscriber. Но после перезагрузки никаких изменений на телефоне не происходит.

Другой причиной проблем с репликацией может быть несоответствие конфигураций между Publisher и Subscriber, - при этом в CUCM logs мы будем видеть ошибку: Database Communication Error.
Возможные причины:
- Сеть. Проверьте пинг между серверами.
- Name resolution
- Недостаточно сетевых ресурсов. Как минимум Round-trip delay between two replication peer servers должен быть минимум 80ms

Также, с ошибкой в Database Replication можно попробовать побороться через Recreate Databes Relationship между Publisher и Subscriber.

Диагностика проблем с репликацией

Проверить репликацию мы можем через использование CLI, Cisco Unified Reporting или Cisco Unified Real-Time Monitoring Tool (RTMT).
Все эти инструменты отображают главный показатель: Replicate_State, который может иметь следующие значения:

  • 0 - Репликация не запущена. Либо нет ни одного Subscriber, либо остановлен сервис Cisco Databes Layer Monitor
  • 1 - replicates have been created, but their count isincorrect.
  • 2 - replication is good.
  • 3 - replication is bad in the cluster.
  • 4 - replication setup did not succeed.

CUCM Unified Reporting
Unified Reporting > System Reports > Unified CM Database Status > Generate new Report
Если все нормально мы должны там:
- Найти фразу All servers have a good replication status
- Значение Replicate_State = 2
- У всех нодов значения Number of Replicates Created должны быть одинаковыми.
troubleshooting_database_replication_unified_cm_database_status_ciscomaster.ru.jpg

RTMT
RTMT (Real Time Monitoring Tool) - очень полезный инструмент не только для проверки репликации но и многих других задач.
На левой панели выбираем Call Manager, затем Database summary.
- Значение Replicate_State = 2 должно быть для всех нодов.
- Значение Replicates Created должно быть одинаковым для всех нодов.
troubleshooting_database_replication_unified_cm_database_status_rtmt_ciscomaster.ru.jpg

Также эти значения получить и в виде графика:
System > Perfomance > Open Perfomance Monitoring > First Node > Number of Replicates Created and State of Replication

CUCM OS Admin CLI
Подробнее по CLI см. CUCM CLI
Здесь для проверки мы можем использовать команды из консоли Publisher:
utils dbreplication status
utils dbreplication runtimestate

troubleshooting_database_replication_unified_cm_database_status_cli_ciscomaster.ru.jpg

Главная команда utils dbreplication status не может быть выполнена мгновенно. Через некоторое время следует выполнить
utils dbreplication runtimestate
Replication status command COMPLETED - типа проверка завершена
Нас интересуют значения в столбце REPLICATION SETUP (RTMT) & details, если видим значение (2) значит всё нормально.

Более подробные детали по БД можно посмотреть командой:
file view activelog cm/trace/dbl/sdi/ReplicationStatus.2014_01_24_04_42_57.out

Методы решения проблем с Database Replication

  • Repair Databases Replication - можно производить со стороны Publisher:
    utils dbreplication repair all

    Процесс восстановления запустится в background, его прогресс можно посмотреть командой:

    utils dbreplication runtimestate

    После окончания проверьте статус репликации еще раз. Если не помогло, переходим к следующему пункту.

  • Resetting Database Replication - Перед началом проверим общее состояние системы:
    Cisco Unified Reporting > Unified CM Cluster Overview
    Удостоверьтесь что у нодов:
    - одинаковы Unified CM Version
    - проверьте CM Server Connectivity
    - проверьте Unified CM Time and Delay
    1. Для всех Subscriber выполняем команду:
      utils dbreplication stop
    2. На Publisher выполняем:
      utils dbreplication stop

      Выполнение команды может занять время: дождаться окончания выполнения.

    3. На Publisher выполняем для всех subscriber:
      utils dbreplication reset all
    4. Проверяем статус командой:
      utils dbreplication runtimestate

      Дожидаемся пока статус не будет SYNC COMPLETED

    5. Проверяем статус репликации:
      utils dbreplication status
  • Если команда utils dbreplication reset all не проканала, попробовать utils dbreplication clusterreset

  • Resetting the cluster - данную процедуру следует проводить только если не помогло reset replication.
    1. Для всех Subscriber выполняем команду:
      utils dbreplication stop
    2. На Publisher выполняем:
      utils dbreplication stop

      Выполнение команды может занять время: дождаться окончания выполнения.

    3. На Publisher выполняем:
      utils dbreplication clusterreset
    4. На Publisher выполняем для всех subscriber:
      utils dbreplication reset all
    5. Проверяем статус репликации командой:
      utils dbreplication status
      Если статус =2 ребутаем все Subsribers

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

Filtered HTML

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

Plain text

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