Visão geral

No modelo de implantação de site único, em que um Nó de sobrevivência aprimorado (ESN) é implantado em um site juntamente com um gateway local para roteamento de chamadas PSTN. Um máximo de 7500 dispositivos pode ser registrado 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 depende da exigência de negócios 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 pode ser adicionado a um cluster do 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, não é recomendado. Se houver uma interrupção de rede, o site poderá ficar isolado e, nesse caso, o ESN não poderá acessar o Gateway local para roteamento das chamadas para PSTN.

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

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

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

Monitoramos e gerenciamos o Nó de sobrevivência aprimorada como outros nós que são implantados no datacenter da Ocorrência dedicada. Durante um evento de sobrevivência, quando o ESN é desconectado da Nuvem Cisco é quando perdemos o acesso ao Nó e nos conectamos automaticamente de volta quando a interrupção é resolvida e a conectividade é restaurada.

Gerenciamos os certificados de aplicativos UC e, durante a ativação do Nó de sobrevivência aprimorada, atualizamos o certificado do grupo Unified CM da ocorrência dedicada com o ESN.

Durante a ativação do ESN do Control Hub, haverá uma reinicialização de todos os dispositivos registrados, pois o certificado do cluster do Unified CM será atualizado com os certificados multiSAN. Portanto, planejamos o período de manutenção durante a ativação do ESN do Control Hub. Consulte, Como ativar o nó de sobrevivência aprimorada .

Durante o evento de sobrevivência, o Nó de sobrevivência aprimorado armazena todos os dados CDR/CMR localmente. Quando a conectividade for restaurada, os dados serão sincronizados de volta com o Editor do Unified CM da ocorrência dedicada. A quantidade de dados que podem ser armazenados é baseada no tamanho do disco do nó de sobrevivência aprimorado. O espaço máximo de alocação de disco que pode ser definido para CDR é 3328 MB . Isso pode ser com tamanho de arquivo CDR pequeno a grande com base no intervalo CDR que está 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 permanecer mais do que quando os registros não processados também forem removidos.

• Marca de água alta % que é configurado nas configurações de "Gerenciamento CDR", os arquivos CDR serão removidos. Por exemplo, se a "High Water Mark %” is configured as 80% e o uso do disco forem 80%, os arquivos CDR serão removidos.

• Preservação de arquivos CDR / CMR Duração (dias) que é configurado nas configurações de "Gerenciamento de CDR", os arquivos CDR serão eliminados. Por padrão, ele é definido como 30 dias.

A seguir, os alertas em RTMT relacionados ao Nó de sobrevivência aprimorada:

• SurvivabilityEvent - o alarme é disparado quando todos os nós da Ocorrência dedicada não estão acessíveis a partir do nó de sobrevivência aprimorada.

• RemoteSurvivableNodeNotReachable - o alarme é disparado quando um Nó de sobrevivência aprimorado não está acessível do editor do Unified CM da ocorrência dedicada.

Durante o evento de sobrevivência, você precisa conectar a 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 Ocorrência dedicada, pois o ESN não estará acessível da nuvem durante o evento de sobrevivência.

Durante a operação normal, a replicação do banco de dados é totalmente malhada entre todos os servidores, incluindo o Nó de sobrevivência aprimorada no cluster do Unified CM. Os dados de configuração estática, porque são criados por meio de movimentos, adições e alterações, são sempre armazenados no editor e replicados de uma maneira do editor para cada assinante e um nó de sobrevivência aprimorado no cluster.

Durante um evento de sobrevivência, apenas os recursos voltados ao usuário são modificados nos dispositivos que estão registrados no Nó de sobrevivência aprimorada e os recursos voltados ao usuário são normalmente caracterizados usando o fato de que você pode ativar ou desativar um recurso diretamente em seu telefone pressionando um ou mais botões, ao invés de alterar um recurso por meio de uma GUI baseada na web. Portanto, o Nó de sobrevivência aprimorada permite o autocuidado e a GUI de administração 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 novamente com o editor DI Unified CM quando a conectividade for restabelecida.

Os recursos voltados ao usuário são todos os recursos que podem ser ativados ou desativados ao pressionar botões no telefone e incluir o seguinte:

• Encaminhar todas as chamadas (CFA)

• Ativação ou desativação de privacidade

• Ativar ou desativar Não perturbar (NãoPtb)

• Login no Cisco Extension Mobility

• Logon ou logoff do grupo de busca

• Mobilidade do Dispositivo

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

A autenticação de soft clients (aplicativo Cisco Jabber e Webex) para logon durante o failover para o nó de sobrevivência aprimorada é a seguinte:

1. Autenticação local : Quando a autenticação dos usuários é feita localmente dentro do Unified CM, durante o evento de sobrevivência, o Nó de sobrevivência aprimorado poderá autenticar os clientes registrados nele.

2. Autenticação LDAP : Nesse caso, a autenticação de usuários é feita usando o servidor LDAP local. Em seguida, durante o evento de sobrevivência, a autenticação de soft clients 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 Registro Único (SSO) : A autenticação de logon de SSO dos usuários é feita usando o servidor IDP. Em seguida, durante o evento de sobrevivência, a autenticação do trabalho de soft clients, desde que o servidor IDP seja acessível a partir do Nó de sobrevivência aprimorada.

   Para logon da IU da web do Unified CM habilitado para logon de SSO, a acessibilidade do IDP é necessária ou o logon da URL baseado em recuperação precisa ser usado.

   Os clientes já autenticados continuam logados, 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 da autenticação anterior, o ESN será redirecionado 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, Bridge de Conferência (software), os serviços devem ser ativados no ESN. Se os recursos de mídia baseados em hardware foram implantados, então durante o evento de sobrevivência você deve certificar-se de que os servidores de mídia estão acessíveis a partir do ESN.

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

Se houver um evento de sobrevivência, a nuvem RedSky não estará acessível a partir do ESN e, portanto, é necessário que você configure o plano de discagem de chamadas de emergência de modo que, se o RedSky não estiver disponível, encaminhe as chamadas de emergência por meio do GW PSTN local configurado nesse site. O grupo de rotas deve consistir no GW PSTN local para lidar com o roteamento de chamadas durante o evento de sobrevivência.

Para chamadas de emergência em outras regiões da Ocorrência dedicada, bem como o plano de discagem precisa ser configurado para encaminhar as chamadas através do GW PSTN local durante o evento de sobrevivência.

Configure o plano de discagem para roteamento de chamadas intrasite, intersite, entre clusters e PSTN durante o evento de sobrevivência. Em geral, o ESN pode rotear chamadas apenas para dispositivos que estão registrados nele. Todas as outras chamadas precisam ser roteadas para o PSTN GW local (configurado em cada site onde o ESN está implantado) e de lá para o PSTN. A seguir, 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 do Unified CM de ocorrência dedicada – O plano de discagem deve rotear as chamadas do ESN para o GW PSTN local, de lá para o DI Unified CM via PSTN. Durante o evento de sobrevivência, o plano de discagem deve detectar a falha do roteamento de chamadas e reencaminhar as chamadas por meio do GW PSTN local. O mesmo deve ser aplicável para chamadas recebidas do ESN de dispositivos DI Unified CM.

• O telefone 1 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 a capacidade de detectar falhas de roteamento de chamadas e redirecionar a chamada por meio do gateway PSTN local disponível.

Não recomendamos chamadas ICT entre os nós do ESN 2, embora seja viável quando os ESNs estão acessíveis em sua rede.

• Durante o evento de sobrevivência, quando a conectividade do seu site para a nuvem de Ocorrência dedicada estiver inativa (WAN ou interrupção de conectividade), os recursos de correio de voz e atendimento automático não funcionarão para os dispositivos que se registram no ESN, pois o servidor Cisco Unity Connection está hospedado na nuvem de Ocorrência dedicada à qual a conectividade do ESN está inoperante. 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 um correio de voz no Unity Connection da ocorrência dedicada. O que pode ser recuperado quando os dispositivos voltam para assinantes do DI Unified CM.

• No entanto, durante um evento de sobrevivência, quando a conectividade com a nuvem de Ocorrência dedicada estiver disponível, mas o cluster do Unified CM no DI estiver inativo, nesse caso, os recursos de correio de voz e atendimento automático funcionarão para dispositivos que estão registrados no ESN, pois o ESN terá conectividade com o servidor Unity Connection implantado na nuvem 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 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 aos Cisco Expressways na nuvem DI, ele poderá se registrar no DI Unified CM, desde que o cluster na DI esteja funcional.

Para que as integrações baseadas em CTI funcionem com o Nó de sobrevivência aprimorado, você deve adicionar o Nó de sobrevivência aprimorado como parte da lista de servidores do CTI. Aprimoramentos de CTI são feitos para aplicativos que usam JTAPI para permitir o Nó de sobrevivência aprimorado como um servidor CTI para o qual o aplicativo pode se conectar apenas no evento quando os servidores CTI primários ou secundários na lista configurada não estiverem acessíveis. Durante uma operação normal, os aplicativos CTI no local podem se conectar com os servidores CTI primários e secundários na nuvem DI e durante o evento de sobrevivência, eles podem se conectar com o Nó de sobrevivência aprimorado para uma experiência CTI contínua. Os aplicativos devem se adaptar às novas APIs conforme exposto pela interface JTAPI para garantir que o fallback do Nó de sobrevivência aprimorada 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

O serviço da Web AXL está habilitado no Nó de sobrevivência aprimorado com privilégios de administrador de somente leitura. Recomendamos que todos os aplicativos de terceiros, como o servidor de provisionamento, façam a interface apenas com o editor do DI Unified CM para quaisquer atualizações relacionadas ao banco de dados. No entanto, é possível que esses aplicativos sejam somente leitura quando conectados ao Nó de sobrevivência aprimorada.

Aplicativos de terceiros que interagem por meio dos troncos SIP suportam com o Nó de sobrevivência aprimorado. Nas configurações do tronco SIP, a configuração " executar em todos os nós " deve estar ativada.

Dispositivos de terceiros são suportados que têm capacidade TFTP temporária.