В большинстве инсталляций 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 должны быть одинаковыми.

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

Также эти значения получить и в виде графика:
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

Главная команда 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

Также см.
https://community.cisco.com/t5/collaboration-voice-and-video/troubleshoo...