Contenu

Introduction

Fond

Collecte des données de cluster

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

Installer le serveur de publication CUCM

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

Redémarrer le noeud Publisher

Vérifier l'authentification du cluster

Effectuer une nouvelle sauvegarde

Ajouter un périphérique de sauvegarde

Démarrer une sauvegarde manuelle

Restauration du serveur de publication à partir de la base de données de l'abonné

État de la restauration

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

Redémarrer le cluster

Vérifier les exigences de configuration de la réplication

Configuration de la réplication

Post-restauration

Activer les services

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

Dépannage

Le cluster ne s'authentifie pas

La restauration ne traite pas le composant CCMDB

Échec de la réplication

Les téléphones ne s'inscrivent pas ou ne peuvent pas accéder aux services

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 (DB) 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, le seul moyen de le récupérer était de réinstaller et de restaurer la base de données à partir d'une sauvegarde DRS (Disaster Recovery System).

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

Dans CUCM version 8.6(1), 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 correctement une base de données d'éditeur à partir de l'abonné.

Cisco recommande vivement de conserver une sauvegarde complète du cadre de reprise après sinistre (DRF) de l'ensemble du cluster. Puisque ce processus récupère uniquement la configuration de la base de données CUCM, d'autres données, telles que les certificats, la musique d'attente (MoH) et les fichiers TFTP, ne sont pas récupérées. Afin d'éviter ces problèmes, conservez une sauvegarde DRF de cluster complète.

Note: Cisco vous recommande de passer en revue 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 recueillir les détails pertinents concernant 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 de passe de sécurité

- Version exacte de CUCM

- Fichiers COP (Cisco Options Package) installés

Afin de récupérer les trois premiers éléments de la liste, entrez la commande show network cluster au niveau de 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 aucun nom de domaine n'est configuré pour l'éditeur.

La phrase de passe de sécurité (le quatrième élément de la liste) est récupérée à partir de la documentation du site. Si vous n'êtes pas sûr de la phrase de passe de sécurité, faites une estimation du meilleur effort et vous pouvez tenter de la vérifier et de la corriger selon les besoins en fonction de la version CUCM. Si la phrase de passe de sécurité est incorrecte, une panne de cluster est requise 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 à partir 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.1000-28 est installée sans fichiers COP supplémentaires.

Note: Il est possible que certains fichiers COP aient été précédemment installés sur l'éditeur, mais n'aient pas été installés sur l'abonné, et vice versa. Utilisez ce résultat uniquement comme une directive.

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 des abonnés actuelles. Afin d'empêcher cela, entrez la commande utils dbreplication stop sur tous les abonnés :

admin:utils dbreplication stop

********************************************************************************

This command will delete the marker file(s) so that automatic replication setup

is stopped

It will 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

Collectez une image amorçable de la version appropriée et effectuez une installation avec une mise à niveau vers la version appropriée.

Note: La plupart des versions spéciales de CUCM Engineering (ES) 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 de passe de sécurité mentionnées précédemment.

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

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

Afin de récupérer la liste des noeuds, entrez la commande run sql select name,description,nodeid from process node dans la CLI d'un abonné actif. Les valeurs de noms peuvent être des noms d'hôte, 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 pub_from_sub doit être exécutée sur l'interface de ligne de commande de l'éditeur avant de pouvoir ajouter des noeuds à System > Server :

Après avoir reçu la liste des noeuds, accédez à System > Server et ajoutez toutes les valeurs de noms autres que EnterpriseWideData à la page Administration Unified CM de Publisher Server. Les valeurs de nom doivent correspondre au champ Nom d'hôte/Adresse IP du menu Système > Serveur.

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

Note: L'installation par défaut ajoute le nom d'hôte de l'éditeur à la table de noeud de processus. Vous devrez peut-être le remplacer par une 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 Nom d'hôte/Adresse IP actuel.

Redémarrer le noeud Publisher

Afin de redémarrer l'éditeur 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 de passe 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 2013172.18.172.214 cucm911ccnasub2  Subscriber authenticated using TCP since

Tue Dec 3 14:25:09 2013

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

Note: Bien que vous puissiez utiliser la base de données de l'abonné pour la restauration, une sauvegarde est toujours nécessaire pour restaurer les composants autres que la base de données.

Si aucune sauvegarde n'est disponible, effectuez-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 pour accéder au système de reprise après sinistre et ajouter un périphérique de secours.

Démarrer une sauvegarde manuelle

Une fois le périphérique de sauvegarde ajouté, lancez une sauvegarde manuelle.

Note: 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 de l'abonné

Sur la page Disaster Recovery System, accédez à Restore > Restore Wizard. Si une sauvegarde actuelle était disponible et que vous avez ignoré la section précédente, cochez toutes les cases de fonction dans la section Sélectionner les fonctionnalités : Enterprise License Manager (ELM) si disponible, CDR_CAR et Unified Communications Manager (UCM). Si vous utilisez une sauvegarde effectuée dans la section précédente, cochez uniquement la case UCM :

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

État de la 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 retournent les mêmes valeurs sur les noeuds de l'éditeur et de l'abonné avant de continuer :

- exécuter sql select count(*) à partir du périphérique

- exécuter sql select count(*) à partir de l'utilisateur final

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 la 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 n'ait pas encore été 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 devront être redémarrés. Si ces fichiers ne correspondent pas, ne passez pas à l'étape suivante ou ne réinitialisez pas la réplication.

Configuration de la réplication

Selon la version, la réplication peut ne pas être configurée automatiquement. Pour vérifier cela, 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 réplication est en cours (état 0 pour deux noeuds) :

Ce résultat indique que la réplication est 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, consultez l'article Dépannage de la réplication de base de données CUCM dans le modèle d'appliance Linux Cisco pour plus d'informations sur la façon de résoudre le problème.

Post-restauration

Comme 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 des services, 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 Servicability :

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 non nord-américaine (NANP))

- Locales

- Autres fichiers 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)

- Exportations de certificats en masse pour les clusters EMCC (Extension Mobility Cross Cluster), LBM (Intercluster Location Bandwidth Manager) et ILS (Intercluster Lookup Service)

- Échanges de certificats pour les liaisons sécurisées, les passerelles et les ponts de conférence

Note: Pour les clusters en mode mixte, vous devez réexécuter le client CTL (Certificate Trust List).

Dépannage

Cette section décrit divers scénarios susceptibles d'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 incohérences des phrases de passe de sécurité et les problèmes de connectivité sur le port TCP 8500.

Afin de vérifier que les phrases de passe de sécurité du cluster correspondent, entrez la commande utils create report platform dans l'interface de ligne de commande des deux noeuds et examinez la valeur de hachage à partir du fichier platformConfig.xml. Celles-ci doivent correspondre sur les noeuds de l'éditeur et de l'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 - outil de récupération de pwrecovery réinitialisation du mot de passe sftpuser uniquement

- ID de bogue Cisco CSCug92142 - l'outil de récupération de paquets ne met pas à jour les mots de passe utilisateur internes

- ID de bogue Cisco CSCug97360 - refus selinux dans l'utilitaire de récupération de paquets

- 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 cli de réinitialisation du pwd renvoie une valeur correcte mais ne modifie pas le mot de passe

- ID de bogue Cisco CSCup30002 - Le service DB 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 de 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 CUCM contient des correctifs pour tous ces problèmes, la solution la plus simple est de terminer 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 CUCM ne contient pas les correctifs pour ces problèmes, le centre d'assistance technique Cisco (TAC) peut être en mesure d'effectuer une solution de contournement, selon la situation.

La restauration ne traite pas le composant CCMDB

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

Échec de la réplication

Référez-vous à l'article Dépannage de la réplication de base de données CUCM dans le modèle d'appliance Linux Cisco afin de dépanner une défaillance de réplication.

Les téléphones ne s'inscrivent pas 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 certificats TVS (Trust Verification Service) des abonnés de confiance des téléphones 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 complètes du cluster.

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.

Note: Reportez-vous à l'article Sécurité par défaut de Communications Manager et Fonctionnement et dépannage ITL de Cisco pour plus d'informations sur le dépannage des fichiers ITL (Initial Trust List).