Panoramica

Nel modello di distribuzione del sito singolo, in cui un nodo di survivability avanzata (ESN) viene distribuito all'interno di un sito insieme a un gateway locale per l'indirizzamento chiamata PSTN. È possibile registrare un massimo di 7500 dispositivi sull'ESN durante un'interruzione.

Nel modello di distribuzione con più siti, in cui sono presenti più siti e l'ESN può essere distribuito in ciascun sito, in base ai requisiti aziendali per la survivability del sito. I requisiti di un gateway locale e DNS sono sempre una necessità e un totale di 8 nodi ESN può essere aggiunto a un cluster Unified CM.

Questo modello di distribuzione è rilevante per un cliente in una regione con più siti e la survivability è un requisito per più di tali siti. Sebbene sia possibile condividere il gateway locale PSTN tra i siti, non è consigliato. In caso di un'interruzione di rete, il sito può rimanere isolato e, in tal caso, l'ESN non potrà raggiungere il gateway locale per indirizzare le chiamate alla PSTN.

Di seguito sono riportate 2 opzioni di distribuzione per una distribuzione su più siti:

• Opzione 1: Nodo survivability avanzato distribuito in ciascun sito.

• Opzione 2 – Nodo di survivability avanzata comune condiviso tra più siti.

È possibile monitorare e gestire il nodo survivability avanzato come altri nodi distribuiti nel centro dati dell'istanza dedicata. Durante un evento di survivability, quando l'ESN viene disconnesso dal cloud Cisco si verifica quando perdiamo l'accesso al nodo e ci riconnettiamo automaticamente quando l'interruzione viene risolta e la connettività viene ripristinata.

I certificati dell'applicazione UC vengono gestiti e durante l'attivazione del nodo survivability avanzato viene aggiornato il certificato del cluster Unified CM dell'istanza dedicata con l'ESN.

Durante l'attivazione dell'ESN da Control Hub ci sarà un riavvio di tutti i dispositivi registrati poiché il certificato per il cluster Unified CM verrà aggiornato con i certificati multi-SAN. Pertanto, pianifichiamo il periodo di manutenzione durante l'attivazione dell'ESN da Control Hub. Fai riferimento a Come attivare il nodo survivability avanzato.

Durante l'evento di survivability, il nodo di survivability avanzata memorizza localmente tutti i dati CDR/CMR. Una volta ripristinata la connettività, i dati vengono sincronizzati nuovamente al publisher di Unified CM dell'istanza dedicata. La quantità di dati che possono essere memorizzati si basa sulla dimensione del disco del nodo survivability avanzato. Lo spazio massimo di allocazione del disco che può essere impostato per CDR è 3328 MB. Può essere con dimensioni file CDR da piccole a grandi in base all'intervallo CDR configurato. L'eliminazione avviene in base a:

• Quando l'utilizzo del disco supera lo spazio su disco allocato o configurato, vengono eliminati i record elaborati. Se l'utilizzo del disco deve essere maggiore rispetto a quando vengono eliminati anche i record non elaborati.

• High Water Mark % configurato nelle impostazioni di "CDR Management", i file CDR verranno eliminati. Ad esempio, se il "High Water Mark %” is configured as 80% e l'utilizzo del disco è 80%, i file CDR verranno eliminati.

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

Di seguito sono riportati gli avvisi in RTMT relativi al nodo survivability avanzato:

• SurvivabilityEvent- l'allarme si attiva quando tutti i nodi dell'istanza dedicata non sono raggiungibili dal nodo survivability avanzato.

• RemoteSurvivableNodeNotReachable - l'allarme si attiva quando un nodo survivability avanzato non è raggiungibile dal publisher di Unified CM dell'istanza dedicata.

Durante l'evento di survivability, devi connettere RTMT al nodo di survivability avanzato per monitorare le prestazioni dell'ESN. Lo stesso non sarà disponibile, se RTMT è connesso ai nodi dell'istanza dedicata poiché l'ESN non sarà raggiungibile dal cloud durante l'evento survivability.

Durante il normale funzionamento, la replicazione del database viene eseguita completamente tra tutti i server incluso il nodo survivability avanzato all'interno del cluster Unified CM. I dati di configurazione statica, poiché vengono creati tramite spostamenti, aggiunte e modifiche, sono sempre memorizzati sull'editore e replicati in un modo dall'editore a ciascun abbonato e nodo survivability avanzato nel cluster.

Durante un evento di survivability, solo le funzioni rivolte all'utente vengono modificate sui dispositivi registrati nel nodo di survivability avanzato e le funzioni rivolte all'utente vengono solitamente caratterizzate utilizzando il fatto che è possibile abilitare o disabilitare una funzione direttamente sul telefono premendo uno o più pulsanti, anziché modificare una funzione attraverso una GUI basata sul Web. Quindi, il nodo Survivability Enhanced consente l'auto-cura e la GUI di amministrazione del web come operazioni di sola lettura. I dispositivi dell'utente registrati in ESN possono apportare modifiche solo alle funzioni rivolte all'utente elencate di seguito durante il failover. Tuttavia, queste modifiche non verranno sincronizzate con il publisher DI Unified CM una volta ripristinata la connettività.

Le funzioni rivolte all'utente sono qualsiasi funzione che può essere abilitata o disabilitata premendo i pulsanti sul telefono e includono quanto segue:

• Inoltro di tutte le chiamate (CFA)

• Abilitazione o disabilitazione della privacy

• Abilitazione o disabilitazione della funzione Non disturbare (NoDist)

• Accesso a Cisco Extension Mobility

• Accesso o disconnessione gruppo di risposta

• Mobilità dispositivo

• Stato CTI CAPF per gli utenti finali e gli utenti delle applicazioni.

L'autenticazione dei client soft (Cisco Jabber e applicazione Webex) per l'accesso durante il failover al nodo survivability avanzato è la seguente:

1. Autenticazione locale: Quando l'autenticazione degli utenti viene eseguita localmente all'interno di Unified CM, durante l'evento survivability, il nodo survivability avanzato sarà in grado di autenticare i client registrati.

2. Autenticazione LDAP: In questo caso, l'autenticazione degli utenti viene eseguita utilizzando il server LDAP locale. Quindi, durante l'evento survivability, l'autenticazione dei client soft funzionerà a condizione che il server LDAP sia raggiungibile dal nodo survivability avanzato.

   Devi assicurarti che la raggiungibilità della rubrica LDAP per l'ESN durante l'evento survivability.

3. Autenticazione Single Sign On (SSO): L'autenticazione di accesso SSO degli utenti viene eseguita utilizzando il server IDP. Quindi, durante l'evento survivability, l'autenticazione dei client soft funziona a condizione che il server IDP sia raggiungibile dal nodo survivability avanzato.

   Per l'accesso all'interfaccia utente Web Unified CM abilitato per SSO, è necessaria la raggiungibilità IDP oppure è necessario utilizzare l'accesso all'URL basato sul recupero.

   I client già autenticati continuano ad essere connessi perché l'autenticazione si basa sul token ottenuto prima dell'evento survivability. Tuttavia, per i nuovi accessi quando il client non dispone di un token valido dall'autenticazione precedente, l'ESN verrà reindirizzato al server IDP per l'autenticazione. Pertanto, è sempre necessario garantire la raggiungibilità del server IDP all'ESN durante l'evento survivability.

Le risorse multimediali sono richieste per le funzioni di base di Unified CM, come musica di attesa, annunci, servizi software (Conference Bridge) devono essere abilitate sull'ESN. Se sono state distribuite risorse multimediali basate su hardware, durante l'evento survivability devi assicurarti 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 indirizzate attraverso il cloud RedSky in cui è presente un trunk SIP configurato tra il cluster Dedicated Instnace unified CM e il cloud RedSky.

Se è presente un evento survivability, il cloud RedSky non sarà raggiungibile dall'ESN e pertanto è necessario configurare il piano di chiamata di emergenza Calling in modo che, se RedSky non è disponibile, sia possibile indirizzare le chiamate di emergenza attraverso il PSTN GW locale configurato su tale sito. Il gruppo di indirizzamento deve essere costituito dal PSTN GW locale per gestire l'indirizzamento chiamata durante l'evento survivability.

Per le chiamate di emergenza anche in altre regioni dell'istanza dedicata, il piano di chiamata deve essere configurato per indirizzare le chiamate attraverso PSTN GW locale durante l'evento survivability.

Configura il piano di chiamata per l'indirizzamento di chiamate intrasite, intersito, intercluster e PSTN durante l'evento survivability. In generale, l'ESN può indirizzare le chiamate solo per i dispositivi registrati. Tutte le altre chiamate devono essere indirizzate al PSTN GW locale (configurato in ogni sito in cui viene distribuito l'ESN) e da lì al PSTN. Di seguito sono illustrati alcuni scenari:

• Telefono 1 e Telefono 2 registrati sullo stesso ESN – La chiamata viene indirizzata all'interno dell'ESN.

• Telefono 1 registrato a ESN e telefono 2 registrato a cluster Unified CM istanza dedicata - Il piano di chiamata deve indirizzare le chiamate da ESN al PSTN GW locale, da qui al DI Unified CM tramite PSTN. Durante l'evento survivability, il piano di chiamata deve rilevare il problema di indirizzamento chiamata e inoltrare nuovamente le chiamate attraverso la PSTN GW locale. Lo stesso deve essere applicabile per le chiamate in ingresso a ESN da dispositivi DI Unified CM.

• Il telefono 1 registrato su ESN e il telefono 2 è un dispositivo PSTN: Durante l'evento survivability, le chiamate PSTN devono essere indirizzate al gateway PSTN locale. Devi assicurarti che il piano di chiamata abbia la possibilità di rilevare errori di indirizzamento chiamata e reindirizzare la chiamata attraverso il gateway PSTN locale disponibile.

Le chiamate ICT tra i nodi di 2 ESN non sono consigliate, sebbene sia possibile quando gli ESN sono raggiungibili all'interno della rete.

• Durante l'evento survivability, quando la connettività dal sito al cloud dell'istanza dedicata è inattiva (interruzione WAN o connettività), le funzioni della casella vocale e dell'operatore automatico non funzioneranno per i dispositivi che si registrano sull'ESN, poiché il server Cisco Unity Connection è ospitato nel cloud dell'istanza dedicata a cui la connettività dall'ESN è inattiva. Se il dispositivo è configurato con "Inoltro chiamata non registrato (CFU)" e la chiamata viene ricevuta in DI Unified CM, il chiamante può depositare una casella vocale in Connessione unità istanza dedicata. Che può essere recuperato quando i dispositivi tornano agli abbonati DI Unified CM.

• Tuttavia, durante un evento di survivability quando è disponibile la connettività al cloud Istanza dedicata ma il cluster Unified CM in DI è inattivo, in tal caso le funzioni della casella vocale e dell'operatore automatico funzionano per i dispositivi registrati sull'ESN, poiché l'ESN avrà connettività al server Unity Connection distribuito nel cloud DI.

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

Affinché le integrazioni basate su CTI funzionino con il nodo survivability avanzato, è necessario aggiungere il nodo survivability avanzato come parte dell'elenco di server di CTI. I miglioramenti CTI vengono effettuati per le applicazioni che utilizzano JTAPI per consentire il nodo survivability avanzato come server CTI a cui l'applicazione può connettersi solo nel caso in cui i server CTI primario o secondario nell'elenco configurato non siano raggiungibili. Durante un normale funzionamento, le applicazioni CTI sul sito possono connettersi con i server CTI primari e secondari nel cloud DI e durante l'evento survivability, possono connettersi con il nodo survivability avanzato per un'esperienza CTI continua. Le applicazioni devono adattarsi alle nuove API come esposte sull'interfaccia JTAPI per garantire che il fallback dal nodo survivability avanzato abbia luogo quando viene ripristinata la connettività.

Per ulteriori 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

Il servizio Web AXL è abilitato nel nodo survivability avanzato con privilegi di amministratore di sola lettura. Si consiglia a tutte le applicazioni di terze parti, come il server di provisioning, di interfacciarsi solo con publisher DI Unified CM per qualsiasi aggiornamento relativo al database. Tuttavia, è possibile per queste applicazioni leggere solo quando connesse al nodo survivability avanzato.

Applicazioni di terze parti che si interfacciano attraverso i trunk SIP supportano con il nodo survivability avanzato. Nelle configurazioni trunk SIP, è necessario abilitare la configurazione "Esegui su tutti i nodi".

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