Dziękujemy za opinię.

W modelu wdrażania pojedynczej witryny, gdzie węzeł rozszerzonej przeżywalności (ESN) jest wdrażany w obrębie witryny wraz z lokalną bramą do routingu połączeń PSTN. Maksymalnie 7500 urządzeń może zostać zarejestrowanych w ESN podczas awarii.

W modelu wdrażania wielu lokalizacji, gdzie istnieje wiele witryn, a ESN można wdrożyć w każdej witrynie, zależy od wymagań biznesowych dotyczących przetrwania witryny. Wymagania dotyczące bramy lokalnej i DNS są zawsze koniecznością, a do Unified CM klastra można dodać łącznie 8 węzłów ESN.

Ten model wdrażania jest odpowiedni dla klienta w regionie z wieloma witrynami, a zdolność przetrwania jest wymagana dla wielu z tych witryn. Chociaż możliwe jest udostępnianie lokalnej bramy PSTN między witrynami, nie jest to zalecane. jeśli wystąpi awaria w sieci, witryna może zostać odizolowana i w takim przypadku ESN nie będzie w stanie dotrzeć do lokalnej bramy w celu kierowania połączeń do PSTN.

Poniżej znajdują się 2 opcje wdrażania dla wdrożenia w wielu lokalizacjach:

• Opcja 1: U lepszony węzeł przeżywalności wdrożony w każdym miejscu.

• Opcja 2 — Wspól ny węzeł ulepszonej przeżywalności współdzielony między wieloma witrynami.

Monitorujemy węzeł Enhanced Survivability Node i zarządzamy nim, podobnie jak inne węzły wdrożone w centrum danych dedykowanych instancji. Podczas zdarzenia przeżywalności, gdy ESN jest odłączony od Cisco Cloud is, tracimy dostęp do węzła i automatycznie łączymy się ponownie, gdy awaria zostanie rozwiązana, a łączność zostanie przywrócona.

Zarządzamy certyfikatami aplikacji UC, a podczas aktywacji węzła Enhanced Survivability Node zaktualizowaliśmy certyfikat Unified CM klastra instancji dedykowanej aktualizowany o ESN.

Podczas zdarzenia przetrwania węzeł Enhanced Survivability Node przechowuje wszystkie dane CDR/CMR lokalnie. Po przywróceniu łączności dane zostaną zsynchronizowane z programem Dedicated Instance Unified CM Publisher. Ilość danych, które można przechowywać, zależy od rozmiaru dysku węzła Enhanced Survivability Node. Maksymalna przestrzeń alokacji dysku, którą można ustawić dla CDR, wynosi 3328 MB. Może to być z małym lub dużym rozmiarem pliku CDR w oparciu o skonfigurowany przedział CDR. Czyszczenie odbywa się na podstawie:

• Gdy użycie dysku przekracza przydzielone lub skonfigurowane miejsce na dysku, usuwa przetworzone rekordy. Jeśli użycie dysku pozostanie większe, ma to miejsce wtedy, gdy nieprzetworzone rekordy są również usuwane.

• Wysoki znak wodny%, który jest skonfigurowany w ustawieniach „Zarządzanie CDR”, pliki CDR zostaną usunięte. Na przykład, jeśli „High Water Mark%” jest skonfigurowany jako 80%, a użycie dysku wynosi 80%, pliki CDR zostaną usunięte.

• Zacho@@ wanie plików CDR/CMR Czas trwania (dni) skonfigurowany w ustawieniach „Zarządzanie CDR” pliki CDR zostaną usunięte. Domyślnie jest ustawiony na 30 dni.

Poniżej znajdują się alerty w RTMT związane z węzłem Enhanced Survivability Node:

• SurvivabilityEvent — alarm jest uruchamiany, gdy wszystkie węzły wystąpienia dedykowanego nie są dostępne z węzła Enhanced Survivability Node.

• RemoteSurvivableNodeNotReachable — alarm jest uruchamiany, gdy węzeł rozszerzonej przeżywalności nie jest dostępny z wydawcy dedykowanej instancji. Unified CM

Podczas zdarzenia przeżywalności należy podłączyć RTMT do węzła Enhanced Survivability Node, aby monitorować wydajność ESN. To samo nie będzie dostępne, jeśli RTMT jest podłączony do węzłów instancji dedykowanej, ponieważ ESN nie będzie dostępny z chmury podczas zdarzenia przetrwania.

Podczas normalnej pracy replikacja bazy danych jest w pełni połączona między wszystkimi serwerami, w tym węzłem Enhanced Survivability Node w klastrze. Unified CM Statyczne dane konfiguracyjne, ponieważ są tworzone za pomocą ruchów, dodawania i zmian, są zawsze przechowywane w wydawcy i replikowane w jedną stronę od wydawcy do każdego subskrybenta i zwiększonej przeżywalności węzła w klastrze.

Podczas zdarzenia przetrwania, tylko funkcje skierowane do użytkownika są modyfikowane na urządzeniach zarejestrowanych w węźle Enhanced Survivability Node, a funkcje skierowane do użytkownika są zazwyczaj charakteryzowane faktem, że można włączyć lub wyłączyć funkcję bezpośrednio w telefonie, naciskając jeden lub więcej przycisków, w przeciwieństwie do zmiany funkcji za pomocą internetowego interfejsu użytkownika. Tak więc węzeł Enhanced Survivability Node umożliwia samoopiekę i interfejs użytkownika administratora stron internetowych jako operacje tylko do odczytu. Urządzenia użytkownika zarejestrowane w ESN mogą wprowadzać zmiany tylko do funkcji wymienionych poniżej podczas przełączania awaryjnego. Jednak zmiany te nie zostaną ponownie zsynchronizowane z Unified CM wydawcą DI po przywróceniu łączności.

Funkcje skierowane do użytkownika to wszystkie funkcje, które można włączyć lub wyłączyć, naciskając przyciski w telefonie i obejmują następujące elementy:

• Prześlij wszystkie połączenia (CFA)

• Prywatność Włącz lub Wyłącz

• Nie przeszkadzać (DND) Włącz lub wyłącz

• Cisco Extension MobilityZaloguj się

• Logowanie lub wylogowanie do grupy Hunt-group

• Mobilność urządzenia

• Status CTI CAPF dla użytkowników końcowych i użytkowników aplikacji.

Uwierzytelnianie klientów miękkich (Cisco Jabberi aplikacji Webex) do logowania podczas przełączania awaryjnego do węzła Enhanced Survivability Node jest następujące:

1. Uwierzytelnianie lokalne: Gdy uwierzytelnianie użytkowników odbywa się lokalnie w ramachUnified CM, podczas zdarzenia przetrwania węzeł Enhanced Survivability Node będzie mógł uwierzytelnić zarejestrowanych w nim klientów.

2. U@@ wierzytelnianie LDAP: W tym przypadku uwierzytelnianie użytkowników odbywa się za pomocą lokalnego serwera LDAP. Następnie podczas zdarzenia przetrwania uwierzytelnianie klientów miękkich będzie działać pod warunkiem, że serwer LDAP jest dostępny z węzła Enhanced Survivability Node.

   Powinieneś zapewnić dostępność katalogu LDAP do ESN przez cały czas trwania zdarzenia przeżywalności.

3. Uwierzy@@ telnianie logowania jednokrotnego (SSO): Uwier zytelnianie logowania użytkowników SSO odbywa się za pomocą serwera IDP. Następnie podczas zdarzenia przetrwania uwierzytelnianie klientów miękkich działa pod warunkiem, że serwer IDP jest dostępny z węzła Enhanced Survivability Node.

   W przypadku logowania do interfej Unified CM su internetowego z obsługą SSO wymagana jest dostępność IDP lub należy użyć logowania URL opartego na odzyskiwaniu.

   Klienci już uwierzytelnieni są nadal zalogowani, ponieważ uwierzytelnianie opiera się na tokenie uzyskanym przed zdarzeniem przetrwania. Jednak w przypadku nowych logowań, gdy klient nie ma prawidłowego tokena z poprzedniego uwierzytelniania, ESN przekieruje na serwer IDP w celu uwierzytelnienia. Dlatego zawsze konieczne jest zapewnienie dostępności serwera IDP do ESN przez cały czas trwania zdarzenia przetrwania.

Zasoby multimedialne są wymagane do podstawowych Unified CM funkcji, takich jak Music on Hold, Announcement, Conference Bridge (oprogramowanie) usługi muszą być włączone w ESN. Jeśli wdrożono zasoby multimedialne oparte na sprzęcie, to podczas zdarzenia przetrwania należy upewnić się, że serwery multimediów są dostępne z ESN.

Podczas normalnej pracy Unified CM klastra DI połączenia alarmowe (szczególnie w regionie AMER) są kierowane przez chmurę RedSky, gdzie znajduje się łącznik SIP skonfigurowany między zunifikowanym klastrem CM Dedicated Instnace a chmurą RedSky.

Jeśli wystąpi zdarzenie przetrwania, chmura RedSky nie będzie dostępna z ESN, dlatego konieczne jest skonfigurowanie planu wybierania połączeń alarmowych w taki sposób, aby, jeśli RedSky nie jest dostępny, kierował połączenia alarmowe przez lokalny PSTN GW skonfigurowany w tym miejscu. Grupa tras musi składać się z lokalnego PSTN GW, aby obsłużyć routing połączeń podczas zdarzenia przeżywalności.

Skonfiguruj plan wybierania dla routingu połączeń wewnątrzlokalizacyjnych, międzylokalizacyjnych, międzyklastrów i połączeń PSTN podczas zdarzenia przeżywalności. Ogólnie rzecz biorąc, ESN może kierować połączenia tylko dla urządzeń, które są na nim zarejestrowane. Wszystkie pozostałe połączenia muszą być kierowane do lokalnego PSTN GW (skonfigurowanego w każdej witrynie, w której wdrożony jest ESN), a stamtąd do PSTN. Poniżej wyjaśniono kilka scenariuszy:

• Telefon 1 i Telefon 2 zarejestrowany w tym samym ESN - połączenie jest kierowane w ESN.

• Telefon 1 zarejestrowany w ESN i telefon 2 zarejestrowany w Unified CM klastrze dedykowanych instancji - Plan wybierania powinien kierować połączenia z ESN do lokalnego PSTN GW, stamtąd do DI przez PSTN. Unified CM Podczas zdarzenia przeżywalności plan wybierania powinien wykryć awarię przekierowania połączeń i przekierować połączenia przez lokalny PSTN GW. To samo powinno dotyczyć połączeń przychodzących do ESN z Unified CM urządzeń DI.

• Telefon 1 zarejestrowany w ESN, a telefon 2 jest urządzeniem PSTN: Podczas zdarzenia przeżywalności połączenia PSTN muszą być skierowane do lokalnej bramy PSTN. Należy upewnić się, że plan wybierania może wykrywać awarie routingu połączeń i przekierowywać połączenie przez dostępną lokalną bramę PSTN.

• Podczas zdarzenia przetrwania, gdy łączność z witryny z chmurą dedykowanej instancji jest wyłączona (wyłączenie sieci WAN lub łączności), funkcje poczty głosowej i automatycznej obsługi nie będą działać dla urządzeń rejestrujących się w ESN, ponieważ Cisco Unity Connection serwer jest hostowany w chmurze dedykowanej instancji, z którą łączność z ESN jest wyłączona. Jeśli urządzenie jest skonfigurowane z funkcją „Call Forward Unzarejestrowane (CFU)”, a połączenie jest odbierane w DIUnified CM, wówczas dzwoniący może zdeponować pocztę głosową w Połączeniu dedykowanej instancji Unity. Które można odzyskać, gdy urządzenia wrócą do subskrybentów CM zunifikowanych DI.

• Jednak podczas zdarzenia przetrwania, gdy łączność z chmurą dedykowanej instancji jest dostępna, ale Unified CM klaster w DI jest wyłączony, w takim przypadku funkcje poczty głosowej i automatycznej obsługi działają na urządzeniach zarejestrowanych w ESN, ponieważ ESN będzie miał łączność z serwerem Unity Connection wdrożonym w chmurze DI.

Podczas zdarzenia przeżywalności ESN nie będzie w stanie dotrzeć do Cisco Expressway E & C w chmurze DI i odwrotnie. Tak więc w tym przypadku użytkownicy MRA nie mogą uzyskać usługi z ESN, a zatem nie będą mogli się zarejestrować. Jeśli jednak urządzenie MRA ma internet i może połączyć się z Cisco Expressways w chmurze DI, może zarejestrować się w DI, Unified CM pod warunkiem, że klaster w DI jest funkcjonalny.

Aby integracje oparte na CTI działały z węzłem Enhanced Survivability Node, należy dodać węzeł Enhanced Survivability Node jako część listy serwerów CTI. Ulepszenia CTI są wprowadzane dla aplikacji, które używają JTAPI, aby zezwolić na węzeł Enhanced Survivability Node jako serwer CTI, z którym aplikacja może łączyć się tylko w przypadku, gdy podstawowe lub wtórne serwery CTI na skonfigurowanej liście nie są dostępne. Podczas normalnej pracy aplikacje CTI na miejscu mogą łączyć się z podstawowymi i wtórnymi serwerami CTI w chmurze DI, a podczas zdarzenia przetrwania mogą łączyć się z węzłem Enhanced Survivability Node, aby zapewnić ciągłe korzystanie z CTI. Aplikacje muszą dostosować się do nowych interfejsów API ujawnionych przez interfejs JTAPI, aby zapewnić, że po przywróceniu łączności nastąpi rezerwa z węzła Enhanced Survivability Node.

Aby uzyskać więcej informacji na temat nowych dodanych interfejsów API, zapoznaj się z sekcją Redundancja, https://www.cisco.com/c/en/us/td/docs/ voice_ip_comm /cucm/ /14_0_1/ -unified-jtapi-developers-guide-14/ jtapi_dev -unified-jtapi-developers-guide-1251_chapter_00.html cucm_b_cisco cucm_b_cisco

Aplikacje innych firm, które łączą się za pośrednictwem kanałów SIP, obsługują węzeł Enhanced Survivability Node. W konfiguracjach magistrali SIP konfiguracja „uruchom na wszystkich węzł ach” musi być włączona.

Obsługiwane są urządzenia innych firm, które mają funkcję Trzeciorzędowego TFTP.