Voix et communications unifiées : Cisco Unified Communications Manager Version 7.1

Cisco Unified Communications Manager 7.x/8.x : Dépannage du problème de sauvegarde

18 octobre 2014 - Traduction automatique
Autres versions: PDFpdf | Anglais (25 septembre 2014) | Commentaires


Contenu


Introduction

Les sauvegardes de Cisco Unified Communications Manager ne s'exécutent pas comme prévu. Tous les services de reprise sur sinistre (DRF) sont inactifs, et aucun nouveau périphérique, programme, ou état ne peuvent être visualisés de la console DRF. Ce document discute comment effectuer le dépannage de ce problème.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations dans ce document sont basées sur Cisco Unified Communications Manager 7.1(3)/8.x.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problème

Les sauvegardes de Cisco Unified Communications Manager ne s'exécutent pas comme prévu. Tous les services de reprise sur sinistre (DRF) sont inactifs, et aucun nouveau périphérique, programme, ou état ne peuvent être visualisés de la console DRF. En outre, quand vous accédez aux pages d'admin DRF, ce message d'erreur est reçu :

Status:  Local Agent is not responding. 
This may be due to Master or Local Agent being down.

http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unified-communications-manager-version-71/111796-cucm-drf-01.gif

Cette alerte RTMT est reçue pendant la panne de sauvegarde :

CiscoDRFFailure Reason : Master Agent was unable to send a 
backup/restore request to the local agent. 
Node [ELS-PUB1] is not connected. 
AppID : Cisco DRF Master 
ClusterID : NodeID: ELS-pub1 .
The alarm is generated on Tue Nov 24 02:00:04 PST 2009

Solution

D'abord, vérifiez si le numéro de série de certificat dans le keystore de Publisher est présent dans le Truststore de tous les abonnés. Procédez comme suit :

  1. Ouvrez une session à la page de gestion de SYSTÈME D'EXPLOITATION CUCM du serveur de Publisher de l'installation de batterie. Choisissez la Gestion de Sécurité > de certificat. Les affichages de fenêtre de liste de certificat.

  2. Vous pouvez utiliser la découverte contrôle afin de filtrer le certificat.

  3. Cliquez sur en fonction le fichier ipsec.pem et vérifiez le numéro de série du certificat.

  4. Ouvrez une session à la page de gestion de SYSTÈME D'EXPLOITATION CUCM de chaque noeud de la batterie. Choisissez la Gestion de Sécurité > de certificat. Les affichages de fenêtre de liste de certificat.

  5. Vous pouvez utiliser la découverte contrôle afin de filtrer le certificat.

  6. Cliquez sur en fonction le fichier ipsec-trust.pem avec le nom du fichier de l'adresse Internet de l'éditeur et vérifiez le numéro de série du certificat.

  7. Le numéro de série de certificat devrait être même sur tous les Noeuds de la batterie. Si le numéro de série de n'importe quel noeud est mal adapté, terminez-vous ces étapes.

    1. Ouvrez une session à la page d'admin de SYSTÈME D'EXPLOITATION CUCM du noeud affecté.

    2. Choisissez la Gestion de Sécurité > de certificat. Les affichages de fenêtre de liste de certificat.

    3. Vous pouvez utiliser la découverte contrôle afin de filtrer le certificat.

    4. Cliquez sur en fonction le fichier ipsec.pem et téléchargez ce certificat.

    5. Trouvez l'ipsec-confiance existante avec le nom du fichier de l'adresse Internet de l'éditeur, cliquez sur en fonction le nom du fichier et supprimez.

    6. Téléchargez le fichier téléchargé ipsec.pem avec l'ipsec-confiance de légende.

    7. Redémarrez l'agent local du maître Agent(MA)/DRF DRF (LA).

Erreur : Ne peut pas écrire : Tube cassé

La sauvegarde DRF a manqué avec ce message d'erreur :

/bin/tar: -: Cannot write: Broken pipe
/bin/tar: Error is not recoverable: exiting now
CCMDB Backup failed, unable to tar data to master agent
Restoring CAR services ...

Cette question est documentée dans l'ID de bogue Cisco CSCte62205 (les clients enregistrés seulement)

Comme essai un de contournement de ces étapes :

  1. Désactivez les messages actifs de client sur le serveur ouvert de SSH

  2. Placez le ClientAliveCountMax et ClientAliveInterval à une haute assez comptent/intervalles ainsi le serveur ne fait pas délai d'attente la connexion à CUCM pendant la sauvegarde.

  3. Redémarrez l'agent local du maître Agent(MA)/DRF DRF (LA).

Le jeu rouleau-tambour s'arrête pendant la sauvegarde CCMDB

Problème

Le jeu rouleau-tambour s'arrête pendant la sauvegarde CCMDB s'il y a grand nombre de fichiers CDR/CMR accumulés dans le répertoire de conserve. Cette question est documentée dans l'ID de bogue Cisco CSCsl16967 (clients enregistrés seulement).

Remarque: Si vous arrêtez le service de CAR, il n'arrête pas l'accumulation des fichiers plats CDR.

Solution

Procédez comme suit pour résoudre ce problème :

  1. Terminez-vous ces étapes afin de nettoyer les fichiers CDR temporairement de sorte que le jeu rouleau-tambour puisse poursuivre :

    1. Arrêtez le service d'agent CDR sur tous les serveurs dans la batterie, de sorte qu'aucun nouveau fichier CDR ne soit poussé à l'éditeur.

    2. Exécutez cette commande afin de vérifier que tous les fichiers ont été poussés aux serveurs de facturation :

      file list activelog /cm/cdr_repository/destination/*
      
  2. Terminez-vous ces étapes afin de vérifier qu'il n'y a aucun lien symbolique dans des sous-dossiers l'uns des :

    1. Arrêtez le gestionnaire de référentiel CDR, le programmateur de CAR, et le service Web de CAR sur l'éditeur.

    2. Employez cette commande afin de retirer tous les fichiers sous le <date de /var/log/active/cm/cdr_repository/preserve/ > qui ont été accumulés :

      file delete activelog /cm/cdr_repository/preserve/* noconfirm
      
    3. Employez cette commande afin de retirer tous les liens symboliques sous le <date de /var/log/active/cm/cdr_repository/car/ > :

      file delete activelog /cm/cdr_repository/car/* noconfirm
      
    4. Redémarrez le gestionnaire de référentiel CDR, le programmateur de CAR, et les services Web de CAR sur l'éditeur.

  3. Terminez-vous ces étapes afin d'arrêter davantage d'accumulation des fichiers CDR :

    Remarque: Afin d'arrêter davantage d'accumulation des fichiers CDR, vous devez commencer le service de programmateur de CAR, placez le chargeur pour programmer le chargement continu, et le chargement CDR seulement.

    1. S'il n'est pas encore créé, créez un compte de ccmadmin en Gestion de groupe d'utilisateurs à la page de ccmadmin.

    2. Ouvrez une session dans le CAR, et allez au système > au programmateur > au chargement CDR.

    3. Vérifiez le chargement continu 24/7 et les cases du chargement CDR seulement, et cliquez sur la mise à jour.

    4. Choisissez le système > la base de données > configurent la purge automatique de base de données.

    5. Écrivez l'âge minimum de 1par des articles mouvement d'appel et l'âge maximum des articles mouvement d'appel, et cliquez sur la mise à jour.

    6. Choisissez le config d'état > génération/alerte automatiques.

    7. Pour chaque état, choisissez handicapé, et cliquez sur la mise à jour.

  4. Redémarrez le service d'agent CDR sur tous les serveurs.

Erreur : Le système est actuellement verrouillé par un autre processus. Essayez s'il vous plaît de nouveau plus tard

Les sauvegardes jeu rouleau-tambour cessent d'exécuter automatiquement et quand vous tentez une sauvegarde manuelle, vous obtenez l'exécution de sauvegarde en cours. S'il vous plaît attendez et essayez après un jour ou l'autre message d'erreur. Quand vous essayez d'installer une nouvelle version ou un fichier de COP, vous obtenez le le système est actuellement verrouillé par un autre processus. Veuillez essayer de nouveau le message d'erreur postérieur. Cette question se produit si DRF est sauvegarde programmée le serveur CUCM automatiquement. Ceci est documenté par l'ID de bogue Cisco CSCsr87199 (clients enregistrés seulement).

Solution

Remettez à l'état initial l'agent principal DRF afin de résoudre le problème.

La sauvegarde échoue avec l'erreur de Winsock

Avec CUCM 8.x, la sauvegarde a manqué avec le message d'erreur de l'erreur 10054/10035/10053 de Winsock.

Solution

Assurez-vous que le Pare-feu est désactivé sur le périphérique de sauvegarde distant et exécutez la sauvegarde de nouveau.

La sauvegarde DRF fait pas les Certificats de sauvegarde

Avec CUCM 8.x, sur un serveur restauré par mise à jour de passerelle, le fichier ITL n'a pas un signataire valide. Les téléphones n'ont pas des services de https si l'éditeur est le serveur TFTP. Sur un transfert à l'UCS, ou aucun nouveau matériel où un de sauvegarde et une restauration est exécuté, les téléphones ne reçoivent pas des fichiers de configuration et des modifications de la nouvelle batterie sans suppression manuelle de l'ITL existante des téléphones.

Quand vous restaurez d'une situation de Reprise sur sinistre, les téléphones n'identifient plus leur configuration ou fichiers ITL après la restauration jeu rouleau-tambour si le serveur restauré était le serveur TFTP. Les téléphones peuvent ne pas identifier des modifications ou des mises à jour de configuration jusqu'à ce que leur ITL existante soit supprimée et remplacée par l'ITL nouvellement générée.

En outre, quand vous émettez la commande ITL CLI d'exposition sur les serveurs, ce message d'erreur apparaît :

This etoken was not used to sign the ITL file.
Verification of the ITL file failed.
Error parsing the ITL file

Cette question est documentée par l'ID de bogue Cisco CSCtn50405 (clients enregistrés seulement).

Solution

Après une situation de transfert de Reprise sur sinistre ou de matériel, terminez-vous ces étapes.

  1. Régénérez le fichier CallManager.pem (seulement sur le serveur restauré) au sync le fichier CallManager.pem sur le système de fichiers à celui dans la base de données.

  2. Reprise TV et TFTP.

  3. Pour une batterie de noeud simple, ou seulement un serveur TFTP, supprimez le fichier ITL manuellement de tous les téléphones dans la batterie.

  4. Pour une batterie multi de noeud, les téléphones devraient automatiquement employer des TV des serveurs alternatifs de groupe de CallManager afin d'authentifier le nouveau fichier ITL. Alternativement des téléphones peuvent être indiqués un autre serveur TFTP dans la batterie.

Après qu'une mise à jour de passerelle, se terminent ces étapes.

  1. Régénérez le fichier CallManager.pem (seulement sur le serveur restauré) au sync le fichier CallManager.pem sur le système de fichiers à celui dans la base de données.

  2. Reprise TV et TFTP.

  3. Les téléphones doivent être remis à l'état initial afin de télécharger le nouveau fichier ITL, mais ne devraient pas devoir faire supprimer le fichier ITL car ils n'auraient jamais eu un fichier valide ITL au télécharger jusqu'ici.

Message d'erreur : mauvais déchiffrage 16404:error

Avec CUCM 8.x, la restauration jeu rouleau-tambour échoue pour les composants TFTP avec ce message d'erreur

error:06065064:digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Solution

Ce message d'erreur est une indication de la non-concordance d'adresse IP ou d'adresse Internet. Assurez-vous que le serveur CUCM a la mêmes adresse IP et adresse Internet que sur les serveurs MCS d'où la sauvegarde se trouve. Si l'adresse Internet n'est pas identique que le serveur de sauvegarde, vous devez modifier l'adresse Internet afin d'être le même que le serveur de sauvegarde et exécuter la restauration de nouveau.

Erreur à la page de sauvegarde sur CUCM

Problème

Quand vous naviguez vers la page de sauvegarde, l'agent local ne répond pas. Ceci peut devoir maîtriser ou l'agent local étant en bas du message d'erreur apparaît. Ceci se produit également tandis que vous tentez d'ajouter un périphérique de sauvegarde.

Solution

Procédez comme suit pour résoudre ce problème :

  1. Procédure de connexion à la page d'admin de SYSTÈME D'EXPLOITATION CUCM.

  2. Choisissez la Gestion de Sécurité > de certificat.

  3. Vérifiez le numéro de série pour le fichier ipsec.pem.

  4. Assurez-vous que le numéro de série sélectionne le fichier ipsec-trust.pem pour les abonnés.

  5. Redémarrez le maître de Cisco DRF et le service local DRF dans Publisher.

  6. Lancez le service TFTP.

Incapable d'ajouter le périphérique de sauvegarde

Problème

Vous ne pouvez pas ajouter le périphérique de sauvegarde à la page jeu rouleau-tambour CUCM.

Solution

Afin de résoudre ce problème, vous devez ajouter le serveur Cisco-recommandé de SFTP comme périphérique de sauvegarde. Vous pouvez utiliser des n'importe quels de ces serveurs de SFTP :

  • Ouvrez le SSH — pour des systèmes Unix

  • Cygwin leavingcisco.com

  • Titan leavingcisco.com

  • Serveur de GlobalSCAPE EFT — autrefois connu sous le nom de GlobalSCAPE sécurisez le ftp server

Cisco recommande les Produits de SFTP qui sont certifiés avec Cisco par le programme partenaires de développeur de technologie Cisco (CTDP).

Référez-vous configurent le serveur de sauvegarde pour le pour en savoir plus de Cisco Unified Communications Manager.

Incapable de restaurer le serveur CUCM 8.x

Problème

Ce message d'erreur apparaît quand vous essayez de restaurer CUCM 8.5 :

digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Solution

Cette erreur se produit si des DN étaient configurés quand la sauvegarde a été prise, mais elle n'a pas été configurée quand la restauration est faite. Afin de résoudre ce problème, terminez-vous les étapes :

  1. Configurez les DN avant que vous exécutiez la restauration.

  2. Assurez-vous que le FQDN du serveur est résoluble par des DN.

    Remarque: Ceci est documenté dans l'ID de bogue Cisco CSCtk05743 (les clients enregistrés seulement)

Incapable de restaurer CUCM 8.5

Problème

Incapable de restaurer un serveur 8.5, donnant l'erreur suivante :

digital envelope routines:EVP_DecryptFinal:bad
decrypt:evp_enc.c:438:

Solution

Cette question peut se produire s'il y a n'importe quelle non-concordance de mot de passe IP/adresse Internet/Sécurité. Cependant, dans ce cas tous sont appariés.

La question est par rapport aux DN/information de domaines n'étant pas configuré sur le serveur pour apparier. Ceci se produira si des DN étaient configurés quand la sauvegarde a été prise, mais elle n'a pas été configurée quand la restauration est faite.

Pour résoudre ce problème configurez les DN avant d'exécuter la restauration. Assurez-vous que le FQDN du serveur est résoluble par des DN.

Remarque: Ceci est documenté dans l'ID de bogue Cisco : CSCtk05743 (clients enregistrés seulement)

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 111796