Общ преглед

В модела за модел за разгръщане на един сайт, където възел за подобрена оцеляване (ESN) се разполага в рамките на обект заедно с локален шлюз за маршрутизиране на повикване. Максимум 7500 устройства могат да бъдат регистрирани към ESN по време на прекъсване.

В модел за разгръщане на множество сайтове, където има множество сайтове и ESN може да бъде разгърнат във всеки сайт, зависи от бизнес изискването за оцеляване на сайта. Изискванията за локален шлюз и DNS винаги са необходими и общо 8 ESN възела могат да бъдат добавени към Unified CM клъстер.

Този модел за разгръщане е подходящ за клиент в регион с множество сайтове и оцеляването е изискване за множество от тези сайтове. Въпреки че е възможно да споделяте локален шлюз на PSTN между сайтове, това не се препоръчва. ако има прекъсване на мрежата, сайтът може да се изолира и в този случай ESN няма да може да достигне до локалния шлюз за насочване на повикванията към PSTN.

По-долу са дадени 2 опции за внедряване за внедряване на няколко сайта:

• Опция 1: Подобрен възел за оцеляване, разположен на всеки обект.

• Вариант 2 – Общ възел за подобрена оцеляване, споделен между множество сайтове.

Ние наблюдаваме и управляваме възела за подобрена оцеляване като други възли, които са разположени в центъра за данни за Специализирани инстанции. По време на събитие за оцеляване, когато ESN е изключен от Cisco Cloud , губим достъп до възела и автоматично се свързваме обратно, когато прекъсването е разрешено и свързаността е възстановена.

Ние управляваме сертификатите за приложения на UC и по време на активирането на Enhanced Survivability Node актуализирахме сертификата за клъстер в Unified CM за специални инстанции, който се актуализира с ESN.

По време на активирането на ESN от Control Hub ще има рестартиране на всички регистрирани устройства, тъй като сертификатът за Unified CM Cluster ще бъде актуализиран с мулти-SAN сертификатите. Следователно ние планираме периода на поддръжка по време на активирането на ESN от Control Hub. Препратете, Как да активирате възела за подобрена оцеляване .

По време на събитието за оцеляване, възелът за подобрена оцеляване съхранява всички CDR/CMR данни локално. Когато свързаността бъде възстановена, данните ще бъдат синхронизирани обратно към Dedicated Instance Unified CM Publisher. Количеството данни, което може да се съхранява, се основава на размера на диска на тогавашния възел за подобрена оцеляване. Максималното дисково пространство, което може да се зададе за CDR, е 3328 MB . Това може да бъде с малък до голям размер на CDR файл въз основа на CDR интервала, който е конфигуриран. Прочистването се извършва въз основа на:

• Когато използване на диск надвиши разпределеното или конфигурирано дисково пространство, то изтрива обработените записи. Ако използване на диск остане по-голямо, тогава необработените записи също се изчистват.

• Висок воден знак % който е конфигуриран в настройките на "CDR Management", CDR файловете ще бъдат изчистени. Например, ако „High Water Mark%” is configured as 80% и използване на диск е 80%, тогава CDR файловете ще бъдат изчистени.

• Продължителност на запазване на CDR / CMR файлове (дни) който е конфигуриран в настройките на "CDR Management", CDR файловете ще бъдат изчистени. По подразбиране е настроен на 30 дни.

Следват сигналите в RTCP , свързани с Enhanced Survivability Node:

• Събитие за оцеляване - алармата се задейства, когато всички възли за специален екземпляр не са достъпни от възела за подобрена оцеляване.

• RemoteSurvivableNodeNotReachable - алармата се задейства, когато възелът за подобрена оцеляване не е достъпен от издателя на Unified CM за Специализирани инстанции.

По време на събитието за оцеляване, трябва да свържете RTCP към Enhanced Survivability Node, за да наблюдавате производителността на ESN. Същото няма да бъде достъпно, ако RTCP е свързан към възлите за специален екземпляр, тъй като ESN няма да бъде достъпен от облака по време на събитието за оцеляване.

По време на нормална работа, репликация на базата с данни е напълно свързана между всички сървъри, включително възела за подобрена преживяемост в рамките на клъстер в Unified CM. Данните за статичната конфигурационни данни, тъй като се създават чрез премествания, добавяния и промени, винаги се съхраняват на издателя и се репликират по един начин от издателя към всеки абонат и възел за подобрена оцеляване в клъстера.

По време на събитие за оцеляване, само функциите, насочени към потребителя, се променят на устройствата, които са регистрирани в Enhanced Survivability Node и функциите, насочени към потребителя, обикновено се характеризират с факта, че можете да активирате или деактивирате функция директно на техния телефон, като натиснете един или повече бутони, за разлика от промяната на функция чрез уеб-базиран GUI. И така, възелът за подобрена оцеляване позволява самообслужване и GUI на уеб администратора като операции само за четене. Устройствата на потребителя, регистрирани в ESN, могат да правят промени само в функциите, изправени пред потребителя, изброени по-долу по време на отказ. Тези промени обаче няма да бъдат синхронизирани обратно с издателя на DI Unified CM , когато връзката бъде възстановена.

Функции, насочени към потребителя, са всички функции, които могат да бъдат активирани или деактивирани чрез натискане на бутони на телефона и включват следното:

• Пренасочване на всички (CFA)

• Поверителност Активиране или деактивиране

• Не безпокойте(DND) Активирайте или деактивирайте

• Вход за Cisco Extension Mobility

• Hunt-group Login или Изход

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

• Състояние на CTI CAPF за крайни потребители и потребители на приложения.

Удостоверяването на меки клиенти (Cisco Jabber и Webex приложение) за влизане по време на отказ към Enhanced Survivability Node е както следва:

1. Локално удостоверяване : Когато удостоверяването на потребителите се извършва локално в рамките на Unified CM, по време на събитието за оцеляване, възелът за подобрена оцеляване ще може да удостовери автентичността на клиентите, регистрирани в него.

2. LDAP удостоверяване : В този случай удостоверяването на потребителите се извършва с помощта на локалния LDAP сървър. След това по време на събитието за оцеляване, удостоверяването на меки клиенти ще работи, при условие че LDAP сървър е достъпен от възела за подобрена оцеляване.

   Трябва да гарантирате достъпността на LDAP директорията до ESN по време на събитието за оцеляване.

3. Удостоверяване с единичен вход (SSO). : Удостоверяването за влизане в SSO на потребителите се извършва с помощта на IDP сървъра. След това по време на събитието за оцеляване автентификацията на меките клиенти работи, при условие че IDP сървърът е достъпен от възела за подобрена оцеляване.

   За влизане в Unified CM web UI с активиран SSO е необходима достъпност на IDP или трябва да се използва URL за вход, базиран на възстановяване.

   Вече удостоверените клиенти продължават да влизат в системата, тъй като удостоверяването се основава на токена, получен преди събитието за оцеляване. Въпреки това, за нови влизания, когато клиентът няма валиден токен от предишно удостоверяване, ESN ще пренасочи към IDP сървъра за удостоверяване. Следователно винаги е необходимо да се гарантира достъпността на IDP сървъра до ESN по време на събитието за оцеляване.

Медийните ресурси са необходими за основните функции на Unified CM , като например Музика на изчакване, Обявление, Конферентен мост (софтуер) услугите трябва да бъдат активирани на ESN. Ако са били разгърнати хардуерно базирани медийни ресурси , тогава по време на събитието за оцеляване трябва да се уверите, че медийните сървъри са достъпни от ESN.

По време на нормални операции на клъстер в Unified CM, спешните повиквания (особено в региона AMER) се пренасочват през облака RedSky, където има външна линия SIP транк, който е конфигуриран между Dedicated Instnace unified CM клъстер и RedSky облака.

Ако има събитие за оцеляване, облакът RedSky няма да бъде достъпен от ESN и следователно се изисква от вас да конфигурирате плана за набиране при спешни повиквания, така че, ако RedSky не е наличен, тогава да насочвате спешните повиквания през локалния PSTN GW, конфигуриран на този сайт. група маршрути трябва да се състои от локален PSTN GW, за да обработва маршрутизиране на повикване по време на събитието за оцеляване.

За спешни повиквания и в други региони на Специални инстанции, планът за набиране трябва да бъде конфигуриран да насочва повикванията през Local PSTN GW по време на събитието за оцеляване.

Конфигурирайте плана за набиране за маршрутизиране на вътрешносайтови, междусайтови, междуклъстерни и PSTN повиквания по време на събитието за оцеляване. По принцип ESN може да маршрутизиране на повиквания само за устройства, които са регистрирани към него. Всички други повиквания трябва да бъдат насочени към локалния PSTN GW (конфигуриран във всеки сайт, където е разположен ESN) и оттам към PSTN. По-долу са обяснени няколко сценария:

• Телефон 1 и Телефон 2 са регистрирани към същия ESN – Обаждането се пренасочва в рамките на ESN.

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

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

Не препоръчваме ICT повиквания между 2 ESN възела, въпреки че е възможно, когато ESN са достъпни във вашата мрежа.

• По време на събитието за оцеляване, когато свързаността от вашия сайт към облака за специален екземпляр е прекъсната (прекъсване на WAN или свързаността), функциите за гласова поща и автоматичен секретар няма да работят за устройствата, които се регистрират към ESN, тъй като Cisco Unity Connection server се хоства в облака за специален екземпляр, към който връзката от 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 .