Restauração de nó do editor CUCM a partir do banco de dados do assinante sem backup prévio ou acesso raiz

Introduction

Este documento descreve como restaurar o nó do editor do Cisco Unified Communications Manager (CUCM) do banco de dados de assinantes (DB) sem backup prévio ou acesso raiz.

Background

Em versões anteriores do CUCM, o nó do editor foi considerado como a única fonte autoritativa para o banco de dados de Linguagem de Consulta Estruturada (SQL - Structured Query Language). Consequentemente, se um nó publicador foi perdido devido a uma falha de hardware ou a um sistema de arquivos corrompido, a única maneira de recuperá-lo era reinstalar e restaurar o banco de dados de um backup do Sistema de Recuperação de Desastre (DRS).

Alguns clientes não mantinham backups adequados ou tinham backups desatualizados, então a única opção era reconstruir e reconfigurar o nó do servidor do editor. 

No CUCM versão 8.6(1), um novo recurso foi introduzido para restaurar um DB de editor de um banco de dados de assinante. Este documento descreve como aproveitar este recurso para restaurar com êxito um banco de dados de 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 somente 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 de DRF de cluster completo. 

Note: A Cisco recomenda que você analise e conheça todo o processo descrito neste documento antes de começar.  

Reunir dados do cluster

Antes de reinstalar o editor, é importante que você reúna os detalhes pertinentes sobre o editor anterior. Esses 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 na lista, insira o comando show network cluster na CLI atual do nó do assinante:

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 é cucm911cnapub, 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 suposição de melhor esforço e tente 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 do 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), reúna 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 no assinante, e vice-versa. Use esta saída apenas como diretriz.

Interromper replicação em todos os assinantes

Quando o editor está instalado, é essencial que a replicação não configure e exclua os bancos de dados atuais do assinante. Para evitar isso, insira o comando utils dbreplication stop em todos os assinantes:

admin:utils dbreplication stop
********************************************************************************
This command will delete the marker file(s) so that automatic replication setup
is stopped
It will 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

Reúna uma imagem inicializável da versão apropriada e execute uma instalação com uma atualização para a versão apropriada.

Note: A maioria das versões do Cisco CUCM Engineering Special (ES) já é inicializável.

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

Atualizar valores do nó de processo no editor

Note: O editor deve estar ciente de pelo menos um servidor de assinante para restaurar o banco de dados 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 desastre_recovery prepare restore pub_from_sub deve ser executado na CLI do editor antes de continuar para adicionar nós ao Sistema > Servidor:

Depois de receber a lista de nós, navegue para System > Server e adicione todos os valores de nome diferentes de EnterpriseWideData à página do Publisher Server Unified CM Administration. 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. Talvez seja necessário alterá-lo para um endereço IP se a coluna de nome lista 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 depois que as alterações no nó de processamento estiverem concluídas, 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 a autenticação do cluster

Após a reinicialização do editor, se você fez as alterações corretamente e a senha de segurança estiver correta, o cluster deve 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 2013172.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 banco de dados do assinante para a restauração, ainda é necessário um backup para restaurar os componentes não-DB.

Se não houver backup disponível, execute um novo backup; se já existir um backup, você pode ignorar esta seção. 

Adicionar um dispositivo de backup

Use o menu de navegação para navegar até o Sistema de recuperação de desastres e adicionar 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 banco de dados do assinante

Na página Sistema de recuperação de desastre, navegue para Restaurar > Assistente de restauração. Se um backup atual estiver disponível e você tiver ignorado 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 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 banco de dados do assinante 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 Publisher do Backup do Assinante:

Execute uma verificação de integridade no banco de dados do Publisher

Antes de reinicializar e configurar a replicação, é recomendável verificar se a restauração foi bem-sucedida e se o banco de dados 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(*) do usuário final

Reinicie o cluster

Depois que a restauração for concluída, 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 os 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 Unified CM Hosts, Unified CM Rhosts e Unified CM Sqlhosts correspondam ao editor. Caso contrário, os nós que não coincidirem 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 pode não ser configurada automaticamente. Para verificar isso, aguarde até que todos os serviços sejam iniciados e insira o comando utils dbreplication runtime. 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 dos nós):

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

Se algum nó aparecer com um valor de estado de 4, ou se a replicação não for configurada com êxito após várias horas, insira o comando utils dbreplication reset all do nó publicador. Se a replicação continuar a falhar, consulte o artigo Troubleshooting CUCM Database Replication in Linux Appliance Model da 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 instalados ou restaurados manualmente.

Ativar serviços

A restauração de DRF não ativa nenhum serviço. Navegue até 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 não houver um backup completo disponível, você deverá reproduzir determinadas configurações manuais. Especificamente, as configurações que envolvem certificados e funções TFTP:

• arquivos MoH
• Pacotes de dispositivos
• Planos de discagem (para discagem de Plano de numeração não norte-americano (NANP))
• Locais
• Quaisquer outros arquivos COP diversos
• Quaisquer arquivos que foram carregados manualmente para o editor (se fosse um servidor TFTP)
• Strings de comunidade do Protocolo de Gerenciamento de Rede Simples (SNMP - Simple Network Management Protocol)
• Exportações em massa de certificados para o Cluster de cruzamento de mobilidade de ramal (EMCC), Gerenciador de largura de banda de local entre clusters (LBM) e Serviço de pesquisa entre clusters (ILS)
• Trocas de certificados para troncos seguros, gateways e pontes de conferência

Note: Para clusters de modo misto, você deve executar novamente o cliente da lista de confiança de certificado (CTL).

Troubleshoot

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 autenticar, as duas causas mais comuns são senhas de segurança e problemas de conectividade incompatíveis 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 do editor e do 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 não houver correspondência, pode haver dificuldades ao 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 da Cisco CSCug97360 - nega os selinux no utilitário pwrecovery
• ID de bug da Cisco CSCts10778 - Negações lançadas para o procedimento de recuperação de senha de segurança
• ID de bug da Cisco CSCua09290 - CLI "set password user security" não definiu a senha correta do aplicativo
• ID de bug da Cisco CSCtx45528 - pwd reset cli retorna bom, mas não altera a senha
• ID de bug da Cisco CSCup30002 - o serviço DB está inoperante, depois de alterar a senha de segurança no CUCM 10.5
• ID de bug Cisco CSCus13276 - A recuperação de senha de segurança 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 Cisco Unified Communications Operating System Administration Guide, Release 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) pode ter a capacidade de 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 DB, então é possível que o backup em si não contenha um componente DB. Assegure-se de que o banco de dados do editor execute e possa aceitar consultas e executar um novo backup.

Falha na replicação

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

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

Como a restauração do banco de dados não restaura nenhum certificado, se o editor for o servidor TFTP principal, o assinante será diferente. Se os telefones confiarem nos certificados do TVS (Trust Verification Service) do assinante e a porta 2445 do TCP 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 anterior bem-sucedido, devido à ID de bug da Cisco CSCtn50405.

Note: Consulte o artigo Segurança por padrão do Communications Manager e Operação e Troubleshooting do ITL da Cisco para obter informações adicionais sobre como solucionar problemas de arquivos da Lista de Confiança Inicial (ITL).