Problembehandlung bei der CUCM-Datenbankreplikation

Einleitung

Dieses Dokument beschreibt die Diagnose von Datenbankreplikationsproblemen und enthält die erforderlichen Schritte zur Erkennung und Behebung dieser Probleme.

Schritte zur Diagnose der Datenbankreplikation

In diesem Abschnitt werden Szenarien beschrieben, in denen die Datenbankreplikation unterbrochen wird, und es wird die Fehlerbehebungsmethode beschrieben, um das Problem zu diagnostizieren und zu isolieren.

Schritt 1: Überprüfen, ob die Datenbankreplikation fehlerhaft ist

Um festzustellen, ob Ihre Datenbankreplikation fehlerhaft ist, müssen Sie die verschiedenen Status des Real Time Monitoring Tools (RTMT) für die Replikation kennen.

Führen Sie zum Überprüfen der Datenbankreplikation den Befehl utils dbreplication runtimestate über die CLI des Publisherknotens aus, wie in diesem Bild dargestellt. 

Stellen Sie sicher, dass der Clusterreplikationsstatus in der Ausgabe nicht die alten Synchronisierungsinformationen enthält. Überprüfen Sie den Wert, und verwenden Sie den Zeitstempel.

Wenn die Broadcast-Synchronisierung nicht mit einem aktuellen Datum aktualisiert wird, führen Sie den Befehl utils dbreplication status aus, um alle Tabellen und die Replikation zu überprüfen. Wenn Fehler/Nichtübereinstimmungen erkannt werden, werden diese in der Ausgabe angezeigt, und der RTMT-Status ändert sich entsprechend (siehe Abbildung).

o

Nachdem Sie den Befehl ausgeführt haben, werden alle Tabellen auf Konsistenz geprüft und ein genauer Replikationsstatus angezeigt.

Hinweis: Lassen Sie alle Tabellen überprüfen, und fahren Sie dann mit der Fehlerbehebung fort.

Sobald ein genauer Replikationsstatus angezeigt wird, überprüfen Sie die Replikations-Einrichtung (RTMT) und die Details, wie in der ersten Ausgabe dargestellt. Sie müssen den Status für jeden Knoten überprüfen. Wenn ein Knoten einen anderen Status als 2 hat, fahren Sie mit der Fehlerbehebung fort.

Schritt 2: CM-Datenbankstatus von der Seite "Cisco Unified Reporting" auf CUCM erfassen

1. Wenn Sie Schritt 1 abgeschlossen haben, wählen Sie die Cisco Unified Reporting-Option aus der Dropdown-Liste Navigation im CUCM-Publisher (Cisco Unified Communications Manager) aus, wie in diesem Bild dargestellt.

2. Navigieren Sie zu Systemberichte, und klicken Sie auf Unified CM Database Status (Unified CM-Datenbankstatus), wie in dieser Abbildung dargestellt.

3. Erstellen Sie einen neuen Bericht, klicken Sie auf das Symbol Neuen Bericht erstellen, wie in diesem Bild dargestellt.

4. Warten Sie, bis der neue Bericht erfolgreich erstellt wurde.

5. Klicken Sie nach der Erstellung auf das Symbol, um den Bericht herunterzuladen und zu speichern, damit er einem TAC-Techniker bereitgestellt werden kann, falls ein Serviceticket (SR) geöffnet werden muss.

Schritt 3: Überprüfen Sie den Unified CM-Datenbankbericht aller Komponenten, die als Fehler gekennzeichnet sind.

Wenn die Komponenten Fehler enthalten, sind diese mit einem roten X gekennzeichnet, wie in dieser Abbildung gezeigt.

• Stellen Sie sicher, dass auf lokale Datenbanken und Publisher-Datenbanken zugegriffen werden kann.

• Überprüfen Sie im Fall eines Fehlers die Netzwerkverbindungen zwischen den Knoten. Überprüfen Sie, ob der Cisco DB-Dienst A über die CLI des Knotens ausgeführt wird und den Befehl utils service list verwendet.

• Wenn der Cisco DB-Dienst nicht aktiv ist, führen Sie den Befehl utils service start A Cisco DB aus, um ihn zu starten. Wenn dies fehlschlägt, wenden Sie sich an das Cisco TAC.     

• Stellen Sie sicher, dass Replication Server List (cdr list serv) für alle Knoten ausgefüllt ist.

Dieses Bild stellt eine ideale Ausgabe dar.

 Wenn die Cisco Database Replicator (CDR)-Liste für einige Knoten leer ist, fahren Sie mit Schritt 8 fort.

• Stellen Sie sicher, dass die Unified CM-Hosts, Rhosts und Sqlhosts auf allen Knoten gleich sind.

Dies ist ein wichtiger Schritt. Wie in dieser Abbildung dargestellt, sind die Unified CM-Hosts, die Rhosts und die Sqlhosts auf allen Knoten gleichwertig.

Die Hosts-Dateien stimmen nicht überein:

Wenn sich eine IP-Adresse ändert oder der Hostname auf dem Server aktualisiert wird, kann eine falsche Aktivität vorliegen.

Unter diesem Link können Sie die IP-Adresse in den Hostnamen für den CUCM ändern.

Änderungen der IP-Adresse und des Hostnamens

Starten Sie diese Dienste über die CLI des Publisher-Servers neu, und überprüfen Sie, ob die Inkongruenz behoben ist. Wenn ja, fahren Sie mit Schritt 8 fort. Falls nein, wenden Sie sich an das Cisco TAC. Generieren Sie bei jeder Änderung an der GUI/CLI einen neuen Bericht, um zu überprüfen, ob die Änderungen übernommen wurden.

Cluster Manager ( utils service restart Cluster Manager) 
A Cisco DB ( utils service restart A Cisco DB)

Die Rhosts-Dateien stimmen nicht überein:

Wenn die Rhosts-Dateien und die Host-Dateien nicht übereinstimmen, befolgen Sie die Schritte unter „Die Hosts-Dateien stimmen nicht überein“. Wenn nur die Rhosts-Dateien nicht übereinstimmen, führen Sie die Befehle über die CLI aus:

A Cisco DB ( utils service restart A Cisco DB )
Cluster Manager ( utils service restart Cluster Manager)

Generieren Sie einen neuen Bericht, und überprüfen Sie, ob die Rhost-Dateien auf allen Servern gleich sind. Wenn ja, fahren Sie mit Schritt 8 fort. Falls nein, wenden Sie sich an das Cisco TAC.

Die Sqlhosts stimmen nicht überein:

Wenn die Sqlhosts und die Host-Dateien nicht übereinstimmen, befolgen Sie die Schritte unter „Die Hosts-Dateien stimmen nicht überein“. Wenn nur die Sqlhosts-Dateien nicht übereinstimmen, führen Sie folgenden Befehl über die CLI aus:

utils service restart A Cisco DB

Generieren Sie einen neuen Bericht, und überprüfen Sie, ob die Sqlhost-Dateien auf allen Servern gleichwertig sind. Wenn ja, fahren Sie mit Schritt 8 fort. Falls nein, wenden Sie sich an das Cisco TAC

• Stellen Sie sicher, dass der DBL-RPC-Hello (Database Layer Remote Procedural Call/Remoteprozeduraufruf auf Datenbankebene) erfolgreich ist (siehe Abbildung).

  Wenn der RPC-Hello für einen bestimmten Knoten nicht funktioniert:

• Stellen Sie sicher, dass eine Netzwerkverbindung zwischen dem jeweiligen Knoten und dem Publisher besteht.
• Stellen Sie sicher, dass die Portnummer 1515 im Netzwerk erlaubt ist.

Unter diesem Link finden Sie Details zur Verwendung von TCP-/UDP-Ports:

Cisco Unified Communications Manager TCP and UDP Port Usage (TCP- und UDP-Port-Nutzung in Cisco Unified Communications Manager)

• Stellen Sie sicher, dass die Netzwerkverbindung zwischen den Knoten erfolgreich ist (siehe Abbildung):

Wenn die Netzwerkverbindung für die Knoten ausfällt:

• Stellen Sie sicher, dass die Netzwerkerreichbarkeit zwischen den Knoten vorhanden ist.
• Stellen Sie sicher, dass die entsprechenden TCP-/UDP-Portnummern im Netzwerk zulässig sind.

Generieren Sie einen neuen Bericht, und überprüfen Sie, ob die Verbindung erfolgreich hergestellt wurde. Wenn die Verbindung nicht hergestellt werden konnte, fahren Sie mit Schritt 8 fort.

Schritt 4: Überprüfen Sie die einzelnen Komponenten, die den Utils Diagnose-Testbefehl verwenden.

Der Befehl utils diagnostize test überprüft alle Komponenten und gibt als Wert „passed/failed“ (bestanden/fehlgeschlagen) zurück. Folgende Komponenten sind für das ordnungsgemäße Funktionieren der Datenbankreplikation essenziell:

• Netzwerkkonnektivität:

Der Befehl validate_network überprüft alle Aspekte der Netzwerkverbindung mit allen Knoten im Cluster. Wenn ein Verbindungsproblem vorliegt, wird häufig ein Fehler auf dem Domain Name Server/Reverse Domain Name Server (DNS/RDNS) angezeigt. Mit dem Befehl validate_network wird der Vorgang in 300 Sekunden abgeschlossen. Die häufigsten Fehlermeldungen aus den Netzwerkverbindungstests:

1. Fehler "Kommunikation innerhalb des Clusters unterbrochen", wie in diesem Bild dargestellt.

• Ursache

Dieser Fehler wird verursacht, wenn ein oder mehrere Knoten im Cluster ein Netzwerkverbindungsproblem haben. Stellen Sie sicher, dass alle Knoten über Ping erreichbar sind.

• Wirkung

Wenn die Kommunikation innerhalb des Clusters unterbrochen wird, treten Probleme bei der Datenbankreplikation auf.

2. Fehler bei der umgekehrten DNS-Suche.

• Ursache

Dieser Fehler wird verursacht, wenn die umgekehrte DNS-Suche auf einem Knoten fehlschlägt. Sie können jedoch überprüfen, ob der DNS konfiguriert ist und ordnungsgemäß funktioniert, wenn Sie die folgenden Befehle verwenden:

utils network eth0 all - Shows the DNS configuration (if present)
utils network host <ip address/Hostname> - Checks for resolution of ip address/Hostname

• Wirkung

Wenn der DNS nicht ordnungsgemäß funktioniert, kann es bei der Definition der Server und der Verwendung der Hostnamen zu Problemen mit der Datenbankreplikation kommen.

• NTP-Erreichbarkeit (Netzwerkzeit-Protokoll):

Das NTP ist dafür verantwortlich, die Uhrzeit des Servers mit der Referenzuhr zu synchronisieren. Der Publisher synchronisiert die Uhrzeit immer mit dem Gerät, dessen IP-Adresse als NTP-Server aufgeführt ist, während die Subscriber die Uhrzeit mit dem Publisher synchronisieren.

Es ist äußerst wichtig, dass das NTP voll funktionsfähig ist, um Probleme bei der Datenbankreplikation zu vermeiden.

Es ist wichtig, dass die NTP-Schicht (Anzahl der Hops zum übergeordneten Referenzuhr) kleiner als 5 ist, da sie sonst als unzuverlässig gilt.

Gehen Sie folgendermaßen vor, um den NTP-Status zu überprüfen:

1. Verwenden Sie den Befehl utils diagnose test, um die Ausgabe zu überprüfen, wie in dieser Abbildung dargestellt.

  2. Außerdem können Sie den folgenden Befehl ausführen:

utils ntp status

Schritt 5: Überprüfen des Verbindungsstatus aller Knoten – dabei sicherstellen, dass sie authentifiziert sind

1. Wenn nach Abschluss von Schritt 4 keine Probleme gemeldet werden, führen Sie den Befehl utils network connectivity auf allen Knoten aus, um zu überprüfen, ob die Verbindung zu den Datenbanken erfolgreich ist (siehe Abbildung).

2. Wenn Sie als Fehlermeldung "TCP/UDP-Pakete können nicht gesendet werden" erhalten, überprüfen Sie Ihr Netzwerk auf Neuübertragungen oder blockieren Sie die TCP/UDP-Ports. Der Befehl show network cluster überprüft die Authentifizierung aller Knoten.

3. Wenn der Status des Knotens nicht authentifiziert ist, stellen Sie sicher, dass die Netzwerkverbindung und das Sicherheitskennwort auf allen Knoten identisch sind, wie in diesem Bild gezeigt.

Über die Links können Sie die Sicherheitskennwörter ändern/wiederherstellen:

So setzen Sie Kennwörter auf CUCM zurück

Wiederherstellung des CUCM-Betriebssystemadministrator-Passworts

Schritt 6: Der Befehl „utils dbreplication runtimestate“ zeigt den Status als asynchron oder nicht angefordert an

Sie müssen wissen, dass die Datenbankreplikation eine netzwerkintensive Aufgabe ist, da sie die tatsächlichen Tabellen an alle Knoten im Cluster weiterleitet. Stellen Sie Folgendes sicher:

•  Die Knoten befinden sich im gleichen Rechenzentrum/Standort: Alle Knoten sind mit einer niedrigeren Round-Trip Time (RTT) erreichbar. Wenn der RTT-Wert ungewöhnlich hoch ist, überprüfen Sie die Netzwerkleistung.

•  Die Knoten sind über das Wide Area Network (WAN) verteilt: Stellen Sie sicher, dass die Knoten über Netzwerkverbindungen mit deutlich unter 80 ms verfügen. Wenn einige Knoten nicht in der Lage sind, sich am Replikationsprozess zu beteiligen, erhöhen Sie den Parameter wie gezeigt auf einen höheren Wert.

utils dbreplication setprocess <1-40>

Hinweis: Wenn Sie diesen Parameter ändern, verbessert er die Performance der Replikations-Einrichtung, beansprucht jedoch zusätzliche Systemressourcen.

• Das Replikations-Timeout basiert auf der Anzahl der Knoten im Cluster: Das Replikations-Timeout (Standard: 300 Sekunden) ist die Zeit, die der Publisher auf alle Subscriber wartet, um ihre definierten Nachrichten zu senden. Berechnen Sie das Replikations-Timeout basierend auf der Anzahl der Knoten im Cluster.

Server 1-5 = 1 Minute Per Server Servers 6-10  = 2 Minutes Per Server Servers >10 = 3 Minutes Per Server.

Example: 12 Servers in Cluster : Server 1-5 * 1 min = 5 min, + 6-10 * 2 min = 10 min, + 11-12 * 3 min = 6 min,  
Repltimeout should be set to 21 Minutes.

Befehle zum Überprüfen/Festlegen des Replikations-Timeouts:

show tech repltimeout ( To check the current replication timeout value )
utils dbreplication setrepltimeout ( To set the replication timeout )

Die Schritte 7 und 8 müssen ausgeführt werden, wenn die Checkliste erfüllt ist:

Checkliste:

• Alle Knoten sind miteinander verbunden. Siehe Schritt 5.

• RPC ist erreichbar. Siehe Schritt 3.

• Konsultieren Sie das Cisco TAC, bevor Sie mit den Schritten 7 und 8 fortfahren, falls der Knoten größer als 8 ist.

• Führen Sie das Verfahren außerhalb der Geschäftszeiten durch.

Schritt 7. Reparieren aller/selektiver Tabellen für die Datenbankreplikation

Wenn der Befehl utils dbreplication runtimestate anzeigt, dass es Tabellen mit Fehlern/nicht übereinstimmende Tabellen gibt, führen Sie folgenden Befehl aus:

Utils dbreplication repair all

Führen Sie den Befehl utils dbreplication runtimestate aus, um den Status erneut zu überprüfen.

Fahren Sie mit Schritt 8 fort, wenn sich der Status nicht ändert.

Schritt 8: Zurücksetzen der Datenbankreplikation von Grund auf

Informationen zum Zurücksetzen der Datenbankreplikation und zum Starten des Prozesses von Grund auf finden Sie in der Sequenz.

utils dbreplication stop all  (Only on the publisher)
utils dbreplication dropadmindb (First on all the subscribers one by one then the publisher)
utils dbreplication reset all ( Only on the publisher )

Um den Prozess zu überwachen, führen Sie den Befehl RTMT/utils dbreplication runtimestate aus.

Beachten Sie die Reihenfolge zum Zurücksetzen der Datenbankreplikation für einen bestimmten Knoten:

utils dbreplication stop <sub name/IP> (Only on the publisher)
utils dbreplcation dropadmindb (Only on the affected subscriber)
utils dbreplication reset <sub name/IP> (Only on the publisher )

Falls Sie das Cisco TAC für weitere Unterstützung erreichen, stellen Sie sicher, dass die folgenden Ergebnisse und Berichte bereitgestellt werden:

utils dbreplication runtimestate
utils diagnose test
utils network connectivity

Berichte:

• Der Cisco Unified Reporting CM-Datenbankbericht (siehe Schritt 2).

• Der Befehl utils create report database aus der CLI. Laden Sie die TAR-Datei herunter und verwenden Sie einen SFTP-Server.

Zugehörige Informationen

• Die Ausgabe von utils dbreplication runtime-state für CUCM
• Troubleshooting CUCM Database Replication Linux Appliance Model (Fehlerbehebung bei der CUCM-Datenbankreplikation im Linux-Appliance-Modell)
• Datenschutz und Privatsphäre bei CX-Bereitstellung