A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
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.
Não existem requisitos específicos para este documento.
As informações neste documento são baseadas nestas versões de software e hardware:
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.
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.
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:
Nesta encenação, como você está usando CUCMSUB1 a ser instalado através do registro automático, você gerencie 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.
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.
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.
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 base 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 base 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 base 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
)
Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.
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.
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: