Voz y Comunicaciones unificadas : Cisco Unified Communications Manager Version 7.1

Administrador 7.x/8.x de las Comunicaciones unificadas de Cisco: Problema del respaldo del Troubleshooting

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Los respaldos de Cisco Unified Communications Manager no se ejecutan como estaba previsto. Todos los servicios del Marco de la recuperación de catástrofes (DRF) están inactivos, y no se puede ver ningún nuevo dispositivo, planificación o estado en la consola DRF. En este documento se describe cómo resolver este problema.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

La información en este documento se basa en el administrador 7.1(3)/8.x de las Comunicaciones unificadas de Cisco.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Problema

Los respaldos de Cisco Unified Communications Manager no se ejecutan como estaba previsto. Todos los servicios del Marco de la recuperación de catástrofes (DRF) están inactivos, y no se puede ver ningún nuevo dispositivo, planificación o estado en la consola DRF. También, cuando usted accede las páginas de administración DRF, se recibe este mensaje de error:

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

Esta RTMT alerta se recibe durante el error de reserva:

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

Solución

Primero, verifique si el número de serie del certificado en el keystore de Publisher está presente en el Truststore de todos los suscriptores. Complete estos pasos:

  1. Abra una sesión a la página de administración CUCM OS del servidor editor de la configuración del cluster. Elija el Certificate Management (Administración de certificados) de la Seguridad. Las visualizaciones de la ventana de la lista del certificado.

  2. Usted puede utilizar el hallazgo controla para filtrar el certificado.

  3. Haga clic en el archivo ipsec.pem y marque el número de serie del certificado.

  4. Abra una sesión a la página de administración CUCM OS de cada nodo del cluster. Elija el Certificate Management (Administración de certificados) de la Seguridad. Las visualizaciones de la ventana de la lista del certificado.

  5. Usted puede utilizar el hallazgo controla para filtrar el certificado.

  6. Haga clic en el archivo ipsec-trust.pem con el nombre del archivo del nombre de host del editor y marque el número de serie del certificado.

  7. El número de serie del certificado debe ser lo mismo en todos los Nodos del cluster. Si el número de serie de cualquier nodo se une mal, complete estos pasos.

    1. Abra una sesión a la página de administración CUCM OS del nodo afectado.

    2. Elija el Certificate Management (Administración de certificados) de la Seguridad. Las visualizaciones de la ventana de la lista del certificado.

    3. Usted puede utilizar el hallazgo controla para filtrar el certificado.

    4. Haga clic en el archivo ipsec.pem y descargue ese certificado.

    5. Encuentre la IPSec-confianza existente con el nombre de fichero del nombre de host del editor, haga clic en el nombre del archivo y borre.

    6. Cargue el archivo descargado ipsec.pem con la IPSec-confianza del encabezamiento.

    7. Recomience el agente local del master Agent(MA)/DRF DRF (LA).

Error: No puede escribir: Tubo roto

Respaldo DRF fallado con este mensaje de error:

/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 ...

Este problema se documenta en el Id. de bug Cisco CSCte62205 (el clientes registrados solamente)

Como intento uno de la solución alternativa de estos pasos:

  1. Mensajes ALIVE del cliente de la neutralización en el servidor SSH abierto

  2. Fije el ClientAliveCountMax y el ClientAliveInterval arriba bastante a una cuenta/a un intervalo así que el servidor no hace descanso la conexión a CUCM durante el respaldo.

  3. Recomience el agente local del master Agent(MA)/DRF DRF (LA).

Los DR cuelgan durante el respaldo CCMDB

Problema

Los DR cuelgan durante el respaldo CCMDB si hay número grande de archivos CDR/CMR acumulados en la carpeta del coto. Este problema se documenta en el Id. de bug Cisco CSCsl16967 (clientes registrados solamente).

Nota: Si usted para el servicio CAR, no para la acumulación de tablas CDR.

Solución

Complete estos pasos para resolver este problema:

  1. Complete estos pasos para limpiar los archivos CDR temporalmente de modo que los DR puedan proceder:

    1. Pare el servicio del agente CDR en todos los servidores en el cluster, para no avanzar ningún nuevo archivo CDR al editor.

    2. Funcione con este comando para verificar que todos los archivos se han avanzado a los servidores de la factura:

      file list activelog /cm/cdr_repository/destination/*
      
  2. Complete estos pasos para verificar que no hay links simbólicos en el subfolders un de los:

    1. Pare el administrador repositorio CDR, el Planificador de CAR, y el servicio web CAR en el editor.

    2. Utilice este comando para quitar todos los archivos bajo /var/log/active/cm/cdr_repository/preserve/ <date> se han acumulado que:

      file delete activelog /cm/cdr_repository/preserve/* noconfirm
      
    3. Utilice este comando para quitar todos los links simbólicos bajo /var/log/active/cm/cdr_repository/car/ <date>:

      file delete activelog /cm/cdr_repository/car/* noconfirm
      
    4. Recomience el administrador repositorio CDR, el Planificador de CAR, y los servicios web CAR en el editor.

  3. Complete estos pasos para parar la acumulación adicional de archivos CDR:

    Nota: Para parar la acumulación adicional de archivos CDR, usted debe comenzar el servicio del Planificador de CAR, fija el cargador para programar el cargamento continuo, y la carga CDR solamente.

    1. Si todavía no se crea, cree una cuenta del ccmadmin en Administración del grupo de usuarios en la página del ccmadmin.

    2. Inicie sesión al CAR, y vaya al sistema > al planificador de trabajos > a la carga CDR.

    3. Marque el cargamento continuo 24/7 y las casillas de verificación de la carga CDR solamente, y haga clic la actualización.

    4. Elija la purgación automática del sistema > de la base de datos > de la base de datos de la configuración.

    5. Ingrese 1 para la edad mínima de los registros de detalles de la llamada y la edad máxima de los registros de detalles de la llamada, y haga clic la actualización.

    6. Elija los Config > la Generación automática/la alerta del informe.

    7. Para cada informe, elija discapacitado, y haga clic la actualización.

  4. Recomience el servicio del agente CDR en todos los servidores.

Error: El sistema es bloqueado actualmente por otro proceso. Intente por favor otra vez más adelante

Los respaldos DR paran para ejecutar automáticamente y cuando usted intenta un respaldo manual, usted consigue la operación de backup actualmente en curso. Espere e intente por favor después alguna vez del mensaje de error. Cuando usted intenta instalar una nueva versión o un archivo del POLI, usted consigue el sistema es bloqueado actualmente por otro proceso. Intente por favor otra vez el mensaje de error posterior. Este problema ocurre si DRF es respaldo programado el servidor CUCM automáticamente. Esto es documentada por el Id. de bug Cisco CSCsr87199 (clientes registrados solamente).

Solución

Reajuste el agente principal DRF para resolver el problema.

El respaldo falla con el error de winsock

Con CUCM 8.x, el respaldo falló con el mensaje de error del error de winsock 10054/10035/10053.

Solución

Aseegurese que el Firewall está inhabilitado en el dispositivo de backup remoto y realice el respaldo otra vez.

El respaldo DRF hace no los Certificados de reserva

Con CUCM 8.x, en un servidor restablecido actualización del Bridge, el archivo ITL no tiene un firmante válido. Los teléfonos no tienen los servicios del https si el editor es el servidor TFTP. En una migración al UCS, o ningún nuevo hardware donde se realiza un de reserva y un restore, los teléfonos no validan los archivos de configuración y los cambios del nuevo cluster sin la Eliminación manual de la ITL existente de los teléfonos.

Cuando usted restablece de una situación de recuperación de desastre, los teléfonos reconocen no más su configuración o los archivos ITL después del restore DR si el servidor restablecido era el servidor TFTP. Los teléfonos pueden no reconocer los cambios de configuración o las actualizaciones hasta que su ITL existente se borre y se substituya por la ITL nuevamente generada.

También, cuando usted publica el comando CLI ITL de la demostración en los servidores, este mensaje de error aparece:

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

Este problema es documentado por el Id. de bug Cisco CSCtn50405 (clientes registrados solamente).

Solución

Después de una situación de la migración de la Recuperación tras desastres o del hardware, complete estos pasos.

  1. Regenere el archivo CallManager.pem (solamente en el servidor restablecido) para sincronizar el archivo CallManager.pem en el sistema de archivos al que está en la base de datos.

  2. Recomience los TV y el TFTP.

  3. Para un cluster del nodo único, o solamente un servidor TFTP, borre el archivo ITL manualmente de todos los teléfonos en el cluster.

  4. Para un cluster multi del nodo, los teléfonos deben utilizar automáticamente los TV de los servidores alternos del grupo de CallManager para autenticar el nuevo archivo ITL. Alternativamente los teléfonos se pueden señalar a otro servidor TFTP en el cluster.

Después de que una actualización del Bridge, complete estos pasos.

  1. Regenere el archivo CallManager.pem (solamente en el servidor restablecido) para sincronizar el archivo CallManager.pem en el sistema de archivos al que está en la base de datos.

  2. Recomience los TV y el TFTP.

  3. Los teléfonos necesitan ser reajustados para descargar el nuevo archivo ITL, pero no deben necesitar hacer el archivo ITL borrar pues nunca habrían tenido un archivo válido ITL a descargar hasta ahora.

Mensaje de error: mún decrypt 16404:error

Con CUCM 8.x, el restore DR falla para los componentes TFTP con este mensaje de error

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

Solución

Este mensaje de error es una indicación de la discordancía de la dirección IP o del nombre de host. Aseegurese que el servidor CUCM tiene la misma dirección IP y nombre de host que en los servidores MCS de donde se localiza el respaldo. Si el nombre de host no es lo mismo que el servidor de backup, usted necesita modificar el nombre de host para ser lo mismo que el servidor de backup y ejecutar el restore otra vez.

Error en la página de reserva en CUCM

Problema

Cuando usted navega a la página de reserva, el agente local no está respondiendo. Esto puede deber dominar o el agente local que está abajo del mensaje de error aparece. Esto también sucede mientras que usted intenta agregar un dispositivo de reserva.

Solución

Complete estos pasos para resolver este problema:

  1. Inicie sesión a la página de administración CUCM OS.

  2. Elija el Certificate Management (Administración de certificados) de la Seguridad.

  3. Marque el número de serie para el archivo ipsec.pem.

  4. Asegúrese de que el número de serie haga juego el archivo ipsec-trust.pem para los suscriptores.

  5. Recomience el master de Cisco DRF y el servicio local DRF en Publisher.

  6. Active servicio TFTP.

Incapaz de agregar el dispositivo de backup

Problema

Usted no puede agregar el dispositivo de backup en la página CUCM DR.

Solución

Para resolver este problema, usted necesita agregar al servidor SFTP Cisco-recomendado como el dispositivo de backup. Usted puede utilizar de estos servidores SFTP:

  • Abra SSH — para los sistemas Unix

  • Cygwin leavingcisco.com

  • Titán leavingcisco.com

  • Servidor de GlobalSCAPE EFT — conocido antes como GlobalSCAPE asegure al servidor FTP

Cisco recomienda los Productos SFTP que se certifican con Cisco con el Partner Program del desarrollador de la tecnología de Cisco (CTDP).

Refiera al servidor de backup de la configuración para el administrador de las Comunicaciones unificadas de Cisco para más información.

Incapaz de restablecer el servidor CUCM 8.x

Problema

Este mensaje de error aparece cuando usted intenta restablecer CUCM 8.5:

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

Solución

Este error ocurre si el DNS fue configurado cuando el respaldo fue tomado, pero no fue configurado cuando se está haciendo el restore. Para resolver este problema, complete los pasos:

  1. Configuración DNS antes de que usted realice el restore.

  2. Asegúrese de que el FQDN del servidor sea resolvable por el DNS.

    Nota: Esto se documenta en el Id. de bug Cisco CSCtk05743 (el clientes registrados solamente)

Incapaz de restablecer CUCM 8.5

Problema

Incapaz de restablecer un servidor 8.5, dando el error siguiente:

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

Solución

Este problema puede ocurrir si hay cualquier discordancía del IP/del nombre de host/de la contraseña de seguridad. Sin embargo, en este caso todos se corresponden con.

El problema está en relación con el DNS/la información sobre el dominio que no son configurados en el servidor para hacer juego. Esto ocurrirá si el DNS fue configurado cuando el respaldo fue tomado, pero no fue configurado cuando se está haciendo el restore.

Para resolver este problema configure el DNS antes de realizar el restore. Asegúrese de que el FQDN del servidor sea resolvable por el DNS.

Nota: Esto se documenta en el Id. de bug Cisco: CSCtk05743 (clientes registrados solamente)


Información Relacionada


Document ID: 111796