CUCM Publisher vom Abonnenten neu erstellen

Einleitung

In diesem Dokument wird beschrieben, wie Sie den Publisher-Knoten von Cisco Unified Communications Manager (CUCM) ohne vorherige Sicherung aus einer Subscriber-Datenbank wiederherstellen.

Hintergrund

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.

Anmerkung: Cisco empfiehlt, dass Sie den gesamten in diesem Dokument beschriebenen Prozess lesen und sich mit diesem vertraut machen, bevor Sie beginnen.

Sammeln von Cluster-Daten

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:

• IP-Adresse
• Host-Name
• Domänenname
• Sicherheits-Kennzeichenfolge
• Genaue CUCM-Version
• Installierte Cisco Options Package (COP)-Dateien

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. 

Anmerkung: Es ist möglich, dass einige COP-Dateien zuvor auf dem Publisher installiert wurden, aber nicht auf dem Subscriber installiert wurden, und umgekehrt. Verwenden Sie diese Ausgabe nur als Richtlinie.

Replikation auf allen Abonnenten beenden

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

Installation von CUCM Publisher

Erstellen Sie ein bootfähiges Image der entsprechenden Version, und führen Sie eine Installation mit einem Upgrade auf die entsprechende Version durch.

Anmerkung: 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. 

Prozessknotenwerte auf dem Verleger aktualisieren

Anmerkung: 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; Hierbei handelt es sich jedoch um einen wichtigen 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

Anmerkung: 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. 

Publisher-Knoten neu starten

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

Cluster-Authentifizierung überprüfen

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

Anmerkung: Wenn die Abonnenten nicht als authentifiziert angezeigt werden, lesen Sie den Abschnitt Fehlerbehebung in diesem Dokument, um dieses Problem zu beheben, bevor Sie fortfahren.

Neue Sicherung durchführen

Wenn keine vorherige Sicherung verfügbar ist, führen Sie auf der Seite DRS eine Cluster-Sicherung durch.

Anmerkung: Obwohl Sie die Subscriber-DB für die Wiederherstellung verwenden können, ist weiterhin ein Backup erforderlich, um die Nicht-DB-Komponenten wiederherzustellen.

Wenn kein Backup verfügbar ist, führen Sie ein neues aus. Wenn bereits eine Sicherung vorhanden ist, können Sie diesen Abschnitt überspringen.

Hinzufügen eines Sicherungsgeräts

Verwenden Sie das Navigationsmenü, um zum Disaster Recovery System zu navigieren und ein Backup-Gerät hinzuzufügen.

Starten einer manuellen Sicherung

Starten Sie nach dem Hinzufügen des Sicherungsgeräts eine manuelle Sicherung.

Anmerkung: Es ist wichtig, dass die CCMDB-Komponente auf dem Publisher-Knoten registriert ist.

Publisher-Wiederherstellung von der Abonnenten-DB

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.

Status wiederherstellen

Wenn die Wiederherstellung die CCMDB-Komponente erreicht, muss der Text "Status" als "Wiederherstellen des Verlegers von der Abonnentensicherung" angezeigt werden:

Führen Sie eine Integritätsprüfung auf der Publisher-DB durch.

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:

• sql select count(*) vom Gerät ausführen
• sql select count(*) vom Endbenutzer ausführen

Cluster neu starten

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

Überprüfung der Replikations-Setup-Anforderungen

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.

Replikations-Setup

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. 

Nach der Wiederherstellung

Da bei der DB-Wiederherstellung nicht alle vorherigen Komponenten wiederhergestellt werden, müssen viele Elemente auf Serverebene manuell installiert oder wiederhergestellt werden.

Services aktivieren

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:

Daten installieren, die nicht wiederhergestellt wurden

Wenn kein vollständiges Backup verfügbar war, müssen Sie bestimmte manuelle Konfigurationen reproduzieren. Insbesondere die Konfigurationen, die Zertifikate und TFTP-Funktionen beinhalten:

• Warteschleifenmusik-Dateien
• Gerätepakete
• Wählpläne (für NANP-Wählverfahren (nicht für Nordamerika)
• Gebietsschemata
• Sonstige COP-Dateien
• Alle Dateien, die zuvor manuell in den Publisher hochgeladen wurden (falls es sich um einen TFTP-Server handelte)
• Simple Network Management Protocol (SNMP) Community Strings
• Massenexporte von Zertifikaten für Extension Mobility Cross Cluster (EMCC), Intercluster Location Bandwidth Manager (LBM) und Intercluster Lookup Service (ILS)
• Zertifikataustausch für sichere Trunks, Gateways und Konferenzbrücken

Anmerkung: Bei Clustern im gemischten Modus müssen Sie den CTL-Client (Certificate Trust List) erneut ausführen.

Fehlerbehebung

In diesem Abschnitt werden verschiedene Szenarien beschrieben, die dazu führen können, dass diese Prozedur fehlschlägt.

Cluster wird nicht authentifiziert

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:

• Cisco Bug-ID CSCtn79868 - pwrecovery tool setzt nur sftpuser-Passwort zurück
• Cisco Bug-ID CSCug92142 - Das pwrecovery-Tool aktualisiert die internen Benutzerkennwörter nicht
• Cisco Bug-ID CSCug97360 - selinux denials im Dienstprogramm pwrecovery
• Cisco Bug-ID CSCts10778 - Abgelehnt für Sicherheit Passwort Wiederherstellung Verfahren
• Cisco Bug-ID CSCua09290 - CLI "set password user security" (Benutzersicherheit festlegen) hat nicht das richtige Kennwort für Apps festgelegt
• Cisco Bug-ID CSCtx4528 - pwd reset cli ergibt gute, ändert aber Kennwort nicht
• Cisco Bug-ID CSCup3002 - DB-Service ist nach Ändern des Sicherheitskennworts auf CUCM 10.5 ausgefallen
• Cisco Bug-ID CSCus13276 - CUCM 10.5.2 Sicherheitskennwort-Wiederherstellung bewirkt, dass DB nicht beim Neustart startet

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. 

Wiederherstellung verarbeitet CCMDB-Komponente nicht

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.

Replikationsfehler

Weitere Informationen zur Fehlerbehebung bei Replikationsfehlern finden Sie im Artikel Troubleshooting CUCM Database Replication in Linux Appliance Model Cisco.

Telefone registrieren sich nicht oder können nicht auf Services zugreifen

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.

Anmerkung: 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.