Installez la VM de Touchless pour CUCM

Introduction

Ce document décrit la caractéristique d'installation du virtual machine de Touchless (VM) qui est introduite dans Cisco Unified Communications Manager (CUCM) 10.5.2 et releases plus élevées.

Conditions préalables

Conditions requises

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

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Image de démarrage pour l'Unity Connection CUCM/Cisco (CUC)/Messagerie instantanée et la présence (IM&P) pour la version 10.5.2 et ultérieures
• Ouvrez les archives de virtualisation (OVULES) pour UC 10.5.2.
• Image souple virtuelle créée avec la sortie de l'outil du générateur de fichier de réponse (AFG). 

La procédure pour créer l'image souple virtuelle avec l'outil AFG est documentée dans le lien suivant. Ce site Web fournit des instructions pour de plusieurs plateformes cliente telles que Windows, le Mac OS X et le Linux.

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.

Configurez

Utilisez l'outil AFG pour générer un fichier d'image souple. Cette image souple contient le fichier platformConfig.xml et le clusterConfig.xmlfile pour l'éditeur CUCM et seulement le platformConfig.xmlfile pour tous autres Noeuds qui incluent les abonnés CUCM, l'abonné PIM Publisher et PIM.

Débuts d'installation en initialisant les Noeuds VM avec l'image souple et l'OIN amorçable étant montées. Suivant la procédure d'installation VM de Touchless, aucune intervention manuelle n'est exigée pendant l'installation d'un noeud autonome ou pendant l'installation de batterie.

Avec cette configuration, l'installation entière de batterie peut être mise sur pied en même temps. L'abonné devra attendre l'éditeur pour être livré en ligne au cas où l'installation de Publisher serait encore en cours. Sur la fin de l'installation d'éditeur, les abonnés attendants seront ajoutés à sa table des serveurs. Une fois que les abonnés sont ajoutés à l'éditeur, les abonnés peuvent poursuivre le leur installent.

Une coordination collective du gestionnaire de batterie (CLM) et du service arriviste fait cet échange d'informations entre l'éditeur et l'abonné possibles. Cette installation simplifiée de batterie peut être réalisée par la configuration du cluster de prédéfinis générée utilisant l'outil AFG. En cela, l'éditeur a les informations complètes sur ses Noeuds d'abonné à partir de fichier clusterConfig.xml. Publisher emploie ces informations pour ajouter ces Noeuds à sa table de processnode/application après que l'éditeur soit avec succès installé.

Avant de commencer, faites la note qu'il y a une nouvelle caractéristique qui a été ajoutée. C'est configuration du cluster dynamique.

1. Les nouveaux Noeuds d'abonné obtiennent ajouté à la table des serveurs de Publisher automatiquement quand ils sont livré en ligne et essayent d'authentifier avec Publisher. Pour que ceci se produise, la dynamique-batterie-configuration doit être activée d'abord.
2. Ceci peut être activé par l'intermédiaire de l'outil AFG ou par l'intermédiaire de l'interface de ligne de commande (CLI).
3. Avec ce cadre, vous n'avez pas besoin devez manuellement ajouter les petits groupes de l'abonné en page du serveur de Publisher.

Comme partie de cette caractéristique, vous devez pouvoir générer le fichier platformConfig.xml et le clusterConfig.xmlfile de l'outil AFG. En outre, vous devez pouvoir à la valeur de temporisateur de configuration de DynamicCluster de specifythe être utilisé et fournir un clusterConfig.xmlfile prêt à l'emploi. Si la dynamique-batterie-configuration est utilisée, vous devez pouvoir ajouter des détails de valeur du dépassement de durée pour la dynamique-batterie-configuration.

Vous pouvez trouver la valeur dynamique de temporisateur de configuration du cluster dans le fichier platformconfig.xml de l'éditeur :

<PostInstallAutoRegister>
  <ParamNameText>
    Number of Seconds to Enable Auto Register Post-Install on Pub
  </ParamNameText>
  <ParamDefaultValue>0</ParamDefaultValue>
 

 <ParamValue>1000</ParamValue>

</PostInstallAutoRegister>

Dès que le fichier sera créé, un événement arriviste est envoyé déclarant que le fichier est créé. À la réception de l'événement, le service arriviste qui écoute l'événement arriviste configure le gestionnaire de batterie avec ce temporisateur.

Par exemple, si le temporisateur est configuré à 10 heures, les Noeuds CUCM Subsriber obtiennent ajouté au noeud de processus pour l'éditeur CUCM jusqu'à ce que le temps soit en hausse de l'éditeur de moment soit en ligne. Des Noeuds d'abonné peuvent être ajoutés à une date ultérieure à l'aide du <number de dynamique-batterie-configuration d'abonné de batterie de réseau de positionnement de la commande de hours> :

 là où      

<number de hours> - est une valeur entre 1 à 24

le par défaut - placera le vaule de dynamique-batterie-configuration à 24 heures

Une fois activée, la commande de batterie de show network donne la sortie suivante :

admin:show network cluster

10.106.61.120 CUCMPUB  Publisher callmanager DBPub authenticated
10.106.61.121 CUCMSUB  Subscriber callmanager DBSub authenticated using TCP since Fri Nov 28 17:59:21 2014
10.106.61.122 CUCMSUB1  Subscriber callmanager DBSub authenticated using TCP since Fri Nov 28 18:06:41 2014

Server Table (processnode) Entries
----------------------------------
CUCMPUB
10.106.61.121
10.106.61.122
Dynamic Cluster Configuration is enabled for 23 Hours 59 Minutes.

Remarque: Sur à l'aide du fichier clusterconfig.xml avec platformconfig.xmlfile, l'autoregister de Noeuds au bar CUCM, et donc le temporisateur disucssed au-dessus des supports inutiles. Le temporisateur est utile seulement où vous utilisez le fichier platformconfig.xml du serveur de Publisher, juste comme le bar CUCM est inconscient de tous autres Noeuds dans la batterie dans ce cas.

Dans ce scénario, vous allez construire 3 batteries de noeud (Publisher CUCMPUB et 2 abonnés CUCMSUB et CUCMSUB1) suivre les deux méthodes.

Sur 2 abonnés CUCM, installez CUCMSUB par l'intermédiaire du fichier clusterconfig.xml, et le CUCMSUB1 utilisant le procédé d'enregistrement automatique.

3 fichiers sont créés :

1. Fichier Platformconfig.xml pour le noeud primaire CUCMPUB
2. Fichier Platformconfig.xml pour le noeud secondaire CUCMSUB
3. Le fichier Clusterconfig.xml ont les détails pour la batterie entière. Semblable à platformconfig.xml, il contient la liste des informations d'adresses Internet, d'IP address, de domaine, de rôle et d'utilisation pour tous les périphériques dans la batterie.

Dans ce scénario, car vous utilisez CUCMSUB1 à installer par l'intermédiaire de l'enregistrement automatique, vous générez un autre fichier AFG qui est semblable à celui ci-dessus, et avez le fichier platformconfig.xml pour l'éditeur avec le nouveau platformconfig.xmlfor le CUCMSUB1.

Suivant les indications de cette image.

Une fois que nous avons le fichier clusterconfig.xml de l'éditeur, et platformconfig.xmlfile de tous les serveurs, il est temps de faire une image souple de la même chose.

Pour Publisher

Si vous aimez utiliser l'option dynamique de config de batterie, vous exigez de créer une image souple en combinant le les deux les fichier clusterconfig.xml et platformconfig.xmlfile de Publisher. La combinaison de les deux fichiers est seulement exigée pour l'éditeur, et pas pour n'importe quel autre serveur. Pour des abonnés, vous pouvez utiliser seulement le platformconfig.xmlfiles respectif.

Déploiement VM

Une fois que vous faites créer l'image souple, il est temps de monter le CD (avec l'image de démarrage .iso) aussi bien que le lecteur de disquette (avec l'image .flp que vous avez créée plus tôt).

Cette image affiche comment monter le CD :

Cette image affiche comment monter le lecteur de disquette :

Vous devez s'assurer que l'ordinateur VM est configuré pour démarrer de la CD-ROM. Sinon, vous pouvez modifier le réglage du bios pour permettre la même chose. Veuillez mettre sous tension les VMs. De cette étape en fonction, aucune intervention manuelle n'est exigée, et tous les serveurs doivent être installés. Dans ce scénario, car vous avez désactivé la configuration de dynamic auto, vous devez manuellement configurer le temporisateur, qui est affiché plus tard.

Une fois que les VMs ont été mises sous tension, il commence son processus d'étape de pré-démarrage où il te demande de tester les medias ou de continuer.

Cette image affiche la fenêtre de test de medias :

Les serveurs CUCM recherche le fichier clusterconfig.xml et le platformconfig.xmlfile pendant cette phase de pré-démarrage.

Vérifiez

Utilisez cette section pour confirmer que votre configuration fonctionne correctement.

Des logs d'installer de CUCMPUB, vous pouvez voir s'il a pu trouver les fichiers ou pas. Dans notre exemple,

    platformconfig.xm l fichier

11/28/2014 08:05:28 anaconda|Looking for platformConfig.xml...|<LVL::Info>
11/28/2014 08:05:28 anaconda|Find a platformConfig.xml file|<LVL::Info>
11/28/2014 08:05:28 anaconda|Check on /dev/fd0|<LVL::Debug>
11/28/2014 08:05:28 anaconda|Looking for platformConfig.xml on device /dev/fd0|<LVL::Info>
11/28/2014 08:05:28 anaconda

|Found platformConfig.xml on device /dev/fd0|<LVL::Info>

   fichier clusterconfig.xml

11/28/2014 08:05:28 anaconda|Copying /mnt/floppy/platformConfig.xml to /tmp/platformConfig.xml|<LVL::Debug>
11/28/2014 08:05:28 anaconda|Looking for clusterConfig.xml...|<LVL::Info>
11/28/2014 08:05:28 anaconda|Find a clusterConfig.xml file|<LVL::Info>
11/28/2014 08:05:28 anaconda|Check on /dev/fd0|<LVL::Debug>
11/28/2014 08:05:28 anaconda|Looking for clusterConfig.xml on device /dev/fd0|<LVL::Info>
11/28/2014 08:05:28 anaconda|

Found clusterConfig.xml on device /dev/fd0|<LVL::Info>

11/28/2014 08:05:28 anaconda|Copying /mnt/floppy/clusterConfig.xml to /tmp/clusterConfig.xml|<LVL::Debug>

Vous voyez le message semblable dans les logs pour les 2 autres abonnés.

Une fois que la phase de Pré-démarrage est terminée, 2 du début de serveurs avec la phase de POST-démarrage.

Cette image affiche la phase de POST-démarrage :

Car CUCM Publisher n'est pas installé, installation des interruptions d'abonné en ce moment de temps, car il ne peut pas trouver son entrée dans la table de processus de noeud de l'éditeur. L'avertissement a été modifié accrodingly, mentionnant que cela pour touchless installe, ceci est normal, alors que l'éditeur installs.take aucune action. Install reprendra automatiquement comme affichée est cette image.

Une fois que le CUCM Publisher est installé, un événement arriviste est envoyé pour annoncer qui installent est terminé. Le fichier de Processnode obtient créé, et il recherche le fichier clusterconfig.xml sur Publisher, pour voir quels Noeuds sont présents dans clusterconfig.xmlfile à ce moment-là. Dans ce cas il trouve un plus de noeud, et il ajoute ce noeud dans la base de données. Souvenez-vous pour le serveur CUCMSUB1, vous utilisez pour le procédé d'enregistrement automatique, et ses détails ne sont pas présents dans le clusterconfig.xmlfile de l'éditeur.

Un événement dans les logs d'installer est affiché.

Nov 28 16:44:37 CUCMPUB local7 6 Cisco: Database Layer Monitor: DBNotify SDI Initialization successful

Nov 28 16:44:37 CUCMPUB user 6 ilog_impl: emitted platform-event (--no-wait 

platform-system-processnode-created

)

Une fois que le CUCM Publisher ajoute les Noeuds à sa base de données, il y a une nouvelle section dans le fichier clusterconfig.xml qui s'appelle l'icl_state, et il marque l'état comme terminé. Ceci est exigé comme les besoins CUCM Publisher de regarder le fichier clusterconfig.xml peu de fois pendant l'installation globale. Si l'état a été marqué en tant que terminé, il connaît quel noeud s'est terminé l'installation.

Entre-temps, le gestionnaire de batterie de CUCMSUB, cependant pas complètement en ligne essaye toujours de voter le CUCM Publisher. Car Publisher n'est toujours pas installé, vous recevez une erreur suivant les indications des logs de ClusterManager :

09:48:53.054 |tcp connection closed to 

10.106.61.120

, back to initiator state
09:48:53.054 |exec'ing: sudo /root/.security/ipsec/disable_ipsec.sh --desthostName=CUCMPUB --op=delete
09:48:53.509 |Timeout or error() 115 - Operation now in progress, port 8500

09:48:53.509 |

tcp recv error: Connection refused.

09:49:15.773 |tcp connection closed to 

10.106.61.120

, back to initiator state
09:49:15.773 |exec'ing: sudo /root/.security/ipsec/disable_ipsec.sh --desthostName=CUCMPUB --op=delete
09:49:16.223 |Timeout or error() 115 - Operation now in progress, port 8500

09:49:16.223 |

tcp recv error: Connection refused

.

Maintenant une fois que l'installation d'éditeur est terminée et le fichier de processnode obtient créé, il visite son fichier clusterconfig.xml et ajoute l'autre noeud (CUCMSUB). Dès que le noeud obtiendra ajouté à la base de données, et l'événement arriviste est envoyé au CUCMPUB et au CUCMSUB.

Le gestionnaire de batterie de CUCMSUB reçoit l'état injecté par stratégie de CUCMPUB. Un événement arriviste est envoyé avec l'adresse Internet de CUCMPUB et de l'état injecté par stratégie. CUCMSUB afin d'essayer de créer une topologie à maillage avec d'autres serveurs reçoit l'événement arriviste de tous les autres serveurs, cependant, il est plus intéressé par l'événement arriviste qu'il reçoit avec l'adresse Internet du CUCMPUB en tant que lui reprend l'installation quand l'éditeur est en ligne. Une fois que le service arriviste reçoit l'événement arriviste, il envoie un signal de mise à mort à l'assistant d'installer. Ce les tentatives au revalidate le fichier platformconfig.xml, et consécutivement lui commence la validation de Connectivité par le CUCMPUB. Car l'éditeur est maintenant disponible, la validation réussit et l'installation continue.

Pour l'installation CUCMSUB1, vous exigez de modifier la valeur dynamique de configuration du cluster à n'importe quelle autre valeur, ainsi, que notre serveur obtient ajouté au processnode de l'éditeur. Dans cet exemple, vous avez modifié la même chose à 1 heure.

placez la commande de la dynamique-batterie-configuration 1 d'abonné de batterie de réseau.

Une fois la commande ci-dessus est appliquée, des accpets CUCMPUB la demande de registre de noeud de CUCMSUB1. Si la commande ci-dessus n'est pas configurée, quand les essais CUCMSUB1 pour contacter l'éditeur, les aspects d'éditeur dans son temporisateur d'automatique-Reg, si la valeur est 0, il n'ajoute pas le noeud dans sa table clusterconfig.xml aussi bien que de processnode.

Une fois que le CUCMSUB1 entre en contact avec CUCMPUB, il reçoit la connexion socket de CUCMSUB1(10.106.61.122), et il ajoute les données d'abonné au fichier clusterconfig.xml. 

Des logs de clusterManager de Publisher, cet événement est imprimé comme saveClusterSubscriberNodeData.

16:56:19.455 |

accepted client IP(10.106.61.122), socket(10):

16:56:24.489 | 

saveClusterSubscriberNodeData api, hostname=CUCMSUB1

, peerdat=icl_master=no icl_clustered=yes icl_deployment=callmanager icl_active_version=10.5.2.10000-2 icl_inactive_version=0.0.0.0000-0000 icl_active_unrest=false icl_inactive_unrest=false icl_disk_size=110 icl_mtu_changed=no icl_mtu_size= icl_app_uid=administrator icl_app_pw= icl_db_master=no icl_state=Installing icl_ip_address=10.106.61.122 icl_fqdn=CUCMSUB1 icl_domain= icl_pub_enc_dkey=

En raison de ce que le fichier clusterconfig.xml sur l'éditeur change, et cet événement est vu.

CUCMPUB user 6 ilog_impl: Received request for platform-event (platform-event-clusterconfig-changed)

L'installation du serveur continue là en fonction.

Une fois que les CUCMSUB et les CUCMSUB1 sont installés, vous recevez l'événement suivant plate--système-clusternode-installer-terminé des deux Noeuds. Cet événement est envoyé à chaque noeud dans la batterie.

STATE=ready indique que l'installation est terminée, d'autre il est en installant l'état.

Ce message est vu dans le Syslog CUCMPUB, cela signifie l'installation de CUCMSUB et CUCMSUB1 sont terminés.

Line 13154: Nov 28 17:59:17 CUCMPUB user 6 ilog_impl: emitted platform-event(--

no-wait platform-system-clusternode-install-completed HOSTNAME=CUCMSUB STATE=ready

)
Line 14514: Nov 28 18:06:36 CUCMPUB user 6 ilog_impl: emitted platform-event(--

no-wait platform-system-clusternode-install-completed

HOSTNAME=CUCMSUB1 STATE=ready

)

Dépannez

Il n'existe actuellement aucune information de dépannage spécifique pour cette configuration.

Commandes CLI qui ont été introduites dans cette caractéristique

1. placez le <ip> < nom de domaine > de <hostname> de type> de <server de petits groupes d'abonné de batterie de réseau

Cette commande est d'ajouter l'abonné à la table des serveurs de processnode/app.

Syntaxe :

Paramètres	Description
Type de serveur	Les valeurs sont CUCM ou PIM ou CUC (obligatoires)
IP	IP address de l'adresse Internet ajoutée (obligatoire pour PIM Publisher et CUC et facultatif pour d'autres Noeuds
le nom de domaine	Nom de domaine de l'éditeur PIM (obligatoire pour PIM Publisher et non requis pour d'autres Noeuds)

2. petits groupes supprimés d'abonné de batterie de réseau

Cette commande affiche le message mentionnant que l'abonné peut être supprimé du GUI. On ne permet pas l'exécution supprimée sur le CLI. Cette exécution peut seulement être faite de la page Web.

3. placez le dynamique-batterie-config d'abonné de batterie de réseau

Placez la dynamique-batterie-configuration d'abonné de batterie de réseau {<default> | < nombre d'heures >                

Ce dynamique-batterie-config de commandes enables sur l'éditeur.

              Description de la syntaxe

Paramètres	Description
par défaut	Ceci activera le dynamique-batterie-config pour 24hrs
<no. de hours>	Valeur entre 1-24 heures

4. batterie de show network

Cette commande affiche la valeur à jour de dynamique-batterie-configuration sur l'éditeur quand elle est activée.

Avantages

• Pour fournir un toucher moins de processus d'installation, dans lequel aucune intervention manuelle n'est exigée pendant l'installation et l'établissement du programme pendant le déploiement d'une nouvelle batterie CUCM.
• Pour simplifier l'ajout de nouveaux abonnés à un cluster existant.
• Épargnez le temps

Pendant une installation typique CUCM, vous voyez que de plusieurs écrans et intervention manuelle d'Assistant d'installation sont exigés pour ces scénarios :

1. En tant qu'élément de l'installation, vous fournissez certaines informations sur les écrans d'Assistant d'installation. Ceci exige l'intervention manuelle en tant que vous tapent manuellement les informations que le processus d'installation recherche.

2. Pour installer un environnement typique de batterie, d'abord Publisher est installé. Après que Publisher soit installé, vous ajoutez des coordonnées des abonnés dans les tables des serveurs de l'éditeur de la page Web de l'éditeur. Puis, quand un abonné est installé, un Assistant d'installation pour des passages d'abonné invitant l'administartor pour remplir abonné installent des détails.