Configurazione e risoluzione dei problemi dell'opzione UCCE in uscita High Availability - Guida di riferimento rapido

Introduzione

In questo documento viene descritto come configurare Cisco Unified Contact Center Enterprise (UCCE) Outbound Option High Availability (OHA) e risolvere i relativi problemi.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• UCCE Outbound Option
• Replica transazionale Microsoft SQL

Componenti usati

Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:

• Cisco UCCE 11.6
• Microsoft SQL Server 2014

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Architettura

La funzionalità OOHA (Outbound Option High-Availability) è stata introdotta nella versione UCCE 11.6. OOHA è una funzionalità facoltativa. Dalla versione UCCE 11.6, il processo di Campaign Manager può essere ridondante con il modello di failover Active-StandBy. Quando OOHA è abilitato in WebSetup, il sistema esegue automaticamente la replica transazionale bidirezionale SQL tra i database BA_A e BA_B.

Le tabelle seguenti vengono replicate:

• Contatti
• Elenco_di_composizione
• PCB
• Non_chiamare

Architettura UCCE 11.6 OOHA

  

Panoramica sui modelli di failover

Responsabili della campagna attivi - Standby

• Il processo Active Campaign Manager avvia il failover se per impostazione predefinita non è disponibile alcuna connessione dialer per più di 60 secondi. È possibile modificare questo timer aggiungendo dword EMTClientTimeoutToFailover in Logger/BlendedAgent/CurrentVersion/ percorso del Registro di sistema; il valore deve essere un tempo di attesa in secondi per la connessione dialer.
• I processi di Campaign Manager continuano a salire da A a B e viceversa se il dialer non riesce a stabilire una connessione con nessuno di essi.
• Il failover di Campaign Manager può impiegare fino a 4,5 minuti in presenza di un'enorme coda di replica tra i database BA. 4,5 minuti è un timer hardcoded e non può essere modificato.

Dialer attivi - StandBy

• Nessuna modifica rispetto alle versioni precedenti. Il modello di failover dialer rimane lo stesso, con un solo dialer attivo alla volta.

BaImport - Nessun failover

• BaImport funziona solo con il processo locale di Gestione campagne e ne replica lo stato. In caso di arresto anomalo del processo BaImport, viene attivato il failover a livello di Gestione campagne.

  

Configurazione

Passi preliminari

Passaggio 1. Verificare che la funzionalità di replica di SQL Server sia abilitata.

• Durante l'installazione di SQL è necessario selezionare la replica come funzionalità. Per verificare che la funzionalità di replica sia abilitata nel server di registrazione, passare a Unità disco SQL > setup.exe > Strumenti ed eseguire il report Individuazione SQL installata
• Se la funzionalità non è elencata nel report, eseguire questo comando nello strumento CMD di Windows e specificare il nome dell'istanza di SQL Server nel parametro del comando corrispondente

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

Passaggio 2. Verificare che l'account utente di SQL Server sia configurato.

• Il nome utente e la password devono essere gli stessi sul lato A e sul lato B.
• L'utente deve disporre del privilegio di amministratore di sistema di SQL Server.
• Utilizzare questo nome utente e questa password quando si esegue WebSetup per configurare Outbound Option e abilitare Outbound Option High Availability.
• Non è necessario che l'utente sia l'utente sa SQL. Può trattarsi di un altro utente, ma deve disporre del privilegio sysadmin e rimanere abilitato.

        

Passaggio 3. In SQL user NT AUTHORITY\SYSTEM deve avere il ruolo sysadmin. 

Passaggio 4. Il nome host del server di registrazione e il nome del server SQL Server (@@nomeserver) devono corrispondere.

Nuova configurazione di installazione

Passaggio 1. Creare i database BA su entrambi i server di registrazione.

Passaggio 2. Configurare lo stesso utente SQL locale con ruolo sysadmin in entrambi i logger.

Passaggio 3. Avviare WebSetup su LoggerA, modificare il componente Logger e abilitare Outbound Option e Outbound High Availability.

Nota: Assicurarsi di specificare il nome host dei logger nei campi Interfaccia pubblica del logger. Questo valore deve corrispondere al nome del server SQL nel rispettivo logger.

Al termine dell'installazione Web, sarà necessario visualizzare la pubblicazione creata e il server SQL LoggerA e la sottoscrizione nel LoggerB.

Controllarla da SQL Server Management Studio (SSMS) in Replica > Pubblicazioni locali sul LoggerA e Sottoscrizioni locali sul LoggerB.

Eseguire WebSetup su LoggerB, modificare il componente Logger e abilitare Outbound Option e Outbound High Availability.

La pubblicazione deve essere creata su LoggerB e la sottoscrizione su LoggerA. 

Nell'immagine è illustrata la pubblicazione e la sottoscrizione create nel server LoggerB.

Nell'immagine sono illustrati la pubblicazione e la sottoscrizione create nel server di registrazione A.

  

Risoluzione dei problemi

Controllo stato replica SQL

Selezionare Avvia strumento di monitoraggio replica da SSMS per controllare lo stato della replica.

Lo stato della replica deve essere OK.

Espandere l'autore per ottenere ulteriori informazioni sulle prestazioni e sulla latenza.

Passare alla seconda scheda Tracer Tokens e selezionare Insert Tracer. In questo modo viene verificata la latenza tra server di pubblicazione e server di distribuzione e tra server di distribuzione e Sottoscrittore.

Questa opzione deve essere selezionata su entrambi i logger.

Cambia nome server SQL 

Aprire SSMS ed eseguire questa query SQL.

SELECT @@servername

Confrontare l'output della query con il nome host del server Windows. Devono corrispondere.

Nell'immagine è illustrato uno scenario di problema in cui il nome host di LoggerA e il nome del server SQL non corrispondono. Assicurarsi di correggerlo prima di eseguire l'installazione OO HA.

Per eliminare il nome server SQL, eseguire questo comando in SSMS sul database master.

EXEC sp_dropserver @server=

Per aggiungere un nuovo nome server SQL, eseguire questo comando.

EXEC sp_addserver @server=, @local=LOCAL

Riavviare SQL Server e SQL Server Agent dai servizi di Windows e controllare l'output della query SQL select @@servername.

Abilita replica SQL manualmente

Attenzione: Utilizzare questa procedura solo se WebSetup non è in grado di stabilire la replica e gli errori non sono chiari.

Eseguire questa stored procedure nei database BA di entrambi i logger con i rispettivi valori di variabile.

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

Se si verifica un errore "CREATE DATABASE failed", verificare che l'account MSSQLSERVER disponga dell'accesso completo alla directory di lavoro SQL.

In questa immagine vengono visualizzati gli errori rispettivi nei log di SQL Server. 

Verificare che l'account MSSQLSERVER disponga dell'accesso completo alla directory di lavoro SQL.

Verificare che la pubblicazione e la sottoscrizione vengano create in ogni server SQL del logger.

   

Disabilita replica SQL manualmente

Attenzione: Utilizzare questa procedura solo se WebSetup non è in grado di stabilire la replica e gli errori non sono chiari.

Eseguire questa procedura sui database BA di entrambi i logger con i rispettivi valori di variabile.

EXEC sp_ba_remove_replication 
@instance = ,
@subscriber = 

Verificare se le pubblicazioni vengono rimosse da entrambi i server SQL del logger.

Per cancellare completamente SQL Server dalla configurazione di replica, è necessario eliminare manualmente le sottoscrizioni ed eliminare i database di distribuzione in entrambi i server SQL del logger.

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

In alcuni casi l'ultimo comando può non riuscire e viene visualizzato il messaggio di errore "Impossibile eliminare il nome del server come server di pubblicazione del database di distribuzione perché in tale server sono presenti database abilitati per la replica".

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1

Informazioni correlate

• Guida alle opzioni in uscita UCCE 11.6
• Guida alla progettazione di UCCE 11.6 - Considerazioni sull'opzione di uscita per l'alta disponibilità
• Riferimento per la replica transazionale SQL
• Documentazione e supporto tecnico – Cisco Systems