Konfiguration und Fehlerbehebung für ausgehende UCCE-Optionen Hohe Verfügbarkeit - Kurzreferenz

Einführung

In diesem Dokument wird beschrieben, wie Cisco Unified Contact Center Enterprise (UCCE) Outbound Option High Availability (OHA) konfiguriert und Fehler bei diesen behoben werden.

Voraussetzungen

Anforderungen

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

• Outbound-Option für UCCE
• Microsoft SQL-Transaktionsreplikation

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Cisco UCCE 11,6
• MS SQL Server 2014

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Architektur

Die Funktion "Outbound Option High-Availability" (OOHA) wurde in Version UCCE 11.6 eingeführt. OOHA ist eine optionale Funktion. Der Campaign Manager-Prozess der UCCE-Version 11.6 kann mithilfe des Active-StandBy-Failover-Modells redundant ausgeführt werden. 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
• PCB
• Nicht_Anruf

UCCE 11.6 OOHA-Architektur

  

Übersicht über Failover-Modelle

Aktive Kampagnenmanager - StandBy

• Der aktive Campaign Manager-Prozess initiiert ein Failover, wenn standardmäßig keine DFÜ-Verbindung für mehr als 60 Sekunden besteht. Dieser Timer kann geändert werden, indem das Wort EMTClientTimeoutToFailover unter Protokollierung/BlendedAgent/CurrentVersion/Registrierungspfad hinzugefügt wird. Beim Wert muss es sich um eine Wartezeit für die Wählverbindung in Sekunden handeln.
• Kampagnen-Manager-Prozesse springen immer von A nach B und umgekehrt, wenn der Wähler keine Verbindung zu einem dieser Geräte herstellen kann.
• Das Failover für Campaign Manager kann bis zu 4,5 Minuten in Anspruch nehmen, wenn eine große Replikationswarteschlange zwischen BA-Datenbanken besteht. 4,5 Minuten sind ein hardcodierter Timer und können nicht geändert werden.

Dialer Active (Dialer aktiv) - StandBy

• Keine Änderungen gegenüber den vorherigen Versionen. Das DFÜ-Wählmodell bleibt unverändert, es ist jeweils nur ein Wähler aktiv.

BaImport - Kein Failover

• BaImport funktioniert nur mit dem lokalen Kampagnen-Manager-Prozess und repliziert seinen Status. Bei einem Absturz des BaImport-Prozesses wird ein Failover auf Kampagnen-Manager-Ebene 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 Logger-Server aktiviert ist, navigieren Sie zu SQL-Festplattenlaufwerk>setup.exe > Tools und führen Sie den Installed SQL Discovery Report aus.
• Wenn das Feature nicht im Bericht aufgeführt ist, führen Sie diesen Befehl im Windows CMD-Tool aus und geben Sie im entsprechenden Befehlsparameter den SQL Server-Instanznamen 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 Outbound-Option zu konfigurieren und die hohe Verfügbarkeit der Outbound-Option zu aktivieren.
• Der Benutzer muss nicht der SQL-Benutzer sein. Es kann ein anderer Benutzer sein, muss jedoch über eine sysadmin-Berechtigung verfügen und bleibt aktiviert.

        

Schritt 3: In SQL-Benutzer NT AUTHORITY\SYSTEM muss sysadmin Rolle haben. 

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 Logger-Servern.

Schritt 2: Konfigurieren des gleichen lokalen SQL-Benutzers mit der sysadmin-Rolle auf beiden Loggern

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

Hinweis: Stellen Sie sicher, dass Sie den Hostnamen von Loggers in den Feldern Public Interface (Öffentliche Protokollierung) angeben. Dieser Wert muss mit dem SQL-Servernamen in der entsprechenden Protokollierung übereinstimmen.

Nachdem das WebSetup erfolgreich abgeschlossen wurde, müssen Publication erstellt und LoggerA SQL Server und Subscribtion on LoggerB angezeigt werden.

Überprüfen Sie die Informationen im SQL Server Management Studio (SSMS) unter Replication > Lokale Veröffentlichungen auf LoggerA und auf Lokale AnmeldungenB.

Führen Sie WebSetup auf LoggerB aus, bearbeiten Sie die Protokollierungskomponente, und aktivieren Sie Outbound Option und Outbound High Availability.

Veröffentlichung muss auf LoggerB und Abonnement 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 LoggerA-Server erstellt wurden.

  

Fehlerbehebung

SQL Replication Health-Prüfung

Wählen Sie Replikationsmonitor-Tool von SSMS starten aus, um den Replikationsstatus zu überprüfen.

Der Replikationsstatus muss OK sein.

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

Navigieren Sie zur zweiten Registerkarte Tracer-Token, und wählen Sie Tracer einfügen aus. Dadurch wird die Latenz zwischen Publisher und Distributor sowie zwischen Distributor und Subscriber getestet.

Dies muss auf beiden Loggern überprüft werden.

Ändern des SQL-Servernamens 

Öffnen Sie SSMS, 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 Name des SQL-Servers nicht übereinstimmen. Stellen Sie sicher, dass das Problem vor der OO HA-Einrichtung behoben wird.

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

EXEC sp_dropserver @server=
     
     

Um einen neuen SQL-Servernamen hinzuzufügen, führen Sie diesen Befehl aus.

EXEC sp_addserver @server=
     
     
       , @local=LOCAL 
     

Starten Sie SQL Server und SQL Server Agent von Windows-Diensten aus, und überprüfen Sie die Ausgabe von auswählen @@servername SQL-Abfrage.

Manuelles Aktivieren der SQL-Replikation

Vorsicht: Verwenden Sie dieses Verfahren nur, wenn WebSetup nicht in der Lage ist, die Replikation aufzubauen, 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 der Fehler "CREATE DATABASE failed" (ERSTELLTE DATENBANK fehlgeschlagen) angezeigt wird, prüfen Sie, ob das MSSQLSERVER-Konto über vollständigen Zugriff auf das SQL-Arbeitsverzeichnis verfügt.

Dieses Image zeigt den entsprechenden Fehler in SQL-Serverprotokollen an. 

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

Stellen Sie sicher, dass Veröffentlichung und Abonnement auf jedem Logger-SQL-Server erstellt werden.

   

Manuelles Deaktivieren der SQL-Replikation

Vorsicht: Verwenden Sie dieses Verfahren nur, wenn WebSetup nicht in der Lage ist, die Replikation aufzubauen, und die Fehler nicht klar sind.

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

EXEC sp_ba_remove_replication 
@instance = 
     
     
       , @subscriber = 
       
     

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

Um SQL Server vollständig aus der Replikationskonfiguration zu löschen, müssen Sie manuell Subscriptions löschen und 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, indem die Fehlermeldung "Der Servername als Distributor Publisher kann nicht verworfen werden, da Datenbanken für die Replikation auf diesem Server aktiviert sind" angezeigt wird.

EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1

Zugehörige Informationen

• UCCE 11.6 - Leitfaden für Outbound-Optionen
• UCCE 11.6 Designleitfaden - Überlegungen zur Hochverfügbarkeit ausgehender Optionen
• Referenz zur SQL-Transaktionsreplikation
• Technischer Support und Dokumentation - Cisco Systems