Ricostruisci autore CUCM dal Sottoscrittore

Introduzione

In questo documento viene descritto come ripristinare il nodo del server di pubblicazione Cisco Unified Communications Manager (CUCM) dal database sottoscrittore senza un backup precedente o senza accesso alla directory principale.

Introduzione

Nelle prime versioni di CUCM, il nodo del server di pubblicazione era considerato l'unica origine autorevole per il database SQL (Structured Query Language).

Di conseguenza, se un nodo del server di pubblicazione è stato perso a causa di un guasto hardware o di un danneggiamento del file system, l'unico modo per recuperarlo è stato reinstallare e ripristinare il database da un backup del sistema di ripristino di emergenza (DRS).

Alcuni clienti non hanno conservato i backup corretti o disponevano di backup obsoleti, pertanto l'unica opzione disponibile è stata quella di ricreare e riconfigurare il nodo del server di pubblicazione. 

In CUCM versione 8.6(1) è stata introdotta una nuova funzionalità per ripristinare un database di pubblicazione da un database sottoscrittore.

In questo documento viene descritto come utilizzare questa funzionalità per ripristinare correttamente un database di pubblicazione dal sottoscrittore.

Cisco consiglia di mantenere un backup completo di Disaster Recovery Framework (DRF) dell'intero cluster.

Poiché questo processo recupera solo la configurazione del database CUCM, gli altri dati, quali i certificati, i file MoH (Music on Hold) e i file TFTP, non vengono recuperati. Per evitare questi problemi, mantenere un backup DRF cluster completo.

Nota: Cisco consiglia di esaminare e acquisire familiarità con l'intero processo descritto in questo documento prima di iniziare.

Raccogli dati cluster

Prima di reinstallare l'autore, è importante raccogliere i dettagli relativi all'autore precedente. Questi dettagli devono corrispondere all'installazione dell'autore originale:

• Indirizzo IP
• Nome host
• Nome dominio
• Passphrase di sicurezza
• Versione CUCM esatta
• File COP (Cisco Options Package) installati

Per recuperare le prime tre voci dell'elenco, immettere il comando show network cluster nella CLI del nodo del sottoscrittore corrente:

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 questo caso, l'indirizzo IP è 172.18.172.212, il nome host è cucm911ccnapub e non è stato configurato alcun nome di dominio per il server di pubblicazione.   

La passphrase di protezione (il quarto elemento dell'elenco) viene recuperata dalla documentazione del sito.

In caso di dubbi sulla passphrase di protezione, eseguire una stima accurata e provare a verificarla e correggerla in base alla versione CUCM.

Se la passphrase di protezione non è corretta, per correggere la situazione è necessaria un'interruzione del cluster. 

Per recuperare la versione esatta di CUCM e i file COP installati (gli ultimi due elementi nell'elenco), catturare l'output di sistema dal comando show version active:

admin:show version active
Active Master Version: 9.1.2.10000-28
Active Version Installed Software Options:
No Installed Software Options Found.

In questo caso, la versione 9.1.2.10000-28 viene installata senza file COP aggiuntivi. 

Nota: è possibile che alcuni file COP siano stati precedentemente installati nel server di pubblicazione, ma non nel Sottoscrittore e viceversa. Utilizzare questo output solo come riferimento.

Arresta replica in tutti i Sottoscrittori

Al momento dell'installazione del server di pubblicazione, è fondamentale che la replica non configuri ed elimini i database sottoscrittori correnti. Per evitare questo problema, immettere il comando utils duplication stop su tutti i sottoscrittori:

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

Installare CUCM Publisher

Raccogliere un'immagine di avvio della versione appropriata ed eseguire un'installazione con un aggiornamento alla versione appropriata.

Nota: la maggior parte delle versioni di CUCM Engineering Special (ES) è già avviabile.

Installare l'autore e specificare i valori corretti per l'indirizzo IP, il nome host, il nome di dominio e la passphrase di protezione menzionati in precedenza. 

Aggiorna valori Processnode nel server di pubblicazione

Nota: per ripristinare il database da un determinato sottoscrittore, è necessario che l'autore riconosca almeno un server sottoscrittore. Cisco consiglia di aggiungere tutti i sottoscrittori. 

Per recuperare l'elenco dei nodi, immettere il comando run sql select name,description,nodeid from processnode nella CLI di un sottoscrittore corrente.

I valori dei nomi possono essere nomi host, indirizzi IP o nomi di dominio completi (FQDN).

Se si esegue CUCM versione 10.5(2) o successive, il comando utils disaster_recovery prepare restore pub_from_sub deve essere eseguito nella CLI del server di pubblicazione prima di poter procedere con l'aggiunta di nodi a Sistema > Server:

Avviso: molte persone che utilizzano CUCM versione 10.5(2) o successive ignorano il comando utilizza disaster_recovery preparare restore pub_from_sub; tuttavia, si tratta di un comando critico. Accertarsi di non saltare alcun passaggio in questo documento.

Dopo aver ricevuto l'elenco dei nodi, passare a Sistema > Server e aggiungere tutti i valori dei nomi diversi da EnterpriseWideData alla pagina Amministrazione di Publisher Server Unified CM.

I valori del nome devono corrispondere al campo Nome host/Indirizzo IP del menu Sistema > Server.

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

Nota: l'installazione predefinita aggiunge il nome host del publisher alla tabella processnode. Se nella colonna Nome è indicato un indirizzo IP per l'autore, è possibile modificarlo in un indirizzo IP. In questo caso, non rimuovere la voce dell'autore, ma aprire e modificare il campo Nome host/Indirizzo IP corrente. 

Riavvia il nodo del server di pubblicazione

Per riavviare il server di pubblicazione dopo il completamento delle modifiche al nodo di processo, immettere il comando utils system restart:

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

Verifica autenticazione cluster

Dopo il riavvio del server di pubblicazione, se le modifiche sono state apportate correttamente e la passphrase di protezione è corretta, il cluster deve essere in stato autenticato. Per verificare questa condizione, immettere il comando show network cluster:

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

Nota: se i sottoscrittori non vengono visualizzati come autenticati, consultare la sezione Risoluzione dei problemi in questo documento per risolvere il problema prima di procedere.

Esegui un nuovo backup

Se non è disponibile alcun backup precedente, eseguire un backup del cluster nella pagina DRS.

Nota: sebbene sia possibile utilizzare il database sottoscrittore per il ripristino, è comunque necessario un backup per ripristinare i componenti non del database.

Se non è disponibile alcun backup, eseguirne uno nuovo. Se esiste già un backup, è possibile ignorare questa sezione.

Aggiungi dispositivo di backup

Utilizzare il menu di navigazione per passare al sistema di ripristino di emergenza e aggiungere un dispositivo di backup.

Avvia backup manuale

Dopo aver aggiunto il dispositivo di backup, avviare un backup manuale.

Nota: è fondamentale che il componente CCMDB del nodo di pubblicazione sia registrato.

Ripristino del server di pubblicazione dal database del sottoscrittore

Nella pagina Disaster Recovery System, selezionare Ripristino > Ripristino guidato.

Se era disponibile un backup corrente e la sezione precedente è stata ignorata, selezionare tutte le caselle di controllo delle funzionalità nella sezione Selezione funzionalità: Enterprise License Manager (ELM) se disponibile, CDR_CAR e Unified Communications Manager (UCM).

Se si utilizza un backup eseguito nella sezione precedente, selezionare solo la casella di controllo UCM:

Fare clic su Next (Avanti). Selezionare la casella di controllo del nodo del server di pubblicazione (CUCM911CCNAPUB) e scegliere il database del sottoscrittore da cui viene eseguito il ripristino. Quindi fare clic su Ripristina.

Ripristina stato

Quando il ripristino raggiunge il componente CCMDB, il testo Status deve essere visualizzato come Restoring Publisher from Subscriber Backup (Ripristino del server di pubblicazione dal backup del sottoscrittore):

Eseguire un controllo di integrità nel database del server di pubblicazione

Prima di riavviare e configurare la replica, è buona norma verificare che il ripristino sia stato eseguito correttamente e che il database del server di pubblicazione contenga le informazioni necessarie.

Prima di continuare, verificare che queste query restituiscano gli stessi valori nei nodi del server di pubblicazione e del sottoscrittore:

• esegui conteggio selezioni sql (*) dal dispositivo
• esegui conteggio selezioni sql (*) da utente finale

Riavvia il cluster

Al termine del ripristino, immettere il comando utils system restart su ogni nodo. Iniziare con l'editore seguito da ogni sottoscrittore.

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

Verifica dei requisiti di configurazione della replica

Passare alla pagina Cisco Unified Reporting e generare un report sullo stato del database CCM unificato.

È probabile che la replica non sia ancora stata configurata, ma è importante verificare che i file Unified CM Hosts, Unified CM Rhosts e Unified CM Sqlhosts corrispondano all'autore.

In caso contrario, sarà necessario riavviare nuovamente i nodi che non corrispondono. Se questi file non corrispondono, non procedere al passaggio successivo o reimpostare la replica.

Impostazione replica

A seconda della versione, la replica non può essere impostata automaticamente. Per verificare questa condizione, attendere l'avvio di tutti i servizi e immettere il comando utils duplication runtimestate.

Il valore 0 per lo stato indica che è in corso l'installazione, mentre il valore 2 indica che la replica è stata configurata correttamente per il nodo.

Questo output indica che l'impostazione della replica è in corso (lo stato viene visualizzato come 0 per due dei nodi):

Questo output indica che la replica è stata configurata correttamente:

Se uno o più nodi vengono visualizzati con un valore di stato pari a 4, o se la replica non viene configurata correttamente dopo diverse ore, immettere il comando utils duplication reset all dal nodo di pubblicazione.

Se il problema persiste, consultare l'articolo Risoluzione dei problemi di replica del database CUCM nel modello di appliance Linux Cisco per ulteriori informazioni sulla risoluzione del problema. 

Post-ripristino

Poiché il ripristino del database non ripristina tutti i componenti precedenti, molti elementi a livello di server devono essere installati o ripristinati manualmente.

Attiva servizi

Il ripristino DRF non attiva alcun servizio. Passare a Strumenti > Attivazione servizio e attivare tutti i servizi necessari che l'autore deve eseguire, in base alla documentazione del sito disponibile nella pagina Unified Serviceability:

Installa dati non ripristinati

Se non è disponibile un backup completo, è necessario riprodurre alcune configurazioni manuali. In particolare, le configurazioni che implicano certificati e funzioni TFTP:

• file MoH
• Pacchetti dispositivi
• Piani di composizione (per la composizione NANP (non-North American Numbering Plan)
• Impostazioni internazionali
• Qualsiasi altro file COP
• Tutti i file precedentemente caricati manualmente nel server di pubblicazione (se si tratta di un server TFTP)
• Stringhe della community SNMP (Simple Network Management Protocol)
• Esportazioni in blocco di certificati per Extension Mobility Cross Cluster (EMCC), Intercluster Location Bandwidth Manager (LBM) e Intercluster Lookup Service (ILS)
• Scambi di certificati per trunk sicuri, gateway e bridge di conferenza

Nota: per i cluster a modalità mista, è necessario eseguire nuovamente il client dell'elenco di certificati attendibili (CTL, Certificate Trust List).

Risoluzione dei problemi

In questa sezione vengono descritti vari scenari che possono impedire il completamento di questa procedura.

Il cluster non esegue l'autenticazione

Se il cluster non viene autenticato, le due cause più comuni sono passphrase di sicurezza non corrispondenti e problemi di connettività sulla porta TCP 8500.

Per verificare che le passphrase di sicurezza del cluster corrispondano, immettere il comando utils create report platform nella CLI di entrambi i nodi e controllare il valore hash dal file platformConfig.xml. Questi devono corrispondere nei nodi del server di pubblicazione e del Sottoscrittore.

  <IPSecSecurityPwCrypt>
    <ParamNameText>Security PW for this node</ParamNameText>
    <ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
    12812AB2825C831812812AB2825C </ParamValue>
  </IPSecSecurityPwCrypt>

Se corrispondono, verificare la connettività TCP sulla porta 8500. Se non corrispondono, possono verificarsi problemi quando si tenta di correggere la passphrase a causa di diversi difetti del codice CUCM che circondano la procedura:

• ID bug Cisco CSCtn79868 - lo strumento pwrecovery reimposta solo la password sftpuser
• ID bug Cisco CSCug92142 - lo strumento pwrecovery non aggiorna le password degli utenti interni
• ID bug Cisco CSCug97360 - Rifiuti selinux nell'utility pwrecovery
• ID bug Cisco CSCts10778 - Scelta non consentita per la procedura di recupero della password di sicurezza
• ID bug Cisco CSCua09290 - La CLI "set password user security" (Impostazione password di sicurezza utente) non ha impostato la password corretta per le app
• Cisco ID bug CSCtx45528 - la funzione pwd reset cli restituisce un valore valido ma non modifica la password
• ID bug Cisco CSCup30002 - Il servizio DB è inattivo, dopo aver modificato la password di sicurezza su CUCM 10.5
• ID bug Cisco CSCus13276 - il recupero della password di sicurezza CUCM 10.5.2 impedisce l'avvio del database al riavvio

Se la versione CUCM contiene correzioni per tutti questi problemi, la soluzione più semplice è completare la procedura di recupero della password descritta in Cisco Unified Communications Operating System Administration Guide (Guida all'amministrazione del sistema operativo di Cisco Unified Communications), versione 10.0(1) su tutti i nodi.

Se la versione CUCM non contiene le correzioni per questi problemi, il Cisco Technical Assistance Center (TAC) può essere in grado di eseguire una soluzione alternativa, a seconda della situazione. 

Il ripristino non elabora il componente CCMDB

Se il ripristino non elenca il componente DB, è possibile che il backup stesso non contenga un componente DB. Verificare che il database del server di pubblicazione sia in esecuzione e in grado di accettare query ed eseguire un nuovo backup.

Errore di replica

Per risolvere i problemi relativi alla replica del database CUCM in Cisco, consultare l'articolo Risoluzione dei problemi relativi alla replica del database CUCM nel modello di appliance Linux.

I telefoni non si registrano o non sono in grado di accedere ai servizi

Poiché il ripristino del database non ripristina alcun certificato, se il server di pubblicazione è il server TFTP primario, il firmatario è diverso.

Se i certificati TVS (Trust Subscriber Trust Verification Service) del telefono sono attendibili e la porta TCP 2445 è aperta tra i telefoni e i server TVS, il problema deve essere risolto automaticamente.

Per questo motivo, Cisco consiglia di mantenere backup DRF completi dei cluster. 

Anche le versioni di CUCM precedenti alla versione 8.6 possono presentare problemi di certificato, anche se il backup è stato precedentemente completato correttamente, a causa dell'ID bug Cisco CSCtn50405.

Nota: per ulteriori informazioni su come risolvere i problemi relativi ai file dell'elenco di attendibilità iniziale (ITL), consultare l'articolo Sicurezza predefinita di Cisco Communications Manager e l'articolo ITL Operation and Troubleshooting Cisco.