Nel modello di distribuzione Single Site, in cui un Enhanced Survivability Node (ESN) viene distribuito all'interno di un sito insieme a un Local Gateway per l'instradamento delle chiamate PSTN. Durante un'interruzione è possibile registrare al massimo 7500 dispositivi sull'ESN.

Nel modello di distribuzione multi-sito, in cui sono presenti più siti e l'ESN può essere distribuito in ciascun sito, dipende dai requisiti aziendali per la sopravvivenza del sito. I requisiti di un gateway locale e di un DNS sono sempre necessari e a un cluster Unified CM è possibile aggiungere un totale di 8 nodi ESN.

Questo modello di distribuzione è rilevante per un cliente che opera in una regione con più sedi e la sopravvivenza è un requisito per più di tali sedi. Sebbene sia possibile condividere il gateway locale PSTN tra più siti, tale scelta non è consigliata. In caso di interruzione della rete, il sito potrebbe isolarsi e in tal caso ESN non sarà in grado di raggiungere il gateway locale per instradare le chiamate alla PSTN.

Di seguito sono riportate 2 opzioni di distribuzione per una distribuzione multi-sito:

• Opzione 1: Nodo di sopravvivenza avanzato distribuito in ogni sito.

• Opzione 2 – Nodo di sopravvivenza migliorato comune condiviso tra più siti.

Monitoriamo e gestiamo l'Enhanced Survivability Node come altri nodi distribuiti nel data center Dedicated Instance. Durante un evento di sopravvivenza, quando l'ESN viene disconnesso dal Cisco Cloud, perdiamo l'accesso al Nodo e ci riconnettiamo automaticamente quando l'interruzione viene risolta e la connettività viene ripristinata.

Gestiamo i certificati delle applicazioni UC e durante l'attivazione dell'Enhanced Survivability Node abbiamo aggiornato il certificato del cluster Dedicated Instance Unified CM con l'ESN.

Durante l'evento di sopravvivenza, il nodo di sopravvivenza potenziato memorizza tutti i CDR/CMR dati in locale. Una volta ripristinata la connettività, i dati verranno sincronizzati nuovamente con Dedicated Instance Unified CM Publisher. La quantità di dati che possono essere archiviati dipende dalla dimensione del disco dell'Enhanced Survivability Node. Lo spazio massimo di allocazione del disco che può essere impostato per CDR è 3328 MB. Ciò può avvenire con dimensioni di file CDR da piccole a grandi, in base all'intervallo CDR configurato. La pulizia avviene in base a:

• Quando l'utilizzo del disco supera lo spazio allocato o configurato, i record elaborati vengono eliminati. Se l'utilizzo del disco continua ad essere maggiore, vengono eliminati anche i record non elaborati.

• Punto più alto % configurato nelle impostazioni di “Gestione CDR”, i file CDR verranno eliminati. Ad esempio, se il valore “High Water Mark %” is configured as 80% ” e l’utilizzo del disco è pari all’80%, i file CDR verranno eliminati.

• CDR / Durata di conservazione dei file CMR (giorni) configurata nelle impostazioni di "Gestione CDR", i file CDR verranno eliminati. Per impostazione predefinita, il valore è 30 giorni.

Di seguito sono riportati gli avvisi in RTMT relativi all'Enhanced Survivability Node:

• SurvivabilityEvent- l'allarme viene attivato quando tutti i nodi dell'istanza dedicata non sono raggiungibili dal nodo di sopravvivenza avanzato.

• RemoteSurvivableNodeNotReachable - l'allarme viene attivato quando un Enhanced Survivability Node non è raggiungibile dal publisher Unified CM dell'istanza dedicata.

Durante l'evento di sopravvivenza, è necessario connettere RTMT all'Enhanced Survivability Node per monitorare le prestazioni dell'ESN. Lo stesso non sarà disponibile se RTMT è connesso ai nodi di istanza dedicati, poiché l'ESN non sarà raggiungibile dal cloud durante l'evento di sopravvivenza.

Durante il normale funzionamento, la replicazione del database è completamente distribuita tra tutti i server, incluso l'Enhanced Survivability Node nel cluster Unified CM. I dati di configurazione statica, poiché vengono creati tramite spostamenti, aggiunte e modifiche, vengono sempre archiviati sul publisher e replicati in un modo dal publisher a ciascun sottoscrittore e nodo di sopravvivenza avanzata nel cluster.

Durante un evento di sopravvivenza, sui dispositivi registrati sull'Enhanced Survivability Node vengono modificate solo le funzionalità rivolte all'utente e le funzionalità rivolte all'utente sono in genere caratterizzate dal fatto che è possibile abilitare o disabilitare una funzionalità direttamente sul telefono premendo uno o più pulsanti, anziché modificare una funzionalità tramite un'interfaccia utente grafica basata sul Web. Pertanto, l'Enhanced Survivability Node consente l'auto-cura e l'amministrazione tramite GUI web come operazioni di sola lettura. Durante il failover, i dispositivi dell'utente registrati su ESN possono apportare modifiche solo alle funzionalità accessibili all'utente elencate di seguito. Tuttavia, queste modifiche non verranno sincronizzate con DI Unified CM Publisher quando la connettività verrà ristabilita.

Le funzionalità accessibili all'utente sono tutte quelle che possono essere attivate o disattivate premendo i pulsanti sul telefono e includono quanto segue:

• Inoltro di chiamata a tutti (CFA)

• Abilita o disabilita la privacy

• Abilita o disabilita Non disturbare (DND)

• Accesso a Cisco Extension Mobility

• Accesso o disconnessione dal gruppo di ricerca

• Mobilità del dispositivo

• Stato CTI CAPF per utenti finali e utenti dell'applicazione.

L'autenticazione dei client software (Cisco Jabber e Webex Application) per l'accesso durante il failover su Enhanced Survivability Node è la seguente:

1. Autenticazione locale: Quando l'autenticazione degli utenti viene eseguita localmente all'interno di Unified CM, durante l'evento di sopravvivenza l'Enhanced Survivability Node sarà in grado di autenticare i client registrati.

2. Autenticazione LDAP: In questo caso l'autenticazione degli utenti avviene tramite il server LDAP locale. Quindi, durante l'evento di sopravvivenza, l'autenticazione dei client software funzionerà a condizione che il server LDAP sia raggiungibile dall'Enhanced Survivability Node.

   È necessario garantire la raggiungibilità della directory LDAP da parte di ESN durante l'evento di sopravvivenza.

3. Autenticazione Single Sign On (SSO): L'autenticazione di accesso SSO degli utenti viene effettuata tramite il server IDP. Quindi, durante l'evento di sopravvivenza, l'autenticazione dei client software funziona a condizione che il server IDP sia raggiungibile dall'Enhanced Survivability Node.

   Per l'accesso all'interfaccia utente Web di Unified CM abilitato tramite SSO, è richiesta la raggiungibilità dell'IDP oppure è necessario utilizzare l'accesso tramite URL basato sul ripristino.

   I client già autenticati continuano a essere connessi poiché l'autenticazione si basa sul token ottenuto prima dell'evento di sopravvivenza. Tuttavia, per i nuovi accessi in cui il client non dispone di un token valido dall'autenticazione precedente, l'ESN reindirizzerà al server IDP per l'autenticazione. Pertanto è sempre necessario garantire la raggiungibilità del server IDP da parte dell'ESN durante l'intero evento di sopravvivenza.

Le risorse multimediali sono necessarie per le funzionalità di base di Unified CM, ad esempio i servizi Musica di attesa, Annuncio e Conference Bridge (software) devono essere abilitati sull'ESN. Se sono state distribuite risorse multimediali basate su hardware, durante l'evento di sopravvivenza è necessario assicurarsi che i server multimediali siano raggiungibili dall'ESN.

Durante le normali operazioni del cluster DI Unified CM, le chiamate di emergenza (in particolare nella regione AMER) vengono instradate tramite il cloud RedSky, dove è presente un trunk SIP configurato tra il cluster Unified CM dell'istanza dedicata e il cloud RedSky.

In caso di evento di sopravvivenza, il cloud RedSky non sarà raggiungibile dall'ESN e quindi è necessario configurare il piano di selezione delle chiamate di emergenza in modo che, se RedSky non è disponibile, le chiamate di emergenza vengano instradate tramite il PSTN GW locale configurato in quel sito. Il gruppo di instradamento deve essere costituito dal GW PSTN locale per gestire l'instradamento delle chiamate durante l'evento di sopravvivenza.

Configurare il piano di selezione per l'instradamento delle chiamate intra-sito, inter-sito, inter-cluster e PSTN durante l'evento di sopravvivenza. In generale, l'ESN può instradare le chiamate solo verso i dispositivi ad esso registrati. Tutte le altre chiamate devono essere instradate al GW PSTN locale (configurato in ogni sito in cui è distribuito ESN) e da lì alla PSTN. Di seguito vengono spiegati alcuni scenari:

• Telefono 1 e telefono 2 registrati sullo stesso ESN: la chiamata viene instradata all'interno dell'ESN.

• Telefono 1 registrato su ESN e telefono 2 registrato su cluster Dedicated Instance Unified CM: il piano di selezione dovrebbe instradare le chiamate da ESN al GW PSTN locale, da lì al DI Unified CM tramite PSTN. Durante l'evento di sopravvivenza, il piano di selezione dovrebbe rilevare l'errore di instradamento delle chiamate e reindirizzare le chiamate tramite la rete GW PSTN locale. Lo stesso dovrebbe essere applicabile alle chiamate in arrivo verso ESN dai dispositivi DI Unified CM.

• Telefono 1 registrato su ESN e telefono 2 è un dispositivo PSTN: Durante un evento di sopravvivenza, le chiamate PSTN devono essere instradate al gateway PSTN locale. È necessario assicurarsi che il piano di selezione sia in grado di rilevare errori di instradamento delle chiamate e di reindirizzare la chiamata tramite il gateway PSTN locale disponibile.

• Durante l'evento di sopravvivenza, quando la connettività dal tuo sito al cloud dell'istanza dedicata è inattiva (interruzione della WAN o della connettività), le funzionalità di segreteria telefonica e risponditore automatico non funzioneranno per i dispositivi registrati all'ESN, poiché il server Cisco Unity Connection è ospitato nel cloud dell'istanza dedicata a cui è inattiva la connettività dall'ESN. Se il dispositivo è configurato con "Inoltro chiamata non registrato (CFU)" e la chiamata viene ricevuta in DI Unified CM, il chiamante può depositare un messaggio vocale nella connessione Unity dell'istanza dedicata. Che può essere recuperato quando i dispositivi tornano agli abbonati DI Unified CM.

• Tuttavia, durante un evento di sopravvivenza quando la connettività al cloud di Dedicated Instance è disponibile ma il cluster Unified CM in DI è inattivo, in tal caso le funzionalità di segreteria telefonica e risponditore automatico funzionano per i dispositivi registrati su ESN, poiché ESN avrà connettività al server Unity Connection distribuito nel cloud DI.

Durante l'evento di sopravvivenza, l'ESN non sarà in grado di raggiungere la Cisco Expressway E & C nel cloud DI e viceversa. Quindi, in questo caso, gli utenti MRA non potranno ottenere il servizio da ESN e quindi non potranno registrarsi. Tuttavia, se il dispositivo MRA dispone di Internet e può connettersi a Cisco Expressways nel cloud DI, può registrarsi con DI Unified CM a condizione che il cluster in DI sia funzionante.

Per far sì che le integrazioni basate su CTI funzionino con Enhanced Survivability Node, è necessario aggiungere Enhanced Survivability Node come parte dell'elenco dei server CTI. I miglioramenti CTI sono stati apportati alle applicazioni che utilizzano JTAPI per consentire a Enhanced Survivability Node di fungere da server CTI a cui l'applicazione può connettersi solo nel caso in cui il server CTI primario o secondario nell'elenco configurato non sia raggiungibile. Durante un normale funzionamento, le applicazioni CTI in loco possono connettersi ai server CTI primari e secondari nel cloud DI e, durante un evento di sopravvivenza, possono connettersi all'Enhanced Survivability Node per un'esperienza CTI continua. Le applicazioni devono adattarsi alle nuove API esposte tramite l'interfaccia JTAPI per garantire che il fallback dall'Enhanced Survivability Node avvenga quando la connettività viene ripristinata.

Per maggiori informazioni sulle nuove API aggiunte, fare riferimento alla sezione ridondanza, 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

Le applicazioni di terze parti che si interfacciano tramite i trunk SIP supportano Enhanced Survivability Node. Nelle configurazioni del trunk SIP, deve essere abilitata la configurazione 'esegui su tutti i nodi'.

Sono supportati dispositivi di terze parti dotati di funzionalità TFTP terziario.