I Single Site-implementeringsmodellen, hvor en Enhanced Survivability Node (ESN) er implementeret på et websted sammen med en Local Gateway til PSTN-opkaldsdirigering. Der kan maksimalt registreres 7500 enheder til ESN under en udfald.

I multiple-site-implementeringsmodellen, hvor der er flere sites, og ESN kan implementeres på hvert site, afhænger af forretningskravet til sitets overlevelsesevne. Kravene til en lokal gateway og DNS er altid en nødvendighed, og i alt 8 ESN noder kan tilføjes til en Unified CM Cluster.

Denne implementeringsmodel er relevant for en kunde på tværs af en region med flere websteder, og overlevelsesevne er et krav for flere af disse websteder. Selvom det er muligt at dele den lokale PSTN-gateway på tværs af websteder, anbefales det ikke. hvis der er et netværksudfald, kan webstedet blive isoleret, og i så fald vil ESN ikke være i stand til at nå den lokale gateway for at dirigere opkaldene til PSTN.

Nedenfor er 2 implementeringsmuligheder for en implementering på flere websteder:

• Mulighed 1: Enhanced Survivability Node installeret på hvert sted.

• Mulighed 2 – Fælles Enhanced Survivability Node deles mellem flere steder.

Vi overvåger og administrerer Enhanced Survivability Node ligesom andre noder, der er implementeret i Dedicated Instance-datacenteret. Under en overlevelsesbegivenhed, når ESN er afbrudt fra Cisco Cloud, er det, når vi mister adgangen til noden og automatisk forbinder tilbage, når udfaldet er løst, og forbindelsen genoprettes.

Vi administrerer UC-applikationscertifikaterne, og under aktiveringen af Enhanced Survivability Node opdaterede vi, at Dedicated Instance Unified CM-klyngecertifikatet er opdateret med ESN.

Under overlevelsesbegivenheden gemmer Enhanced Survivability Node alle CDR/CMR data lokalt. Når forbindelsen er gendannet, vil dataene blive synkroniseret tilbage til Dedicated Instance Unified CM Publisher. Mængden af data, der kan gemmes, er baseret på diskstørrelsen på den daværende Enhanced Survivability Node. Den maksimale diskallokeringsplads, der kan indstilles til CDR, er 3328 MB. Dette kan være med lille til stor CDR-filstørrelse baseret på det CDR-interval, der er konfigureret. Udrensningen sker baseret på:

• Når diskforbruget overstiger den tildelte eller konfigurerede diskplads, sletter den de behandlede poster. Hvis diskforbruget stadig er mere, er det, når de ubehandlede poster også renses.

• Højvandsmærke % der er konfigureret i "CDR Management"-indstillingerne, vil CDR-filerne blive slettet. For eksempel, hvis "Høj vandmærke %” is configured as 80% og diskforbruget er 80%, vil CDR-filerne blive renset.

• CDR / Bevarelse af CMR-filer Varighed (dage), som er konfigureret i "CDR Management"-indstillingerne, vil CDR-filerne blive slettet. Som standard er den indstillet til 30 dage.

Følgende er advarslerne i RTMT relateret til Enhanced Survivability Node:

• SurvivabilityEvent- alarmen udløses, når alle dedikerede instansknudepunkter ikke er tilgængelige fra Enhanced Survivability Node.

• RemoteSurvivableNodeNotReachable - alarmen udløses, når en Enhanced Survivability Node ikke er tilgængelig fra Dedicated Instance Unified CM-udgiveren.

Under overlevelseshændelsen skal du forbinde RTMT til Enhanced Survivability Node for at overvåge ydeevnen af ESN. Det samme vil ikke være tilgængeligt, hvis RTMT er forbundet til de dedikerede instansknudepunkter, da ESN ikke vil være tilgængeligt fra skyen under overlevelsesbegivenheden.

Under normal drift er databasereplikeringen fuldstændigt meshed mellem alle serverne inklusive Enhanced Survivability Node i Unified CM-klyngen. De statiske konfigurationsdata, fordi de er skabt gennem flytninger, tilføjelser og ændringer, gemmes altid på udgiveren og replikeres én vej fra udgiveren til hver abonnent og node med forbedret overlevelse i klyngen.

Under en overlevelseshændelse ændres kun de brugervendte funktioner på de enheder, der er registreret til Enhanced Survivability Node, og de brugervendte funktioner er typisk karakteriseret ved, at du kan aktivere eller deaktivere en funktion direkte på deres telefon ved at trykke på en eller flere knapper, i modsætning til at ændre en funktion gennem en webbaseret GUI. Så Enhanced Survivability Node tillader selvpleje og webadministrations-GUI som skrivebeskyttede operationer. Brugerens enheder, der er registreret til ESN, er kun i stand til at foretage ændringer til de brugervendte funktioner, der er anført nedenfor under failover. Disse ændringer vil dog ikke blive synkroniseret tilbage til DI Unified CM-udgiveren, når forbindelsen er genetableret.

Brugervendte funktioner er alle funktioner, der kan aktiveres eller deaktiveres ved at trykke på knapperne på telefonen og omfatter følgende:

• Viderestil alle (CFA)

• Privatliv Aktiver eller Deaktiver

• Forstyr ikke (DND) Aktiver eller deaktiver

• Cisco Extension Mobility Login

• Jagtgruppe Login eller Log ud

• Enhedsmobilitet

• CTI CAPF-status for slutbrugere og applikationsbrugere.

Godkendelsen af bløde klienter (Cisco Jabber og Webex Application) til login under failover til Enhanced Survivability Node er som følger:

1. Lokal godkendelse: Når autentificering af brugere udføres lokalt i Unified CM, vil Enhanced Survivability Node under overlevelseshændelsen være i stand til at autentificere de klienter, der er registreret til den.

2. LDAP-godkendelse: I dette tilfælde udføres godkendelsen af brugere ved hjælp af den lokale LDAP-server. Så under overlevelseshændelsen vil godkendelsen af bløde klienter fungere, forudsat at LDAP-serveren er tilgængelig fra Enhanced Survivability Node.

   Du bør sikre, at LDAP-biblioteket er tilgængeligt for ESN under hele overlevelsesbegivenheden.

3. Single Sign On (SSO)-godkendelse: SSO-logingodkendelsen af brugere udføres ved hjælp af IDP-serveren. Derefter fungerer godkendelsen af bløde klienter under overlevelseshændelsen, forudsat at IDP-serveren er tilgængelig fra Enhanced Survivability Node.

   For SSO-aktiveret Unified CM web-UI-login kræves IDP-tilgængelighed, eller også skal det gendannelsesbaserede URL-login bruges.

   Allerede godkendte klienter er fortsat logget ind, da godkendelsen er baseret på det token, der er opnået før overlevelseshændelsen. For nye logins, når klienten ikke har et gyldigt token fra tidligere godkendelse, vil ESN omdirigere til IDP-serveren for godkendelse. Derfor er det altid nødvendigt at sikre IDP-serverens tilgængelighed til ESN under hele overlevelsesbegivenheden.

Medieressourcer er nødvendige for grundlæggende Unified CM-funktioner, såsom musik i venteposition, annoncering, konferencebro (software)-tjenester skal være aktiveret på ESN. Hvis hardwarebaserede medieressourcer blev implementeret, skal du under overlevelsesbegivenheden sørge for, at medieserverne er tilgængelige fra ESN.

Under normal drift af DI Unified CM-klyngen dirigeres nødopkaldene (især i AMER-regionen) gennem RedSky-skyen, hvor der er en SIP-trunk, der er konfigureret mellem den dedikerede Instnace unified CM-klynge og RedSky-skyen.

Hvis der er en overlevelsesbegivenhed, vil RedSky-skyen ikke være tilgængelig fra ESN, og det er derfor påkrævet for dig at konfigurere nødopkaldsplanen, således at hvis RedSky ikke er tilgængelig, kan du dirigere nødopkaldene gennem den lokale PSTN GW, der er konfigureret på det pågældende sted. Rutegruppen skal bestå af det lokale PSTN GW for at håndtere opkaldsdirigeringen under overlevelseshændelsen.

Konfigurer opkaldsplanen til routing af intrasite-, intersite-, inter-cluster- og PSTN-opkald under overlevelseshændelsen. Generelt kan ESN kun dirigere opkald til enheder, der er registreret til det. Alle andre opkald skal dirigeres til det lokale PSTN GW (konfigureret på alle steder, hvor ESN er installeret) og derfra til PSTN. Følgende er nogle få scenarier forklaret:

• Telefon 1 og telefon 2 registreret til samme ESN – Opkaldet dirigeres inden for ESN.

• Telefon 1 registreret til ESN og telefon 2 registreret til Dedicated Instance Unified CM cluster – Opkaldsplanen skal dirigere opkaldene fra ESN til det lokale PSTN GW, derfra til DI Unified CM via PSTN. Under overlevelseshændelsen bør opkaldsplanen registrere opkaldsdirigeringsfejlen og omdirigere opkaldene gennem det lokale PSTN GW. Det samme bør gælde for indgående opkald til ESN fra DI Unified CM-enheder.

• Telefon 1 er registreret til ESN og telefon 2 er en PSTN-enhed: Under overlevelseshændelse skal PSTN-opkald dirigeres til den lokale PSTN-gateway. Du skal sikre dig, at opkaldsplanen har mulighed for at opdage opkaldsdirigeringsfejl og omdirigere opkaldet gennem den tilgængelige lokale PSTN-gateway.

• Under overlevelseshændelsen, når forbindelsen fra dit websted til Dedicated Instance-skyen er nede (WAN eller Connectivity outage), vil voicemail- og auto-attendant-funktionerne ikke fungere for de enheder, der registrerer sig til ESN, da Cisco Unity Connection-serveren hostes i Dedicated Instance-skyen, hvortil forbindelsen fra ESN er nede. Hvis din enhed er konfigureret med "Call Forward Unregistered (CFU)", og opkaldet modtages i DI Unified CM, kan den, der ringer, indsætte en voicemail i den dedikerede Instance Unity Connection. Som kan hentes, når enhederne falder tilbage til DI unified CM-abonnenter.

• Men under en overlevelsesbegivenhed, når forbindelsen til Dedicated Instance-skyen er tilgængelig, men Unified CM-klyngen i DI er nede, fungerer voicemail- og auto-attendant-funktionerne for enheder, der er registreret til ESN, da ESN vil have forbindelse til Unity Connection-serveren implementeret i DI-skyen.

Under overlevelsesbegivenheden vil ESN ikke være i stand til at nå Cisco Expressway E & C i DI-sky og omvendt. Så i dette tilfælde kan MRA-brugerne ikke få tjenesten fra ESN og vil derfor ikke være i stand til at registrere sig. Men hvis MRA-enheden har internet og kan oprette forbindelse til Cisco Expressways i DI-skyen, så kan den registreres hos DI Unified CM, forudsat at klyngen i DI er funktionel.

For at CTI-baserede integrationer skal fungere med Enhanced Survivability Node, skal du tilføje Enhanced Survivability Node som en del af CTIs serverliste. CTI-forbedringer er lavet til applikationer, der bruger JTAPI til at tillade Enhanced Survivability Node som en CTI-server, hvortil applikationen kun kan oprette forbindelse i tilfælde af, hvor den primære eller sekundære CTI-server på den konfigurerede liste ikke er tilgængelig. Under en normal drift kan CTI-applikationer på stedet oprette forbindelse til de primære og sekundære CTI-servere i DI-skyen, og under overlevelseshændelser kan de oprette forbindelse til Enhanced Survivability Node for en fortsat CTI-oplevelse. Applikationer skal tilpasse sig de nye API'er, som de er eksponeret over JTAPI-grænsefladen for at sikre, at tilbagefald fra Enhanced Survivability Node finder sted, når forbindelsen gendannes.

For mere information om de nye tilføjede API'er, se redundansafsnittet, 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

Tredjepartsapplikationer, der grænseflader gennem SIP-trunkene, understøttes med Enhanced Survivability Node. I SIP-trunk-konfigurationerne skal konfigurationen 'run on all nodes' være aktiveret.

Tredjepartsenheder understøttes, som har tertiær TFTP-kapacitet.