Recriar Editor do CUCM a partir do Assinante

Introdução

Este documento descreve a restauração do nó do editor do Cisco Unified Communications Manager (CUCM) a partir de um banco de dados de assinantes sem backup anterior.

Background

Nas versões anteriores do CUCM, o nó do editor era considerado como a única fonte autoritativa para o banco de dados SQL (Structured Query Language).

Consequentemente, se um nó do editor foi perdido devido a uma falha de hardware ou corrupção do sistema de arquivos, a única maneira de recuperá-lo era reinstalar e restaurar o DB a partir de um backup do Sistema de Recuperação de Desastres (DRS).

Alguns clientes não mantiveram os backups adequados ou tinham backups desatualizados; portanto, a única opção era recriar e reconfigurar o nó do servidor do editor. 

No CUCM Versão 8.6(1), um novo recurso foi introduzido para restaurar um DB do editor de um banco de dados de assinante.

Este documento descreve como aproveitar esse recurso para restaurar com êxito um BD do editor do assinante.

A Cisco recomenda que você mantenha um backup completo da Estrutura de recuperação de desastres (DRF) de todo o cluster.

Como esse processo recupera apenas a configuração do CUCM DB, outros dados, como certificados, música em espera (MoH) e arquivos TFTP, não são recuperados. Para evitar esses problemas, mantenha um backup DRF de cluster completo.

Note: A Cisco recomenda que você revise e se familiarize com todo o processo descrito neste documento antes de começar.

Coletar Dados do Cluster

Antes de reinstalar o editor, é importante que você reúna os detalhes pertinentes sobre o editor anterior. Estes detalhes devem corresponder à instalação original do editor:

• Endereço IP
• Nome do host
• Nome de domínio
• Senha de segurança
• Versão exata do CUCM
• Arquivos do Pacote de opções da Cisco (COP) instalados

Para recuperar os três primeiros itens da lista, insira o comando show network cluster na CLI do nó do assinante atual:

admin:show network cluster
172.18.172.213 cucm911ccnasub1  Subscriber authenticated
172.18.172.212 cucm911ccnapub  Publisher not authenticated - INITIATOR
 since Tue Dec 3 12:43:24 2013
172.18.172.214 cucm911ccnasub2  Subscriber authenticated using TCP since
 Sun Dec 1 17:14:58 2013

Nesse caso, o endereço IP é 172.18.172.212, o nome do host é cucm911ccnapub e não há nenhum nome de domínio configurado para o editor.   

A senha de segurança (o quarto item da lista) é recuperada da documentação do site.

Se você não tiver certeza sobre a senha de segurança, faça uma estimativa de melhor esforço e você poderá tentar verificá-la e corrigi-la conforme necessário com base na versão do CUCM.

Se a senha de segurança estiver incorreta, uma interrupção de cluster será necessária para corrigir a situação. 

Para recuperar a versão exata do CUCM e os arquivos COP instalados (os dois últimos itens na lista), obtenha a saída do sistema do comando show version ative:

admin:show version active
Active Master Version: 9.1.2.10000-28
Active Version Installed Software Options:
No Installed Software Options Found.

Nesse caso, a versão 9.1.2.10000-28 é instalada sem arquivos COP complementares. 

Note: É possível que alguns arquivos COP tenham sido instalados anteriormente no editor, mas não tenham sido instalados no assinante e vice-versa. Use esta saída apenas como diretriz.

Parar Replicação em Todos os Assinantes

Quando o editor é instalado, é crítico que a replicação não configure e exclua os atuais BDs do assinante. Para evitar isso, insira o comando utils dbreplication stop em todos os assinantes:

admin:utils dbreplication stop

********************************************************************************
This command can delete the marker file(s) so that automatic replication setup
is stopped
It can also stop any replication setup currently executing
********************************************************************************

Deleted the marker file, auto replication setup is stopped

Service Manager is running
Commanded Out of Service
A Cisco DB Replicator[NOTRUNNING]
Service Manager is running
A Cisco DB Replicator[STARTED]

Completed replication process cleanup

Please run the command 'utils dbreplication runtimestate' and make sure all nodes
are RPC reachable before a replication reset is executed

Instalar o Editor do CUCM

Reunir uma imagem inicializável da versão apropriada e executar uma instalação com uma atualização para a versão apropriada.

Note: A maioria das versões especiais de engenharia (ES) do CUCM já é inicializável.

Instale o editor e especifique os valores corretos para o endereço IP, o nome de host, o nome de domínio e a senha de segurança mencionados anteriormente. 

Atualizar Valores de Processnode no Publicador

Note: O editor deve estar ciente de pelo menos um servidor de assinante para restaurar o BD desse assinante. A Cisco recomenda que você adicione todos os assinantes. 

Para recuperar a lista de nós, insira o comando run sql select name,description,nodeid from processnode na CLI de um assinante atual.

Os valores de nome podem ser nomes de host, endereços IP ou nomes de domínio totalmente qualificados (FQDNs).

Se você executar o CUCM versão 10.5(2) ou posterior, o comando utils disaster_recovery prepare restore pub_from_sub deverá ser executado na CLI do editor antes que você possa continuar a adicionar nós a System > Server:

aviso: Muitas pessoas que usam o CUCM versão 10.5(2) ou posterior ignoram o comando utils recuperação_desastre preparar restauração pub_from_sub; no entanto, esse é um comando crítico. Certifique-se de não pular nenhuma etapa neste documento.

Depois de receber a lista de nós, navegue para Sistema > Servidor e adicione todos os valores de nome diferentes de EnterpriseWideData à página Administração do Unified CM do Publisher Server.

Os valores de nome devem corresponder ao campo Nome do host/Endereço IP no menu Sistema > Servidor.

admin:run sql select name,description,nodeid from processnode
name               description     nodeid
================== =============== ======
EnterpriseWideData                 1
172.18.172.212     CUCM901CCNAPub  2
172.18.172.213     CUCM901CCNASub1 3
172.18.172.214     CUCM901CCNASub2 4

Note: A instalação padrão adiciona o nome do host do editor à tabela processnode. Você poderá alterá-lo para um endereço IP se a coluna de nome listar um endereço IP para o editor. Nesse caso, não remova a entrada do editor, mas abra e modifique o campo Nome do host/Endereço IP atual. 

Reinicie o nó do editor

Para reiniciar o editor após a conclusão das alterações no nó do processo, insira o comando utils system restart:

admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes

Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...
 \Service Manager shutting down services... Please Wait

Broadcast message from root (Tue Dec  3 14:29:09 2013):

The system is going down for reboot NOW!
Waiting .

Operation succeeded

Verificar Autenticação de Cluster

Depois que o editor for reiniciado, se você fez as alterações corretamente e a senha de segurança estiver correta, o cluster deverá estar no estado autenticado. Para verificar isso, insira o comando show network cluster:

admin:show network cluster
172.18.172.212 cucm911ccnapub  Publisher authenticated
172.18.172.213 cucm911ccnasub1  Subscriber authenticated using TCP since
 Tue Dec 3 14:24:20 2013
172.18.172.214 cucm911ccnasub2  Subscriber authenticated using TCP since
 Tue Dec 3 14:25:09 2013

Note: Se os assinantes não aparecerem como autenticados, consulte a seção Solução de problemas deste documento para resolver esse problema antes de continuar.

Executar um Novo Backup

Se nenhum backup anterior estiver disponível, execute um backup de cluster na página DRS.

Note: Embora você possa usar o DB do assinante para a restauração, ainda é necessário um backup para restaurar os componentes não-DB.

Se nenhum backup estiver disponível, execute um novo; se já existir um backup, ignore esta seção.

Adicionar um dispositivo de backup

Use o menu de navegação para navegar para o Sistema de recuperação de desastres e adicione um dispositivo de backup.

Iniciar um Backup Manual

Depois que o dispositivo de backup for adicionado, inicie um backup manual.

Note: É crítico que o nó do editor tenha o componente CCMDB registrado.

Restauração do Publisher do BD do Assinante

Na página Sistema de Recuperação de Desastres, navegue para Restaurar > Assistente de Restauração.

Se um backup atual estava disponível e você ignorou a seção anterior, marque todas as caixas de seleção de recursos na seção Selecionar recursos: Enterprise License Manager (ELM), se disponível, CDR_CAR, e Unified Communications Manager (UCM).

Se você usar um backup que foi executado na seção anterior, marque apenas a caixa de seleção UCM:

Clique em Next. Marque a caixa de seleção do nó do editor (CUCM911CCNAPUB) e escolha o DB do assinante a partir do qual a restauração ocorre. Em seguida, clique em Restaurar.

Status da restauração

Quando a restauração alcança o componente CCMDB, o texto Status deve aparecer como Restaurando o Publicador do Backup do Assinante:

Executar uma Verificação de Sanidade no BD do Publicador

Antes de reinicializar e configurar a replicação, é uma boa prática verificar se a restauração foi bem-sucedida e se o BD do editor contém as informações necessárias.

Certifique-se de que essas consultas retornem os mesmos valores nos nós do editor e do assinante antes de continuar:

• executar sql select count(*) do dispositivo
• executar sql select count(*) de enduser

Reinicializar o cluster

Após a conclusão da restauração, insira o comando utils system restart em cada nó. Comece com o editor seguido por cada assinante.

admin:utils system restart
Do you really want to restart ?
Enter (yes/no)? yes

 Appliance is being Restarted ...
Warning: Restart could take up to 5 minutes.

Shutting down Service Manager. Please wait...
 \ Service Manager shutting down services... Please Wait

Broadcast message from root (Tue Dec  3 14:29:09 2013):

The system is going down for reboot NOW!
Waiting .

Operation succeeded

Verificar Requisitos de Configuração da Replicação

Navegue até a página Cisco Unified Reporting e gere um relatório de status do banco de dados do Unified CM.

É provável que a replicação ainda não tenha sido configurada, mas é importante garantir que os arquivos Hosts do Unified CM, Rhosts do Unified CM e Sqlhosts do Unified CM correspondam ao editor.

Caso contrário, os nós que não corresponderem precisarão ser reinicializados novamente. Se esses arquivos não corresponderem, não vá para a próxima etapa ou redefina a replicação.

Configuração de Replicação

Dependendo da versão, a replicação não pode ser configurada automaticamente. Para verificar isso, aguarde até que todos os serviços sejam iniciados e insira o comando utils dbreplication runtimestate.

Um valor de estado 0 indica que a configuração está em andamento, enquanto um valor de 2 indica que a replicação foi configurada com êxito para esse nó.

Esta saída indica que a configuração de replicação está em andamento (o estado aparece como 0 para dois nós):

Esta saída indica que a replicação foi configurada com êxito:

Se algum nó for exibido com um valor de estado 4, ou se a replicação não for configurada com êxito após várias horas, insira o comando utils dbreplication reset all no nó do editor.

Se a replicação continuar a falhar, consulte o artigo Troubleshooting CUCM Database Replication in Linux Appliance Model Cisco para obter mais informações sobre como solucionar o problema. 

Pós-restauração

Como a restauração do banco de dados não restaura todos os componentes anteriores, muitos itens no nível do servidor devem ser manualmente instalados ou restaurados.

Ativar serviços

A restauração do DRF não ativa nenhum serviço. Navegue para Ferramentas > Ativação de serviço e ative todos os serviços necessários que o editor deve executar, com base na documentação do site na página Unified Serviceability:

Instalar dados que não foram restaurados

Se um backup completo não estava disponível, você deve reproduzir determinadas configurações manuais. Particularmente, as configurações que envolvem certificados e funções TFTP:

• arquivos MoH
• Pacotes de dispositivo
• Planos de discagem (para discagem NANP (Plano de numeração não norte-americano)
• Localidades
• Quaisquer outros arquivos COP diversos
• Todos os arquivos que anteriormente foram carregados manualmente no editor (se fosse um servidor TFTP)
• Strings de comunidade do Protocolo de Gerenciamento de Rede Simples (SNMP - Simple Network Management Protocol)
• Exportações de certificados em massa para Extension Mobility Cross Cluster (EMCC), Intercluster Location Bandwidth Manager (LBM) e Intercluster Lookup Service (ILS)
• Troca de certificados para troncos, gateways e pontes de conferência seguros

Note: Para clusters de modo misto, você deve executar novamente o cliente da Lista de Certificados Confiáveis (CTL).

Troubleshooting

Esta seção descreve vários cenários que podem fazer com que esse procedimento falhe.

O cluster não autentica

Se o cluster não for autenticado, as duas causas mais comuns serão senhas de segurança incompatíveis e problemas de conectividade na porta TCP 8500.

Para verificar se as senhas de segurança do cluster correspondem, insira o comando utils create report platform na CLI de ambos os nós e inspecione o valor de hash do arquivo platformConfig.xml. Eles devem corresponder nos nós publicador e assinante.

  <IPSecSecurityPwCrypt>
    <ParamNameText>Security PW for this node</ParamNameText>
    <ParamDefaultValue>password</ParamDefaultValue><ParamValue>0F989713763893AC831812812AB2825C8318
    12812AB2825C831812812AB2825C </ParamValue>
  </IPSecSecurityPwCrypt>

Se eles corresponderem, verifique a conectividade TCP na porta 8500. Se eles não corresponderem, pode haver dificuldades quando você tentar corrigir a senha devido a vários defeitos no código CUCM que envolvem o procedimento:

• ID de bug da Cisco CSCtn79868 - ferramenta pwrecovery redefinindo somente a senha sftpuser
• ID de bug da Cisco CSCug92142 - a ferramenta pwrecovery não atualiza as senhas internas do usuário
• ID de bug Cisco CSCug97360 - negações do selinux no utilitário pwrecovery
• ID de bug Cisco CSCts10778 - Negações lançadas para procedimento de segurança de recuperação de senha
• ID de bug da Cisco CSCua09290 - A "segurança de usuário de definição de senha" da CLI não definiu a senha correta dos aplicativos
• ID de bug Cisco CSCtx45528 - a cli de redefinição de pwd retorna bom, mas não altera a senha
• ID de bug da Cisco CSCup30002 - O serviço de BD está inoperante, depois de alterar a senha de segurança no CUCM 10.5
• ID de bug da Cisco CSCus13276 - A recuperação de senha de segurança do CUCM 10.5.2 faz com que o DB não inicie na reinicialização

Se a versão do CUCM contiver correções para todos esses problemas, a solução mais fácil é concluir o procedimento de recuperação de senha detalhado no Guia de Administração do Sistema Operacional do Cisco Unified Communications, Versão 10.0(1) em todos os nós.

Se a versão do CUCM não contiver as correções para esses problemas, o Cisco Technical Assistance Center (TAC) poderá executar uma solução alternativa, dependendo da situação. 

A restauração não processa o componente CCMDB

Se a restauração não listar o componente do BD, é possível que o próprio backup não contenha um componente do BD. Certifique-se de que o BD do editor seja executado e possa aceitar consultas e executar um novo backup.

Falha de Replicação

Consulte o artigo Troubleshooting CUCM Database Replication in Linux Appliance Model Cisco para solucionar problemas de uma falha de replicação.

Os telefones não se registram ou não podem acessar os serviços

Como a restauração do BD não restaura nenhum certificado, se o publicador for o servidor TFTP principal, o assinante será diferente.

Se os telefones confiarem nos certificados do Trust Verification Service (TVS) do assinante e a porta TCP 2445 estiver aberta entre os telefones e os servidores TVS, o problema deverá ser resolvido automaticamente.

Por esse motivo, a Cisco recomenda que você mantenha backups completos de DRF de cluster. 

As versões do CUCM anteriores à versão 8.6 também podem ter problemas de certificado, mesmo com um backup bem-sucedido anterior, devido ao bug da Cisco ID CSCtn50405.

Note: Consulte o artigo Communications Manager Security By Default e ITL Operation and Troubleshooting da Cisco para obter informações adicionais sobre como solucionar problemas de arquivos da lista de confiança inicial (ITL).