Oversikt

I distribusjonsmodell for ett sted , der en ESN (Enhanced Survivability Node) distribueres på et område sammen med en lokal gateway for PSTN samtaleruting. Maksimalt 7500 enheter kan registreres til ESN under et driftsbrudd.

I distribusjonsmodell for flere nettsteder , der det finnes flere nettsteder og ESN kan distribueres på hvert nettsted, avhenger det av forretningskravet for nettstedets overlevelsesevne. Kravene til en lokal gateway og DNS er alltid en nødvendighet, og totalt 8 ESN-noder kan legges til i en Unified CM -klynge.

Denne distribusjonsmodell er relevant for en kunde i en region med flere nettsteder, og overlevelsesevne er et krav for flere av disse nettstedene. Selv om det er mulig å dele den lokal gateway på tvers av nettsteder, anbefales det ikke. Hvis det oppstår et nettverksavbrudd, kan området bli isolert, og i så fall vil ikke ESN kunne nå den lokale gatewayen for å rute anropene til PSTN.

Nedenfor finner du to distribusjonsalternativer for en distribusjon på flere nettsteder:

• Alternativ 1: Node for forbedret overlevelse er distribuert på hvert nettsted.

• Alternativ 2 – Felles node for utvidet overlevelse deles mellom flere nettsteder.

Vi overvåker og administrerer noden for forbedret overlevelse som andre noder som er distribuert i datasenteret for dedikert forekomst. Under en overlevelseshendelse, når ESN kobles fra Cisco Cloud , er det når vi mister tilgangen til noden og automatisk kobler til tilbake når strømbruddet er løst, og tilkoblingen gjenopprettes.

Vi administrerer UC-applikasjonssertifikatene, og under aktiveringen av noden for forbedret overlevelse oppdaterte vi at Unified CM-klynge oppdateres med ESN.

Under aktiveringen av ESN fra Control Hub vil det være en omstart av alle registrerte enheter ettersom sertifikatet for Unified CM -klyngen vil bli oppdatert med multi-SAN-sertifikatene. Derfor planlegger vi vedlikeholdsperioden under aktiveringen av ESN fra Control Hub. Se, Slik aktiverer du node for utvidet overlevelse .

Under overlevelseshendelsen lagrer noden for utvidet overlevelse alle CDR/CMR-dataene lokalt. Når tilkoblingen er gjenopprettet, synkroniseres dataene tilbake til den dedikerte forekomsten Unified CM-utgiver. Mengden data som kan lagres, er basert på diskstørrelsen til noden for utvidet overlevelse. Den maksimale disktildelingsplassen som kan angis for CDR, er 3328 MB . Dette kan være med liten til stor CDR-filstørrelse basert på CDR-intervallet som er konfigurert. Fjerningen skjer basert på:

• Når diskbruk overskrider den tildelte eller konfigurerte diskplassen, slettes de behandlede oppføringene. Hvis diskbruk gjenstår å være mer, er det når de ubehandlede oppføringene også fjernes.

• Høy vannmerke i % som er konfigurert i «CDR Management»-innstillingene, vil CDR-filene bli slettet. For eksempel hvis «Høyt vannmerke%” is configured as 80% og diskbruk er 80 %, blir CDR-filene slettet.

• Varighet for bevaring av CDR-/CMR-filer (dager) som er konfigurert i «CDR Management»-innstillingene, vil CDR-filene bli slettet. Som standard er den satt til 30 dager.

Følgende er varslene i RTMT relatert til node for utvidet overlevelse:

• SurvivabilityEvent – Alarmen utløses når alle dedikerte forekomstnodene ikke er tilgjengelige fra noden for utvidet overlevelse.

• RemoteSurvivableNodeNotReachable – Alarmen utløses når en node for utvidet overlevelse ikke kan nås fra den dedikerte forekomsten av Unified CM -utgiveren.

Under overlevelseshendelsen må du koble RTMT til noden for forbedret overlevelse for å overvåke ytelsen til ESN. Det samme vil ikke være tilgjengelig hvis RTMT er koblet til dedikerte forekomstnodene, da ESN ikke vil være tilgjengelig fra skyen under overlevelseshendelsen.

Under normal drift er databasereplikering fullstendig maskenett mellom alle serverne, inkludert noden for utvidet overlevelse i Unified CM-klynge. De statiske konfigurasjonsdata, fordi de opprettes gjennom bevegelser, tilføyelser og endringer, lagres alltid på utgiveren og replikeres én vei fra utgiveren til hver abonnent og noden for utvidet overlevelse i klyngen.

Under en overlevelseshendelse er det bare de brukervendte funksjonene som endres på enhetene som er registrert for noden for forbedret overlevelse, og de brukervendte funksjonene karakteriseres vanligvis ved at du kan aktivere eller deaktivere en funksjon direkte på telefonen ved å trykke på én eller flere knapper, i motsetning til å endre en funksjon via et nettbasert GUI. Så noden for utvidet overlevelse tillater egenomsorg og GUI for nettadministrasjon som skrivebeskyttet operasjoner. Brukernes enheter som er registrert på ESN, kan bare gjøre endringer i de brukervendte funksjonene som er oppført nedenfor under failover. Disse endringene synkroniseres imidlertid ikke tilbake til DI Unified CM -utgiveren når tilkoblingen gjenopprettes.

Brukervendte funksjoner er alle funksjoner som kan aktiveres eller deaktiveres ved å trykke på knappene på telefonen, og inkluderer følgende:

• Viderekoble alle anrop (CFA)

• Personvern aktiver eller deaktiver

• ikke forstyrr(DND) Aktiver eller deaktiver

• Pålogging for Cisco Extension Mobility

• Pålogging eller avlogging for Hunt-gruppe

• Mobilitet for enhet

• CTI CAPF-status for sluttbrukere og applikasjonsbrukere.

Autentiseringen av myke klienter (Cisco Jabber og Webex Application) for pålogging under failover til Node for utvidet overlevelse er som følger:

1. Lokal autentisering : Når autentisering av brukere gjøres lokalt i Unified CM, vil noden for utvidet overlevelse kunne godkjenne klientene som er registrert for den, under overlevelseshendelsen.

2. LDAP-autentisering : I dette tilfellet utføres autentiseringen av brukere ved hjelp av den lokale LDAP-server. I løpet av overlevelseshendelsen fungerer deretter autentiseringen av myke klienter forutsatt at LDAP-server er tilgjengelig fra noden for utvidet overlevelse.

   Du bør sikre at LDAP-katalogen er tilgjengelig for ESN gjennom overlevelseshendelsen.

3. Autentisering med engangspålogging (SSO). : SSO-påloggingsautentiseringen for brukere gjøres ved hjelp av IDP-serveren. Under overlevelseshendelsen fungerer deretter autentiseringen av myke klienter forutsatt at IDP-serveren er tilgjengelig fra noden for forbedret overlevelse.

   For SSO-aktivert Unified CM -nettgrensesnittpålogging er IDP-tilgjengelighet nødvendig, eller så må den gjenopprettingsbaserte URL-påloggingen brukes.

   Allerede godkjente klienter fortsetter å være logget på ettersom autentiseringen er basert på tokenet som ble hentet før overlevelseshendelsen. For nye pålogginger når klienten ikke har et gyldig token fra tidligere godkjenning, vil imidlertid ESN omdirigere til IDP-serveren for godkjenning. Derfor er det alltid nødvendig å sikre IDP-serverens tilgjengelighet for ESN gjennom overlevelseshendelsen.

Medieressurser er nødvendige for grunnleggende Unified CM -funksjoner, for eksempel Musikk på vent, Kunngjøring, Conference Bridge (programvare), må være aktivert på ESN. Hvis maskinvarebaserte medieressurser ble distribuert, må du under overlevelseshendelsen sørge for at medieserverne er tilgjengelige fra ESN.

Under normal drift av DI Unified CM-klynge rutes nødanropene (spesielt i AMER-regionen) gjennom RedSky-skyen der det finnes en SIP-trunk som er konfigurert mellom den dedikerte Instnace unified CM-klyngen og RedSky-skyen.

Hvis det er en overlevelseshendelse, vil ikke RedSky-skyen være tilgjengelig fra ESN, og derfor er det nødvendig for deg å konfigurere nødnummerplanen slik at hvis RedSky ikke er tilgjengelig, kan du rute nødanropene gjennom det lokale PSTN GW konfigurert på dette nettstedet. rutegruppe må bestå av den lokale PSTN GW for å håndtere samtaleruting under overlevelseshendelsen.

For nødanrop også i andre dedikerte forekomstregioner må ringeplanen konfigureres til å rute anropene gjennom lokal PSTN GW under overlevelseshendelsen.

Konfigurer oppringingsplanen for ruting av intrasite-, intersite-, inter-cluster- og PSTN-anrop under overlevelseshendelsen. Generelt kan ESN bare rute anrop for enheter som er registrert for det. Alle andre samtaler må rutes til det lokale PSTN GW (konfigurert på alle områder der ESN er distribuert) og derfra til PSTN. Følgende er noen scenarier forklart:

• Telefon 1 og telefon 2 registrert til samme ESN – Samtalen rutes innenfor ESN.

• Telefon 1 registrert til ESN og telefon 2 registrert til Dedikert forekomst Unified CM-klynge – Oppringingsplanen skal rute anropene fra ESN til det lokale PSTN GW, derfra til DI Unified CM via PSTN. Under overlevelseshendelsen skal oppringingsplanen oppdage feilen ved samtaleruting og samtaleruting samtalene gjennom det lokale PSTN GW-en. Det samme bør gjelde for innkommende anrop til ESN fra DI Unified CM enheter.

• Telefon 1 er registrert på ESN og telefon 2 er en PSTN-enhet: Under overlevelseshendelsen må PSTN-anrop rutes til den lokale PSTN-gateway. Du må sørge for at oppringingsplanen har mulighet til å oppdage feil med samtaleruting og omdirigere samtalen gjennom den tilgjengelige lokale PSTN-gateway.

Vi anbefaler ikke IKT-anrop mellom to ESN-noder, selv om det er mulig når ESN-ene er tilgjengelige i nettverket ditt.

• Under overlevelseshendelsen, når tilkoblingen fra nettstedet ditt til skyen for dedikert forekomst er nede (WAN eller tilkoblingsbrudd), vil ikke funksjonene for talepost og automatisk svartjeneste fungere for enhetene som registreres til ESN, ettersom Cisco Unity Connection-server er vert for i skyen for dedikerte forekomster som tilkoblingen fra ESN er nede. Hvis enheten er konfigurert med «Viderekoble viderekobling uregistrert (CFU)» og anropet mottas i DI Unified CM, kan anroperen sette inn en talepost i den dedikerte forekomst Unity-tilkoblingen. Som kan hentes når enhetene faller tilbake til DI unified CM-abonnenter.

• Under en overlevelseshendelse når tilkoblingsmulighetene til skyen for dedikert forekomst er tilgjengelig, men Unified CM-klynge i DI er nede, fungerer imidlertid funksjonene for talepost og automatisk svartjeneste for enheter som er registrert til ESN, ettersom ESN vil ha tilkobling til Unity Connection-serveren distribuert i DI-skyen.

Under overlevelseshendelsen vil ikke ESN kunne nå Cisco Expressway E & C i DI-sky og omvendt. Så i dette tilfellet kan ikke MRA-brukere få tjenesten fra ESN og vil derfor ikke kunne registrere seg. Men hvis MRA-enheten har Internett og kan koble til Cisco Expressways i DI-skyen, kan den registreres med DI Unified CM forutsatt at klyngen i DI er funksjonell.

For at CTI-baserte integrasjoner skal fungere med Enhanced Survivability Node, må du legge til Enhanced Survivability Node som en del av CTIs serverliste. CTI-forbedringer er laget for programmer som bruker JTAPI til å tillate Enhanced Survivability Node som en CTI-server som applikasjonen bare kan koble til i tilfelle de primære eller sekundære CTI-serverne i den konfigurerte listen ikke kan nås. Under en normal drift kan CTI-applikasjoner på stedet koble til de primære og sekundære CTI-serverne i DI-skyen, og under overlevelseshendelse kan de koble til Enhanced Survivability Node for en fortsatt CTI-opplevelse. Applikasjoner må tilpasses de nye API-ene som de er eksponert over JTAPI-grensesnittet for å sikre at tilbakefall fra noden for forbedret overlevelse finner sted når tilkoblingen gjenopprettes.

Hvis du vil ha mer informasjon om de nye API-ene som er lagt til, kan du se delen om redundans, 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 Web-tjeneste er aktivert i noden for forbedret overlevelse med skrivebeskyttede administratorrettigheter. Vi anbefaler at alle tredjepartsprogrammer, for eksempel klargjøringsserveren, bare bruker grensesnitt med DI Unified CM -utgiver for eventuelle databaserelaterte oppdateringer. Det er imidlertid mulig for disse programmene å bli skrivebeskyttet når de er koblet til noden for utvidet overlevelse.

Tredjepartsprogrammer som bruker grensesnitt gjennom SIP-trunkene, støtter Node for utvidet overlevelse. I SIP-trunk , kjør på alle noder '-konfigurasjonen må være aktivert.

Tredjepartsenheter som har tertiær TFTP-funksjonalitet støttes.