Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

Architecture

Présentation des modèles de basculement

Configuration

Étapes préliminaires

Nouvelle configuration d'installation

Dépannage

Vérification de l'intégrité de la réplication SQL

Modifier le nom de serveur SQL

Activer la réplication SQL manuellement

Désactiver la réplication SQL manuellement

Informations connexes

Introduction

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

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- UCCE Outbound Option

- Réplication transactionnelle Microsoft SQL

Components Used

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 OOHA UCCE 11.6

Présentation des modèles de basculement

Responsables de campagne actifs - StandBy

- Le processus Gestionnaire de campagnes actif initie le basculement s'il n'y a pas de connexion de numéroteur pendant plus de 60 secondes par défaut. Ce compteur peut être modifié en ajoutant dword EMTClientTimeoutToFailover sous Logger/BlendedAgent/CurrentVersion/ chemin d'accès au Registre ; la valeur doit être un délai d'attente pour la connexion du numéroteur en secondes.

- Les processus du Gestionnaire de campagnes continuent à rebondir de A à B et vice versa si le numéroteur ne peut pas établir de connexion à l'un d'eux.

- Le basculement de Campaign Manager peut prendre jusqu'à 4,5 minutes s'il existe une file d'attente de réplication énorme entre les bases de données BA. 4,5 minutes est un minuteur codé en dur et ne peut pas être modifié.

Numéroteurs actifs - StandBy

- 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 actif à la fois.

BaImport - Pas de basculement

- BaImport fonctionne uniquement avec le processus du Gestionnaire de campagnes local et duplique son état. En cas de panne du processus BaImport, le basculement au niveau du Gestionnaire de campagnes est déclenché.

Configuration

Étapes préliminaires

Étape 1. Assurez-vous que la fonctionnalité de réplication 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 de journalisation, accédez à lecteur de disque SQL > setup.exe > Outils et exécutez le rapport Détection SQL installée

- Si la fonctionnalité n'est pas répertoriée dans le rapport, exécutez cette commande dans l'outil CMD Windows et indiquez le nom de l'instance SQL Server dans le paramètre de commande respectif

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 les champs Logger Side A et Logger Side B.

- L'utilisateur doit disposer du privilège 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.

- L'utilisateur n'a pas besoin d'être l'utilisateur SQL sa. Il peut s'agir d'un autre utilisateur, mais il doit avoir le privilège sysadmin et rester activé.

Étape 3. Dans l'utilisateur SQL 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éez des bases de données BA sur les deux serveurs de journalisation.

Étape 2. Configurez le même utilisateur SQL local avec le rôle sysadmin sur les deux journaux.

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

Note: Assurez-vous de fournir le nom d'hôte Loggers dans les champs de l'interface publique Logger. Cette valeur doit correspondre au nom du serveur SQL sur chaque enregistreur.

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

Vérifiez-la à partir de SQL Server Management Studio (SSMS) sous Replication > Local Publications on LoggerA and Local Subsciptions on LoggerB.

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

La composition doit être créée sur LoggerB et 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 de l'intégrité de la réplication SQL

Sélectionnez Lancer l'outil Replication Monitor à partir de 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 deuxième onglet Jetons de trace et sélectionnez Insérer un traceur. Cela teste la latence entre Publisher et Distributor et entre Distributor et Subscriber.

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

Modifier le nom de serveur SQL

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 montre 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 corriger avant de configurer OO HA.

Afin de supprimer le nom de serveur SQL, exécutez cette commande dans SSMS contre 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 SQL Server Agent à partir des services Windows et vérifiez le résultat de sélectionner @@servername Requête SQL.

Activer la réplication SQL manuellement

Attention : Utilisez cette procédure uniquement si WebSetup ne peut pas établir de 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 journaux avec des valeurs de variable respectives.

EXEC sp_ba_create_replication

@instance=

,

@publisher=

,

@subscriber=

,

@working_directory =

,

@login =

,

@pwd =

Si vous rencontrez une erreur « Échec de la création de la base de données », vérifiez si le compte MSSQLSERVER a 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 a 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 la réplication SQL manuellement

Attention : Utilisez cette procédure uniquement si WebSetup ne peut pas établir de réplication et que les erreurs ne sont pas claires.

Exécutez cette procédure avec les bases de données BA des deux journaux avec des 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 de distribution car il y a des bases de données activées pour la réplication sur ce serveur ».

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1

Informations connexes

- Guide d'option de sortie UCCE 11.6

- Guide de conception UCCE 11.6 - Considérations relatives à la haute disponibilité des options sortantes

- Référence de réplication transactionnelle SQL

- Support et documentation techniques - Cisco Systems