Installer une machine virtuelle sans contact pour CUCM

Introduction

Ce document décrit la fonctionnalité d'installation de la machine virtuelle sans contact (VM) qui est introduite dans Cisco Unified Communications Manager (CUCM) 10.5.2 et versions ultérieures.

Conditions préalables

Conditions requises

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

Components Used

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

• Image amorçable pour CUCM/Cisco Unity Connection (CUC)/ Messagerie instantanée et présence (IM&P) pour la version 10.5.2 et ultérieure
• Open Virtualization Archive (OVA) pour UC 10.5.2.
• Image de disquette virtuelle créée avec la sortie de l'outil de générateur de fichiers de réponses (AFG). 

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Configuration

Utilisez l'outil AFG pour générer un fichier image de disquette. Cette image de disquette contient le fichier platformConfig.xml et le fichier clusterConfig.xml pour l'éditeur CUCM et uniquement platformConfig.xml pour tous les autres noeuds qui incluent les abonnés CUCM, IMP Publisher et l'abonné IMP.

L'installation démarre en démarrant les noeuds de VM avec une image de disquette et une ISO amorçable en cours de montage. À l'aide de la procédure d'installation de VM sans contact, aucune intervention manuelle n'est requise lors de l'installation d'un noeud autonome ou lors de l'installation d'un cluster.

Grâce à cette fonctionnalité, l'installation complète du cluster peut être lancée en même temps. L'abonné devra attendre que l'éditeur se connecte au cas où l'installation de Publisher est en cours. Une fois l'installation de l'éditeur terminée, les abonnés en attente seront ajoutés à sa table de serveurs. Une fois les abonnés ajoutés à l'éditeur, les abonnés peuvent poursuivre leur installation.

Une coordination collective entre le gestionnaire de cluster (clm) et le service upstart rend possible cet échange d'informations entre l'éditeur et l'abonné. Cette installation de cluster simplifiée peut être réalisée par une configuration de cluster prédéfinie générée à l'aide de l'outil AFG. Dans ce cas, l'éditeur dispose des informations complètes sur ses noeuds d'abonné à partir du fichier clusterConfig.xml. Publisher utilise ces informations pour ajouter ces noeuds à sa table de noeuds de processus/d'applications après l'installation de l'éditeur.

Avant de continuer, notez qu'une nouvelle fonctionnalité a été ajoutée. Il s'agit de la configuration dynamique du cluster.

1. Les nouveaux noeuds d'abonné sont ajoutés automatiquement à la table de serveurs de Publisher lorsqu'ils se connectent et tentent de s'authentifier auprès de Publisher. Pour cela, la configuration de cluster dynamique doit être activée en premier.
2. Cette option peut être activée via l'outil AFG ou via l'interface de ligne de commande (CLI).
3. Avec ce framework, vous n'avez pas besoin d'ajouter manuellement les détails de l'Abonné dans la page serveur de Publisher.

Dans le cadre de cette fonctionnalité, vous devez être en mesure de générer des fichiers platformConfig.xml et clusterConfig.xml à partir de l'outil AFG. En outre, vous devez être en mesure de spécifier la valeur du compteur de configuration dynamique de cluster à utiliser et de fournir un fichier clusterConfig.xml préconfiguré. Si la configuration de cluster dynamique est utilisée, vous devez être en mesure d'ajouter des détails sur la valeur de délai d'attente pour la configuration de cluster dynamique.

Vous pouvez trouver la valeur du compteur Configuration dynamique 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 est créé, un événement upstart est envoyé indiquant que le fichier est créé. À la réception de l'événement, le service de démarrage à l'écoute de l'événement de démarrage à l'état supérieur configure le gestionnaire de cluster avec ce minuteur.

Par exemple, si le compteur est configuré sur 10 heures, les noeuds d'abonné CUCM sont ajoutés au noeud de processus pour l'éditeur CUCM jusqu'à ce que le délai soit écoulé à partir du moment où l'éditeur est en ligne. Vous pouvez ajouter des noeuds d'abonné à une date ultérieure à l'aide de la commande set network cluster subscribe dynamic-cluster-configuration <nombre d'heures> :

 where      

<nombre d'heures> - est une valeur comprise entre 1 et 24

par défaut : définit la valeur de configuration de cluster dynamique sur 24 heures.

Lorsque cette option est activée, la commande show network cluster affiche le résultat suivant :

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.

Note: Lors de l'utilisation du fichier clusterconfig.xml avec le fichier platformconfig.xml, les noeuds s'enregistrent automatiquement dans le pub CUCM, et par conséquent le minuteur décrit ci-dessus n'est pas pertinent. Le minuteur n'est utile que lorsque vous utilisez le fichier platformconfig.xml du serveur de publication, tout comme le pub CUCM ne connaît pas tous les autres noeuds du cluster dans ce cas.

Dans ce scénario, vous allez créer 3 clusters de noeuds (Publisher CUCMPUB et 2 abonnés CUCMSUB et CUCMSUB1) en utilisant les deux méthodes.

Sur 2 abonnés CUCM, installez CUCMSUB via le fichier clusterconfig.xml et CUCMSUB1 à l'aide du processus d'enregistrement automatique.

3 fichiers sont créés :

1. Fichier Platformconfig.xml pour le noeud principal CUCMPUB
2. Fichier Platformconfig.xml pour le noeud secondaire CUCMSUB
3. Le fichier Clusterconfig.xml contient les détails de l'ensemble du cluster. Comme platformconfig.xml, il contient la liste des noms d'hôte, adresse IP, domaine, rôle et informations d'utilisation pour tous les périphériques du cluster.

Dans ce scénario, comme vous utilisez CUCMSUB1 pour être installé via l'enregistrement automatique, vous générez un autre fichier AFG similaire à celui ci-dessus et qui a le fichier platformconfig.xml pour l'éditeur ainsi que le nouveau platformconfig.xml pour CUCMSUB1.

Comme le montre cette image.

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

Pour le serveur de publication

Si vous souhaitez utiliser l'option de configuration dynamique du cluster, vous devez créer une image de disquette en combinant le fichier clusterconfig.xml et platformconfig.xml du serveur de publication. La combinaison des deux fichiers n'est requise que pour l'éditeur et non pour aucun autre serveur. Pour les abonnés, vous pouvez utiliser uniquement les fichiers respectifs platformconfig.xml.

Déploiement de VM

Une fois l'image de disquette créée, il est temps de monter le CD (avec l'image amorçable .iso) ainsi que le lecteur de disquette (avec l'image .flp que vous avez créée précédemment).

Cette image montre comment monter un CD :

Cette image montre comment monter le lecteur de disquette :

Vous devez vous assurer que la machine virtuelle est configurée pour démarrer à partir du CD-ROM. Si ce n'est pas le cas, vous pouvez modifier le paramètre du BIOS pour autoriser la même chose. Mettez les machines virtuelles sous tension. À partir de cette étape, aucune intervention manuelle n'est requise et tous les serveurs doivent être installés. Dans ce scénario, comme vous avez désactivé la configuration automatique dynamique, vous devez configurer manuellement le minuteur, qui est affiché plus tard.

Une fois que les machines virtuelles ont été mises sous tension, il commence son processus de pré-démarrage dans lequel il vous demande de tester le support ou de continuer.

Cette image montre la fenêtre de test du support :

Les serveurs CUCM recherchent les fichiers clusterconfig.xml et platformconfig.xml pendant cette phase de prédémarrage.

Vérification

Utilisez cette section pour confirmer que votre configuration fonctionne correctement.

À partir des journaux d'installation de CUCMPUB, vous pouvez voir s'il a pu trouver les fichiers ou non. Dans notre exemple,

    platformconfig.xmfichier l

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>

   clusterconfig.xml fichier

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 même message dans les journaux des 2 autres abonnés.

Une fois la phase de prédémarrage terminée, 2 des serveurs démarrent avec la phase de post-démarrage.

Cette image montre la phase post-démarrage :

Comme CUCM Publisher n'est pas installé, l'installation de l'abonné s'arrête à ce stade, car il ne peut pas trouver son entrée dans la table des noeuds de processus de l'éditeur. L'avertissement a été modifié en conséquence, mentionnant que pour les installations sans contact, c'est normal, tandis que l'éditeur instals.n'agit pas. L'installation reprendra automatiquement, comme indiqué sur cette image.

Une fois le serveur de publication CUCM installé, un événement upstart est envoyé pour signaler que l'installation est terminée. Le fichier Processnode est créé et recherche le fichier clusterconfig.xml sur le serveur de publication pour voir quels noeuds sont présents dans le fichier clusterconfig.xml à ce moment-là. Dans ce cas, il trouve un noeud supplémentaire et ajoute ce noeud dans la base de données. N'oubliez pas que pour le serveur CUCMSUB1, vous utilisez pour le processus d'enregistrement automatique, et ses détails ne sont pas présents dans le fichier clusterconfig.xml de l'éditeur.

Un événement dans les journaux d'installation s'affiche.

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 serveur de publication CUCM ajoute les noeuds à sa base de données, il y a une nouvelle section dans le fichier clusterconfig.xml qui est appelée icl_state, et elle marque l'état comme terminé. Cela est nécessaire car CUCM Publisher doit rechercher le fichier clusterconfig.xml plusieurs fois au cours de l'installation globale. Si l'état a été marqué comme terminé, il sait quel noeud a terminé l'installation.

Pendant ce temps, le gestionnaire de cluster de CUCMSUB, bien que pas complètement en ligne essaie toujours de sonder le serveur de publication CUCM. Comme le serveur de publication n'est toujours pas installé, vous recevez une erreur comme indiqué dans les journaux 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 que l'installation de l'éditeur est terminée et que le fichier de noeud de processus est créé, il visite son fichier clusterconfig.xml et ajoute l'autre noeud (CUCMSUB). Dès que le noeud est ajouté à la base de données, et l'événement upstart est envoyé à CUCMPUB et CUCMSUB.

Le gestionnaire de cluster de CUCMSUB reçoit l'état de stratégie injecté de CUCMPUB. Un événement upstart est envoyé avec le nom d'hôte CUCMPUB et l'état de la stratégie injectée. CUCMSUB dans une tentative de création d'une topologie maillée avec d'autres serveurs reçoit l'événement upstart de tous les autres serveurs, cependant, il est plus intéressé par l'événement upstart qu'il reçoit avec le nom d'hôte du CUCMPUB lorsqu'il reprend l'installation lorsque l'éditeur est en ligne. Une fois que le service upstart a reçu l'événement upstart, il envoie un signal d'arrêt à l'assistant d'installation. Ceci tente de revalider le fichier platformconfig.xml, et à son tour, il commence la validation de connectivité avec CUCMPUB. À mesure que l'éditeur est disponible, la validation réussit et l'installation continue.

Pour l'installation de CUCMSUB1, vous devez modifier la valeur de configuration de cluster dynamique sur toute autre valeur, afin que notre serveur soit ajouté au noeud de processus de l'éditeur. Dans cet exemple, vous avez modifié la même à 1 heure.

commande set network cluster Subscriber dynamic-cluster-configuration 1.

Une fois la commande ci-dessus appliquée, CUCMPUB accepte la demande de registre de noeud de CUCMSUB1. Si la commande ci-dessus n'est pas configurée, lorsque CUCMSUB1 tente de contacter l'éditeur, l'éditeur recherche dans son compteur d'enregistrement automatique, si la valeur est 0, il n'ajoute pas le noeud dans son clusterconfig.xml ainsi que dans la table de noeud de traitement.

Une fois que CUCMSUB1 a contacté CUCMPUB, il accepte la connexion socket de CUCMSUB1(10.106.61.122) et ajoute les données de l'abonné au fichier clusterconfig.xml. 

À partir des journaux clusterManager du serveur de publication, cet événement est imprimé en tant que 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 conséquence de quoi 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à-bas.

Une fois que CUCMSUB et CUCMSUB1 sont installés, vous recevez l'événement suivant platform-system-clusternode-install-complete des deux noeuds. Cet événement est envoyé à chaque noeud du cluster.

STATE=ready indique que l'installation est terminée, sinon elle est en état d'installation.

Ce message apparaît dans le syslog CUCMPUB, qui signifie que l'installation de CUCMSUB et CUCMSUB1 est terminée.

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épannage

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

Commandes CLI introduites dans cette fonction

1. définir les détails de l'abonné du cluster de réseau <type de serveur> <nom d'hôte> <ip> <nom de domaine>

Cette commande permet d'ajouter un abonné à la table de serveur de noeud/d'applications de traitement.

Syntaxe:

2. annuler les détails de l'abonné au cluster réseau

Cette commande affiche le message indiquant que l'abonné peut être supprimé de l'interface utilisateur graphique. L'opération de désactivation n'est pas autorisée sur l'interface de ligne de commande. Cette opération ne peut être effectuée qu'à partir de la page Web.

3. set network cluster abonn dynamic-cluster-config

Définir la configuration dynamique de cluster de l'abonné réseau { <default> | < nombre d'heures >                

Cette commande active dynamic-cluster-config sur publisher.

              Description de la syntaxe

4. show network cluster

Cette commande affiche une valeur de configuration de cluster dynamique à jour sur le serveur de publication lorsqu'elle est activée.

Avantages

• Pour fournir un processus d'installation légèrement inférieur, dans lequel aucune intervention manuelle n'est requise pendant l'installation et la planification lors du déploiement d'une nouvelle grappe CUCM.
• Pour simplifier l'ajout de nouveaux abonnés à un cluster existant.
• Gagner du temps

Lors d'une installation CUCM classique, plusieurs écrans de l'Assistant d'installation et une intervention manuelle sont nécessaires pour ces scénarios :

1. Dans le cadre de l'installation, vous fournissez certaines informations sur les écrans de l'Assistant d'installation. Cela nécessite une intervention manuelle lorsque vous tapez manuellement les informations recherchées par le processus d'installation.

2. Pour configurer un environnement de cluster classique, un serveur de publication est d'abord installé. Après l'installation d'un serveur de publication, vous ajoutez des détails sur les abonnés dans les tables serveur de l'éditeur à partir de la page Web de l'éditeur. Ensuite, lorsqu'un abonné est installé, un Assistant d'installation pour l'abonné s'exécute pour demander à l'administrateur de renseigner les détails d'installation de l'abonné.