Rozpocznij od rozszerzonej możliwości przetrwania

W modelu wdrożenia pojedynczej witryny, w którym w witrynie jest wdrożony węzeł rozszerzonej możliwości utrzymania (ESN) wraz z bramą lokalną do trasowania połączeń PSTN. W przypadku awarii ESN można zarejestrować maksymalnie 7500 urządzeń.

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

Ten model wdrożenia jest istotny dla klienta w całym regionie z wieloma witrynami, a możliwość przetrwania jest wymagana dla wielu z tych witryn. Chociaż istnieje możliwość udostępniania bramy lokalnej PSTN w witrynach, nie jest to zalecane. Jeśli wystąpi awaria sieci, witryna może zostać odizolowana i w takim przypadku ESN nie będzie w stanie dotrzeć do bramy lokalnej w celu przekierowania połączeń do PSTN.

Poniżej przedstawiono 2 opcje wdrożenia dla wdrożenia w wielu lokalizacjach:

• Opcja 1: Ulepszony węzeł utrzymania wdrożony w każdym zakładzie.

• Wariant 2 – Wspólny węzeł rozszerzonej możliwości przetrwania udostępniony między wieloma witrynami.

Monitorujemy i zarządzamy węzłem rozszerzonej żywotności, podobnie jak innymi węzłami, które są wdrażane w centrum danych dedykowanego wystąpienia. Podczas zdarzenia powodującego przeżycie, gdy ESN jest odłączony od chmury Cisco, oznacza to, że tracimy dostęp do węzła i automatycznie nawiązujemy połączenie z powrotem po rozwiązaniu awarii i przywróceniu łączności.

Zarządzamy certyfikatami aplikacji UC i podczas aktywacji węzła Ulepszonego utrzymania zaktualizowaliśmy certyfikat klastra dedykowanego wystąpienia Unified CM z ESN.

Podczas zdarzenia utrzymania węzeł rozszerzonego utrzymania przechowuje wszystkie dane CDR/CMR lokalnie. Po przywróceniu łączności dane zostaną zsynchronizowane z powrotem do dedykowanego wydawcy Unified CM Instance. Ilość danych, które mogą być przechowywane, zależy od rozmiaru dysku, a następnie węzła rozszerzonego utrzymania. Maksymalny obszar alokacji dysku, który można ustawić dla protokołu CDR, to 3328 MB. Może to być mały lub duży rozmiar pliku CDR w oparciu o skonfigurowany interwał 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 niż wtedy, gdy nieprzetworzone rekordy również zostaną usunięte.

• High Water Mark % skonfigurowany w ustawieniach „CDR Management” pliki CDR zostaną usunięte. Jeśli na przykład „High Water Mark %” is configured as 80% i użycie dysku wynosi 80%, pliki CDR zostaną usunięte.

• Czas trwania (dni) przechowywania plików CDR/CMR skonfigurowany w ustawieniach „Zarządzanie CDR”, pliki CDR zostaną usunięte. Domyślnie ustawiono go na 30 dni.

Poniżej znajdują się alerty w interfejsie RTMT związane z węzłem rozszerzonej żywotności:

• SurvivabilityEvent- alarm jest uruchamiany, gdy wszystkie węzły dedykowanego wystąpienia nie są dostępne z węzła rozszerzonego utrzymania.

• RemoteSurvivableNodeNotReachable - alarm jest wyzwalany, gdy węzeł rozszerzonej żywotności nie jest osiągalny od wydawcy dedykowanego wystąpienia Unified CM.

Podczas zdarzenia utrzymania należy połączyć RTMT z węzłem rozszerzonego utrzymania w celu monitorowania wydajności ESN. To samo nie będzie dostępne, jeśli RTMT jest podłączony do węzłów dedykowanego wystąpienia, ponieważ ESN nie będzie osiągalny z chmury podczas zdarzenia utrzymania.

Podczas normalnej pracy replikacja bazy danych jest w pełni powiązana między wszystkimi serwerami, w tym węzłem rozszerzonej żywotności w klastrze Unified CM. Statyczne dane konfiguracyjne, ponieważ są tworzone poprzez ruchy, dodawanie i zmiany, są zawsze przechowywane w wydawcy i replikowane w jedną stronę od wydawcy do każdego abonenta oraz ulepszony węzeł utrzymania w klastrze.

Podczas zdarzenia utrzymania tylko funkcje skierowane do użytkownika są modyfikowane na urządzeniach zarejestrowanych w węźle rozszerzonego utrzymania, a funkcje skierowane do użytkownika są zazwyczaj charakteryzowane przy użyciu faktu, ż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 GUI. Tak więc węzeł rozszerzonej zdolności do przetrwania umożliwia samoobsługę i GUI administratora WWW jako operacje tylko do odczytu. Urządzenia użytkownika zarejestrowane w ESN mogą wprowadzać zmiany tylko dla użytkownika, który ma do czynienia z funkcjami wymienionymi poniżej podczas przełączania awaryjnego. Zmiany te nie zostaną jednak zsynchronizowane z wydawcą DI Unified CM po ponownym nawiązaniu połączenia.

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

• Przekierowanie wszystkich połączeń (CFA)

• Włączanie lub wyłączanie prywatności

• Nie przeszkadzać (Nie przeszkadzać) Włącz lub Wyłącz

• Cisco Extension Mobility Login

• Logowanie lub wylogowanie grupy poszukiwania

• Mobilność urządzeń

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

Uwierzytelnianie klientów miękkich (aplikacji Cisco Jabber i Webex) do logowania się podczas przełączania awaryjnego na węzeł rozszerzonego utrzymania jest następujące:

1. Uwierzytelnianie lokalne: Gdy uwierzytelnianie użytkowników odbywa się lokalnie w systemie Unified CM, podczas zdarzenia utrzymania węzeł rozszerzonej możliwości utrzymania będzie mógł uwierzytelniać zarejestrowanych do niego klientów.

2. Uwierzytelnianie LDAP: W tym przypadku uwierzytelnianie użytkowników odbywa się za pomocą lokalnego serwera LDAP. Następnie podczas zdarzenia utrzymania uwierzytelnianie klientów miękkich będzie działać pod warunkiem, że serwer LDAP będzie dostępny z węzła rozszerzonego utrzymania.

   Należy upewnić się, że katalog LDAP jest dostępny dla ESN przez cały czas trwania zdarzenia.

3. Uwierzytelnianie jednokrotnego logowania (SSO): Uwierzytelnianie logowania SSO użytkowników odbywa się za pomocą serwera IDP. Następnie podczas zdarzenia utrzymania uwierzytelnianie klientów miękkich działa pod warunkiem, że serwer IDP jest dostępny z węzła rozszerzonego utrzymania.

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

   Uwierzytelnieni klienci są nadal zalogowani, ponieważ uwierzytelnianie jest oparte na tokenie otrzymanym przed zdarzeniem utrzymania. Jednak w przypadku nowych logowań, gdy klient nie ma prawidłowego tokena z poprzedniego uwierzytelniania, ESN przekieruje go do serwera IDP w celu uwierzytelnienia. Dlatego też zawsze konieczne jest zapewnienie dostępności serwera IDP do ESN przez cały czas trwania zdarzenia.

Zasoby multimedialne są wymagane dla podstawowych funkcji Unified CM, takich jak Muzyka w zawieszeniu, Komunikat, usługi Conference Bridge (oprogramowanie) muszą być włączone w ESN. Jeśli zasoby multimedialne oparte na sprzęcie zostały wdrożone, podczas zdarzenia utrzymania należy upewnić się, że serwery multimedialne są dostępne z ESN.

Podczas normalnej pracy klastra DI Unified CM połączenia alarmowe (zwłaszcza w regionie AMER) są przekierowywane przez chmurę RedSky, w której znajduje się łącze magistralowe SIP skonfigurowane między klastrem Dedicated Instnace unified CM a chmurą RedSky.

Jeśli wystąpi zdarzenie utrzymania, chmura RedSky nie będzie dostępna z ESN i dlatego konieczne jest skonfigurowanie planu wybierania połączeń alarmowych w taki sposób, że jeśli usługa RedSky nie jest dostępna, przekierowanie połączeń alarmowych przez lokalną sieć PSTN GW skonfigurowaną w tej witrynie. Grupa tras musi składać się z lokalnej sieci PSTN GW, aby obsługiwać trasowanie połączeń podczas zdarzenia utrzymania.

Skonfiguruj plan wybierania połączeń wewnątrzzakładowych, międzyzakładowych, międzyklastrowych i PSTN podczas zdarzenia podtrzymania połączenia. Generalnie ESN może kierować połączenia tylko do urządzeń, które są do niego zarejestrowane. Wszystkie inne połączenia muszą być kierowane do lokalnej sieci PSTN GW (skonfigurowanej w każdej lokalizacji, w której jest wdrożona sieć ESN), a stamtąd do sieci PSTN. Poniżej wyjaśniono kilka scenariuszy:

• Telefony 1 i 2 zarejestrowane w tej samej sieci ESN — połączenie jest kierowane w sieci ESN.

• Telefon 1 zarejestrowany na ESN i telefon 2 zarejestrowany na klaster dedykowanego wystąpienia Unified CM – plan wybierania powinien kierować połączenia z ESN do lokalnej PSTN GW, stamtąd do DI Unified CM za pośrednictwem PSTN. Podczas zdarzenia podtrzymania połączenia plan wybierania powinien wykrywać usterkę trasowania połączeń i przekierowywać połączenia przez lokalną sieć PSTN GW. To samo powinno mieć zastosowanie do połączeń przychodzących do ESN z urządzeń DI Unified CM.

• Telefon 1 zarejestrowany na ESN i telefon 2 jest urządzeniem PSTN: Podczas zdarzenia podtrzymania połączenia PSTN muszą być kierowane do lokalnej bramy PSTN. Należy upewnić się, że plan wybierania ma możliwość wykrywania awarii przekierowywania połączeń i przekierowywania połączeń przez dostępną lokalną bramę PSTN.

• Podczas zdarzenia podtrzymania połączenia, gdy połączenie z witryny do chmury dedykowanego wystąpienia nie działa (awaria sieci WAN lub połączenia), funkcje poczty głosowej i automatycznego asystenta nie będą działać dla urządzeń rejestrujących się w ESN, ponieważ serwer Cisco Unity Connection jest hostowany w chmurze dedykowanego wystąpienia, do której połączenie z ESN jest wyłączone. Jeśli urządzenie jest skonfigurowane za pomocą funkcji „Call Forward Unregistered (CFU)” i połączenie jest odbierane w systemie DI Unified CM, dzwoniący może złożyć wiadomość głosową w systemie Dedicated Instance Unity Connection. Które można pobrać, gdy urządzenia wrócą do ujednoliconych subskrybentów DI CM.

• Jednak podczas zdarzenia utrzymania, gdy dostępna jest chmura łączności z dedykowanym wystąpieniem, ale klaster Unified CM w DI jest wyłączony, w tym przypadku funkcje poczty głosowej i automatycznego asystenta działają dla urządzeń zarejestrowanych w ESN, ponieważ ESN będzie miał połączenie z serwerem Unity Connection wdrożonym w chmurze DI.

Podczas zdarzenia utrzymania 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 i dlatego nie będą mogli się zarejestrować. Jeśli jednak urządzenie MRA ma dostęp do Internetu 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 działa.

Aby integracje oparte na CTI mogły pracować z węzłem rozszerzonej żywotności, należy dodać węzeł rozszerzonej żywotności jako część listy serwerów CTI. Udoskonalenia CTI są wykonywane dla aplikacji, które używają JTAPI, aby umożliwić węzeł rozszerzonej żywotności jako serwer CTI, do którego aplikacja może się łączyć tylko w przypadku, gdy pierwotne lub wtórne serwery CTI na skonfigurowanej liście nie są osiągalne. Podczas normalnej pracy aplikacje CTI w witrynie mogą łączyć się z głównymi i drugorzędnymi serwerami CTI w chmurze DI, a podczas zdarzenia Surviability mogą łączyć się z węzłem rozszerzonej żywotności, aby zapewnić ciągłość obsługi CTI. Aplikacje muszą dostosowywać się do nowych interfejsów API, które są narażone na działanie interfejsu JTAPI, aby zapewnić, że po przywróceniu połączenia nastąpi awaria węzła rozszerzonej żywotności.

Aby uzyskać więcej informacji na temat nowych interfejsów API, zobacz sekcję redundancji, 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

Usługa sieciowa AXL jest włączona w węźle rozszerzonego utrzymania z uprawnieniami administratora tylko do odczytu. Zalecamy, aby wszystkie aplikacje innych firm, takie jak serwer obsługi administracyjnej, łączyły się tylko z wydawcą DI Unified CM w przypadku aktualizacji związanych z bazą danych. Jednak możliwe jest, aby te aplikacje były tylko do odczytu po podłączeniu do węzła rozszerzonego utrzymania.

Aplikacje innych firm obsługujące interfejs za pośrednictwem łączy magistralowych SIP z węzłem rozszerzonej żywotności. W konfiguracjach łącza magistralowego SIP musi być włączona konfiguracja „run on all nodes” (Uruchom we wszystkich węzłach).

Obsługiwane są urządzenia 3rd party z funkcją TFTP.