In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird beschrieben, wie der Publisher-Knoten von Cisco Unified Communications Manager (CUCM) ohne vorherige Sicherung oder Root-Zugriff aus der Subscriber-Datenbank wiederhergestellt wird.
In früheren Versionen von CUCM wurde der Publisher-Knoten als einzige autoritative Quelle für die SQL-Datenbank (Structured Query Language) angesehen.
Wenn also ein Publisher-Knoten aufgrund eines Hardwarefehlers oder einer Beschädigung des Dateisystems verloren ging, war die einzige Möglichkeit, ihn wiederherzustellen, die Neuinstallation und Wiederherstellung der DB über ein DRS-Backup (Disaster Recovery System).
Einige Kunden hatten keine ordnungsgemäßen Sicherungen oder veraltete Sicherungen. Daher bestand die einzige Option darin, den Publisher-Serverknoten neu zu erstellen und zu konfigurieren.
In CUCM-Version 8.6(1) wurde eine neue Funktion eingeführt, um eine Publisher-DB aus einer Subscriber-Datenbank wiederherzustellen.
In diesem Dokument wird beschrieben, wie Sie diese Funktion nutzen können, um eine Publisher-DB vom Abonnenten erfolgreich wiederherzustellen.
Cisco empfiehlt dringend, eine vollständige DRF-Sicherung (Disaster Recovery Framework) für den gesamten Cluster zu erstellen.
Da bei diesem Prozess nur die CUCM-DB-Konfiguration wiederhergestellt wird, werden andere Daten wie Zertifikate, Warteschleifenmusik (Music on Hold, MoH) und TFTP-Dateien nicht wiederhergestellt. Um diese Probleme zu vermeiden, sollten Sie ein vollständiges DRF-Backup für den Cluster beibehalten.
Hinweis: Cisco empfiehlt, den gesamten in diesem Dokument beschriebenen Prozess vor Beginn zu überprüfen und sich mit diesem vertraut zu machen.
Vor der Neuinstallation des Publishers müssen Sie unbedingt die relevanten Details zum vorherigen Publisher sammeln. Diese Angaben müssen mit der ursprünglichen Herausgeberinstallation übereinstimmen:
Um die ersten drei Elemente in der Liste abzurufen, geben Sie den Befehl show network cluster in der aktuellen Subscriber-Knoten-CLI ein:
admin:show network cluster
172.18.172.213 cucm911ccnasub1 Subscriber authenticated
172.18.172.212 cucm911ccnapub Publisher not authenticated - INITIATOR
since Tue Dec 3 12:43:24 2013
172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
Sun Dec 1 17:14:58 2013
In diesem Fall lautet die IP-Adresse 172.18.172.212, der Hostname lautet cucm911ccnapub, und es ist kein Domänenname für den Herausgeber konfiguriert.
Die Sicherheits-Passphrase (das vierte Element in der Liste) wird aus der Standortdokumentation abgerufen.
Wenn Sie sich über die Sicherheits-Passphrase nicht sicher sind, raten Sie nach bestem Wissen, und versuchen Sie, sie basierend auf der CUCM-Version nach Bedarf zu überprüfen und zu korrigieren.
Wenn die Sicherheits-Passphrase falsch ist, ist ein Clusterausfall erforderlich, um die Situation zu korrigieren.
Um die genaue CUCM-Version und die installierten COP-Dateien (die letzten beiden Elemente in der Liste) abzurufen, rufen Sie die Systemausgabe mit dem Befehl show version active auf:
admin:show version active
Active Master Version: 9.1.2.10000-28
Active Version Installed Software Options:
No Installed Software Options Found.
In diesem Fall wird Version 9.1.2.10000-28 ohne zusätzliche COP-Dateien installiert.
Hinweis: Es ist möglich, dass einige COP-Dateien zuvor auf dem Publisher installiert wurden, jedoch nicht auf dem Subscriber installiert wurden und umgekehrt. Verwenden Sie diese Ausgabe nur als Richtlinie.
Wenn der Publisher installiert ist, ist es wichtig, dass die Replikation die aktuellen Subscriber-DBs nicht konfiguriert und löscht. Um dies zu verhindern, geben Sie den Befehl utils dbreplication stop auf allen Abonnenten ein:
admin:utils dbreplication stop
********************************************************************************
This command can delete the marker file(s) so that automatic replication setup
is stopped
It can also stop any replication setup currently executing
********************************************************************************
Deleted the marker file, auto replication setup is stopped
Service Manager is running
Commanded Out of Service
A Cisco DB Replicator[NOTRUNNING]
Service Manager is running
A Cisco DB Replicator[STARTED]
Completed replication process cleanup
Please run the command 'utils dbreplication runtimestate' and make sure all nodes
are RPC reachable before a replication reset is executed
Erstellen Sie ein bootfähiges Image der entsprechenden Version, und führen Sie eine Installation mit einem Upgrade auf die entsprechende Version durch.
Hinweis: Die meisten CUCM Engineering Special (ES)-Versionen sind bereits bootfähig.
Installieren Sie den Publisher, und geben Sie die korrekten Werte für die zuvor erwähnte IP-Adresse, den Hostnamen, den Domänennamen und die Sicherheits-Passphrase an.
Hinweis: Der Publisher muss mindestens einen Subscriber-Server kennen, um die DB von diesem Subscriber wiederherzustellen. Cisco empfiehlt, alle Teilnehmer hinzuzufügen.
Um die Knotenliste abzurufen, geben Sie den Befehl run sql select name,description,nodeid aus processNode in der CLI eines aktuellen Subscribers ein.
Bei den Namenswerten kann es sich um Hostnamen, IP-Adressen oder FQDNs (Fully Qualified Domain Names) handeln.
Wenn Sie CUCM Version 10.5(2) oder höher ausführen, muss der Befehl utils disaster_recovery prepare restore pub_from_sub auf der Publisher-CLI ausgeführt werden, bevor Sie System > Server Knoten hinzufügen können:
Warnung: Viele Benutzer, die CUCM-Version 10.5(2) oder höher verwenden, überspringen den Befehl utils disaster_recovery prepare restore pub_from_sub. Dies ist jedoch ein kritischer Befehl. Überspringen Sie keine der in diesem Dokument beschriebenen Schritte.
Nachdem Sie die Knotenliste erhalten haben, navigieren Sie zu System > Server und fügen Sie alle anderen Namenswerte als EnterpriseWideData zur Seite Unified CM-Verwaltung von Publisher Server hinzu.
Die Namenswerte müssen dem Feld Hostname/IP-Adresse im Menü System > Server entsprechen.
admin:run sql select name,description,nodeid from processnode
name description nodeid
================== =============== ======
EnterpriseWideData 1
172.18.172.212 CUCM901CCNAPub 2
172.18.172.213 CUCM901CCNASub1 3
172.18.172.214 CUCM901CCNASub2 4
Hinweis: Bei der Standardinstallation wird der Hostname des Herausgebers zur Prozessknotentabelle hinzugefügt. Sie können sie in eine IP-Adresse ändern, wenn in der Namensspalte eine IP-Adresse für den Herausgeber aufgeführt ist. Entfernen Sie in diesem Fall nicht den Herausgebereintrag, sondern öffnen und ändern Sie das aktuelle Feld Hostname/IP-Adresse.
Um den Publisher nach Abschluss der Änderungen am Prozessknoten neu zu starten, geben Sie den Befehl utils system restart ein:
admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes
Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.
Shutting down Service Manager. Please wait...
\Service Manager shutting down services... Please Wait
Broadcast message from root (Tue Dec 3 14:29:09 2013):
The system is going down for reboot NOW!
Waiting .
Operation succeeded
Wenn Sie nach dem Neustart des Publishers die Änderungen ordnungsgemäß durchgeführt haben und die Sicherheits-Passphrase korrekt ist, muss sich der Cluster im authentifizierten Zustand befinden. Um dies zu überprüfen, geben Sie den Befehl show network cluster ein:
admin:show network cluster
172.18.172.212 cucm911ccnapub Publisher authenticated
172.18.172.213 cucm911ccnasub1 Subscriber authenticated using TCP since
Tue Dec 3 14:24:20 2013 172.18.172.214 cucm911ccnasub2 Subscriber authenticated using TCP since
Tue Dec 3 14:25:09 2013
Hinweis: Wenn die Abonnenten nicht als authentifiziert angezeigt werden, lesen Sie den Abschnitt Fehlerbehebung in diesem Dokument, um dieses Problem zu beheben, bevor Sie fortfahren.
Wenn keine vorherige Sicherung verfügbar ist, führen Sie auf der Seite DRS eine Cluster-Sicherung durch.
Hinweis: Sie können zwar die Subscriber-DB für die Wiederherstellung verwenden, es ist jedoch weiterhin ein Backup erforderlich, um die Nicht-DB-Komponenten wiederherzustellen.
Wenn keine Sicherung verfügbar ist, führen Sie eine neue Sicherung durch. Wenn bereits eine Sicherung vorhanden ist, können Sie diesen Abschnitt überspringen.
Verwenden Sie das Navigationsmenü, um zum Disaster Recovery System zu navigieren und ein Backup-Gerät hinzuzufügen.
Starten Sie nach dem Hinzufügen des Sicherungsgeräts eine manuelle Sicherung.
Hinweis: Es ist wichtig, dass die CCMDB-Komponente auf dem Publisher-Knoten registriert ist.
Navigieren Sie auf der Seite Disaster Recovery System (Notfallwiederherstellungssystem) zu Restore > Restore Wizard (Wiederherstellen > Wiederherstellen-Assistent).
Wenn eine aktuelle Sicherung verfügbar war und Sie den vorherigen Abschnitt übersprungen haben, aktivieren Sie alle Kontrollkästchen im Abschnitt Funktionen auswählen: Enterprise License Manager (ELM) falls verfügbar, CDR_CAR und Unified Communications Manager (UCM).
Wenn Sie eine Sicherung verwenden, die im vorherigen Abschnitt durchgeführt wurde, aktivieren Sie nur das Kontrollkästchen UCM:
Klicken Sie auf Next (Weiter). Aktivieren Sie das Kontrollkästchen Publisher-Knoten (CUCM911CCNAPUB), und wählen Sie die Subscriber-DB aus, von der die Wiederherstellung erfolgt. Klicken Sie dann auf Wiederherstellen.
Wenn die Wiederherstellung die CCMDB-Komponente erreicht, muss der Text "Status" als "Wiederherstellen des Verlegers von der Abonnentensicherung" angezeigt werden:
Vor dem Neustart und der Einrichtung der Replikation sollten Sie überprüfen, ob die Wiederherstellung erfolgreich ist und ob die Publisher-DB die erforderlichen Informationen enthält.
Stellen Sie sicher, dass diese Abfragen auf den Publisher- und Subscriber-Knoten dieselben Werte zurückgeben, bevor Sie fortfahren:
Nachdem die Wiederherstellung abgeschlossen ist, geben Sie den Befehl utils system restart auf jedem Knoten ein. Beginnen Sie mit dem Herausgeber gefolgt von jedem Abonnenten.
admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes
Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.
Shutting down Service Manager. Please wait...
\ Service Manager shutting down services... Please Wait
Broadcast message from root (Tue Dec 3 14:29:09 2013):
The system is going down for reboot NOW!
Waiting .
Operation succeeded
Navigieren Sie zur Seite Cisco Unified Reporting, und generieren Sie einen Unified CM-Datenbank-Statusbericht.
Es ist wahrscheinlich, dass die Replikation noch nicht eingerichtet werden kann, aber es ist wichtig, sicherzustellen, dass die Dateien für Unified CM-Hosts, Unified CM-Rhosts und Unified CM-Sqlhosts mit dem Herausgeber übereinstimmen.
Wenn dies nicht der Fall ist, müssen die Knoten, die nicht übereinstimmen, erneut gestartet werden. Wenn diese Dateien nicht übereinstimmen, fahren Sie nicht mit dem nächsten Schritt fort, oder setzen Sie die Replikation zurück.
Je nach Version kann die Replikation nicht automatisch eingerichtet werden. Um dies zu überprüfen, warten Sie, bis alle Dienste gestartet sind, und geben Sie den Befehl utils dbreplication runtimestate ein.
Ein Statuswert von 0 gibt an, dass die Einrichtung ausgeführt wird, während ein Wert von 2 angibt, dass die Replikation für diesen Knoten erfolgreich eingerichtet wurde.
Diese Ausgabe zeigt an, dass die Replikationseinrichtung ausgeführt wird (der Zustand wird für zwei der Knoten als 0 angezeigt):
Diese Ausgabe zeigt an, dass die Replikation erfolgreich eingerichtet wurde:
Wenn Knoten mit einem Statuswert von 4 angezeigt werden oder wenn die Replikation nach mehreren Stunden nicht erfolgreich eingerichtet wurde, geben Sie den Befehl utils dbreplication reset all (Alle zurücksetzen) vom Publisher-Knoten ein.
Wenn die Replikation weiterhin fehlschlägt, finden Sie im Cisco Artikel Troubleshooting CUCM Database Replication in Linux Appliance Model weitere Informationen zur Fehlerbehebung.
Da bei der DB-Wiederherstellung nicht alle vorherigen Komponenten wiederhergestellt werden, müssen viele Elemente auf Serverebene manuell installiert oder wiederhergestellt werden.
Bei der DRF-Wiederherstellung werden keine Dienste aktiviert. Navigieren Sie zu Tools > Service Activation, und aktivieren Sie alle erforderlichen Services, die der Herausgeber ausführen muss. Verwenden Sie hierzu die Standortdokumentation auf der Seite Unified Serviceability:
Wenn kein vollständiges Backup verfügbar war, müssen Sie bestimmte manuelle Konfigurationen reproduzieren. Insbesondere die Konfigurationen, die Zertifikate und TFTP-Funktionen beinhalten:
Hinweis: Bei Clustern im gemischten Modus müssen Sie den CTL-Client (Certificate Trust List) erneut ausführen.
In diesem Abschnitt werden verschiedene Szenarien beschrieben, die dazu führen können, dass diese Prozedur fehlschlägt.
Wenn sich der Cluster nicht authentifiziert, sind die beiden häufigsten Ursachen nicht übereinstimmende Sicherheits-Passphrasen und Verbindungsprobleme am TCP-Port 8500.
Um zu überprüfen, ob die Cluster-Sicherheits-Passphrasen übereinstimmen, geben Sie den Befehl utils create report platform in der CLI beider Knoten ein, und überprüfen Sie den Hashwert aus der Datei platformConfig.xml. Diese müssen auf den Publisher- und Subscriber-Knoten übereinstimmen.
<IPSecSecurityPwCrypt>
<ParamNameText>Security PW for this node</ParamNameText>
<ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
12812AB2825C831812812AB2825C </ParamValue>
</IPSecSecurityPwCrypt>
Wenn diese übereinstimmen, überprüfen Sie die TCP-Verbindung an Port 8500. Wenn sie nicht übereinstimmen, kann es aufgrund mehrerer Fehler im CUCM-Code, die das Verfahren umgeben, zu Schwierigkeiten beim Versuch kommen, die Passphrase zu reparieren:
Wenn die CUCM-Version Korrekturen für alle diese Probleme enthält, besteht die einfachste Lösung darin, das im Cisco Unified Communications Operating System Administration Guide, Release 10.0(1) beschriebene Verfahren zur Kennwortwiederherstellung auf allen Knoten abzuschließen.
Wenn die CUCM-Version keine Korrekturen für diese Probleme enthält, kann das Cisco Technical Assistance Center (TAC) je nach Situation eine Problemumgehung durchführen.
Wenn die DB-Komponente bei der Wiederherstellung nicht aufgeführt wird, enthält die Sicherung selbst möglicherweise keine DB-Komponente. Stellen Sie sicher, dass die Publisher-DB ausgeführt wird und Abfragen annehmen kann, und führen Sie eine neue Sicherung durch.
Weitere Informationen zur Fehlerbehebung bei Replikationsfehlern finden Sie im Artikel Troubleshooting CUCM Database Replication in Linux Appliance Model Cisco.
Da bei der DB-Wiederherstellung keine Zertifikate wiederhergestellt werden, ist der Signierer unterschiedlich, wenn der Publisher der primäre TFTP-Server ist.
Wenn die Telefone den Zertifikaten des Subscriber Trust Verification Service (TVS) vertrauen und der TCP-Port 2445 zwischen den Telefonen und den TVS-Servern geöffnet ist, muss das Problem automatisch behoben werden.
Aus diesem Grund empfiehlt Cisco die Beibehaltung vollständiger DRF-Cluster-Backups.
Aufgrund der Cisco Bug-ID CSCtn50405 können bei CUCM-Versionen vor Version 8.6 auch Zertifikatsprobleme auftreten, selbst wenn zuvor eine erfolgreiche Sicherung durchgeführt wurde.
Hinweis: Weitere Informationen zur Fehlerbehebung bei ITL-Dateien (Initial Trust List) finden Sie im Artikel Communications Manager Security By Default und ITL Operation and Troubleshooting Cisco.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
11-Oct-2023 |
Erstveröffentlichung |