I Single Site-distributionsmodellen, där en Enhanced Survivability Node (ESN) distribueras inom en plats tillsammans med en Local Gateway för PSTN-samtalsdirigering. Maximalt 7500 enheter kan registreras till ESN under ett avbrott.

I multi-site-distributionsmodellen, där det finns flera platser och ESN kan distribueras på varje plats beror på affärskraven för webbplatsens överlevnadsförmåga. Kraven på en lokal gateway och DNS är alltid en nödvändighet och totalt 8 ESN-noder kan läggas till ett Unified CM Cluster.

Denna implementeringsmodell är relevant för en kund i en region med flera platser och överlevnadsförmåga är ett krav för flera av dessa platser. Även om det är möjligt att dela den lokala PSTN-gatewayen över webbplatser, rekommenderas det inte. om det finns ett nätverksavbrott kan platsen bli isolerad och i så fall kommer ESN inte att kunna nå den lokala gatewayen för att dirigera samtalen till PSTN.

Nedan finns två distributionsalternativ för en distribution på flera platser:

• Alternativ 1: Enhanced Survivability Node utplacerad på varje plats.

• Alternativ 2 – Gemensam nod för förbättrad överlevnadsförmåga som delas mellan flera platser.

Vi övervakar och hanterar Enhanced Survivability Node som andra noder som är utplacerade i Dedicated Instance datacenter. Under en överlevnadshändelse, när ESN kopplas bort från Cisco Cloud, är det när vi förlorar åtkomst till noden och automatiskt ansluter tillbaka när avbrottet är löst och anslutningen återställs.

Vi hanterar UC-applikationscertifikaten och under aktiveringen av Enhanced Survivability Node uppdaterade vi att Dedicated Instance Unified CM-klustercertifikatet uppdateras med ESN.

Under överlevnadshändelsen lagrar Enhanced Survivability Node alla CDR/CMR data lokalt. När anslutningen är återställd synkroniseras data tillbaka till Dedicated Instance Unified CM Publisher. Mängden data som kan lagras baseras på diskstorleken för den då Enhanced Survivability Node. Det maximala disktilldelningsutrymme som kan ställas in för CDR är 3328 MB. Detta kan vara med liten till stor CDR-filstorlek baserat på CDR-intervallet som är konfigurerat. Rensningen sker baserat på:

• När diskanvändningen överstiger det tilldelade eller konfigurerade diskutrymmet, raderas de bearbetade posterna. Om diskanvändningen återstår att vara mer är det då de obearbetade posterna också rensas.

• Högvattenmärke % som är konfigurerad i inställningarna för ”CDR-hantering”, kommer CDR-filerna att rensas. Till exempel, om "High Water Mark %” is configured as 80% och diskanvändningen är 80% kommer CDR-filerna att rensas.

• CDR / Bevarande av CMR-filer Varaktighet (dagar) som är konfigurerad i "CDR Management"-inställningarna, kommer CDR-filerna att rensas. Som standard är den inställd på 30 dagar.

Följande är varningarna i RTMT relaterade till Enhanced Survivability Node:

• SurvivabilityEvent- larmet utlöses när alla dedikerade instansnoder inte kan nås från Enhanced Survivability Node.

• RemoteSurvivableNodeNotReachable - larmet utlöses när en Enhanced Survivability Node inte kan nås från Dedicated Instance Unified CM-utgivaren.

Under överlevnadshändelsen måste du ansluta RTMT till Enhanced Survivability Node för att övervaka prestandan för ESN. Detsamma kommer inte att vara tillgängligt om RTMT är anslutet till dedicerade instansnoderna eftersom ESN inte kommer att vara tillgänglig från molnet under överlevnadshändelsen.

Under normal drift är databasreplikeringen helt maskad mellan alla servrar inklusive Enhanced Survivability Node inom Unified CM-klustret. Den statiska konfigurationsdatan, eftersom den skapas genom flyttningar, tillägg och ändringar, lagras alltid på utgivaren och replikeras en väg från utgivaren till varje prenumerant och nod för förbättrad överlevnadsförmåga i klustret.

Under en överlevnadshändelse modifieras endast de användarvända funktionerna på enheterna som är registrerade till Enhanced Survivability Node och de användarvända funktionerna karakteriseras vanligtvis genom att du kan aktivera eller inaktivera en funktion direkt på deras telefon genom att trycka på en eller flera knappar, i motsats till att ändra en funktion via ett webbaserat GUI. Så, Enhanced Survivability Node tillåter egenvård och webbadmin GUI som skrivskyddade operationer. Användarens enheter som är registrerade på ESN kan göra ändringar i endast de funktioner som anges nedan för användaren under failover. Dessa ändringar kommer dock inte att synkroniseras tillbaka till DI Unified CM-utgivaren när anslutningen återupprättas.

Användarvända funktioner är alla funktioner som kan aktiveras eller inaktiveras genom att trycka på knapparna på telefonen och inkluderar följande:

• Vidarekoppla alla (CFA)

• Sekretess aktivera eller inaktivera

• Stör ej (DND) Aktivera eller inaktivera

• Cisco Extension Mobility Login

• Inloggning eller utloggning för jaktgrupp

• Enhetsmobilitet

• CTI CAPF-status för slutanvändare och applikationsanvändare.

Autentiseringen av mjuka klienter (Cisco Jabber och Webex Application) för inloggning under failover till Enhanced Survivability Node är som följer:

1. Lokal autentisering: När autentisering av användare görs lokalt inom Unified CM, under överlevnadshändelsen kommer Enhanced Survivability Node att kunna autentisera de klienter som är registrerade på den.

2. LDAP-autentisering: I det här fallet görs autentiseringen av användare med den lokala LDAP-servern. Sedan under överlevnadshändelsen kommer autentiseringen av mjuka klienter att fungera förutsatt att LDAP-servern är tillgänglig från Enhanced Survivability Node.

   Du bör säkerställa att LDAP-katalogen kan nås till ESN under hela överlevnadshändelsen.

3. Single Sign On (SSO) autentisering: SSO-inloggningsautentisering av användare görs med hjälp av IDP-servern. Sedan fungerar autentiseringen av mjuka klienter under överlevnadshändelsen förutsatt att IDP-servern är tillgänglig från Enhanced Survivability Node.

   För SSO-aktiverad Unified CM-webbgränssnittsinloggning krävs IDP-nåbarhet eller så måste den återställningsbaserade URL-inloggningen användas.

   Redan autentiserade klienter fortsätter att vara inloggade eftersom autentiseringen baseras på token som erhålls före överlevnadshändelsen. Men för nya inloggningar när klienten inte har en giltig token från tidigare autentisering kommer ESN att omdirigera till IDP-servern för autentisering. Därför är det alltid nödvändigt att säkerställa IDP-serverns tillgänglighet till ESN under hela överlevnadshändelsen.

Medieresurser krävs för grundläggande Unified CM-funktioner, som musik i vänteläge, meddelande, konferensbrygga (programvara)-tjänster måste vara aktiverade på ESN. Om hårdvarubaserade medieresurser har distribuerats måste du under överlevnadshändelsen se till att medieservrarna är tillgängliga från ESN.

Under normal drift av DI Unified CM-klustret dirigeras nödsamtal (särskilt i AMER-regionen) genom RedSky-molnet där det finns en SIP-trunk som är konfigurerad mellan Dedicated Instnace unified CM-klustret och RedSky-molnet.

Om det finns en överlevnadshändelse kommer RedSky-molnet inte att vara tillgängligt från ESN och därför krävs det för dig att konfigurera nöduppringningsplanen så att, om RedSky inte är tillgänglig, kan du dirigera nödsamtal genom det lokala PSTN GW som är konfigurerat på den platsen. Rutgruppen måste bestå av den lokala PSTN GW för att hantera samtalsdirigeringen under överlevnadshändelsen.

Konfigurera uppringningsplanen för att dirigera intrasite-, intersite-, inter-cluster- och PSTN-samtal under överlevnadshändelsen. I allmänhet kan ESN dirigera samtal endast för enheter som är registrerade på den. Alla andra samtal måste dirigeras till det lokala PSTN GW (konfigurerat på varje plats där ESN är utplacerat) och därifrån till PSTN. Följande är några scenarion som förklaras:

• Telefon 1 och telefon 2 registrerade till samma ESN – Samtalet dirigeras inom ESN.

• Telefon 1 registrerad till ESN och telefon 2 registrerad till Dedicated Instance Unified CM-kluster – Uppringningsplanen ska dirigera samtalen från ESN till det lokala PSTN GW, därifrån till DI Unified CM via PSTN. Under överlevnadshändelsen bör uppringningsplanen upptäcka samtalsdirigeringsfelet och dirigera om samtalen genom det lokala PSTN GW. Detsamma bör gälla för inkommande samtal till ESN från DI Unified CM-enheter.

• Telefon 1 registrerad till ESN och telefon 2 är en PSTN-enhet: Under överlevnadshändelse måste PSTN-samtal dirigeras till den lokala PSTN-gatewayen. Du måste se till att uppringningsplanen har förmågan att upptäcka samtalsdirigeringsfel och dirigera om samtalet genom den tillgängliga lokala PSTN-gatewayen.

• Under överlevnadshändelsen, när anslutningen från din webbplats till molnet för dedikerad instans är nere (WAN eller anslutningsavbrott), fungerar inte funktionerna för röstbrevlåda och automatisk receptionist för enheterna som registrerar sig på ESN, eftersom Cisco Unity Connection-servern är värd i molnet för dedikerade instanser till vilket anslutningen från ESN är nere. Om din enhet är konfigurerad med "Call Forward Unregistered (CFU)" och samtalet tas emot i DI Unified CM, kan den som ringer sätta in ett röstmeddelande i Dedicated Instance Unity Connection. Som kan hämtas när enheterna faller tillbaka till DI unified CM-abonnenter.

• Men under en överlevnadshändelse när anslutningen till Dedicated Instance-molnet är tillgänglig men Unified CM-klustret i DI är nere, fungerar i så fall funktionerna för röstbrevlåda och autoattendant för enheter som är registrerade på ESN, eftersom ESN kommer att ha anslutning till Unity Connection-servern distribuerad i DI-molnet.

Under överlevnadshändelsen kommer ESN inte att kunna nå Cisco Expressway E & C i DI-moln och vice versa. Så i det här fallet kan MRA-användarna inte få tjänsten från ESN och kommer därför inte att kunna registrera sig. Men om MRA-enheten har internet och kan ansluta till Cisco Expressways i DI-molnet, kan den registreras hos DI Unified CM förutsatt att klustret i DI är funktionellt.

För att CTI-baserade integrationer ska fungera med Enhanced Survivability Node måste du lägga till Enhanced Survivability Node som en del av CTIs serverlista. CTI-förbättringar görs för applikationer som använder JTAPI för att tillåta Enhanced Survivability Node som en CTI-server till vilken applikationen endast kan ansluta i händelse av att de primära eller sekundära CTI-servrarna i den konfigurerade listan inte kan nås. Under en normal drift kan CTI-applikationer på plats ansluta till de primära och sekundära CTI-servrarna i DI-molnet och under överlevnadshändelse kan de ansluta till Enhanced Survivability Node för en fortsatt CTI-upplevelse. Applikationer måste anpassa sig till de nya API:erna som exponeras över JTAPI-gränssnittet för att säkerställa att reserv från Enhanced Survivability Node sker när anslutningen återställs.

För mer information om de nya API:erna som lagts till, se redundansavsnittet, 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 som gränssnitt genom SIP-trunkar stöder med Enhanced Survivability Node. I SIP-trunkkonfigurationerna måste konfigurationen 'kör på alla noder' vara aktiverad.

Tredjepartsenheter stöds som har tertiär TFTP-kapacitet.