Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

Mise à niveau d'une grappe Cisco CallManager

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document est destiné pour fournir quelques suggestions de haut niveau pour que la façon améliore une batterie de Cisco CallManager. Les notes d'installation qui accompagnent le logiciel Cisco CallManager fournissent toutes les informations détaillées concernant des étapes d'installation. Ce document, cependant, aborde certaines des autres questions qu'une mise à jour de batterie présente.

Conditions préalables

Conditions requises

Vérifiez ces éléments avant que vous commenciez la mise à jour :

  • Exécutez les derniers correctifs OS/BIOS.

    Référez-vous à la Téléphonie sur IP BIOS de Cisco et à la feuille de route de version du système d'exploitation pour les informations sur la façon dont maintenir vos serveurs de Téléphonie sur IP de Cisco à jour.

  • Vérifiez que le service MSSQL fonctionne. Sinon, vérifiez le mot de passe de SQLSvc.

    Référez-vous à récupérer un mot de passe de compte de SQLSvc.

  • Visualisez la matrice de compatibilité logicielle de Cisco Unified Communications Manager pour les informations sur la compatibilité de solutions de Téléphonie sur IP.

  • Vérifiez que tous les serveurs dans votre batterie utilisent le même DB sous le START > RUN > le REGEDIT > le HKEY_LOCAL_MACHINE \ logiciel \ Cisco Systems, inc. \ DBL.

    Vérifiez que DBConnection 0 (sous le nom de SERVER=Publisher et le DATABASE=CCM030X) est le dernier sur le serveur d'éditeur, tandis que DBConnection 1 devrait indiquer au nom d'abonné et la plus défunte base de données Cisco CallManager.

  • Vérifiez que la réplication est correcte sur tous les serveurs qui utilisent le gestionnaire d'entreprise de Microsoft SQL. Ceci se trouve au début > aux programmes > à la Microsoft SQL Server 7.0 > gestionnaire d'entreprise.

  • Désactivez tous les anti services de détection de virus approuvés par Cisco et d'intrusion.

  • Vous avez plus de 1 yole de l'espace libre. Ceci est recommandé.

    Remarque: Veillez à désactiver les suivis de CallManager et à supprimer les fichiers inutilisés tels que des fichiers de suivi afin de libérer l'espace.

  • N'utilisez pas les services de terminaux, car il n'est pas pris en charge. Au lieu de cela, utilisation Virtual Network Computing (VNC) qui est prise en charge.

Remarque: Si vous avez un contrôleur d'incursion, enlevez un disque avant que vous vous promouviez et veilliez pour avoir une sauvegarde de la dernière version. Ceci te permet de retourner à la configuration en cours précédente au cas où la mise à jour échouerait.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

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

Améliorez Publisher

Puisque la batterie de Cisco CallManager est basée autour des relations de base de données d'éditeur/abonné, il est important de promouvoir l'éditeur d'abord. Quand une mise à jour se produit, une nouvelle base de données est créée sur l'éditeur et des données de la vieille base de données sont migrées vers elle. Ceci permet à toutes les nouvelles modifications au schéma de bases de données d'être facilement manipulées. Quand des abonnés sont ajoutés, ils s'abonnent à la nouvelle base de données sur l'éditeur. C'est pourquoi l'éditeur doit être mis à jour d'abord. Un abonné ne peut pas s'abonner à une base de données qui n'existe pas encore. Ce diagramme montre les relations d'éditeur/abonné, aussi bien que les relations de signalisation d'appel.

Remarque: Le serveur CallManager qui a l'ID CTI = 1 peut être identifié en tant que serveur de Publisher. Afin de trouver l'ID CTI, allez CCM à la page Web > au système > au Cisco CallManager d'admin, du résultat de la recherche cliquez sur en fonction le serveur et vérifiez l'ID CTI.

/image/gif/paws/7426/40784.gif

Est-ce que je dois réduire tous les Cisco CallManagers pour une mise à jour ?

Non. Dans un grand campus, il peut imposer sur un serveur du protocole DHCP (DHCP) pour recevoir des demandes d'adresse IP des milliers de téléphones pendant quelques heures. Ou, il pourrait être indésirable pour que tous les services de téléphonie soient vers le bas pendant un temps étendu de mise à jour. Tandis que des mises à jour devraient être exécutées après des heures, il est possible dans de nombreux cas de garder une partie de l'exécution de batterie pendant une mise à jour. Ceci peut être fait en utilisant les redundancy group de Cisco CallManager. Essentiellement, alors qu'un serveur est mis à jour, les supports de sauvegarde tous les téléphones. Ce document discute trois modèles standard de déploiement.

Configurations du cluster recommandées

2,500 téléphones - Total de trois serveurs

Batterie de Cisco CallManager pour jusqu'à 2500 utilisateurs :

  • Le serveur A est un éditeur de base de données et un serveur dédiés de Protocole TFTP (Trivial File Transfer Protocol).

  • Le serveur B est le Cisco CallManager primaire pour tous les périphériques enregistrés.

  • Le C de serveur est le Cisco CallManager de sauvegarde pour tous les périphériques enregistrés.

Dans cette configuration, seulement un seul redundancy group de Cisco CallManager est prié pour les serveurs B et le C.

  1. Puisque l'éditeur est le premier à mettre à jour, c'est où le processus commence. Publisher A est seulement le serveur de base de données, ainsi il peut être mis et redémarré à jour.

  2. La mise à jour peut commencer pour le C de Cisco CallManager. Puisque le C de Cisco CallManager est la sauvegarde et n'a aucun périphérique enregistré à elle, le Traitement des appels n'est pas interrompu. Supplémentaire, si vous améliorez le Cisco CallManager de sauvegarde avant le Cisco CallManager primaire, ceci s'assure que les périphériques doivent seulement améliorer leur micrologiciel une fois.

  3. Le Cisco CallManager primaire B peut être mis à jour. Quand les débuts de mise à jour, le service de Cisco CallManager est arrêtés et le Basculement de périphériques au C de sauvegarde de Cisco CallManager. Il y a une légère interruption en service tandis que les périphériques enregistrent et reçoivent des mises à jour du firmware.

  4. La dernière étape du processus de mise à niveau est de redémarrer tous les serveurs dans la batterie. Commencez par redémarrer Publisher R. Une fois la réinitialisation est complète, le Cisco CallManager B. de réinitialisation. Quand le serveur revient sur la ligne, attendez 5 à 10 minutes pour permettre aux périphériques pour commencer le processus de restauration. En conclusion, C de Cisco CallManager de réinitialisation. La mise à jour de batterie est maintenant complète.

5,000 téléphones - Total de quatre serveurs

Batterie de Cisco CallManager pour jusqu'à 5000 utilisateurs :

  • Le serveur A est un éditeur dédié de base de données et serveur TFTP.

  • Le serveur B est le Cisco CallManager primaire pour les Téléphones IP 1 à 2500.

  • Le C de serveur est le Cisco CallManager primaire pour les Téléphones IP 2501 à 5000.

  • Le serveur D est le Cisco CallManager de sauvegarde pour tous les périphériques enregistrés.

Dans cette configuration, deux redundancy group de Cisco CallManager sont priés. On est pour les serveurs B et D et l'autre est pour le C de serveurs et le D.

Dans ce scénario, il y a deux Cisco CallManagers primaires avec une sauvegarde. Si chaque primaire a 2,500 téléphones, vous ne pouvez pas arrêter les deux serveurs primaires pour la mise à jour. La sauvegarde finirait par avec 5,000 périphériques, qui violeraient la limite 2,500.

  1. Publisher A est mis à jour d'abord. Puis, le Cisco CallManager D devrait être mis à jour. Jusqu'à ce point, le Traitement des appels n'a pas été interrompu.

  2. Une fois que le Cisco CallManager D est de nouveau, commencez la mise à jour sur le Cisco CallManager B. Une fois les débuts de mise à jour, le Basculement de périphériques au Cisco CallManager D. Il y a une légère interruption de service car les périphériques enregistrent et reçoivent des mises à jour du firmware. Quand le Cisco CallManager B revient sur la ligne, attendez 5 à 10 minutes les périphériques à la restauration.

  3. C de Cisco CallManager de mise à jour. Il y a une légère interruption de service car les périphériques s'inscrivent au Cisco CallManager D et reçoivent des mises à jour du firmware.

  4. Afin de terminer le processus de mise à niveau, tous les serveurs dans la batterie doivent être redémarrés. Réinitialisation Publisher A d'abord. Quand la réinitialisation se termine, redémarrez le Cisco CallManager B. Quand B revient sur la ligne, attendez 5 à 10 minutes les périphériques à la restauration. Ensuite, le C de Cisco CallManager de réinitialisation et l'attente jusqu'au serveur revient sur la ligne. En conclusion, Cisco CallManager D. de réinitialisation. La mise à jour de batterie est maintenant complète. Cette situation fait être la moitié des téléphones en baisse pendant la période de la deuxième mise à jour primaire. Tandis que ce n'est pas idéal, il réduit combien téléphones sont en baisse et pour combien de temps ils sont en baisse.

10,000 téléphones - Total de huit serveurs

Batterie de Cisco CallManager pour jusqu'à 10,000 utilisateurs :

  • Le serveur A est un éditeur dédié de base de données.

  • Le serveur B est un serveur dédié TFTP.

  • Le C de serveur est le Cisco CallManager primaire pour les Téléphones IP 1 à 2500.

  • Le serveur D est le Cisco CallManager primaire pour les Téléphones IP 2501 à 5000.

  • Le serveur E est le Cisco CallManager de sauvegarde pour les Téléphones IP 1 à 5000.

  • Le serveur F est le Cisco CallManager primaire pour les Téléphones IP 5001 à 7500.

  • Le serveur G est le Cisco CallManager primaire pour les Téléphones IP 7501 à 10,000.

  • Le serveur H est le Cisco CallManager de sauvegarde pour les Téléphones IP 5001 à 10,000.

Dans cette configuration, quatre redundancy group de Cisco CallManager sont priés pour le CE de serveurs, le De, le FH et le GH. Ce diagramme montre cette configuration :

/image/gif/paws/7426/42657.gif

  1. Promouvez l'éditeur.

  2. Promouvez le serveur TFTP.

    En ce moment, chacun des six serveurs Cisco CallManagers fonctionne et n'a pas été affecté toujours par la mise à jour. Ce scénario est juste comme celui décrit dans le scénario de 5,000 téléphones. La seule différence est qu'il y a deux ensembles de deux primaires avec une sauvegarde. Les Cisco CallManagers primaires sont C, D, F, et G. Les sauvegardes sont E et H. Primary C et échouer D à E. Primary F et échouer G au H.

  3. Les Cisco CallManagers de sauvegarde E et H devraient être mis à jour ensuite. Quand la mise à jour se termine, attendez les serveurs pour redémarrer et revenir sur la ligne.

  4. Maintenant C et F de Cisco CallManagers sont prêt à être mis à jour. Quand la mise à jour commence, les périphériques ont enregistré à ces Cisco CallManagers le Basculement aux sauvegardes. Il y a une légère interruption de service tandis que les périphériques enregistrent et reçoivent des mises à jour du firmware. Attente 5 à 10 minutes pour les périphériques à la restauration.

  5. Ensuite, les Cisco CallManagers D et le G sont mis à jour. Comme dans l'étape 4, il y a une légère interruption en service. Quand la mise à jour se termine, attendez les serveurs pour redémarrer et revenir sur la ligne.

  6. Afin de terminer la mise à jour, tous les serveurs dans la batterie doivent être redémarrés. Assurez-vous que chaque processus de réinitialisation est complet avant que vous commenciez le prochain groupe. Commencez en redémarrant Publisher R. Ensuite, réinitialisation TFTP B. Quand B est de retour sur la ligne, redémarrez C et F de Cisco CallManagers. L'attente 5 à 10 minutes pour les périphériques à la restauration et redémarrent alors les Cisco CallManagers D et G. En conclusion, Cisco CallManagers E de réinitialisation et H. La mise à jour de batterie est maintenant complète.

Examen : Les règles de la mise à jour de Cisco CallManager

Suivez ces règles quand vous améliorez le Cisco CallManager :

  • Promouvez toujours l'éditeur et le serveur autonome TFTP (si existe) d'abord.

  • Améliorez les Cisco CallManagers de sauvegarde en second lieu.

  • Améliorez les Cisco CallManagers primaires durent.

  • Après tout des Cisco CallManagers sont mis à jour, tous les serveurs doivent être redémarrés.

  • Assurez-vous que quand SA et les mots de passe administrateur sont placés elles sont identiques pour tous les serveurs dans la batterie.

Ce que faites quand l'installation/mise à jour échoue ?

Cisco CallManager 3.1 et 3.2

Recueillez ces logs :

  • C:\ *.log

  • C:\ *.txt

  • C:\Winnt\sti *.*

  • C:\dcdsrvr\log\ *.* (si la question est avec DCD)

  • C:\Install\DBInstall\ *.*

StiSetup.log fournit un aperçu des différentes étapes pendant l'installation/mise à jour. Dbinstall000.log fournit un aperçu sur quelles modifications sont faites à la database level.

Cisco CallManager 3.3

Recueillez ces logs :

  • Tous les *.txt et *.log classe dans le répertoire racine C:\

  • Tous les fichiers dans le C : \ Fichiers de programme \ fichiers communs \ répertoire de Cisco \ logs

  • Tous les fichiers dans la partition STI_DATA

  • Tous les fichiers dans le répertoire de C:\DCDSrvr\log (si les questions sont avec DCD))

Le CCMInst<date><time>.log fournit un aperçu des différentes étapes pendant l'installation/mise à jour. Le CCMDBSetup<date><time>.log fournit un aperçu sur quelles modifications sont faites à la database level.

Cisco CallManager 4.x

Obtenez et examinez tous les fichiers journal (*.log et *.txt) à partir de ces répertoires :

  • Tous les fichiers dans les fichiers de C:\Program Files\Common \ Cisco \ logs

  • Tous les fichiers dans C:\Program Files\Common classe \ Cisco \ répertoire

  • Tous les fichiers dans C:\Install\DBInstall

  • Tous les fichiers dans C:\Dcdsrvr\log

Non tous les messages d'erreur qui affichent dans le fichier journal sont catastrophiques. MSI génère des messages d'erreur dans le fichier journal pour de nombreuses raisons. Par exemple, tentatives d'accéder à un service que le Cisco CallManager n'utilise pas.

Référez-vous à améliorer le pour en savoir plus du Cisco CallManager 4.x.

Remarque: Employez l'utilitaire d'admin seulement dans Publisher afin de résoudre des problèmes de synchronisation de mot de passe.

Visualisateur d'événements : Format des logins .evt d'application et de système

Remarque: Non toutes les erreurs associent aux problèmes réels. Vérifiez toujours avant que vous ouvriez une valise avec le support technique de Cisco.

Référez-vous au pour en savoir plus de journaux d'événements de CallManager. Ce document est mis à jour fréquemment.

Les logs que vous rassemblement êtes utile pour que l'ingénieur TAC étudie votre question en profondeur. Par conséquent, mettez à jour toujours le cas TAC avec ces logs comme ceci accélère le processus de résolution.

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: 7426