В модели развертывания на одном сайте узел повышенной живучести (ESN) развертывается на сайте вместе с локальным шлюзом для маршрутизации вызовов ТфОП. Во время сбоя в ESN можно зарегистрировать максимум 7500 устройств.

В модели развертывания на нескольких площадках, где имеется несколько площадок, возможность развертывания ESN на каждой площадке зависит от бизнес-требований к живучести площадки. Требования к локальному шлюзу и DNS всегда являются необходимостью, а в унифицированный кластер CM можно добавить в общей сложности 8 узлов ESN.

Эта модель развертывания актуальна для клиентов в регионе с несколькими объектами, и для многих из этих объектов требуется отказоустойчивость. Хотя локальный шлюз PSTN можно использовать совместно на нескольких сайтах, делать этого не рекомендуется. В случае сбоя сети сайт может оказаться изолированным, и в этом случае ESN не сможет подключиться к локальному шлюзу для маршрутизации вызовов в PSTN.

Ниже приведены два варианта развертывания для многосайтового развертывания:

• Вариант 1: На каждом объекте развернут узел повышенной живучести.

• Вариант 2 – Общий узел повышенной живучести, общий для нескольких сайтов.

Мы отслеживаем и управляем узлом повышенной живучести, как и другими узлами, развернутыми в центре обработки данных выделенного экземпляра. В случае возникновения аварийной ситуации, когда ESN отключается от облака Cisco, мы теряем доступ к узлу и автоматически подключаемся снова, когда сбой устраняется и связь восстанавливается.

Мы управляем сертификатами приложений UC, и во время активации узла повышенной живучести мы обновили сертификат кластера унифицированного CM выделенного экземпляра, обновив его с помощью ESN.

Во время события выживаемости узел повышенной выживаемости сохраняет все CDR/CMR данные локально. После восстановления подключения данные будут синхронизированы обратно в выделенный экземпляр Unified CM Publisher. Объем данных, которые могут быть сохранены, зависит от размера диска узла повышенной живучести. Максимальный объем дискового пространства, который можно выделить для CDR, составляет 3328 МБ. Размер файла CDR может быть как маленьким, так и большим в зависимости от настроенного интервала CDR. Очистка происходит на основе:

• Когда использование диска превышает выделенное или настроенное дисковое пространство, обработанные записи удаляются. Если использование диска остается большим, то необработанные записи также очищаются.

• Высшая точка %, настроенный в настройках «Управление CDR», файлы CDR будут очищены. Например, если «Высокая отметка %” is configured as 80% » и загрузка диска составляет 80%, то файлы CDR будут очищены.

• CDR / Продолжительность хранения файлов CMR (дни), указанная в настройках «Управление CDR», файлы CDR будут очищены. По умолчанию установлено значение 30 дней.

Ниже приведены оповещения в RTMT, связанные с узлом повышенной живучести:

• SurvivabilityEvent— сигнал тревоги срабатывает, когда все узлы выделенного экземпляра недоступны из узла повышенной живучести.

• RemoteSurvivableNodeNotReachable — сигнал тревоги срабатывает, когда узел повышенной живучести недоступен из выделенного экземпляра унифицированного издателя CM.

Во время мероприятия по обеспечению живучести вам необходимо подключить RTMT к узлу повышенной живучести для мониторинга производительности ESN. То же самое будет недоступно, если RTMT подключен к узлам выделенного экземпляра, поскольку ESN не будет доступен из облака во время события по обеспечению живучести.

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

Во время события, связанного с обеспечением живучести, на устройствах, зарегистрированных в узле повышенной живучести, изменяются только пользовательские функции, а пользовательские функции обычно характеризуются тем, что вы можете включать или отключать функцию непосредственно на телефоне, нажав одну или несколько кнопок, в отличие от изменения функции через веб-интерфейс. Таким образом, узел повышенной живучести позволяет использовать графический интерфейс самообслуживания и веб-администрирования в качестве операций, доступных только для чтения. Устройства пользователя, зарегистрированные в ESN, могут вносить изменения только в перечисленные ниже функции, с которыми сталкивается пользователь во время переключения при сбое. Однако эти изменения не будут синхронизированы с издателем DI Unified CM после восстановления подключения.

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

• Переадресация всех вызовов (CFA)

• Включить или отключить конфиденциальность

• Включение или отключение режима «Не беспокоить» (DND)

• Вход в Cisco Extension Mobility

• Вход или выход из группы Hunt

• Мобильность устройства

• Статус CTI CAPF для конечных пользователей и пользователей приложений.

Аутентификация программных клиентов (приложения Cisco Jabber и Webex) для входа в систему во время переключения на узел повышенной живучести выполняется следующим образом:

1. Локальная аутентификация: Если аутентификация пользователей выполняется локально в Unified CM, во время события живучести узел повышенной живучести сможет аутентифицировать зарегистрированных на нем клиентов.

2. Аутентификация LDAP: В этом случае аутентификация пользователей осуществляется с использованием локального LDAP-сервера. Затем во время события живучести аутентификация программных клиентов будет работать при условии, что сервер LDAP доступен из узла повышенной живучести.

   Вам следует обеспечить доступность каталога LDAP для ESN на протяжении всего мероприятия по обеспечению живучести.

3. Аутентификация с единым входом (SSO): Аутентификация пользователей SSO-входа осуществляется с использованием сервера IDP. Затем во время события живучести аутентификация программных клиентов работает при условии, что сервер IDP доступен из узла повышенной живучести.

   Для входа в веб-интерфейс Unified CM с поддержкой единого входа требуется доступность IDP или необходимо использовать вход по URL-адресу на основе восстановления.

   Уже аутентифицированные клиенты продолжают авторизоваться, поскольку аутентификация основана на токене, полученном до события живучести. Однако при новых входах в систему, когда у клиента нет действительного токена от предыдущей аутентификации, ESN перенаправит его на сервер IDP для аутентификации. Поэтому всегда необходимо обеспечивать доступность сервера IDP для ESN на протяжении всего мероприятия по обеспечению живучести.

Для базовых функций Unified CM, таких как музыка на удержании, объявления, службы Conference Bridge (программное обеспечение), в ESN должны быть включены медиаресурсы. Если были развернуты аппаратные медиаресурсы, то во время мероприятия по обеспечению живучести необходимо убедиться, что медиасерверы доступны из ESN.

Во время нормальной работы кластера унифицированного CM DI экстренные вызовы (особенно в регионе AMER) направляются через облако RedSky, где между кластером унифицированного CM выделенного экземпляра и облаком RedSky настроен SIP-транк.

В случае возникновения аварийной ситуации облако RedSky будет недоступно из ESN, поэтому вам необходимо настроить план набора для экстренных вызовов таким образом, чтобы в случае недоступности RedSky направлять экстренные вызовы через локальный шлюз PSTN, настроенный на этом сайте. Группа маршрутов должна состоять из локального шлюза PSTN для обработки маршрутизации вызовов во время события по обеспечению живучести.

Настройте план набора для маршрутизации внутрисайтовых, межсайтовых, межкластерных и PSTN-вызовов во время события по обеспечению живучести. В общем случае ESN может маршрутизировать вызовы только для тех устройств, которые в нем зарегистрированы. Все остальные вызовы необходимо направлять на локальный шлюз PSTN (настроенный на каждом сайте, где развернут ESN), а оттуда — в PSTN. Ниже приведены несколько сценариев:

• Телефон 1 и телефон 2 зарегистрированы на один и тот же ESN — вызов маршрутизируется внутри ESN.

• Телефон 1 зарегистрирован в ESN, а телефон 2 зарегистрирован в кластере Dedicated Instance Unified CM. План набора должен маршрутизировать вызовы из ESN в локальный PSTN GW, а оттуда в DI Unified CM через PSTN. В случае возникновения проблем с обеспечением живучести план набора должен обнаружить сбой маршрутизации вызовов и перенаправить вызовы через локальный шлюз PSTN. То же самое должно применяться и к входящим вызовам на ESN с устройств DI Unified CM.

• Телефон 1 зарегистрирован в ESN, а телефон 2 является устройством PSTN: В случае возникновения аварийной ситуации вызовы PSTN необходимо направлять на локальный шлюз PSTN. Необходимо убедиться, что план набора позволяет обнаруживать сбои маршрутизации вызовов и перенаправлять вызовы через доступный локальный шлюз PSTN.

• В случае возникновения проблем с обеспечением живучести, когда подключение между вашим сайтом и облаком выделенного экземпляра отсутствует (сбой WAN или подключения), функции голосовой почты и автосекретаря не будут работать для устройств, зарегистрированных в ESN, поскольку сервер Cisco Unity Connection размещен в облаке выделенного экземпляра, подключение к которому из ESN отсутствует. Если на вашем устройстве настроена функция «Переадресация вызовов без регистрации (CFU)» и вызов принимается в DI Unified CM, то вызывающий абонент может разместить голосовое сообщение в выделенном экземпляре Unity Connection. Которые могут быть восстановлены, когда устройства перейдут на унифицированных абонентов DI CM.

• Однако во время событий по обеспечению живучести, когда подключение к облаку выделенного экземпляра доступно, но кластер Unified CM в DI не работает, функции голосовой почты и автосекретаря работают для устройств, зарегистрированных в ESN, поскольку ESN будет иметь подключение к серверу Unity Connection, развернутому в облаке DI.

Во время мероприятия по обеспечению выживаемости ESN не сможет добраться до Cisco Expressway E. & C в облаке DI и наоборот. Таким образом, в этом случае пользователи MRA не смогут получить услугу от ESN и, следовательно, не смогут зарегистрироваться. Однако если устройство MRA имеет доступ к Интернету и может подключаться к Cisco Expressways в облаке DI, то оно может зарегистрироваться в DI Unified CM при условии, что кластер в DI функционирует.

Для работы интеграций на основе CTI с узлом Enhanced Survivability Node необходимо добавить узел Enhanced Survivability Node в список серверов CTI. Улучшения CTI реализованы для приложений, использующих JTAPI, чтобы разрешить Enhanced Survivability Node выступать в качестве сервера CTI, к которому приложение может подключаться только в том случае, если первичный или вторичный серверы CTI в настроенном списке недоступны. Во время нормальной работы приложения CTI на объекте могут подключаться к основному и дополнительному серверам CTI в облаке DI, а во время событий по обеспечению живучести они могут подключаться к узлу Enhanced Survivability Node для непрерывной работы CTI. Приложения должны адаптироваться к новым API, предоставляемым через интерфейс JTAPI, чтобы гарантировать откат от узла повышенной живучести при восстановлении подключения.

Более подробную информацию о новых добавленных API см. в разделе «Избыточность». https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/jtapi_dev/14_0_1/cucm_b_cisco-unified-jtapi-developers-guide-14/cucm_b_cisco-unified-jtapi-developers-guide-1251_chapter_00.html

Приложения сторонних разработчиков, взаимодействующие через каналы SIP, поддерживают узел Enhanced Survivability. В конфигурациях SIP-транка должна быть включена конфигурация «выполняться на всех узлах».

Поддерживаются сторонние устройства, имеющие возможность использования третичного TFTP.