Configuration et dépannage de la haute disponibilité de l'option UCCE Outbound - Guide de référence rapide

Introduction

Ce document décrit comment configurer et dépanner Cisco Unified Contact Center Enterprise (UCCE) Outbound Option High Availability (OOHA).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Option de sortie UCCE
• Réplication transactionnelle Microsoft SQL

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• 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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Architecture

La fonctionnalité Outbound Option High-Availability (OOHA) a été introduite dans la version UCCE 11.6. OOHA est une fonctionnalité facultative. À partir de la version UCCE 11.6, le processus Campaign Manager peut être redondant avec le modèle de basculement Active-StandBy. Lorsque OOHA est activé dans WebSetup, le système effectue automatiquement une réplication transactionnelle bidirectionnelle SQL entre les bases de données BA_A et BA_B.

Ces tables sont répliquées :

• Contact
• Liste_Numérotation
• PCB
• Ne_pas_appeler

Architecture UCCE 11.6 OHA

  

Présentation des modèles de basculement

Responsables de campagne actifs - StandBy

• Le processus Active Campaign Manager lance le basculement si aucune connexion de numérotation n'est établie par défaut pendant plus de 60 secondes. Ce minuteur peut être modifié en ajoutant dword EMTClientTimeoutToFailover sous Logger/BlendedAgent/CurrentVersion/ chemin du registre ; la valeur doit être un délai d'attente de la connexion de numérotation en secondes.
• Les processus du Gestionnaire de campagnes continuent à rebondir de A à B et vice versa si le numéroteur ne peut établir de connexion à aucun d'entre eux.
• Le basculement de Campaign Manager peut prendre jusqu'à 4,5 minutes en cas de file d'attente de réplication importante entre les bases de données BA. 4,5 minutes est un compteur codé en dur et ne peut pas être modifié.

Numéroteurs actifs - Veille

• Aucune modification par rapport aux versions précédentes. Le modèle de basculement du numéroteur reste le même, un seul numéroteur à la fois étant actif.

BaImport - Pas de basculement

• BaImport fonctionne uniquement avec le processus local du Gestionnaire de campagnes et réplique son état. En cas de blocage du processus BaImport, le basculement au niveau du Gestionnaire de campagnes est déclenché.

  

Configurer

Étapes préliminaires

Étape 1. Assurez-vous que la fonctionnalité de réplication de SQL Server est activée.

• Lors de l'installation de SQL, la réplication en tant que fonctionnalité doit être sélectionnée. Afin de s'assurer que la fonctionnalité de réplication est activée sur le serveur Logger, naviguez vers lecteur de disque SQL > setup.exe > Outils et exécutez le rapport Installed SQL Discovery Report
• Si la fonctionnalité n'est pas répertoriée dans le rapport, exécutez cette commande dans l'outil Windows CMD et indiquez le nom de l'instance SQL Server dans le paramètre de commande correspondant

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

Étape 2. Vérifiez que le compte d'utilisateur SQL Server est configuré.

• Le nom d'utilisateur et le mot de passe doivent être identiques dans Logger Side A et Logger Side B.
• L'utilisateur doit disposer du privilège d'administrateur système SQL Server.
• Vous utilisez ce nom d'utilisateur et ce mot de passe lorsque vous exécutez WebSetup pour configurer Outbound Option et activer Outbound Option High Availability.
• Il n'est pas nécessaire que l'utilisateur soit l'utilisateur sa SQL. Il peut s'agir d'un autre utilisateur, mais il doit disposer du privilège sysadmin et rester activé.

        

Étape 3. Dans SQL, l'utilisateur NT AUTHORITY\SYSTEM doit avoir le rôle sysadmin. 

Étape 4. Le nom d’hôte du serveur de journalisation et le nom de serveur SQL Server (@@servername) doivent être identiques.

Nouvelle configuration d'installation

Étape 1 : création de bases de données BA sur les deux serveurs de journalisation

Étape 2 : configuration du même utilisateur SQL local avec le rôle sysadmin sur les deux journaliseurs

Étape 3. Démarrez WebSetup sur LoggerA, modifiez le composant Logger et activez Outbound Option et Outbound High Availability.

Remarque : Assurez-vous de fournir le nom d'hôte des enregistreurs dans les champs Interface publique. Cette valeur doit correspondre au nom du serveur SQL sur le journal respectif.

Une fois WebSetup terminé, vous devez voir Publication créé et LoggerA SQL Server et Abonnement sur LoggerB.

Vérifiez-le à partir de SQL Server Management Studio (SSMS) sous Replication > Local Publications on LoggerA et Local Subscriptions on LoggerB.

Exécutez WebSetup sur LoggerB, modifiez le composant Logger et activez Outbound Option et Outbound High Availability.

La publication doit être créée sur LoggerB et l'abonnement sur LoggerA. 

Cette image montre la publication et l'abonnement créés sur le serveur LoggerB.

Cette image montre la publication et l'abonnement créés sur le serveur LoggerA.

  

Dépannage

Vérification du fonctionnement de la réplication SQL

Sélectionnez Launch Replication Monitor Tool dans SSMS pour vérifier l'état de la réplication.

L'état de la réplication doit être OK.

Développez l'éditeur pour obtenir plus d'informations sur les performances et la latence.

Accédez au second onglet Tracer Tokens et sélectionnez Insert Tracer. qui teste la latence entre le serveur de publication et le serveur de distribution et entre le serveur de distribution et l'abonné.

Cette option doit être cochée sur les deux enregistreurs.

Modifier le nom SQL Server 

Ouvrez SSMS et exécutez cette requête SQL.

SELECT @@servername

Comparez le résultat de la requête avec le nom d'hôte du serveur Windows. Ils doivent correspondre.

Cette image présente un scénario de problème lorsque le nom d'hôte de LoggerA et le nom du serveur SQL ne correspondent pas. Assurez-vous de le réparer avant la configuration OO HA.

Afin de supprimer le nom du serveur SQL, exécutez cette commande dans SSMS sur la base de données maître.

EXEC sp_dropserver @server=

Pour ajouter un nouveau nom de serveur SQL, exécutez cette commande.

EXEC sp_addserver @server=, @local=LOCAL

Redémarrez SQL Server et l'Agent SQL Server à partir des services Windows et vérifiez le résultat de la requête SQL select @@servername.

Activer manuellement la réplication SQL

Mise en garde : Utilisez cette procédure uniquement si WebSetup ne parvient pas à établir la réplication et que les erreurs ne sont pas claires.

Exécutez cette procédure stockée sur les bases de données BA des deux enregistreurs avec les valeurs de variable respectives.

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

Si vous rencontrez l'erreur « Échec de CREATE DATABASE », vérifiez si le compte MSSQLSERVER dispose d'un accès complet au répertoire de travail SQL.

Cette image affiche les erreurs respectives dans les journaux du serveur SQL. 

Assurez-vous que le compte MSSQLSERVER dispose d'un accès complet au répertoire de travail SQL.

Assurez-vous que la publication et l'abonnement sont créés sur chaque serveur SQL Logger.

   

Désactiver manuellement la réplication SQL

Mise en garde : Utilisez cette procédure uniquement si WebSetup ne parvient pas à établir la réplication et que les erreurs ne sont pas claires.

Exécutez cette procédure sur les bases de données BA des deux enregistreurs avec les valeurs de variable respectives.

EXEC sp_ba_remove_replication 
@instance = ,
@subscriber = 

Vérifiez si les publications sont supprimées des deux serveurs SQL de journalisation.

Pour effacer complètement SQL Server de la configuration de réplication, vous devez supprimer manuellement les abonnements et supprimer les bases de données de distribution sur les deux serveurs SQL Logger.

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

Dans certains cas, la dernière commande peut échouer avec le message d'erreur « Impossible de supprimer le nom du serveur en tant que serveur de publication du serveur de distribution car des bases de données sont activées pour la réplication sur ce serveur ».

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1

Informations connexes

• Guide des options sortantes UCCE 11.6
• Guide de conception UCCE 11.6 - Options sortantes - Considérations relatives à la haute disponibilité
• Référence de réplication transactionnelle SQL
• Assistance et documentation techniques - Cisco Systems