Obrigado pelos seus comentários.

No modelo de implantação de site único, em que um Nó de Sobrevivabilidade Avançada (ESN) é implantado em um site junto com um gateway local para roteamento de chamadas PSTN. No máximo 7500 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, depende dos requisitos comerciais para a capacidade de sobrevivência do site. Os requisitos de um gateway local e DNS são sempre necessários e um total de 8 nós ESN podem ser adicionados a um Unified CM cluster.

Esse modelo de implantação é relevante para um cliente em uma região com vários locais, e a capacidade de sobrevivência é um requisito para vários desses sites. Embora seja possível compartilhar o gateway local da PSTN entre sites, isso não é recomendado. Se houver uma interrupção na rede, o site poderá 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 capacidade de sobrevivência aprimorado implantado em cada local.

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

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

Gerenciamos os certificados do aplicativo de UC e, durante a ativação do Enhanced Survivability Node, atualizamos o certificado de Unified CM cluster de instância dedicada e atualizado com o ESN.

Durante o evento de sobrevivência, o Enhanced Survivability Node armazena todos os dados de CDR/CMR localmente. Quando a conectividade for restaurada, os dados serão sincronizados novamente com o Dedicated Instance Unified CM Publisher. A quantidade de dados que podem ser armazenados é baseada no tamanho do disco do Enhanced Survivability Node. O espaço máximo de alocação de disco que pode ser definido para CDR é 3328 MB. Isso pode ser com um tamanho de arquivo CDR pequeno a grande, com base no intervalo de 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, é quando os registros não processados também são eliminados.

• Alta porcentagem de marca d'água configurada nas configurações de “Gerenciamento de CDR”, os arquivos CDR serão eliminados. Por exemplo, se o “High Water Mark%” estiver configurado como 80% e o uso do disco for 80%, os arquivos CDR serão eliminados.

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

A seguir estão os alertas no RTMT relacionados ao Enhanced Survivability Node:

• SurvivabilityEvent - o alarme é acionado quando todos os nós da Instância Dedicada não são acessíveis a partir do Nó de Sobrevivabilidade Avançada.

• RemoteSurvivableNodeNotReachable - o alarme é acionado quando um Nó de Sobrevivabilidade Avançada não pode ser acessado pelo editor da Instância Dedicada. Unified CM

Durante o evento de sobrevivência, você precisa conectar o RTMT ao Enhanced Survivability Node 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 mesclada entre todos os servidores, incluindo o Enhanced Survivability Node dentro do cluster. 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 editor e replicados de uma maneira do editor para cada assinante, além de um nó de capacidade de sobrevivência aprimorada no cluster.

Durante um evento de sobrevivência, somente os recursos voltados para o usuário são modificados nos dispositivos registrados no Enhanced Survivability Node e os recursos voltados para o usuário são normalmente caracterizados pelo fato de que você pode ativar ou desativar um recurso diretamente no telefone pressionando um ou mais botões, em vez de alterar um recurso por meio de uma GUI baseada na web. Portanto, o Enhanced Survivability Node permite o autocuidado e a GUI de administração da web como operações somente para leitura. Os dispositivos do usuário registrados no ESN podem fazer alterações somente nos recursos voltados para o usuário listados abaixo durante o failover. No entanto, essas alterações não serão sincronizadas novamente com o Unified CM editor de DI quando a conectividade for restabelecida.

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

• Call Forward All (CFA)

• Ativar ou desativar a privacidade

• Ativar ou desativar o Não perturbe (DND)

• Cisco Extension MobilityLogin

• Login ou Sair do Grupo de Busca

• Mobilidade de dispositivos

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

A autenticação de clientes virtuais (Cisco Jabbere do aplicativo Webex) 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 dentro doUnified CM, durante o evento de sobrevivência, o Nó de Sobrevivência Avançada poderá autenticar os clientes registrados nele.

2. Autenticação LDAP: Nesse caso, a autenticação dos usuários é feita usando o servidor LDAP local. Então, durante o evento de sobrevivência, a autenticação de clientes flexíveis funcionará, desde que o servidor LDAP seja acessível a partir do Enhanced Survivability Node.

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

3. Autenticação de login ú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 flexíveis funciona, desde que o servidor IDP seja acessível a partir do Enhanced Survivability Node.

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

   Os 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 tem um token válido da 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.

Recursos de mídia são necessários para que Unified CM recursos básicos, como Music on Hold, Announcement, Conference Bridge (software). Os serviços devem estar habilitados no ESN. Se recursos de mídia baseados em hardware foram implantados, durante o evento de sobrevivência, você deve se certificar de que os servidores de mídia estejam acessíveis a partir do ESN.

Durante as operações normais do Unified CM cluster de ID, 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 CM unificado da Instância Dedicada e a nuvem RedSky.

Se houver um evento de sobrevivência, a nuvem RedSky não poderá ser acessada pelo ESN e, portanto, é 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, encaminhe as chamadas de emergência por meio do PSTN GW local configurado nesse site. O grupo de rotas deve consistir no PSTN GW local para lidar com o roteamento de chamadas durante o evento de sobrevivência.

Configure o plano de discagem para rotear chamadas intra-site, entre sites, entre clusters 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 em que o ESN está 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 Unified CM cluster de instâncias dedicadas — O plano de discagem deve rotear as chamadas do ESN para o PSTN GW local, de lá para o DI via PSTN. Unified CM Durante o evento de sobrevivência, o plano de discagem deve detectar a falha no roteamento de chamadas e redirecionar as chamadas pelo PSTN GW local. O mesmo deve ser aplicável às chamadas recebidas para o ESN a partir de dispositivos DIUnified 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 garantir que o plano de discagem tenha a capacidade de detectar falhas no 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 (WAN ou interrupção de conectividade), os recursos de correio de voz e atendedor automático não funcionarão nos dispositivos registrados no ESN, pois o Cisco Unity Connection servidor está hospedado na nuvem da Instância Dedicada na qual a conectividade do ESN está inativa. Se seu dispositivo estiver configurado com “Call Forward Unregistered (CFU)” e a chamada for recebida em DIUnified CM, o chamador poderá depositar uma mensagem de voz na Instância Dedicada Unity Connection. 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 Unified CM cluster em DI está inativo, nesse caso, os recursos de correio de voz e atendedor automático funcionam para dispositivos 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 conseguirá alcançar o Cisco Expressway E & C na nuvem DI e vice-versa. Portanto, neste caso, os usuários do MRA não poderão 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 na DI, Unified CM desde que o cluster na 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 o 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 um evento de sobrevivência, eles podem se conectar ao Enhanced Survivability Node para uma experiência contínua de CTI. Os aplicativos devem se adaptar às novas APIs, conforme 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/ /14_0_1/ -unified-jtapi-developers-guide-14/ -unified-jtapi-developers-guide-1251_chapter_00.html jtapi_dev cucm_b_cisco cucm_b_cisco

Aplicativos de terceiros que interagem por meio dos 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 com capacidade de TFTP terciário.