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

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

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

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

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

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

Ние наблюдаваме и управляваме Enhanced Survivability Node като други възли, които са внедрени в Dedicated Instance център за данни. По време на събитие за оцеляване, когато връзката на ESN от облака на Cisco е когато губим достъп до възела и автоматично се свързваме обратно, когато прекъсването е разрешено и връзката е възстановена.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Cisco Extension Mobility Login

• Вход или излизане от Hunt-group

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

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

Удостоверяването на софтуерни клиенти (Cisco Jabber и Webex Application) за влизане по време на прехода към 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, като Музика в изчакване, Съобщение, услугите Conference Bridge (софтуер) трябва да бъдат активирани на ESN. Ако са били разгърнати медийни ресурси, базирани на хардуер, тогава по време на събитието за оцеляване трябва да се уверите, че медийните сървъри са достъпни от ESN.

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

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

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

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

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

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

• По време на събитието за оцеляване, когато връзката от вашия сайт към облака на специализиран екземпляр е прекъсната (WAN или прекъсване на връзката), функциите за гласова поща и автоматичен придружител няма да работят за устройствата, които се регистрират в ESN, тъй като сървърът на Cisco Unity Connection се хоства в облака на специализиран екземпляр, към който връзката от ESN е прекъсната. Ако вашето устройство е конфигурирано с „Нерегистрирано пренасочване на повикване (CFU)“ и повикването е получено в DI Unified CM, тогава повикващият може да депозира гласова поща в Dedicated Instance Unity Connection. Което може да бъде извлечено, когато устройствата се върнат към DI unified 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, за да се гарантира, че се извършва резервно връщане от 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

Приложенията на трети страни, които се свързват през SIP каналите, поддържат с Enhanced Survivability Node. В конфигурациите на SIP трънк конфигурацията „run on all nodes“ трябва да е активирана.

Поддържат се устройства на трети страни, които имат възможност за третичен TFTP.