Panne de renégociation de batterie d'Unity Connection dépannant TechNote

Introduction

Ce document décrit les étapes pour vérifier et tenter pour aborder la question pour la panne de renégociation de batterie dans le Cisco Unity Connection (CUC).

Conditions préalables

Conditions requises

Cisco recommande que vous ayez la connaissance sur le Cisco Unity Connection.

Composants utilisés

Cisco recommande que vous ayez la connaissance de ce thème :

• Version 8.5 ou ultérieures d'Unity Connection

Informations générales

Généralement, chaque panne finit avec cette déclaration :

La renégociation de batterie a manqué.

Le log cuc-cluster-rejoin_yyyy-mm-dd_hh.mm.ss.log de renégociation de batterie peut être trouvé à l'installation se connectant l'emplacement par l'outil CLI ou de suivi en temps réel (RTMT).

Afin d'obtenir ce log du CLI, vous avez besoin d'un serveur de SFTP pour transférer le fichier, et vous devez sélectionner cette commande : le fichier obtiennent installent cuc-cluster-rejoin_yyyy-mm-dd_hh.mm.ss.lo g

ou

De l'outil de suivi en temps réel (RTMT), choisissez le suivi et le central de log > collectent installent des logs > sélectionnent le noeud > poursuivent.

Dans quelques scénarios, les 10 dernières lignes du log fournissent le message d'erreur ; Par conséquent, il peut être visualisé sur le CLI. Sélectionnez cette commande CLI : la queue de fichier installent cuc-cluster-rejoin_yyyy-mm-dd_hh.mm.ss.log pour visualiser les 10 dernières lignes du log.

Note: La batterie de cuc d'utils renégocient la commande est exécutée sur le serveur d'abonné seulement et copie la base de données du serveur d'abonné sur le serveur de Publisher et établit la réplication.

Dépannez

Cette section fournit des conseils utilisés afin de dépanner la panne de renegotiatio de batterie.

Panne de renégociation de batterie

Problème : Scénario 1

La commande de renégociation échoue à la dernière étape.

Cette sortie témoin est vue sur le serveur de Publisher :

13/12/01 14:32:15 Disabling data replication...
13/12/01 14:32:28 Renegotiating ssh trusts...
13/12/01 14:32:36 Synchronizing platform and LDAP database...
13/12/01 14:35:20 Creating any missing messaging databases on the publisher...
13/12/01 14:35:23 Adding subscriber node to publisher...
13/12/01 14:35:30 Synchronizing Unity Connection databases...
13/12/01 14:43:19 Synchronizing file systems...
13/12/01 14:43:23 Synchronizing message files for mail store UnityMbxDb1...
13/12/01 14:43:25 Copying cluster DSCP configuration to publisher node...
13/12/01 14:43:27 Rebooting publisher node CUC-9A...

Cluster renegotiation failed.

Analyse de log

+ sudo -u cucluster ssh CUC-9A /usr/local/cm/bin/controlcenter.sh 
'Service Manager' stop
++ error
++ '[' 0 -eq 1 ']'
++ '[' 0 -eq 1 ']'
++ echo 'Cluster renegotiation failed.'
++ echo 'The cluster renegotiation log cuc-cluster-rejoin
_2013-12-01_14.32.15.log can be found in the installation logging location through the CLI or RTMT.'
++ exit 1

Solution

L'analyse de suivi prouve que le serveur est affecté par l'ID de bogue Cisco CSCul75841. Il échoue à la dernière étape quand vous essayez d'arrêter le gestionnaire de services. Afin de résoudre ce problème, redémarrez le serveur de Publisher ou écrivez cet overwritedb de batterie de cuc d'utils de commande sur le serveur de Publisher.

Problème : Scénario 2

La mise à jour échoue sur le serveur d'abonné quand l'un ou l'autre de ces comnands CLI est écrit :

l'overwritedb de batterie de cuc d'utils échoue sur le BAR ou le SOUS-TITRE

la batterie de cuc d'utils renégocient échoue sur le SOUS-TITRE

La même question est vue pendant l'installation d'abonné.

La cause principale de cette question est qu'elle n'établit pas la réplication à l'étape de serveur de définir.

Analyse de log

Pour la renégociation de batterie/panne d'OverwriteDB

+ sudo -u informix cdr define server -A /var/opt/cisco/connection/spool/ats/ -c g_ciscounity_sub1 -I g_ciscounity_sub1 -S g_ciscounity_pub
command failed -- fatal server error (100)
++ error
++ '[' 0 -eq 1 ']'
++ echo 'Cluster renegotiation failed.'

Or 

the same errors with the last line as
++ echo 'Cluster overwritedb failed.'

Pour l'abonné installez la panne

Thu Oct 17 06:09:47 GMT+2 2013 + sudo -u informix cdr define server -A /var/opt/cisco/connection/spool/ats/ -c g_ciscounity_pub -I g_ciscounity_pub
Thu Oct 17 06:13:07 GMT+2 2013 command failed -- fatal server error (100)
Thu Oct 17 06:13:07 GMT+2 2013 + LOADDBRC=100Thu Oct 17 06:13:07 GMT+2 2013 + '[' 100 -ne 0 ']'Thu Oct 17 06:13:07 GMT+2 2013 + echo 'loaddb.sh return code was 100'Thu Oct 17 06:13:07 GMT+2 2013 loaddb.sh return code was 100Thu Oct 17 06:13:07 GMT+2 2013 + exit 1Thu Oct 17 06:13:07 GMT+2 2013 /opt/cisco/connection/lib/install/post.d/06_load-database had an exit code of 1error: %post(cuc-9.1.1.10000-32.i386) scriptlet failed, exit status 1

Solution

L'analyse de suivi prouve que le serveur est affecté par l'ID de bogue Cisco CSCue78730. Afin de fonctionner autour de cette question, contact Cisco TAC. Alternativement, promouvez le serveur à une version corrigée du défaut.

Problème : Scénario 3

La renégociation échoue tout en renégociant des confiances de ssh dans la deuxième étape.

Analyse de log

+ echo '11/11/30 20:57:24 Renegotiating ssh trusts..
+ /opt/cisco/connection/lib/install/post.d/02_authorize-cucluster
+ . /usr/local/bin/base_scripts/icluster.sh
++ '[' -n '' ']'
++ IPM_BAD_REMOTE_FILE_ERROR=12
++ IPM_BAD_REMOTE_DIR_ERROR=13
The fingerprint for the RSA key sent by the remote host
is bb:c0:b3:a7:08:07:ef:0c:f9:86:11:1d:a2:99:5e:8a.
Please contact your system administrator.
Add correct host key in /home/sftpuser/.ssh/known_hosts to get rid of this message.
Offending key in /home/sftpuser/.ssh/known_hosts:5

Solution

Terminez-vous ces étapes, afin de résoudre ce problème :

1. Assurez-vous que le mot de passe de Sécurité est même sur les les deux les serveurs.
2. Remettez à l'état initial le mot de passe de Sécurité s'il y a lieu.
3. Si la question existe toujours, le contact Cisco TAC pour vérifier les known_hosts classent de la racine.

Problème : Senario 4

Renégociez échoue à cette étape,
hh yy/mm/dd : millimètre : solides solubles synchronisant des bases de données d'Unity Connection…
La renégociation de batterie a manqué.

Analyse de log

+ sudo -u informix cdr define server -A /var/opt/cisco/connection/spool/ats/ -c g_ciscounity_sub1 -I g_ciscounity_sub1 -S g_ciscounity_pub connect to g_ciscounity_sub1 failed
Incorrect password or user g_ciscounity_sub1 is not known on the database server.
(-951)command failed -- unable to connect to server specified (5)

Solution

Terminez-vous ces étapes, afin de résoudre ce problème :

1. Assurez-vous que les entrées de Domain Name Server (DN)/nom de domaine sont correctes si elles sont « placent » sur les les deux les serveurs.
2. Assurez-vous qu'il n'y a aucun DN d'inverse que des questions de consultation avec les utils diagnostiquent le testcommand.
3. Si la question existe toujours, contactez Cisco TAC pour vérifier le divers fichier d'hôtes. La question pourrait être avec les rhosts et le fichier de SQLhosts.

Problème : Scénario 5

La renégociation échoue pendant qu'elle le script ne crée pas des bases de données sur le serveur de Publisher.

Analyse de log

+ python - -s ciscounity /opt/cisco/connection/lib/config-modules/dbscripts/mailstore/add-missing-mbxdb-space.sh: line 37: cannot create temp file for here document: Permission denied++ error ++ '[' 0 -eq 1 ']' ++ echo 'Cluster renegotiation failed.

Solution

L'analyse de suivi prouve que le serveur est affecté par l'ID de bogue Cisco CSCtr18463. Afin de résoudre ce problème, améliorez la version à une version corrigée.

Problème : Scénario 6

La renégociation de batterie échoue en raison des questions de NTP.

Analyse de log

+ sudo -u informix cdr define server -A /var/opt/cisco/connection/spool/ats/ -c g_ciscounity_sub1 -I g_ciscounity_sub1 -S g_ciscounity_pub
command failed -- System clocks difference is too large. 
(90)
++ error
++ '[' 0 -eq 1 ']'
++ echo 'Cluster renegotiation failed.'

Solution

Afin de résoudre ce problème, vous devez réparer toutes les questions de Protocole NTP (Network Time Protocol), et assignez un NTP avec une bonne valeur de strate. Pour l'Unity Connection, une strate 1 ou la source 2 est préférée.

Problème : Scénario 7

L'erreur suivante est affichée quand la renégociation échoue.

SSH trust renegotiation failed.The security password on the publisher and subscriber servers do not match.
 Run the the CLI command "set password user security" on one or both servers to update the security password, then re-run "utils cuc cluster renegotiate".
Cluster renegotiation failed.

Solution

Terminez-vous ces étapes, afin de résoudre ce problème :

1. Écrivez cette Sécurité d'utilisateur de set password de commande CLI sur les un ou les deux les serveurs pour mettre à jour le mot de passe de Sécurité.
2. Cette erreur pourrait se produire quand l'adresse IP/adresse Internet de l'abonné n'est pas présentée dans les paramètres système de l'éditeur et la page de batterie.
3. Si la question existe toujours, contactez Cisco TAC.

Problème : Scénario 8

La renégociation échoue avec cette erreur dans les logs.

Analyse de log

+ /opt/cisco/connection/lib/install/post.d/sync-cucli-credentials cuc01Going to Sync cucli hash from shadow the node at cuc01...Cannot find platformConfig.xml in /usr/local/platform/conf /tmp /commonFATAL ERROR: Cannot initialize internal variable: Cannot initialize the icluster internal dataCannot initialize the iCluster Library++ error++ '[' 0 -eq 1 ']'++ echo 'Cluster renegotiation failed.'

Solution

Terminez-vous ces étapes, afin de résoudre ce problème :

1. Assurez-vous que tous les services exigés sont fonctionnels avec l'utilisation de cette liste de service d'utils de commande.
2. Entrez dans ce système d'exploitation d'utils de commande le permissiveand que sécurisé a placé les les deux les serveurs en mode laxiste.
3. Exécutez la commande de renégociation sur l'abonné. Des réinitialisations de Publisher après renégociation est terminées.
4. Écrivez les utils de cette commande que le système d'exploitation sécurisé imposent et ont placé les les deux les serveurs imposent dedans le mode.

Problème 9

Cette erreur est affichée quand la renégociation échoue.

Analyse de log

+ sudo -u cucluster ssh cuc01 'sh -lc '\''source /usr/local/cm/db/informix/local/ids.env && ontape' -s -L 0 -F -t 'STDIO'\'''
+ target_exec 't=$(mktemp); ontape -r -v -t STDIO > $t 2>&1; rc=$?; cat $t; exit $rc'
+ sudo -u cucluster ssh cuc01 ' sh -lc '\''source /usr/local/cm/db/informix/local/ids.env && t=$(mktemp); ontape -r -v -t STDIO > $t 2>&1; rc=$?; cat $t; exit $rc'\'''
Server is in an incompatible state or user authentication failed.
Physical restore failed - function read archive backup failed code -1 errno 0

Analyse de log - Avant l'erreur

++ hostname
++ get_primary_hostname
++ is_primary
+++ get_platform_config_value CcmFirstNode
+++ xml sel -t -v /PlatformData/CcmFirstNode/ParamValue
/usr/local/platform/conf/platformConfig.xml
++ test yes == yes
++ hostname
+ /opt/cisco/connection/bin/copy-informix-instance -s ccm@cuc01
-t ccm@cuc01
source=ccm@cuc01
target=ccm@cuc01

Solution

L'analyse de log prouve que l'adresse Internet reste la même pour la source et la cible. La question se produit quand la commande de renégociation est exécutée sur Publisher. Cette commande devrait être exécutée sur le serveur d'abonné seulement.

Si vous exécutez la commande sur l'abonné divisez et vous recevez la même erreur, la question pourriez êtes provoqué par par les blocs supplémentaires de DB ajoutés sur le serveur d'abonné. Entrez en contact avec le TAC afin de fonctionner autour de cette question.