Instalación de una máquina virtual sin contacto para CUCM

Introducción

Este documento describe la función de instalación de la máquina virtual sin contacto (VM) que se presenta en Cisco Unified Communications Manager (CUCM) 10.5.2 y versiones posteriores.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Imagen de inicio para CUCM/Cisco Unity Connection (CUC)/ Instant Messaging & Presence (IM&P) para la versión 10.5.2 y posteriores
• Open Virtualization Archive (OVA) para UC 10.5.2.
• Imagen de disquete virtual creada con el resultado de la herramienta Generador de archivos de respuesta (AFG). 

El procedimiento para crear una imagen de disquete virtual con la herramienta AFG se documenta en el siguiente enlace.Este sitio web proporciona instrucciones para varias plataformas cliente como Windows, Mac OS X y 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.

Configurar

Utilice la herramienta AFG para generar un archivo de imagen de disquete. Esta imagen de disquete contiene el archivo platformConfig.xml y el archivo clusterConfig.xml para el editor de CUCM y sólo el archivo platformConfig.xml para todos los demás nodos que incluyen suscriptores de CUCM, editor IMP y suscriptor IMP.

La instalación comienza iniciando los nodos VM con la imagen de disquete y la ISO de arranque montada. Con el procedimiento de instalación de VM sin contacto, no se requiere ninguna intervención manual durante la instalación de un nodo independiente o durante la instalación del clúster.

Con esta función, se puede iniciar la instalación completa del clúster al mismo tiempo. El suscriptor tendrá que esperar a que el editor se conecte en caso de que la instalación de Publisher siga en curso. Una vez finalizada la instalación del editor, los suscriptores en espera se agregarán a su tabla de servidores. Una vez que los suscriptores se agregan al editor, los suscriptores pueden continuar con su instalación.

Una coordinación colectiva de cluster manager (clm) y upstart service hace posible este intercambio de información entre el editor y el suscriptor. Esta instalación de clúster simplificada se puede lograr mediante la configuración de clúster predefinida generada mediante la herramienta AFG. En esto, el editor tiene la información completa sobre sus nodos suscriptores desde el archivo clusterConfig.xml. Publisher utiliza esta información para agregar estos nodos a la tabla processnode/application después de que el editor se haya instalado correctamente.

Antes de continuar, tenga en cuenta que se ha agregado una nueva función. Se trata de la configuración dinámica del clúster.

1. Los nuevos nodos del suscriptor se agregan automáticamente a la tabla de servidores de Publisher cuando se conectan y tratan de autenticarse con Publisher. Para que esto suceda, primero debe habilitarse la configuración dinámica de clúster.
2. Esto se puede habilitar mediante la herramienta AFG o mediante la interfaz de línea de comandos (CLI).
3. Con este marco de trabajo, no es necesario que agregue manualmente los detalles del suscriptor en la página del servidor de Publisher.

Como parte de esta función, debe poder generar el archivo platformConfig.xml y el archivo clusterConfig.xml de la herramienta AFG. Además, debe ser capaz de especificar el valor del temporizador Dynamic Cluster Configuration que se utilizará y proporcionar un archivo clusterConfig.xml preconstruido. Si se utiliza dynamic-cluster-configuration, debe poder agregar detalles del valor de tiempo de espera para dynamic-cluster-configuration.

Puede encontrar el valor del temporizador Dynamic Cluster Configuration en el archivo platformconfig.xml del editor:

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

 <ParamValue>1000</ParamValue>

</PostInstallAutoRegister>

Tan pronto como se crea el archivo, se envía un evento upstart que indica que se ha creado el archivo. Al recibir el evento, el servicio upstart que escucha el evento upstart configura el administrador del clúster con este temporizador.

Por ejemplo, si el temporizador se configura en 10 horas, los nodos CUCM Subsriber se agregan al nodo de proceso para el editor de CUCM hasta que el tiempo transcurre desde el momento en que el editor está en línea. Los nodos del suscriptor se pueden agregar más tarde usando el comando set network cluster subscriber dynamic-cluster-configuration <number of hour>:

 where      

<number of hour>: es un valor entre 1 y 24

predeterminado: establecerá el valor de configuración de clúster dinámico en 24 horas

Cuando está habilitado, el comando show network cluster proporciona el siguiente resultado:

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.

Nota: Al utilizar el archivo clusterconfig.xml junto con el archivo platformconfig.xml, los nodos se registran automáticamente en el Pub CUCM y, por lo tanto, el temporizador mencionado arriba es irrelevante. El temporizador sólo es útil cuando se utiliza el archivo platformconfig.xml del servidor editor, al igual que el Pub CUCM no conoce todos los demás nodos del clúster en este caso.

En esta situación, va a generar 3 clústeres de nodos (Publisher CUCMPUB y 2 suscriptores CUCMSUB y CUCMSUB1) utilizando ambos métodos.

De los 2 suscriptores de CUCM, instale CUCMSUB a través del archivo clusterconfig.xml y CUCMSUB1 mediante el proceso de registro automático.

Se crean 3 archivos:

1. archivo Platformconfig.xml para el nodo primario CUCMPUB
2. archivo Platformconfig.xml para el nodo secundario CUCMSUB
3. El archivo Clusterconfig.xml tiene los detalles para todo el clúster. Al igual que platformconfig.xml, contiene la lista de nombres de host, dirección ip, dominio, rol e información de uso para todos los dispositivos en el clúster.

En esta situación, mientras utiliza CUCMSUB1 para instalarse mediante el registro automático, genera otro archivo AFG similar al anterior y tiene el archivo platformconfig.xml para el editor junto con el nuevo platformconfig.xml para CUCMSUB1.

Como se muestra en esta imagen.

Una vez que tenemos el archivo clusterconfig.xml del editor y el archivo platformconfig.xml de todos los servidores, es el momento de hacer una imagen de disquete de la misma manera.

Para el editor

Si desea utilizar la opción dynamic cluster config, debe crear una imagen de disquete combinando tanto el archivo clusterconfig.xml como el archivo platformconfig.xml del editor. La combinación de ambos archivos sólo es necesaria para el editor y no para ningún otro servidor. Para los suscriptores, sólo puede utilizar los archivos platformconfig.xml respectivos.

Implementación de VM

Una vez creada la imagen del disquete, es el momento de montar el CD (con la imagen de arranque .iso) así como la unidad de disquete (con la imagen .flp que creó anteriormente).

Esta imagen muestra cómo montar el CD:

Esta imagen muestra cómo montar una unidad de disquete:

Debe asegurarse de que la máquina virtual esté configurada para arrancar desde CD-ROM. Si no es así, puede modificar la configuración del BIOS para permitir lo mismo. Encienda las VM. A partir de esta etapa, no se requiere ninguna intervención manual y se deben instalar todos los servidores. En esta situación, como ha desactivado la configuración automática dinámica, debe configurar manualmente el temporizador, que se muestra más adelante.

Una vez que se han encendido las VM, comienza su proceso de etapa previa al inicio, donde se le solicita que pruebe los medios o continúe.

Esta imagen muestra la ventana de prueba de medios:

Los servidores CUCM buscan el archivo clusterconfig.xml y el archivo platformconfig.xml durante esta fase previa al inicio.

Verificación

Utilize esta sección para confirmar que su configuración funcione correctamente.

Desde los registros de instalación de CUCMPUB, puede ver si ha podido encontrar o no los archivos. En nuestro ejemplo,

    platformconfig.xmarchivo 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 archivo

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>

Verá el mensaje similar en los registros para los otros 2 suscriptores.

Una vez finalizada la fase previa al inicio, 2 de los servidores comienzan con la fase posterior al inicio.

Esta imagen muestra la fase posterior al inicio:

Como CUCM Publisher no está instalado, la instalación del suscriptor se detiene en este momento, ya que no puede encontrar su entrada en la tabla de nodos del proceso del editor. La advertencia se ha modificado en consecuencia, mencionando que para las instalaciones sin contacto, esto es normal, mientras que el editor instala.no realiza ninguna acción. La instalación se reanudará automáticamente como se muestra en esta imagen.

Una vez instalado CUCM Publisher, se envía un evento upstart para notificar que se ha completado la instalación. Se crea el archivo ProcessNode y se busca el archivo clusterconfig.xml en el Editor para ver qué nodos están presentes en el archivo clusterconfig.xml en ese momento. En este caso, encuentra un nodo más y agrega ese nodo a la base de datos. Recuerde que para el servidor CUCMSUB1, utiliza para el proceso de registro automático y sus detalles no están presentes en el archivo clusterconfig.xml del editor.

Se muestra un evento en los registros de instalación.

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

)

Una vez que CUCM Publisher agrega los nodos a su base de datos, hay una nueva sección en el archivo clusterconfig.xml que se denomina icl_state y marca el estado como completado. Esto es necesario, ya que CUCM Publisher debe buscar el archivo clusterconfig.xml varias veces durante la instalación general. Si el estado se ha marcado como completado, sabe qué nodo ha completado la instalación.

Mientras tanto, el administrador de clúster de CUCMSUB, aunque no está completamente online, sigue intentando sondear CUCM Publisher. Dado que Publisher aún no está instalado, se recibe un error como se muestra en los registros 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

.

Ahora, una vez que se completa la instalación del editor y se crea el archivo processnode, visita su archivo clusterconfig.xml y agrega el otro nodo (CUCMSUB). Tan pronto como se agrega el nodo a la base de datos y se envía el evento upstart a CUCMPUB y CUCMSUB.

El administrador de clúster de CUCMSUB recibe el estado de inserción de la política de CUCMPUB. Se envía un evento upstart con el nombre de host de CUCMPUB y el estado de la política inyectada. CUCMSUB en un intento de crear una topología de malla con otros servidores recibe el evento upstart de todos los demás servidores, sin embargo, está más interesado en el evento upstart que recibe con el nombre de host de CUCMPUB cuando reanuda la instalación cuando el editor está en línea. Una vez que el servicio upstart recibe el evento upstart, envía una señal de fin al asistente de instalación. Esto intenta revalidar el archivo platformconfig.xml y, a su vez, comienza la validación de la conectividad con CUCMPUB. A medida que el editor ya está disponible, la validación se realiza correctamente y la instalación continúa.

Para la instalación de CUCMSUB1, debe modificar el valor de configuración de clúster dinámico a cualquier otro valor, de modo que nuestro servidor se agregue al nodo de proceso del editor. En este ejemplo, ha modificado el mismo a 1 hora.

set network cluster subscriber dynamic-cluster-configuration 1 comando.

Una vez que se aplica el comando anterior, CUCMPUB acepta la solicitud de registro de nodos de CUCMSUB1. Si no se configura el comando anterior, cuando CUCMSUB1 intenta ponerse en contacto con el editor, éste busca en su temporizador de auto-reg, si el valor es 0, no agrega el nodo en su clusterconfig.xml ni en la tabla processnode.

Una vez que CUCMSUB1 se pone en contacto con CUCMPUB, acepta la conexión de socket desde CUCMSUB1(10.106.61.122) y agrega los datos del suscriptor al archivo clusterconfig.xml. 

Desde los registros clusterManager del Publisher, este evento se imprime como 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=

Como resultado del cual cambia el archivo clusterconfig.xml en el editor, y se ve este evento.

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

La instalación del servidor continúa allí.

Una vez que se instalan CUCMSUB y CUCMSUB1, recibe el siguiente evento platform-system-clusternode-install-complete de ambos nodos. Este evento se envía a todos los nodos del clúster.

STATE=ready indica que la instalación se ha completado, de lo contrario está en el estado Instalación.

Este mensaje se ve en el syslog de CUCMPUB, que significa que se ha completado la instalación de CUCMSUB y CUCMSUB1.

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

)

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Comandos CLI que se han introducido en esta función

1. set network cluster subscriber details <server type> <hostname> <ip> <domain name>

Este comando es para agregar el suscriptor a la tabla de servidor processnode/app.

Sintaxis:

2. detalles del suscriptor del clúster de red de desconexión

Este comando muestra el mensaje que menciona que el suscriptor se puede eliminar de la GUI. No se permite la operación Unset en la CLI. Esta operación solo se puede realizar desde la página web.

3. set network cluster subscriber dynamic-cluster-config

Set network cluster subscriber dynamic-cluster-configuration { <default> | < número de horas >                

Este comando habilita dynamic-cluster-config en el editor.

              Descripción de la Sintaxis

4. show network cluster

Este comando muestra el valor de configuración dinámica de clúster actualizado en el editor cuando está habilitado.

Beneficios

• Para proporcionar un proceso de instalación sin intervención, en el que no se requiere intervención manual durante la instalación y programación durante la implementación de un nuevo clúster de CUCM.
• Para simplificar la adición de nuevos suscriptores a un clúster existente.
• Ahorrar tiempo

Durante una instalación típica de CUCM, verá varias pantallas del Asistente de instalación y se requiere intervención manual para estos escenarios:

1. Como parte de la instalación,proporciona cierta información en las pantallas del asistente de instalación. Esto requiere una intervención manual a medida que escribe manualmente la información que busca el proceso de instalación.

2. Para configurar un entorno de clúster típico, primero se instala un editor. Después de instalar un editor, agrega los detalles de los suscriptores en las tablas de servidores del editor desde la página web del editor. A continuación, cuando se instala un suscriptor, se ejecuta un asistente de instalación para suscriptor que solicita al administrador que rellene los detalles de instalación del suscriptor.