No modelo de implantação de site único, onde um Nó de Sobrevivência Aprimorada (ESN) é implantado em um site junto com um Gateway Local para roteamento de chamadas PSTN. No máximo 7.500 dispositivos podem ser registrados no ESN durante uma interrupção.

No modelo de implantação de vários sites, onde há vários sites e o ESN pode ser implantado em cada site, dependendo do requisito comercial para a sobrevivência do site. Os requisitos de um Gateway Local e DNS são sempre uma necessidade e um total de 8 nós ESN podem ser adicionados a um Cluster Unified CM.

Este modelo de implantação é relevante para um cliente em uma região com vários sites e a capacidade de sobrevivência é um requisito para vários desses sites. Embora seja possível compartilhar o gateway local PSTN entre os sites, isso não é recomendado. Se houver uma interrupção na rede, o site pode ficar isolado e, nesse caso, a ESN não conseguirá acessar o gateway local para rotear as chamadas para a PSTN.

Abaixo estão duas opções de implantação para uma implantação em vários sites:

• Opção 1: Nó de sobrevivência aprimorado implantado em cada local.

• Opção 2 – Nó de sobrevivência aprimorado comum compartilhado entre vários sites.

Monitoramos e gerenciamos o Nó de Sobrevivência Aprimorada como outros nós implantados no datacenter de Instância Dedicada. Durante um evento de sobrevivência, quando o ESN é desconectado do Cisco Cloud, perdemos o acesso ao Node e nos reconectamos automaticamente quando a interrupção é resolvida e a conectividade é restaurada.

Gerenciamos os certificados do aplicativo UC e, durante a ativação do Enhanced Survivability Node, atualizamos o certificado do cluster Dedicated Instance Unified CM com o ESN.

Durante o evento de sobrevivência, o Nó de Sobrevivência Aprimorada armazena todos os CDR/CMR dados localmente. Quando a conectividade for restaurada, os dados serão sincronizados de volta com o Unified CM Publisher da Instância Dedicada. A quantidade de dados que podem ser armazenados é baseada no tamanho do disco do Nó de Sobrevivência Aprimorada. O espaço máximo de alocação de disco que pode ser definido para CDR é 3328 MB. Isso pode ocorrer com tamanho de arquivo CDR pequeno ou grande, com base no intervalo CDR configurado. A limpeza acontece com base em:

• Quando o uso do disco excede o espaço em disco alocado ou configurado, ele exclui os registros processados. Se o uso do disco continuar sendo maior, os registros não processados também serão eliminados.

• Marca d'água alta % que está configurado nas configurações de “Gerenciamento de CDR”, os arquivos CDR serão eliminados. Por exemplo, se a “Marca d’água alta %” is configured as 80% e o uso do disco for 80%, os arquivos CDR serão eliminados.

• CDR / Duração da preservação dos arquivos CMR (dias) que é configurada nas configurações de “Gerenciamento de CDR”, os arquivos CDR serão eliminados. Por padrão, é definido como 30 dias.

A seguir estão os alertas no RTMT relacionados ao Nó de Sobrevivência Aprimorada:

• SurvivabilityEvent- o alarme é disparado quando todos os nós da Instância Dedicada não podem ser acessados a partir do Nó de Sobrevivência Aprimorada.

• RemoteSurvivableNodeNotReachable - o alarme é disparado quando um Nó de Sobrevivência Aprimorada não pode ser acessado pelo publicador do Unified CM da Instância Dedicada.

Durante o evento de sobrevivência, você precisa conectar o RTMT ao Nó de Sobrevivência Aprimorada para monitorar o desempenho do ESN. O mesmo não estará disponível se o RTMT estiver conectado aos nós da Instância Dedicada, pois o ESN não poderá ser acessado da nuvem durante o evento de sobrevivência.

Durante a operação normal, a replicação do banco de dados é totalmente interligada entre todos os servidores, incluindo o Enhanced Survivability Node dentro do cluster do Unified CM. Os dados de configuração estática, por serem criados por meio de movimentações, adições e alterações, são sempre armazenados no publicador e replicados de uma maneira do publicador para cada assinante e nó de sobrevivência aprimorada no cluster.

Durante um evento de sobrevivência, apenas os recursos voltados ao usuário são modificados nos dispositivos registrados no Nó de Sobrevivência Aprimorada, e os recursos voltados ao usuário são normalmente caracterizados pelo fato de que você pode habilitar ou desabilitar um recurso diretamente no telefone pressionando um ou mais botões, em vez de alterar um recurso por meio de uma interface gráfica do usuário (GUI) baseada na Web. Portanto, o Enhanced Survivability Node permite o autoatendimento e a interface gráfica do usuário do administrador da Web como operações somente leitura. Os dispositivos do usuário registrados no ESN podem fazer alterações somente nos recursos voltados ao usuário listados abaixo durante o failover. No entanto, essas alterações não serão sincronizadas de volta com o publicador do DI Unified CM quando a conectividade for restabelecida.

Os recursos voltados para o usuário são quaisquer recursos que podem ser ativados ou desativados pressionando botões no telefone e incluem o seguinte:

• Encaminhamento de Chamadas para Todos (CFA)

• Habilitar ou desabilitar privacidade

• Não perturbe (DND) ativar ou desativar

• Login de mobilidade de extensão Cisco

• Login ou logout do grupo de busca

• Mobilidade do dispositivo

• Status do CTI CAPF para usuários finais e usuários de aplicativos.

A autenticação de clientes soft (Cisco Jabber e Webex Application) para login durante o failover para o Enhanced Survivability Node é a seguinte:

1. Autenticação local: Quando a autenticação de usuários é feita localmente no Unified CM, durante o evento de sobrevivência, o Enhanced Survivability Node poderá autenticar os clientes registrados nele.

2. Autenticação LDAP: Neste caso a autenticação dos usuários é feita utilizando o servidor LDAP local. Então, durante o evento de sobrevivência, a autenticação de clientes soft funcionará desde que o servidor LDAP esteja acessível a partir do Nó de Sobrevivência Aprimorada.

   Você deve garantir a acessibilidade do diretório LDAP ao ESN durante todo o evento de sobrevivência.

3. Autenticação de logon único (SSO): A autenticação de login SSO dos usuários é feita usando o servidor IDP. Então, durante o evento de sobrevivência, a autenticação de clientes soft funciona desde que o servidor IDP esteja acessível a partir do Nó de Sobrevivência Aprimorada.

   Para login na interface de usuário da Web do Unified CM habilitado para SSO, a acessibilidade do IDP é necessária ou o login de URL baseado em recuperação precisa ser usado.

   Clientes já autenticados continuam conectados, pois a autenticação é baseada no token obtido antes do evento de sobrevivência. No entanto, para novos logins quando o cliente não tiver um token válido de autenticação anterior, o ESN redirecionará para o servidor IDP para autenticação. Portanto, é sempre necessário garantir a acessibilidade do servidor IDP ao ESN durante todo o evento de sobrevivência.

Os recursos de mídia são necessários para os recursos básicos do Unified CM, como Música em Espera, Anúncio, Serviços de Ponte de Conferência (software) que devem ser habilitados no ESN. Se recursos de mídia baseados em hardware foram implantados, durante o evento de sobrevivência, você deve garantir que os servidores de mídia possam ser acessados pelo ESN.

Durante as operações normais do cluster DI Unified CM, as chamadas de emergência (particularmente na região AMER) são roteadas pela nuvem RedSky, onde há um tronco SIP configurado entre o cluster Dedicated Instance Unified CM e a nuvem RedSky.

Se houver um evento de sobrevivência, a nuvem RedSky não poderá ser acessada pelo ESN e, portanto, será necessário que você configure o plano de discagem de chamadas de emergência de forma que, se o RedSky não estiver disponível, roteie as chamadas de emergência por meio do GW PSTN local configurado naquele site. O grupo de rotas deve consistir no GW PSTN local para lidar com o roteamento de chamadas durante o evento de sobrevivência.

Configure o plano de discagem para roteamento de chamadas intrasite, intersite, intercluster e PSTN durante o evento de sobrevivência. Em geral, o ESN pode rotear chamadas somente para dispositivos registrados nele. Todas as outras chamadas precisam ser roteadas para o GW PSTN local (configurado em cada site onde o ESN é implantado) e de lá para o PSTN. A seguir estão alguns cenários explicados:

• Telefone 1 e Telefone 2 registrados no mesmo ESN – A chamada é roteada dentro do ESN.

• Telefone 1 registrado no ESN e Telefone 2 registrado no cluster Unified CM de instância dedicada – O plano de discagem deve rotear as chamadas do ESN para o GW PSTN local e, de lá, para o DI Unified CM via PSTN. Durante o evento de sobrevivência, o plano de discagem deve detectar a falha de roteamento de chamadas e redirecionar as chamadas por meio do GW PSTN local. O mesmo deve ser aplicável para chamadas recebidas para ESN de dispositivos DI Unified CM.

• O telefone 1 está registrado no ESN e o telefone 2 é um dispositivo PSTN: Durante o evento de sobrevivência, as chamadas PSTN precisam ser roteadas para o gateway PSTN local. Você deve certificar-se de que o plano de discagem tenha capacidade de detectar falhas de roteamento de chamadas e redirecionar a chamada por meio do gateway PSTN local disponível.

• Durante o evento de sobrevivência, quando a conectividade do seu site com a nuvem da instância dedicada estiver inativa (interrupção de WAN ou conectividade), os recursos de correio de voz e atendimento automático não funcionarão para os dispositivos registrados no ESN, pois o servidor Cisco Unity Connection está hospedado na nuvem da instância dedicada com a qual a conectividade do ESN está inativa. Se o seu dispositivo estiver configurado com “Encaminhamento de Chamadas Não Registrado (CFU)” e a chamada for recebida no DI Unified CM, o chamador poderá depositar uma mensagem de voz na Conexão Unity da Instância Dedicada. Que pode ser recuperado quando os dispositivos retornam aos assinantes do DI Unified CM.

• No entanto, durante um evento de sobrevivência, quando a conectividade com a nuvem de instância dedicada está disponível, mas o cluster do Unified CM no DI está inativo, nesse caso, os recursos de correio de voz e atendimento automático funcionam para dispositivos registrados no ESN, pois o ESN terá conectividade com o servidor Unity Connection implantado na nuvem do DI.

Durante o evento de sobrevivência, o ESN não poderá alcançar o Cisco Expressway E & C na nuvem DI e vice-versa. Portanto, neste caso, os usuários do MRA não podem obter o serviço do ESN e, portanto, não poderão se registrar. No entanto, se o dispositivo MRA tiver internet e puder se conectar ao Cisco Expressways na nuvem DI, ele poderá se registrar no DI Unified CM, desde que o cluster no DI esteja funcional.

Para que as integrações baseadas em CTI funcionem com o Enhanced Survivability Node, você deve adicionar o Enhanced Survivability Node como parte da lista de servidores do CTI. Os aprimoramentos de CTI são feitos para aplicativos que usam JTAPI para permitir o Enhanced Survivability Node como um servidor CTI ao qual o aplicativo pode se conectar somente no caso de os servidores CTI primários ou secundários na lista configurada não estarem acessíveis. Durante uma operação normal, os aplicativos CTI no local podem se conectar aos servidores CTI primários e secundários na nuvem DI e, durante o evento de sobrevivência, eles podem se conectar ao Enhanced Survivability Node para uma experiência CTI contínua. Os aplicativos devem se adaptar às novas APIs expostas na interface JTAPI para garantir que o fallback do Enhanced Survivability Node ocorra quando a conectividade for restaurada.

Para obter mais informações sobre as novas APIs adicionadas, consulte a seção de redundância, 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

Aplicativos de terceiros que fazem interface por meio de troncos SIP são compatíveis com o Enhanced Survivability Node. Nas configurações de tronco SIP, a configuração 'executar em todos os nós' deve estar habilitada.

São suportados dispositivos de terceiros que possuem capacidade TFTP terciário.