Configuración y solución de problemas de alta disponibilidad de opciones salientes de UCCE: referencia rápida

Introducción

En este documento se describe cómo configurar y solucionar problemas de alta disponibilidad de opciones salientes (OOHA) de Cisco Unified Contact Center Enterprise (UCCE).

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Opción de salida de UCCE
• Replicación transaccional de Microsoft SQL

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Cisco UCCE 11.6
• MS SQL Server 2014

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

Arquitectura

La función de alta disponibilidad de opciones salientes (OOHA) se introdujo en la versión 11.6 de UCCE. OOHA es una función opcional. A partir de la versión 11.6 de UCCE, el proceso de Campaign Manager puede ser redundante con el modelo de conmutación por fallo Active-StandBy. Cuando OOHA está habilitado en WebSetup, el sistema realiza automáticamente la replicación transaccional bidireccional SQL entre las bases de datos BA_A y BA_B.

Estas tablas se replican:

• Contacto
• Lista_marcación
• PCB
• Do_Not_Call

Arquitectura de OOHA de UCCE 11.6

  

Descripción General de los Modelos de Failover

Administradores de campaña activos: en espera

• De forma predeterminada, el proceso de Active Campaign Manager inicia la conmutación por fallo si no hay ninguna conexión de marcador durante más de 60 segundos. Este temporizador se puede cambiar agregando dword EMTClientTimeoutToFailover en la ruta de registro Logger/BlendedAgent/CurrentVersion/; el valor debe ser un tiempo de espera para la conexión del marcador en segundos.
• Los procesos del Administrador de campañas siguen rebotando de A a B y viceversa si el marcador no puede establecer una conexión con ninguno de ellos.
• La conmutación por fallo de Campaign Manager puede tardar hasta 4,5 minutos si hay una cola de replicación enorme entre las bases de datos de BA. 4,5 minutos es un temporizador codificado y no se puede cambiar.

Marcadores activos - En espera

• Sin cambios respecto a las versiones anteriores. El modelo de conmutación por fallas del marcador permanece igual, sólo hay un marcador activo a la vez.

BaImport - Sin conmutación por fallo

• BaImport sólo funciona con el proceso local de Campaign Manager y replica su estado. En caso de que el proceso de BaImport falle, se activa la conmutación por error en el nivel de Campaign Manager.

  

Configurar

Pasos preliminares

Paso 1. Asegúrese de que la característica de replicación de SQL Server esté habilitada.

• Durante la instalación de SQL, debe seleccionarse la replicación como función. Para asegurarse de que la característica de replicación esté habilitada en el servidor Logger, navegue hasta unidad de disco SQL > setup.exe > Herramientas y ejecute el informe Installed SQL Discovery Report
• Si la función no aparece en el informe, ejecute este comando en la herramienta CMD de Windows y proporcione el nombre de la instancia de SQL Server en el parámetro de comando correspondiente

setup.exe /q /Features=Replication /InstanceName= /ACTION=INSTALL /IAcceptSQLServerLicenseTerms

Paso 2. Asegúrese de que la cuenta de usuario de SQL Server esté configurada.

• El nombre de usuario y la contraseña deben ser iguales en el lado A del registrador y en el lado B del registrador.
• El usuario debe tener el privilegio de administración del sistema de SQL Server.
• Utilice este nombre de usuario y contraseña cuando ejecute WebSetup para configurar la opción de salida y activar la alta disponibilidad de la opción de salida.
• El usuario no tiene que ser el usuario SQL sa. Puede ser otro usuario, pero debe tener el privilegio sysadmin y permanecer habilitado.

        

Paso 3. En SQL, el usuario NT AUTHORITY\SYSTEM debe tener la función sysadmin. 

Paso 4. El nombre de host del servidor de registro y el nombre de servidor de SQL Server (@@servername) deben ser iguales.

Nueva configuración de instalación

Paso 1. Crear bases de datos BA en ambos servidores Logger.

Paso 2. Configure el mismo usuario SQL local con el rol sysadmin en ambos Loggers.

Paso 3. Inicie WebSetup en LoggerA, edite Logger Component y habilite Outbound Option y Outbound High Availability.

Nota: Asegúrese de proporcionar el nombre de host de Loggers en los campos Logger Public Interface. Este valor debe coincidir con el nombre del servidor SQL en el registrador respectivo.

Una vez que WebSetup se haya completado correctamente, debe ver Publication created and LoggerA SQL server and Subscribtion on LoggerB.

Compruébelo desde SQL Server Management Studio (SSMS) bajo Replicación > Publicaciones locales en LoggerA y Suscripciones locales en LoggerB.

Ejecute WebSetup en LoggerB, edite el componente Logger y habilite Outbound Option y Outbound High Availability.

La publicación debe crearse en LoggerB y la suscripción en LoggerA. 

Esta imagen muestra la publicación y suscripción creadas en el servidor LoggerB.

Esta imagen muestra la publicación y suscripción creadas en el servidor LoggerA.

  

Troubleshoot

Comprobación de estado de replicación SQL

Seleccione Launch Replication Monitor Tool desde SSMS para verificar el estado de la replicación.

El estado de replicación debe ser OK.

Expanda el editor para obtener más información sobre el rendimiento y la latencia.

Vaya a la segunda pestaña Tracer Tokens y seleccione Insert Tracer. Esto prueba la latencia entre el editor y el distribuidor, y entre el distribuidor y el suscriptor.

Esto debe ser verificado en ambos Loggers.

Cambiar nombre de servidor SQL 

Abra SSMS y ejecute esta consulta SQL.

SELECT @@servername

Compare el resultado de la consulta con el nombre de host del servidor de Windows. Deben coincidir.

Esta imagen muestra un escenario de problema cuando el nombre de host de LoggerA y el nombre del servidor SQL no coinciden. Asegúrese de solucionarlo antes de la configuración de OO HA.

Para descartar SQL servername, ejecute este comando en SSMS contra la base de datos maestra.

EXEC sp_dropserver @server=

Para agregar un nuevo nombre de servidor SQL, ejecute este comando.

EXEC sp_addserver @server=, @local=LOCAL

Reinicie SQL Server y SQL Server Agent desde Windows Services y verifique el resultado de la consulta select @@servername SQL.

Habilitar la replicación SQL manualmente

Precaución: Utilice este procedimiento sólo si WebSetup no puede establecer la replicación y los errores no están claros.

Ejecute este procedimiento almacenado con las bases de datos BA en ambos Loggers con los valores de variable respectivos.

EXEC sp_ba_create_replication 
@instance=,
@publisher=,
@subscriber=,
@working_directory =,
@login =,
@pwd =

Si se produce el error "Error al crear la base de datos", compruebe si la cuenta MSSQLSERVER tiene acceso completo al directorio de trabajo de SQL.

Esta imagen muestra el error correspondiente en los registros del servidor SQL. 

Asegúrese de que la cuenta MSSQLSERVER tenga acceso completo al directorio de trabajo SQL.

Asegúrese de que Publicación y Suscripción se crean en cada servidor SQL Logger.

   

Deshabilitar la replicación SQL manualmente

Precaución: Utilice este procedimiento sólo si WebSetup no puede establecer la replicación y los errores no están claros.

Ejecute este procedimiento con las bases de datos BA en ambos Loggers con los valores de variable respectivos.

EXEC sp_ba_remove_replication 
@instance = ,
@subscriber = 

Compruebe si las publicaciones se han eliminado de ambos servidores Logger SQL.

Para borrar completamente SQL Server de la configuración de replicación, debe eliminar manualmente las suscripciones y soltar las bases de datos de distribución en ambos servidores Logger SQL.

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

En algunos casos, el último comando puede fallar con el mensaje de error "No se puede borrar el nombre del servidor como publicador del distribuidor porque hay bases de datos habilitadas para la replicación en ese servidor".

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1

Información Relacionada

• Guía de opciones salientes de UCCE 11.6
• Guía de diseño de UCCE 11.6 - Consideraciones sobre la opción de salida Alta disponibilidad
• Referencia de Replicación de Transacciones SQL
• Soporte Técnico y Documentación - Cisco Systems