Introduction
Este documento descreve como configurar e solucionar problemas do Cisco Unified Contact Center Enterprise (UCCE) Outbound Option High Availability (OOHA).
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Opção de saída UCCE
- Replicação Transacional do Microsoft SQL
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- Cisco UCCE 11.6
- MS SQL Server 2014
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
Arquitetura
O recurso de Alta Disponibilidade da Opção de Saída (OHA - Outbound Option High-Availability) foi introduzido na versão UCCE 11.6. OOHA é um recurso opcional. Na versão UCCE 11.6, o processo do Campaign Manager pode ser redundante com o modelo de failover Ative-StandBy. Quando o OOHA é habilitado na WebSetup, o sistema faz automaticamente a replicação bidirecional do SQL entre bancos de dados BA_A e BA_B.
Essas tabelas são replicadas:
- Contato
- Dialing_List
- PCB
- Do_Not_Call
Arquitetura UCCE 11.6 OHA
Visão geral dos modelos de failover
Gerentes de campanha ativos - Em standby
- O processo Ative Campaign Manager inicia o failover se não houver conexão de discador por mais de 60 segundos por padrão. Este temporizador pode ser alterado adicionando a palavra EMTClientTimeoutToFailover no caminho Logger/BlendedAgent/CurrentVersion/ do registro; o valor deve ser um tempo de espera para a conexão do discador em segundos.
- Os processos do Campaign Manager continuarão a saltar de A para B e vice-versa se o discador não puder estabelecer uma conexão com nenhum deles.
- O failover do Campaign Manager pode levar até 4,5 minutos se houver uma enorme fila de replicação entre bancos de dados BA. 4,5 minutos é um temporizador codificado e não pode ser alterado.
Discadores ativos - StandBy
- Nenhuma alteração das versões anteriores. O modelo de failover do discador permanece o mesmo, apenas um discador ativo por vez.
BaImport - Sem failover
- O BaImport funciona somente com o processo local do Campaign Manager e replica seu status. Em caso de travamento do processo BaImport, o failover no nível do Gerenciador de campanhas é acionado.
Configurar
Etapas preliminares
Etapa 1. Certifique-se de que o recurso Replicação do SQL Server está ativado.
- Durante a instalação do SQL, a replicação como um recurso precisa ser selecionada. Para garantir que o recurso de replicação esteja habilitado no servidor Logger, navegue para a unidade de disco SQL > setup.exe > Tools e execute o relatório Installed SQL Discovery Report
- Se o recurso não estiver listado no relatório, execute esse comando na ferramenta CMD do Windows e forneça o nome da instância do SQL Server no respectivo parâmetro de comando
setup.exe /q /Features=Replication /InstanceName=
/ACTION=INSTALL /IAcceptSQLServerLicenseTerms
Etapa 2. Verifique se a conta de usuário do SQL Server está configurada.
- O nome de usuário e a senha devem ser os mesmos no Logger Lado A e no Logger Lado B.
- O usuário deve ter o privilégio de Administrador do Sistema do SQL Server.
- Você usa esse nome de usuário e senha ao executar o WebSetup para configurar a Opção de Saída e ativar a Alta Disponibilidade da Opção de Saída.
- O usuário não precisa ser o usuário SQL sa. Pode ser outro usuário, mas deve ter o privilégio sysadmin e permanece habilitado.

Etapa 3. No usuário SQL, o NT AUTHORITY\SYSTEM deve ter a função sysadmin.

Etapa 4. O nome de host do servidor de registro e o nome do servidor do SQL Server (@@servername) devem ser iguais.
Nova configuração de instalação
Etapa 1. Crie bancos de dados BA em ambos os servidores Logger.
Etapa 2. Configure o mesmo usuário SQL local com a função sysadmin em ambos os loggers.
Etapa 3. Inicie o WebSetup no Logger A, edite o componente Logger e habilite a Opção de Saída e a Alta Disponibilidade de Saída.

Note: Certifique-se de fornecer o nome de host dos loggers nos campos da Interface Pública do Logger. Esse valor deve corresponder ao nome do servidor SQL no respectivo logger.
Depois que o WebSetup for concluído com êxito, você deverá ver Publicação criada e LoggerA SQL Server e Assinatura no LoggerB.
Verifique-o no SQL Server Management Studio (SSMS) em Replication > Local Publications no LoggerA e Local Subsciptions no LoggerB.

Execute o WebSetup no Logger B, edite o componente Logger e habilite a Opção de Saída e a Alta Disponibilidade de Saída.

A publicação deve ser criada no LoggerB e na Inscrição no LoggerA.
Esta imagem mostra Publicação e Assinatura criadas no servidor LoggerB.

Esta imagem mostra Publicação e Assinatura criadas no servidor LoggerA.

Troubleshoot
Verificação de Integridade da Replicação do SQL
Selecione Iniciar Ferramenta de Monitor de Replicação do SSMS para verificar o status da Replicação.

O status da replicação deve ser OK.
Expanda o editor para obter mais informações sobre desempenho e latência.

Navegue até a segunda guia Tracer Tokens e selecione Inserir Tracer. Que testa a latência entre o Editor e o Distribuidor e entre o Distribuidor e o Assinante.

Isso deve ser verificado em ambos os loggers.
Alterar nome do servidor SQL
Abra o SSMS e execute esta consulta SQL.
SELECT @@servername
Compare a saída da consulta com o nome de host do servidor Windows. Eles devem combinar.
Esta imagem mostra um cenário de problema quando o nome de host do LoggerA e o nome do servidor SQL não coincidem. Certifique-se de corrigi-lo antes da configuração do HA.

Para soltar o nome do servidor SQL, execute esse comando no SSMS em relação ao banco de dados mestre.
EXEC sp_dropserver @server=

Para adicionar um novo nome de servidor SQL, execute este comando.
EXEC sp_addserver @server=
, @local=LOCAL

Reinicie o SQL Server e o SQL Server Agent do Windows Services e verifique a saída de select @@servername Consulta SQL.
Habilitar Replicação SQL Manualmente
Caution: Use este procedimento apenas se o WebSetup não puder estabelecer a replicação e os erros não estiverem claros.
Execute este procedimento armazenado em bancos de dados BA em ambos os loggers com os respectivos valores variáveis.
EXEC sp_ba_create_replication
@instance=
,
@publisher=
,
@subscriber=
,
@working_directory =
,
@login =
,
@pwd =


Se você enfrentar um erro "Falha ao CRIAR BANCO DE DADOS", verifique se a conta MSSQLSERVER tem acesso total ao diretório de trabalho do SQL.
Esta imagem exibe o respectivo erro nos registros do SQL Server.

Verifique se a conta MSSQLSERVER tem acesso total ao diretório de trabalho SQL.

Certifique-se de que a publicação e a assinatura sejam criadas em cada servidor SQL do Logger.

Desativar Replicação SQL Manualmente
Caution: Use este procedimento apenas se o WebSetup não puder estabelecer a replicação e os erros não estiverem claros.
Execute este procedimento em relação aos bancos de dados BA em ambos os loggers com os respectivos valores variáveis.
EXEC sp_ba_remove_replication
@instance =
, @subscriber =


Verifique se Publications foi removido de ambos os servidores Logger SQL.


Para limpar completamente o SQL Server da configuração de replicação, você precisa excluir manualmente as assinaturas e descartar os bancos de dados de distribuição em ambos os servidores SQL do Logger.

USE master
EXEC sp_dropdistpublisher @publisher=
; EXEC sp_dropdistributiondb @database=distribution; EXEC sp_dropdistributor; GO

Em alguns casos, o último comando pode falhar com a mensagem de erro "Não é possível soltar o nome do servidor como Distributor Publisher porque há bancos de dados ativados para replicação nesse servidor".
EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1
Informações Relacionadas