Огляд

У моделі розгортання на одному місці, де вузол покращеної живучості (ESN) розгортається в межах сайту разом із локальним шлюзом для маршрутизації викликів PSTN. Максимум 7500 пристроїв можна зареєструвати в ESN під час збою.

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

Ця модель розгортання актуальна для клієнта в регіоні з кількома сайтами, і живучість є вимогою для кількох із цих сайтів. Хоча можна спільно використовувати локальний шлюз PSTN між сайтами, це не рекомендується. у разі збою мережі сайт може стати ізольованим, і в цьому випадку ESN не зможе зв’язатися з локальним шлюзом для маршрутизації викликів до телефонної мережі загального користування.

Нижче наведено 2 варіанти розгортання для кількох сайтів:

• Варіант 1. Enhanced Survivability Node, розгорнутий на кожному місці.

• Варіант 2 – Загальний вузол покращеної живучості, спільний для кількох сайтів.

Ми відстежуємо та керуємо вузлом Enhanced Survivability Node, як і іншими вузлами, які розгортаються в центрі обробки даних Dedicated Instance. Під час події живучості, коли ESN від’єднується від Cisco Cloud, ми втрачаємо доступ до вузла та автоматично підключаємось назад, коли збій усунено та з’єднання відновлено.

Ми керуємо сертифікатами додатків UC, і під час активації Enhanced Survivability Node ми оновили сертифікат Dedicated Instance Unified CM cluster, оновлений ESN.

Під час активації ESN від Control Hub відбудеться перезапуск усіх зареєстрованих пристроїв, оскільки сертифікат для Unified CM Cluster буде оновлено сертифікатами multi-SAN. Тому ми плануємо період обслуговування під час активації ESN від Control Hub. Зверніться, Як активувати Enhanced Survivability Node.

Під час події живучості Enhanced Survivability Node зберігає всі дані CDR/CMR локально. Коли з’єднання буде відновлено, дані буде синхронізовано назад із Dedicated Instance Unified CM Publisher. Обсяг даних, який можна зберегти, залежить від розміру диска Enhanced Survivability Node. Максимальний дисковий простір, який можна встановити для CDR 3328 Мб. Це може бути малий або великий розмір файлу CDR залежно від налаштованого інтервалу CDR. Очищення відбувається на основі:

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

• Відмітка високої води % який налаштовано в налаштуваннях «Керування CDR», файли CDR буде очищено. Наприклад, якщо «High Water Mark %” is configured as 80% і використання диска становить 80%, тоді файли CDR буде очищено.

• Тривалість збереження файлів CDR / CMR (дні) який налаштовано в налаштуваннях «Керування CDR», файли CDR буде очищено. За замовчуванням встановлено 30 днів.

Нижче наведено сповіщення в RTMT, пов’язані з Enhanced Survivability Node:

• SurvivabilityEvent- тривога спрацьовує, коли всі вузли виділеного екземпляра недоступні з вузла покращеної живучості.

• RemoteSurvivableNodeNotReachable - тривога спрацьовує, коли вузол Enhanced Survivability Node недоступний для видавця Dedicated Instance Unified CM.

Під час події живучості вам потрібно підключити RTMT до Enhanced Survivability Node, щоб контролювати продуктивність ESN. Те саме буде недоступно, якщо RTMT підключено до вузлів виділеного екземпляра, оскільки ESN не буде доступним із хмари під час події живучості.

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

Під час події живучості змінюються лише функції користувача на пристроях, зареєстрованих у Enhanced Survivability Node, і функції користувача зазвичай характеризуються тим фактом, що ви можете ввімкнути або вимкнути функцію безпосередньо на його телефоні, натиснувши кнопку одну або кілька кнопок, на відміну від зміни функції через веб-графічний інтерфейс. Таким чином, Enhanced Survivability Node дозволяє виконувати самообслуговування та графічний інтерфейс веб-адміністратора як операції лише для читання. Пристрої користувача, зареєстровані в ESN, можуть вносити зміни лише до функцій користувача, перелічених нижче, під час відновлення після відмови. Однак ці зміни не будуть синхронізовані назад із видавцем DI Unified CM, коли з’єднання буде відновлено.

Користувальницькі функції – це будь-які функції, які можна ввімкнути або вимкнути натисканням кнопок на телефоні та включають наступне:

• Переадресація всіх дзвінків (CFA)

• Конфіденційність Увімкнути або Вимкнути

• Увімкнення або вимкнення режиму «Не турбувати» (DND).

• Вхід у Cisco Extension Mobility

• Вхід або вихід із групи пошуку

• Мобільність пристрою

• Статус CTI CAPF для кінцевих користувачів і користувачів програм.

Автентифікація програмних клієнтів (Cisco Jabber і Webex Application) для входу під час перемикання на Enhanced Survivability Node виглядає наступним чином:

1. Локальна автентифікація: Якщо автентифікація користувачів виконується локально в Unified CM, під час події живучості Enhanced Survivability Node зможе автентифікувати клієнтів, зареєстрованих на ньому.

2. Автентифікація LDAP: У цьому випадку автентифікація користувачів здійснюється за допомогою локального сервера LDAP. Тоді під час події живучості автентифікація програмних клієнтів працюватиме за умови, що сервер LDAP доступний із вузла Enhanced Survivability.

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

3. Аутентифікація єдиного входу (SSO).: Автентифікація користувачів під керуванням SSO здійснюється за допомогою сервера IDP. Тоді під час події живучості автентифікація програмних клієнтів працює за умови, що сервер IDP доступний із вузла Enhanced Survivability.

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

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

Медіа-ресурси потрібні для базових функцій Unified CM, таких як Музика в режимі очікування, Оголошення, служби Conference Bridge (програмне забезпечення) мають бути ввімкнені на ESN. Якщо було розгорнуто апаратні медіа-ресурси, то під час події живучості ви повинні переконатися, що медіа-сервери доступні з ESN.

Під час нормальної роботи кластера DI Unified CM екстрені виклики (зокрема в регіоні AMER) направляються через хмару RedSky, де існує транк SIP, налаштований між кластером Dedicated Instnace unified CM і хмарою RedSky.

Якщо станеться подія живучості, хмара RedSky буде недоступна через ESN, і, отже, вам потрібно налаштувати номерний план екстрених викликів таким чином, щоб, якщо RedSky недоступний, маршрутизувати екстрені виклики через локальну телефонну мережу загального користування. GW, налаштований на цьому сайті. Група маршрутів має складатися з локального GW PSTN для обробки маршрутизації викликів під час події живучості.

Для екстрених дзвінків в інших регіонах виділеної інстанції також потрібно налаштувати номерний план для маршрутизації дзвінків через локальну PSTN GW під час події живучості.

Налаштуйте номерний план для маршрутизації внутрішньосайтових, міжсайтових, міжкластерних і телефонних викликів під час події живучості. Загалом ESN може маршрутизувати виклики лише для пристроїв, які на ньому зареєстровані. Усі інші дзвінки потрібно направляти до локальної PSTN GW (налаштованої на кожному сайті, де розгорнуто 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.

Ми не рекомендуємо ICT-дзвінки між 2 вузлами ESN, хоча це можливо, якщо ESN доступні у вашій мережі.

• Під час події живучості, коли з’єднання вашого сайту з хмарою Dedicated Instance відключено (WAN або збій підключення), функції голосової пошти та автосекретаря не працюватимуть для пристроїв, зареєстрованих у ESN, оскільки розміщено сервер Cisco Unity Connection. у хмарі Dedicated Instance, з якою не підключено ESN. Якщо ваш пристрій налаштовано на «Call Forward Unregistered (CFU)» і виклик отримано в DI Unified CM, тоді абонент може внести голосову пошту в Dedicated Instance Unity Connection. Який можна отримати, коли пристрої повертаються до абонентів DI unified CM.

• Однак під час події живучості, коли підключення до хмари Dedicated Instance доступне, але кластер 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, щоб забезпечити відкат від Enhanced Survivability Node після відновлення з’єднання.

Щоб отримати додаткові відомості про нові додані 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

Веб-сервіс AXL увімкнено у Enhanced Survivability Node із правами адміністратора лише для читання. Ми рекомендуємо, щоб будь-які програми сторонніх розробників, такі як сервер ініціалізації, взаємодіяли лише з видавцем DI Unified CM для будь-яких оновлень, пов’язаних з базою даних. Однак ці програми можуть працювати лише для читання, якщо їх підключено до Enhanced Survivability Node.

Програми сторонніх розробників, які взаємодіють через магістралі SIP, підтримуються за допомогою Enhanced Survivability Node. У конфігураціях магістралі SIP, 'працювати на всіх вузлахКонфігурація повинна бути включена.

Підтримуються пристрої сторонніх розробників із підтримкою третинного протоколу TFTP.