Instale Touchless VM para CUCM

Introdução

Este documento descreve a característica da instalação da máquina virtual de Touchless (VM) que está sendo introduzida no gerente das comunicações unificadas de Cisco (CUCM) 10.5.2 e umas liberações mais altas.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Imagem inicializável para CUCM/Cisco conexão de unidade) (CUC/mensagens instantâneas & presença (IM&P) para a versão 10.5.2 e mais recente
• Abra o arquivo da virtualização (ÓVULOS) para UC 10.5.2.
• Imagem flexível virtual criada com a saída da ferramenta do gerador do arquivo da resposta (AFG). 

O procedimento para criar a imagem flexível virtual com a ferramenta AFG é documentado no seguinte link. Este Web site fornece instruções para Plataformas de cliente múltiplo tais como Windows, Mac OS X e Linux.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Configurar

Use a ferramenta AFG para gerar um arquivo de imagem flexível. Esta imagem flexível contém o arquivo platformConfig.xml e o clusterConfig.xmlfile para o editor CUCM e somente o platformConfig.xmlfile para todos Nós restantes que incluem assinantes CUCM, editor IMP & subscritor IMP.

Começos da instalação carreg acima dos Nós VM com imagem flexível e o ISO inicializável que estão sendo montados. Usando o procedimento de instalar de Touchless VM, nenhuma intervenção manual é exigida durante a instalação de um nó independente ou durante a instalação do conjunto.

Com esta característica, a instalação inteira do conjunto pode ser começada ao mesmo tempo. O subscritor terá que esperar o editor para vir em linha caso que a instalação do editor é ainda em andamento. Na conclusão da instalação do editor, os assinantes de espera serão adicionados a sua tabela de servidor. Uma vez que os assinantes são adicionados ao editor, os assinantes podem continuar com seu instalam.

Uma coordenação coletiva da gerente de cluster (clm) e do serviço principiante torna este intercâmbio de informação entre a publisher e subscriber possível. Esta instalação simplificada do conjunto pode ser conseguida pela configuração de grânulos predefinida gerada usando a ferramenta AFG. Nisto, o editor tem a informação completa sobre seus Nós do subscritor do arquivo clusterConfig.xml. O editor usa esta informação para adicionar estes Nós a sua tabela do processnode/aplicativo depois que o editor é instalado com sucesso.

Antes de continuar, faça a anotação que há uns novos recursos que sejam adicionados. É configuração de grânulos dinâmica.

1. Os Nós do novo assinante obtêm adicionados ao editor? tabela de servidor s automaticamente quando vierem em linha e tentarem autenticar com editor. Para que isto aconteça, a dinâmico-conjunto-configuração deve ser permitida primeiramente.
2. Isto pode ser permitido através da ferramenta AFG ou através do comando line interface(cli).
3. Com esta estrutura, você não precisa tem que manualmente adicionar os detalhes do subscritor na página do servidor do editor.

Como parte de esta característica, você deve poder gerar o arquivo platformConfig.xml e o clusterConfig.xmlfile da ferramenta AFG. Também, você deve poder ao valor do temporizador de configuração de DynamicCluster do specifythe ser usado e fornecer um prebuilt clusterConfig.xmlfile. Se a dinâmico-conjunto-configuração é usada, você deve poder adicionar detalhes de valor de timeout para a dinâmico-conjunto-configuração.

Você pode encontrar o valor de temporizador dinâmico da configuração de grânulos no arquivo platformconfig.xml do editor:

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

 <ParamValue>1000</ParamValue>

</PostInstallAutoRegister>

Assim que o arquivo for criado, um evento principiante está enviado que indica que o arquivo está criado. Ao receber o evento, o serviço principiante que está escutando o evento principiante configura a gerente de cluster com este temporizador.

Por exemplo, se o temporizador é configurado às horas 10, os Nós CUCM Subsriber obtêm adicionados ao nó do processo para o editor CUCM até que o tempo seja acima do editor do momento estiver em linha. Os Nós do subscritor podem ser adicionados em um outro dia usando o <number da dinâmico-conjunto-configuração do subscritor do conjunto da rede do grupo do comando do hours>:

 onde      

<number do hours> - é um valor entre 1 a 24

o padrão - ajustará o vaule da dinâmico-conjunto-configuração a 24 horas

Quando permitido, o comando cluster da rede da mostra dá a seguinte saída:

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: Ao usar o arquivo clusterconfig.xml junto com platformconfig.xmlfile, o autoregister dos Nós ao bar CUCM, e consequentemente o temporizador disucssed acima dos suportes irrelevantes. O temporizador é útil somente onde você está usando o arquivo platformconfig.xml do servidor do publicador, apenas como o bar CUCM é inconsciente de todos Nós restantes no conjunto neste caso.

Nesta encenação, você está indo construir 3 conjuntos do nó (editor CUCMPUB e 2 assinantes CUCMSUB e CUCMSUB1) que usam ambos os métodos.

Fora de 2 assinantes CUCM, instale CUCMSUB através do arquivo clusterconfig.xml, e o CUCMSUB1 usando o processo do registro automático.

3 arquivos são criados:

1. Arquivo Platformconfig.xml para o nó principal CUCMPUB
2. Arquivo Platformconfig.xml para o nó secundário CUCMSUB
3. O arquivo Clusterconfig.xml tem os detalhes para o conjunto inteiro. Similar a platformconfig.xml, contém a lista de nomes de host, de endereço IP de Um ou Mais Servidores Cisco ICM NT, de domínio, de papel e de informação de uso para todos os dispositivos no conjunto.

Nesta encenação, como você está usando CUCMSUB1 a ser instalado através do registro automático, você gera um outro arquivo AFG que seja similar a esse acima, e tem o arquivo platformconfig.xml para o editor junto com o platformconfig.xmlfor novo o CUCMSUB1.

Segundo as indicações desta imagem.

Uma vez que nós temos o arquivo clusterconfig.xml do editor, e platformconfig.xmlfile de todos os server, é hora de fazer uma imagem flexível do mesmos.

Para o editor

Se você gosta de usar a opção de configuração dinâmica do conjunto, você exige para criar uma imagem flexível combinando ambo o arquivo clusterconfig.xml e platformconfig.xmlfile do editor. Combinar ambos os arquivos é exigida somente para o editor, e não para todo o outro server. Para assinantes, você pode usar somente o platformconfig.xmlfiles respectivo.

Desenvolvimento VM

Uma vez que você tem a imagem flexível criada, é hora de montar o CD (com a imagem inicializável .iso) assim como o drive flexível (com a imagem .flp que você criou mais cedo).

Esta imagem mostra como montar o CD:

Esta imagem mostra como montar o drive flexível:

Você precisa de assegurar-se de que a máquina VM esteja configurada para carreg da CD-ROM. Se não, você pode alterar o ajuste BIOS para permitir o mesmos. Põe por favor sobre os VM. Desta fase sobre, nenhuma intervenção manual é exigida, e todos os server devem ser instalados. Nesta encenação, como você desabilitou a configuração do auto dinâmico, você deve manualmente configurar o temporizador, que é mostrado mais tarde.

Uma vez que os VM foram postos sobre, começa seu processo da fase da PRE-bota onde pede que você teste os media ou continue.

Esta imagem mostra a janela de teste dos media:

Os server CUCM procuram o arquivo clusterconfig.xml e o platformconfig.xmlfile durante esta fase da PRE-bota.

Verificar

Use esta seção para confirmar se a sua configuração funciona corretamente.

Dos logs da instalação de CUCMPUB, você pode ver se pôde encontrar os arquivos ou não. Em nosso exemplo,

    platformconfig.xm l arquivo

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>

   arquivo 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>

Você vê a mensagem similar nos logs para outros 2 assinantes.

Uma vez que a fase da PRE-bota se acaba, 2 dos server começam com a fase da Cargo-bota.

Esta imagem mostra a fase da Cargo-bota:

Porque o editor CUCM não é instalado, a instalação de paradas do subscritor neste momento do tempo, porque é incapaz de encontrar sua entrada na tabela do nó do processo do editor. O aviso foi alterado accrodingly, mencionando que aquele para touchless instalar, isto é normal, quando o editor installs.take nenhuma ação. Install recomeçará automaticamente é como mostrado esta imagem.

Uma vez que o editor CUCM é instalado, um evento principiante está enviado para notificar que instala é terminado. O arquivo de Processnode obtém criado, e procura o arquivo clusterconfig.xml no editor, para considerar o que os Nós estam presente em clusterconfig.xmlfile naquele tempo. Neste caso encontra um mais nó, e adiciona esse nó no banco de dados. Recorde para o server CUCMSUB1, você usam-se para o processo do registro automático, e seus detalhes não estão atuais no clusterconfig.xmlfile do editor.

Um evento nos logs da instalação é mostrado.

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

)

Uma vez que o editor CUCM adiciona os Nós a seu banco de dados, há uma seção nova no arquivo clusterconfig.xml que é chamado icl_state, e marca o estado como terminado. Isto é exigido enquanto o editor CUCM precisa de olhar o arquivo clusterconfig.xml poucas vezes durante a instalação total. Se o estado foi marcado como terminado, sabe que nó terminou a instalação.

Entretanto, a gerente de cluster de CUCMSUB, embora não completamente em linha ainda tenta votar o editor CUCM. Porque o editor não é instalado ainda, você recebe um erro segundo as indicações dos 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

.

Agora uma vez que a instalação do editor é terminada e o arquivo do processnode obtém criado, visita seu arquivo clusterconfig.xml e adiciona o outro nó (CUCMSUB). Assim que o nó obtiver adicionado ao banco de dados, e o evento principiante estiver enviado ao CUCMPUB e ao CUCMSUB.

A gerente de cluster de CUCMSUB recebe o estado injetado política de CUCMPUB. Um evento principiante é enviado com o hostname de CUCMPUB e do estado injetado política. CUCMSUB na tentativa de criar uma topologia de malha com outros server recebe o evento principiante de todos os server restantes, contudo, está mais interessado no evento principiante que recebe com o hostname do CUCMPUB enquanto recomeça a instalação quando o editor é em linha. Uma vez que o serviço principiante recebe o evento principiante, envia um sinal da matança ao assistente da instalação. Isto tenta ao revalidate o arquivo platformconfig.xml, e por sua vez começa a validação da Conectividade com o CUCMPUB. Porque o editor está agora disponível, a validação sucede e a instalação continua.

Para a instalação CUCMSUB1, você exige para alterar o valor dinâmico da configuração de grânulos a todo o outro valor, assim, que nosso server obtiver adicionado ao processnode do editor. Neste exemplo, você alterou o mesmos a 1 hora.

ajuste o comando 1 da dinâmico-conjunto-configuração do subscritor do conjunto da rede.

Uma vez o comando acima é aplicado, accpets CUCMPUB o pedido do registro do nó de CUCMSUB1. Se o comando acima não está configurado, quando CUCMSUB1 tenta contactar o editor, os olhares do editor em seu temporizador auto-REG, se o valor é 0, não adiciona o nó em sua tabela clusterconfig.xml assim como de processnode.

Uma vez que o CUCMSUB1 contacta CUCMPUB, aceita a conexão de soquete de CUCMSUB1(10.106.61.122), e adiciona os dados do subscritor ao arquivo clusterconfig.xml. 

Dos logs do clusterManager do editor, este evento é imprimido como o 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=

Em consequência de quais o arquivo clusterconfig.xml no editor muda, e este evento é considerado.

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

A instalação do server continua lá sobre.

Uma vez que os CUCMSUB e os CUCMSUB1 são instalados, você recebe o seguinte evento plataforma-sistema-clusternode-instalar-terminado de ambos os Nós. Este evento é mandado a cada nó no conjunto.

STATE=ready indica que a instalação está terminada, outro ele consiste em instalar o estado.

Esta mensagem é considerada no Syslog CUCMPUB, aquela significam a instalação de CUCMSUB e CUCMSUB1 são terminados.

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

)

Troubleshooting

Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.

Comandos CLI que foram introduzidos nesta característica

1. ajuste o <ip> < Domain Name > do <hostname> do type> do <server dos detalhes do subscritor do conjunto da rede

Este comando é adicionar o subscritor à tabela de servidor do processnode/app.

Sintaxe:

Parâmetros	Descrição
Tipo de servidor	Os valores são CUCM ou IMP ou CUC (imperativos)
ip	IP address do hostname adicionado (imperativo para o editor IMP & o CUC & opcional para outros Nós
Nome de domínio	Domain Name do editor IMP (imperativo para o editor IMP & não exigido para outros Nós)

2. detalhes unset do subscritor do conjunto da rede

Este comando indica a mensagem que menciona que o subscritor pode ser suprimido do GUI. A operação Unset não é permitida no CLI. Esta operação pode somente ser feita do Web page.

3. ajuste a dinâmico-conjunto-configuração do subscritor do conjunto da rede

Ajuste a dinâmico-conjunto-configuração do subscritor do conjunto da rede {<default> | < número de horas >                

Este comando permite a dinâmico-conjunto-configuração no editor.

              Descrição da sintaxe

Parâmetros	Descrição
padrão	Isto permitirá a dinâmico-conjunto-configuração para 24hrs
<no. do hours>	Valor entre 1-24 horas

4. mostre o conjunto da rede

Este comando indica o valor atualizado da dinâmico-conjunto-configuração no editor quando é permitido.

Benefícios

• Para fornecer um toque menos processo de instalação, em que nenhuma intervenção manual é exigida durante a instalação e a programação durante o desenvolvimento de um conjunto novo CUCM.
• Para simplificar a adição de novos assinantes a um conjunto existente.
• Ganhe o tempo

Durante uma instalação típica CUCM, você vê que o múltiplo para instalar telas de wizard e a intervenção manual estão exigidos para estas encenações:

1. Como parte da instalação, você fornece determinada informação nas telas de wizard da instalação. Isto exige a intervenção manual como você datilografa manualmente a informação que o processo de instalação procura.

2. Para setup um ambiente típico do conjunto, um editor é instalado primeiramente. Depois que um editor é instalado, você adiciona detalhes dos assinantes no editor? tabelas de servidor s do página da web do editor. Então, quando um subscritor está sendo instalado, um assistente da instalação para corridas do subscritor que pede o administartor para encher o subscritor instala detalhes.