Oversikt

I det usannsynlige tilfellet av nettverksbrudd, eller noe annet avbrudd hindrer deg fra å koble til Webex Calling-dedikert forekomst, overtar Enhanced Survivability Node aktivt samtalekontroll og rutingsfunksjoner. Webex Calling-dedikert forekomst, Webex Calling-flerleietaker og lokal distribusjon har alle overlevelsesalternativer, men løsningsdokumentet beskriver aspektene på løsningsnivå av forbedret overlevelsesevne for Webex Calling-dedikert forekomst.

I dedikert tilfelle distribueres abonnentene til Unified CM-klyngen på tvers av datasenteret i en region for å gi høy tilgjengelighet og Georedundans. Det gjør det mulig for enhetene eller klienten å failover til abonnenten i det andre datasenteret. Men hvis det er et nettverksbrudd mellom nettstedet og skyen for dedikert forekomst, kan den forbedrede overlevelsesnoden som distribueres i nettstedet, håndtere samtalekontroll- og rutingsfunksjonene til tilkoblingen gjenopprettes. Den forbedrede overlevelsesnoden (ESN) gir samtalekontrollfunksjonene til en standard abonnent ved avbrudd.

Den forbedrede overlevelsesnoden kan bare rute samtaler innenfor et nettsted, og for andre samtaler må den rute gjennom PSTN som du må distribuere en lokal gateway for på nettstedet for PSTN. Det krever at du konfigurerer en lokal DNS-server for ESN for oppløsninger, siden ESN ikke kan nå Ciscos DNS-server under avbrudd. Den forbedrede overlevelsesnoden kan også eksistere samtidig med Cisco SRST.

Å vite ansvarsnivået for å distribuere den forbedrede overlevelsesnoden. Referer til Forbedret overlevelsesevne – Roller og Responsibility Matrix.

Depolymentmodeller

Enkelt nettsted

I Single Site-distribusjonsmodellen, der en forbedret overlevelsesnode (ESN) distribueres innenfor et nettsted sammen med en lokal gateway for PSTN-samtaleruting. Maksimalt 7500 enheter kan registreres på ESN under driftsbrudd.

Flere steder

I distribusjonsmodellen for flere steder, hvor det er flere steder, og ESN kan distribueres i hvert sted, avhenger av forretningsbehovet 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 distribusjonsmodellen er relevant for en kunde på tvers av en region med flere steder, og overlevelseskrav er et krav for flere av disse stedene. Selv om det er mulig å dele den lokale PSTN-gatewayen på tvers av nettsteder, anbefales det ikke. Hvis det oppstår et nettverksbrudd, kan nettstedet bli isolert, og i så fall vil ESN ikke kunne nå den lokale gatewayen for ruting av anrop til PSTN.

Nedenfor er 2 distribusjonsalternativer for distribusjon på flere steder:

  • Opsjon 1: Forbedret overlevelsesnode distribuert på hvert sted.
  • Alternativ 2 – Felles node for forbedret overlevelse delt mellom flere steder.

Serviceability

Overvåking

Vi overvåker og administrerer den forbedrede overlevelsesnoden som andre noder som distribueres 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 igjen når avbruddet er løst og tilkoblingen er gjenopprettet.

Sertifikatadministrasjon

Vi administrerer UC-programsertifikatene og under aktiveringen av den forbedrede overlevelsesnoden oppdaterte vi klyngesertifikatet Dedicated Instance Unified CM oppdateres med ESN.

Under aktivering av ESN fra Control Hub vil alle registrerte enheter startes på nytt, da sertifikatet for Unified CM-klyngen vil bli oppdatert med multi-SAN-sertifikatene. Derfor planlegger vi vedlikeholdsperioden under aktivering av ESN fra Control Hub. Referer, Slik aktiverer du forbedret overlevelsesnode.

CDR

Under overlevelseshendelsen lagrer den forbedrede overlevelsesnoden alle CDR/CMR-dataene lokalt. Når tilkoblingen er gjenopprettet, synkroniseres dataene tilbake til Unified CM Publisher for dedikert forekomst. Mengden data som kan lagres, er basert på diskstørrelsen til den deretter Enhanced Survivability Node. Maksimal diskallokeringsplass 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 diskbruken overskrider tildelt eller konfigurert diskplass, slettes de behandlede oppføringene. Hvis diskbruken forblir mer, er det når de ubehandlede oppføringene også slettes.

  • Høyvannmerke % som er konfigurert i innstillingene for «CDR Management», vil CDR-filene bli slettet. Hvis for eksempel "Høyt vannmerke %” is configured as 80% og diskbruken er 80 %, vil CDR-filene bli slettet.

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

RTMT-alarmer

Følgende er varslene i RTMT relatert til Enhanced Survivability Node:

  • SurvivabilityEvent– alarmen utløses når alle nodene for dedikert forekomst ikke kan nås fra den forbedrede overlevelsesnoden.

  • RemoteSurvivableNodeNotReachable – alarmen utløses når en forbedret overlevelsesnode ikke kan nås fra utgiveren av Unified CM for dedikert forekomst.

Ytelsesteller

Under overlevelseshendelsen må du koble RTMT til den forbedrede overlevelsesnoden for å overvåke ytelsen til ESN. Det samme vil ikke være tilgjengelig hvis RTMT er koblet til nodene for dedikert forekomst, da ESN ikke vil være tilgjengelig fra skyen under overlevelseshendelsen.

Unified CM-funksjoner og -innstillinger

Brukerinnstillinger

Under normal drift er databasereplikering fullstendig maskert mellom alle serverne, inkludert Enhanced Survivability Node i Unified CM-klyngen. De statiske konfigurasjonsdataene, fordi de opprettes gjennom flytninger, tillegg og endringer, lagres alltid på utgiveren og replikeres på én måte fra utgiveren til hver abonnent og forbedret overlevelsesnode i klyngen.

Under en overlevelseshendelse endres bare brukerrettede funksjoner på enhetene som er registrert på den forbedrede overlevelsesnoden, og brukerrettede funksjonene karakteriseres vanligvis ved hjelp av det faktum 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 en nettbasert GUI. Derfor tillater Enhanced Survivability Node GUI for selvpleie og webadministrator som skrivebeskyttet operasjoner. Brukerens enheter registrert på ESN er i stand til å gjøre endringer til bare de brukervennlige funksjonene som er oppført nedenfor under failover. Disse endringene synkroniseres imidlertid ikke tilbake til utgiveren av DI Unified CM når tilkoblingen opprettes på nytt.

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

  • Viderekoble alle anrop (CFA)

  • Aktiver eller deaktiver personvern

  • Aktiver eller deaktiver ikke forstyrr (DND)

  • Pålogging for Cisco Extension Mobility

  • Pålogging eller utlogging av huntgruppe

  • Enhetsmobilitet

  • CTI CAPF-status for sluttbrukere og programbrukere.

Autentisering

Godkjenningen av myke klienter (Cisco Jabber- og Webex-programmet) for pålogging under failover til Enhanced Survivability Node er som følger:

  1. Lokal autentisering: Når autentisering av brukere gjøres lokalt innenfor Unified CM, vil den forbedrede overlevelsesnoden i løpet av overlevelseshendelsen kunne autentisere klientene som er registrert på den.

  2. LDAP-autentisering: I dette tilfellet utføres autentiseringen av brukere ved hjelp av den lokale LDAP-serveren. Deretter vil godkjenningen av myke klienter fungere under overlevelseshendelsen forutsatt at LDAP-serveren kan nås fra den forbedrede overlevelsesnoden.

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

  3. Godkjenning av engangspålogging (SSO): SSO-påloggingsautentisering av brukere gjøres ved hjelp av IDP-serveren. Deretter fungerer godkjenningen av myke klienter under overlevelseshendelsen forutsatt at IDP-serveren kan nås fra Enhanced Survivability Node.

    For SSO-aktivert Unified CM web-brukergrensesnittpålogging kreves IDP-rekkevidde, eller den gjenopprettingsbaserte URL-påloggingen må brukes.

    Allerede godkjente klienter fortsetter å bli pålogget da autentiseringen er basert på tokenet som er 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 rekkevidde til ESN gjennom overlevelseshendelsen.

Medieressurser

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

Nødsamtaler

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

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

For nødsamtaler i andre regioner med dedikert forekomst må ringeplanen konfigureres for å rute samtalene gjennom lokal PSTN GW under overlevelseshendelsen.

Samtaleruting

Konfigurer ringeplanen for ruting av intrasite-, intersite-, inter-cluster- og PSTN-anrop under overlevelseshendelsen. Generelt kan ESN kun rute samtaler for enheter som er registrert. Alle andre samtaler må rutes til den lokale PSTN GW (konfigurert på alle steder der ESN distribueres) og derfra til PSTN. Følgende er noen få scenarioer forklart:

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

  • Telefon 1 registrert på ESN og telefon 2 registrert på Dedicated Instance Unified CM-klyngen – Ringeplanen bør rute anropene fra ESN til den lokale PSTN GW, derfra til DI Unified CM via PSTN. Under overlevelseshendelsen skal ringeplanen oppdage feilen for samtaleruting og viderekoble samtalene gjennom den lokale PSTN GW. Det samme gjelder for innkommende anrop til ESN fra DI Unified CM-enheter.

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

Vi anbefaler ikke ICT-anrop mellom 2 ESN-noder, selv om det er mulig når ESN-ene kan nås i nettverket ditt.

Talepost og automatisk svartjeneste

  • I løpet av 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, siden Cisco Unity Connection-serveren er driftet i skyen for dedikert forekomst som tilkoblingen fra ESN er nede til. Hvis enheten din er konfigurert med «Viderekoble uregistrert anrop (CFU)» og anropet mottas i DI Unified CM, kan anroperen sette inn en talepost i Dedicated Instance Unity Connection. Som kan hentes når enhetene faller tilbake til DI unified CM-abonnenter.

  • Men under en overlevelseshendelse når tilkoblingen til Dedikert forekomst-skyen er tilgjengelig, men Unified CM-klyngen i DI er nede, i så fall fungerer funksjonene for talepost og automatisk svartjeneste for enheter som er registrert på ESN, da ESN vil ha tilkobling til Unity Connection-serveren distribuert i DI-skyen.

Mobile and Remote Access (MRA)

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

Tredjepartsintegreringer

CTI

For at CTI-baserte integreringer skal fungere med Enhanced Survivability Node, må du legge til Enhanced Survivability Node som en del av CTIs serverliste. CTI-forbedringer gjøres for programmer som bruker JTAPI for å tillate Enhanced Survivability Node som en CTI-server som programmet bare kan koble til i tilfelle når de primære eller sekundære CTI-serverne i den konfigurerte listen ikke er tilgjengelige. Under normal drift kan CTI-applikasjoner på stedet koble til de primære og sekundære CTI-serverne i DI-skyen, og under overlevelseshendelsen kan de koble til Enhanced Survivability Node for en fortsatt CTI-opplevelse. Applikasjoner må tilpasse seg de nye API-ene som eksponert over JTAPI-grensesnittet for å sikre tilbakefall fra den forbedrede overlevelsesnoden 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

aksel

AXL-webtjenesten er aktivert i den forbedrede overlevelsesnoden med skrivebeskyttede administratorrettigheter. Vi anbefaler at alle tredjepartsprogrammer, for eksempel klargjøringsserver, bare til grensesnitt med DI Unified CM-utgiver for eventuelle databaserelaterte oppdateringer. Det er imidlertid mulig for disse programmene å lese bare når de er koblet til Enhanced Survivability Node.

Tredjeparts SIP

Tredjepartsapplikasjoner som grensesnitt gjennom SIP-trunkene støtter med Enhanced Survivability Node. I SIP trunk-konfigurasjonene må konfigurasjonen «kjør på alle noder» være aktivert.

Tredjeparts telefoner

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