Konfigurieren der UCCE Outbound-Option High Availability und Fehlerbehebung - Kurzreferenz

Einleitung

In diesem Dokument wird die Konfiguration und Fehlerbehebung für Cisco Unified Contact Center Enterprise (UCCE) Outbound Option High Availability (OOHA) beschrieben.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• UCCE Outbound-Option
• Microsoft SQL-Transaktionsreplikation

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• Cisco UCCE 11.6
• MS SQL Server 2014

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

Architektur

Die Funktion für hohe Verfügbarkeit der Outbound-Option (OOHA) wurde in der UCCE 11.6-Version eingeführt. OOHA ist eine optionale Funktion. Ab der UCCE 11.6-Version kann der Campaign Manager-Prozess mit dem Active-StandBy-Failover-Modell redundant sein. Wenn OOHA in WebSetup aktiviert ist, führt das System automatisch eine bidirektionale SQL-Transaktionsreplikation zwischen BA_A- und BA_B-Datenbanken durch.

Diese Tabellen werden repliziert:

• Kontakt
• Wählliste
• Leiterplatte
• Kein_Anruf_tätigen

UCCE 11.6 OOHA-Architektur

  

Überblick über Failover-Modelle

Kampagnen-Manager aktiv - standby

• Der aktive Kampagnen-Manager-Prozess initiiert Failover, wenn standardmäßig für mehr als 60 Sekunden keine Dialer-Verbindung besteht. Dieser Timer kann geändert werden, indem EMTClientTimeoutToFailover unter Logger/BlendedAgent/CurrentVersion/Registry Path hinzugefügt wird. Beim Wert muss es sich um eine Wartezeit in Sekunden für die Wählverbindung handeln.
• Prozesse des Kampagnen-Managers springen immer wieder von A nach B und umgekehrt, wenn der Dialer keine Verbindung zu einem der Prozesse herstellen kann.
• Campaign Manager-Failover kann bis zu 4,5 Minuten dauern, wenn zwischen BA-Datenbanken eine große Replikationswarteschlange besteht. 4,5 Minuten ist ein fest codierter Zeitgeber und kann nicht geändert werden.

Dialer aktiv - standby

• Keine Änderungen gegenüber den vorherigen Versionen. Das Dialer-Failover-Modell bleibt unverändert, es ist jeweils nur ein Dialer aktiv.

BaImport - Kein Failover

• BaImport funktioniert nur mit dem lokalen Campaign Manager Prozess und repliziert dessen Status. Bei einem Absturz des BaImport-Prozesses wird auf Kampagnen-Manager-Ebene ein Failover ausgelöst.

  

Konfigurieren

Vorläufige Schritte

Schritt 1: Stellen Sie sicher, dass die SQL Server-Replikationsfunktion aktiviert ist.

• Während der Installation von SQL muss die Replikation als Funktion ausgewählt werden. Um sicherzustellen, dass die Replikationsfunktion auf dem Protokollierungsserver aktiviert ist, navigieren Sie zu SQL-Laufwerk > setup.exe > Tools, und führen Sie den Bericht Installed SQL Discovery Report aus.
• Wenn die Funktion nicht im Bericht aufgeführt ist, führen Sie diesen Befehl im Windows CMD-Tool aus, und geben Sie den SQL Server-Instanznamen im entsprechenden Befehlsparameter an.

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

Schritt 2: Stellen Sie sicher, dass das SQL Server-Benutzerkonto konfiguriert ist.

• Benutzername und Kennwort müssen auf Protokollierungsseite A und auf Protokollierungsseite B identisch sein.
• Der Benutzer muss über die SQL Server-Systemadministratorberechtigung verfügen.
• Sie verwenden diesen Benutzernamen und dieses Kennwort, wenn Sie WebSetup ausführen, um die Outbound-Option zu konfigurieren und die Outbound-Option High Availability zu aktivieren.
• Der Benutzer muss nicht SQL als Benutzer sein. Es kann sich um einen anderen Benutzer handeln, muss jedoch über die Berechtigung "sysadmin" verfügen und aktiviert bleiben.

        

Schritt 3. In SQL muss der Benutzer NT AUTHORITY\SYSTEM über die Rolle "sysadmin" verfügen. 

Schritt 4: Der Hostname des Protokollierungsservers und der SQL Server-Servername (@@servername) müssen identisch sein.

Neue Installationskonfiguration

Schritt 1: Erstellen Sie BA-Datenbanken auf beiden Protokollservern.

Schritt 2: Konfigurieren desselben lokalen SQL-Benutzers mit der sysadmin-Rolle auf beiden Protokollierungen

Schritt 3: Starten Sie WebSetup auf LoggerA, bearbeiten Sie Logger Component und aktivieren Sie Outbound Option und Outbound High Availability.

Anmerkung: Stellen Sie sicher, dass Sie in den Feldern für die öffentliche Benutzeroberfläche der Protokollierung den Hostnamen des Protokollierungsmoduls angeben. Dieser Wert muss mit dem SQL-Servernamen in der entsprechenden Protokollierung übereinstimmen.

Nachdem WebSetup erfolgreich abgeschlossen wurde, müssen Sie Publication erstellt und LoggerA SQL Server und Subscribtion auf LoggerB sehen.

Überprüfen Sie sie im SQL Server Management Studio (SSMS) unter Replikation > Lokale Veröffentlichungen auf LoggerA und Lokale Abonnements auf LoggerB.

Führen Sie WebSetup auf LoggerB aus, bearbeiten Sie die Protokollkomponente, und aktivieren Sie die Outbound-Option und die Outbound-Hochverfügbarkeit.

Die Veröffentlichung muss auf LoggerB und die Anmeldung auf LoggerA erstellt werden. 

Dieses Bild zeigt die Veröffentlichung und das Abonnement, die auf dem LoggerB-Server erstellt wurden.

Dieses Bild zeigt die Veröffentlichung und das Abonnement, die auf dem LoggerA-Server erstellt wurden.

  

Fehlerbehebung

Integritätsprüfung der SQL-Replikation

Wählen Sie Replication Monitor Tool von SSMS starten, um den Replikationsstatus zu überprüfen.

Replikationsstatus muss OK sein.

Erweitern Sie den Herausgeber, um mehr Informationen über Leistung und Latenz zu erhalten.

Navigieren Sie zur zweiten Registerkarte Tracer Tokens, und wählen Sie Tracer einfügen aus. Dabei wird die Latenz zwischen Publisher und Distributor sowie zwischen Distributor und Abonnent getestet.

Diese Option muss bei beiden Protokollierungsmodulen aktiviert sein.

SQL-Servername ändern 

Öffnen Sie SMS, und führen Sie diese SQL-Abfrage aus.

SELECT @@servername

Vergleichen Sie die Ausgabe der Abfrage mit dem Windows Server-Hostnamen. Sie müssen übereinstimmen.

Dieses Bild zeigt ein Problemszenario, wenn der Hostname von LoggerA und der SQL-Servername nicht übereinstimmen. Stellen Sie sicher, dass Sie es vor der OO HA-Einrichtung beheben.

Um SQL Servername zu löschen, führen Sie diesen Befehl in SSMS gegen die Master-DB aus.

EXEC sp_dropserver @server=

Führen Sie diesen Befehl aus, um einen neuen SQL-Servernamen hinzuzufügen.

EXEC sp_addserver @server=, @local=LOCAL

Starten Sie SQL Server und SQL Server Agent von Windows Services neu, und überprüfen Sie die Ausgabe der SQL-Abfrage select @@servername.

SQL-Replikation manuell aktivieren

Vorsicht: Verwenden Sie dieses Verfahren nur, wenn WebSetup die Replikation nicht herstellen kann und die Fehler nicht klar sind.

Führen Sie diese gespeicherte Prozedur für BA-Datenbanken auf beiden Loggern mit den entsprechenden Variablenwerten aus.

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

Wenn Sie die Fehlermeldung "CREATE DATABASE failed" (DATENBANK ERSTELLEN fehlgeschlagen) erhalten, überprüfen Sie, ob das MSSQLSERVER-Konto vollen Zugriff auf das SQL-Arbeitsverzeichnis hat.

Dieses Bild zeigt den entsprechenden Fehler in den SQL Server-Protokollen an. 

Stellen Sie sicher, dass das MSSQLSERVER-Konto vollen Zugriff auf das SQL-Arbeitsverzeichnis hat.

Stellen Sie sicher, dass Publication und Subscription auf jedem Logger-SQL-Server erstellt werden.

   

SQL-Replikation manuell deaktivieren

Vorsicht: Verwenden Sie dieses Verfahren nur, wenn WebSetup die Replikation nicht herstellen kann und die Fehler nicht klar sind.

Führen Sie diese Prozedur für BA-Datenbanken auf beiden Loggern mit den entsprechenden Variablenwerten aus.

EXEC sp_ba_remove_replication 
@instance = ,
@subscriber = 

Überprüfen Sie, ob Publikationen von beiden Logger SQL-Servern entfernt werden.

Um den SQL-Server vollständig aus der Replikationskonfiguration zu löschen, müssen Sie die Abonnements manuell löschen und die Verteilungsdatenbanken auf beiden Logger SQL-Servern löschen.

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

In einigen Fällen kann der letzte Befehl fehlschlagen, wenn die Fehlermeldung "Der Servername kann nicht als Distributor Publisher abgelegt werden, da auf diesem Server Datenbanken für die Replikation aktiviert sind" angezeigt wird.

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1

Zugehörige Informationen

• UCCE 11.6 Outbound-Optionshandbuch
• UCCE 11.6 Designleitfaden - Überlegungen zur hohen Verfügbarkeit der Outbound-Option
• SQL-Transaktionsreplikationsreferenz
• Technischer Support und Dokumentation für Cisco Systeme