Reconstruire le serveur de publication CUCM à partir de l'abonné

Introduction

Ce document décrit comment restaurer le noeud éditeur de Cisco Unified Communications Manager (CUCM) à partir de la base de données des abonnés sans sauvegarde préalable ni accès racine.

Fond

Dans les premières versions de CUCM, le noeud éditeur était considéré comme la seule source faisant autorité pour la base de données SQL (Structured Query Language).

Par conséquent, si un noeud éditeur a été perdu en raison d'une défaillance matérielle ou d'une corruption du système de fichiers, la seule façon de le récupérer était de réinstaller et de restaurer la base de données à partir d'une sauvegarde du système de récupération d'urgence (DRS).

Certains clients ne conservaient pas les sauvegardes appropriées ou disposaient de sauvegardes obsolètes. La seule option était donc de reconstruire et de reconfigurer le noeud du serveur de publication. 

Dans la version 8.6(1) de CUCM, une nouvelle fonctionnalité a été introduite afin de restaurer une base de données d'éditeur à partir d'une base de données d'abonnés.

Ce document décrit comment tirer parti de cette fonctionnalité afin de restaurer avec succès une base de données d'éditeur à partir de l'abonné.

Cisco vous recommande vivement de conserver une sauvegarde DRF (Disaster Recovery Framework) complète de l'ensemble du cluster.

Comme ce processus ne récupère que la configuration de la base de données CUCM, les autres données, telles que les certificats, la musique d'attente (MoH) et les fichiers TFTP, ne sont pas récupérées. Pour éviter ces problèmes, conservez une sauvegarde DRF de cluster complète.

Remarque : Cisco vous recommande de revoir et de vous familiariser avec l'ensemble du processus décrit dans ce document avant de commencer.

Collecte des données de cluster

Avant de réinstaller l'éditeur, il est essentiel de collecter les informations pertinentes sur l'éditeur précédent. Ces détails doivent correspondre à l'installation d'origine de l'éditeur :

• Adresse IP
• Nom de l´hôte
• le nom de domaine
• Phrase secrète de sécurité
• Version exacte de CUCM
• Fichiers installés du package d'options Cisco (COP)

Afin de récupérer les trois premiers éléments de la liste, entrez la commande show network cluster à l'interface de ligne de commande du noeud d'abonné actuel :

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

Dans ce cas, l'adresse IP est 172.18.172.212, le nom d'hôte est cucm911ccnapub, et il n'y a aucun nom de domaine configuré pour l'éditeur.   

La phrase secrète de sécurité (le quatrième élément de la liste) est extraite de la documentation du site.

Si vous n'êtes pas sûr de la phrase de passe de sécurité, faites une supposition au mieux, et vous pouvez essayer de la vérifier et de la corriger selon les besoins en fonction de la version de CUCM.

Si la phrase secrète de sécurité est incorrecte, une panne de cluster est nécessaire pour corriger la situation. 

Afin de récupérer la version exacte de CUCM et les fichiers COP installés (les deux derniers éléments de la liste), collectez la sortie système de la commande 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.

Dans ce cas, la version 9.1.2.10000-28 est installée sans fichier COP supplémentaire. 

Remarque : il est possible que certains fichiers COP aient été précédemment installés sur l'éditeur, mais pas sur l'abonné, et inversement. Utilisez ce résultat comme ligne directrice uniquement.

Arrêter la réplication sur tous les abonnés

Lorsque l'éditeur est installé, il est essentiel que la réplication ne configure pas et ne supprime pas les bases de données d'abonné actuelles. Afin d'éviter cela, entrez la commande utils dbreplication stop sur tous les abonnés :

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

Installer le serveur de publication CUCM

Rassemblez une image de démarrage de la version appropriée et effectuez une installation avec une mise à niveau vers la version appropriée.

Remarque : la plupart des versions spéciales d'ingénierie CUCM sont déjà amorçables.

Installez l'éditeur et spécifiez les valeurs correctes pour l'adresse IP, le nom d'hôte, le nom de domaine et la phrase secrète de sécurité mentionnés précédemment. 

Mettre à jour les valeurs du noeud Processus sur le serveur de publication

Remarque : l'éditeur doit connaître au moins un serveur d'abonné afin de restaurer la base de données à partir de cet abonné. Cisco vous recommande d'ajouter tous les abonnés. 

Afin de récupérer la liste de noeuds, entrez la commande run sql select name, description, nodeid from process node à l'interface de ligne de commande d'un abonné actuel.

Les valeurs de nom peuvent être des noms d'hôtes, des adresses IP ou des noms de domaine complets (FQDN).

Si vous exécutez CUCM Version 10.5(2) ou ultérieure, la commande utils Disaster_recovery prepare restore pub_from_sub doit être exécutée sur l'interface de ligne de commande de l'éditeur avant de pouvoir continuer à ajouter des noeuds à System > Server :

Avertissement : de nombreuses personnes utilisant CUCM version 10.5(2) ou ultérieure ignorent la commande jusqu'à ce que Disaster_recovery prepare restore pub_from_sub ; cependant, il s'agit d'une commande critique. Veillez à ne pas ignorer les étapes de ce document.

Après avoir reçu la liste de noeuds, accédez à Système > Serveur et ajoutez toutes les valeurs de nom autres qu'EnterpriseWideData à la page d'administration de Publisher Server Unified CM.

Les valeurs de nom doivent correspondre au champ Host Name/IP Address du menu System > 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

Remarque : l'installation par défaut ajoute le nom d'hôte de l'éditeur à la table des noeuds de processus. Vous pouvez le modifier en adresse IP si la colonne name indique une adresse IP pour l'éditeur. Dans ce cas, ne supprimez pas l'entrée de l'éditeur, mais ouvrez et modifiez le champ Host Name/IP Address actuel. 

Redémarrer le noeud Publisher

Afin de redémarrer le serveur de publication une fois les modifications du noeud de processus terminées, entrez la commande 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

Vérifier l'authentification du cluster

Après le redémarrage de l'éditeur, si vous avez effectué les modifications correctement et que la phrase secrète de sécurité est correcte, le cluster doit être à l'état authentifié. Afin de vérifier ceci, entrez la commande 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

Remarque : si les abonnés n'apparaissent pas comme authentifiés, reportez-vous à la section Dépannage de ce document afin de résoudre ce problème avant de continuer.

Effectuer une nouvelle sauvegarde

Si aucune sauvegarde précédente n'est disponible, effectuez une sauvegarde de cluster sur la page DRS.

Remarque : bien que vous puissiez utiliser la base de données de l'abonné pour la restauration, une sauvegarde est toujours requise afin de restaurer les composants non-base de données.

Si aucune sauvegarde n'est disponible, exécutez-en une nouvelle ; si une sauvegarde existe déjà, vous pouvez ignorer cette section.

Ajouter un périphérique de sauvegarde

Utilisez le menu de navigation afin de naviguer jusqu'au système de récupération d'urgence et d'ajouter un périphérique de sauvegarde.

Démarrer une sauvegarde manuelle

Une fois l'unité de sauvegarde ajoutée, lancez une sauvegarde manuelle.

Remarque : il est essentiel que le composant CCMDB soit enregistré sur le noeud éditeur.

Restauration du serveur de publication à partir de la base de données des abonnés

Sur la page Disaster Recovery System, accédez à Restore > Restore Wizard.

Si une sauvegarde en cours était disponible et que vous avez ignoré la section précédente, cochez toutes les cases des fonctions dans la section Sélectionner des fonctions : Enterprise License Manager (ELM) si disponible, CDR_CAR, et Unified Communications Manager (UCM).

Si vous utilisez une sauvegarde qui a été effectuée dans la section précédente, cochez seulement la case UCM :

Cliquez sur Next (Suivant). Cochez la case du noeud éditeur (CUCM911CCNAPUB) et choisissez la base de données d'abonné à partir de laquelle la restauration a lieu. Cliquez ensuite sur Restore.

État de restauration

Lorsque la restauration atteint le composant CCMDB, le texte Status doit apparaître comme Restoring Publisher from Subscriber Backup :

Exécuter un contrôle d'intégrité sur la base de données Publisher

Avant de redémarrer et de configurer la réplication, il est recommandé de vérifier que la restauration a réussi et que la base de données de l'éditeur contient les informations requises.

Assurez-vous que ces requêtes renvoient les mêmes valeurs sur les noeuds de l'éditeur et de l'abonné avant de continuer :

• exécutez sql select count(*) à partir du périphérique
• exécutez sql select count(*) à partir de enduser

Redémarrer le cluster

Une fois la restauration terminée, entrez la commande utils system restart sur chaque noeud. Commencez par l'éditeur suivi de chaque abonné.

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

Vérifier les exigences de configuration de réplication

Accédez à la page Cisco Unified Reporting et générez un rapport d'état de la base de données Unified CM.

Il est probable que la réplication ne puisse pas encore être configurée, mais il est important de s'assurer que les fichiers Unified CM Hosts, Unified CM Rhosts et Unified CM Sqlhosts correspondent à l'éditeur.

Si ce n'est pas le cas, les noeuds qui ne correspondent pas doivent être redémarrés. Si ces fichiers ne correspondent pas, ne passez pas à l'étape suivante ou réinitialisez la réplication.

Configuration de la réplication

En fonction de la version, la réplication ne peut pas être configurée automatiquement. Afin de vérifier ceci, attendez que tous les services démarrent, et entrez la commande utils dbreplication runtimestate.

Une valeur d'état de 0 indique que la configuration est en cours, tandis qu'une valeur de 2 indique que la réplication est correctement configurée pour ce noeud.

Ce résultat indique que la configuration de la réplication est en cours (l'état apparaît comme 0 pour deux des noeuds) :

Ce résultat indique que la réplication a été correctement configurée :

Si des noeuds apparaissent avec une valeur d'état de 4, ou si la réplication n'est pas correctement configurée après plusieurs heures, entrez la commande utils dbreplication reset all à partir du noeud éditeur.

Si la réplication continue à échouer, référez-vous à l'article Dépannage de la réplication de base de données CUCM dans le modèle d'appareil Linux Cisco pour plus d'informations sur la façon de dépanner le problème. 

Post-restauration

Étant donné que la restauration de la base de données ne restaure pas tous les composants précédents, de nombreux éléments de niveau serveur doivent être installés ou restaurés manuellement.

Activer les services

La restauration DRF n'active aucun service. Accédez à Outils > Activation de service, et activez tous les services nécessaires que l'éditeur doit exécuter, en fonction de la documentation du site à partir de la page Unified Serviceability :

Installer les données qui n'ont pas été restaurées

Si aucune sauvegarde complète n'était disponible, vous devez reproduire certaines configurations manuelles. En particulier, les configurations qui impliquent des certificats et des fonctions TFTP :

• Fichiers MoH
• Packs de périphériques
• Plans de numérotation (pour la numérotation NANP (Non-North American Numbering Plan))
• Paramètres régionaux
• Tout autre fichier COP divers
• Tous les fichiers précédemment téléchargés manuellement vers l'éditeur (s'il s'agissait d'un serveur TFTP)
• Chaînes de communauté SNMP (Simple Network Management Protocol)
• Exportation de certificats groupés pour Extension Mobility Cross Cluster (EMCC), Intercluster Location Bandwidth Manager (LBM) et Intercluster Lookup Service (ILS)
• Échanges de certificats pour des agrégations, passerelles et ponts de conférence sécurisés

Remarque : pour les clusters en mode mixte, vous devez exécuter à nouveau le client Liste de certificats de confiance (CTL).

Dépannage

Cette section décrit les différents scénarios pouvant entraîner l'échec de cette procédure.

Le cluster ne s'authentifie pas

Si le cluster ne s'authentifie pas, les deux causes les plus courantes sont les phrases de passe de sécurité non concordantes et les problèmes de connectivité sur le port TCP 8500.

Afin de vérifier que les phrases secrètes de sécurité du cluster correspondent, entrez la commande utils create report platform à l'interface de ligne de commande des deux noeuds, et inspectez la valeur de hachage du fichier platformConfig.xml. Ceux-ci doivent correspondre sur les noeuds d'éditeur et d'abonné.

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

Si elles correspondent, vérifiez la connectivité TCP sur le port 8500. S'ils ne correspondent pas, il peut y avoir des difficultés lorsque vous essayez de corriger la phrase de passe en raison de plusieurs défauts dans le code CUCM qui entourent la procédure :

• ID de bogue Cisco CSCtn79868 - pwrecovery tool réinitialisant uniquement sftpuser password
• ID de bogue Cisco CSCug92142 - l'outil de récupération de fichiers pwrecovery ne met pas à jour les mots de passe utilisateur internes
• ID de bogue Cisco CSCug97360 - refus selinux dans l'utilitaire pwrecovery
• ID de bogue Cisco CSCts10778 - Refus lancés pour la procédure de récupération de mot de passe de sécurité
• ID de bogue Cisco CSCua09290 - CLI « set password user security » n'a pas défini le mot de passe d'application correct
• ID de bogue Cisco CSCtx45528 - l'interface de ligne de commande pwd reset retourne good mais ne modifie pas le mot de passe
• ID de bogue Cisco CSCup3002 - Le service de base de données est arrêté, après avoir modifié le mot de passe de sécurité sur CUCM 10.5
• ID de bogue Cisco CSCus13276 - La récupération du mot de passe de sécurité CUCM 10.5.2 empêche le démarrage de la base de données au redémarrage

Si la version de CUCM contient des correctifs pour tous ces problèmes, la solution la plus simple est de suivre la procédure de récupération de mot de passe détaillée dans le Guide d'administration du système d'exploitation Cisco Unified Communications, version 10.0(1) sur tous les noeuds.

Si la version de CUCM ne contient pas de correctifs pour ces problèmes, le centre d'assistance technique de Cisco (TAC) peut être en mesure d'effectuer une solution de contournement, en fonction de la situation. 

La restauration ne traite pas le composant CCMDB

Si la restauration ne répertorie pas le composant de base de données, il est possible que la sauvegarde elle-même ne contienne pas de composant de base de données. Assurez-vous que la base de données de l'éditeur s'exécute et peut accepter les requêtes, puis effectuez une nouvelle sauvegarde.

Échec de réplication

Reportez-vous à l'article Troubleshooting CUCM Database Replication in Linux Appliance Model Cisco afin de dépanner un échec de réplication.

Les téléphones ne sont pas enregistrés ou ne peuvent pas accéder aux services

Puisque la restauration de la base de données ne restaure aucun certificat, si l'éditeur est le serveur TFTP principal, le signataire est différent.

Si les téléphones font confiance aux certificats TVS (Subscriber Trust Verification Service) et que le port TCP 2445 est ouvert entre les téléphones et les serveurs TVS, le problème doit être résolu automatiquement.

C'est pourquoi Cisco vous recommande de conserver des sauvegardes DRF de cluster complètes. 

Les versions de CUCM antérieures à la version 8.6 peuvent également avoir des problèmes de certificat, même avec une sauvegarde précédente réussie, en raison de l'ID de bogue Cisco CSCtn50405.

Remarque : reportez-vous à l'article Communications Manager Security By Default and ITL Operation and Troubleshooting Cisco pour plus d'informations sur le dépannage des fichiers de la liste de confiance initiale (ITL).