O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
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 como restaurar o nó do editor do Cisco Unified Communications Manager (CUCM) a partir do banco de dados do assinante sem backup anterior ou acesso raiz.
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.
Observação: a Cisco recomenda que você revise e se familiarize com todo o processo descrito neste documento antes de começar.
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:
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.
Observação: é 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.
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
Reunir uma imagem inicializável da versão apropriada e executar uma instalação com uma atualização para a versão apropriada.
Observação: 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.
Observação: 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 Disaster_Recovery prepare restore pub_from_sub; no entanto, este é 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
Observação: 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.
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
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
Observação: 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.
Se nenhum backup anterior estiver disponível, execute um backup de cluster na página DRS.
Observação: embora você possa usar o DB do assinante para a restauração, um backup ainda é necessário 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.
Use o menu de navegação para navegar para o Sistema de recuperação de desastres e adicione um dispositivo de backup.
Depois que o dispositivo de backup for adicionado, inicie um backup manual.
Observação: é crítico que o nó do editor tenha o componente CCMDB registrado.
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.
Quando a restauração alcança o componente CCMDB, o texto Status deve aparecer como Restaurando o Publicador do Backup do Assinante:
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:
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
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.
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.
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.
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:
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:
Observação: para clusters de modo misto, você deve executar novamente o cliente da Lista de Certificados Confiáveis (CTL).
Esta seção descreve vários cenários que podem fazer com que esse procedimento falhe.
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:
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.
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.
Consulte o artigo Troubleshooting CUCM Database Replication in Linux Appliance Model Cisco para solucionar problemas de uma falha de replicação.
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.
Observação: 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).
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
11-Oct-2023 |
Versão inicial |