Voz e comunicações unificadas : Cisco Unity

Replicação do servidor SQL para o Failover do Cisco Unity

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

Quando o Failover é configurado, o Cisco Unity usa a replicação 2000 do Microsoft SQL server para replicate dados do servidor ativo ao server inativo. Se o Failover ocorre, a replicação dos dados assegura-se de que a configuração atual e os dados do subscritor estejam disponíveis no servidor secundário e que, após o failback, as mudanças feitas no secundário quando era ativo replicated de volta ao preliminar. A replicação é executada pelos trabalhos da replicação do servidor SQL, que são executados pelo serviço SQLSERVERAGENT.

Quando a replicação do servidor SQL quebra, as transações da replicação salvar em tabelas do log de auditoria no servidor ativo assim que os dados podem ser replicated ao server inativo quando a replicação?a. Se a replicação sido quebrada por um longo período, as tabelas do log de auditoria podem tornar-se grandes. Isto pode causar a degradação do desempenho, que por sua vez pode causar a resposta deficiente TUI e pode mesmo fazer com que o Failover ocorra. Além disso, o base de dados do Cisco Unity no server inativo não tem os dados da configuração mais atrasada e do subscritor quando se transforma o servidor ativo.

Pré-requisitos

Requisitos

Certifique-se de que você terminou as exigências para o Failover do Cisco Unity antes que você configure o Failover do Cisco Unity.

Componentes Utilizados

A informação neste documento é baseada no Cisco Unity 4.0(3) 5.x direto.

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.

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Monitore a replicação

Causas da falha da replicação de SQL

A replicação pode falhar se o serviço SQLSERVERAGENT não começa e/ou se os trabalhos da replicação que o serviço executa a falha para começar. Estas falhas podem ocorrer quando o servidor SQL reinicia (por exemplo, quando o server do Cisco Unity está recarregado) em consequência das questões de cronometragem, das correções de programa, ou do aplicativo de políticas da Segurança ou do computador.

Use o log de eventos para monitorar o serviço SQLSERVERAGENT

Se o serviço SQLSERVERAGENT não começa, um evento está entrado o log de evento do sistema. Por exemplo:

Event Type:	Error
Event Source:	Service Control Manager
Event Category:	None
Event ID:		7001
Date:		5/4/2007
Time:		10:58:47 PM
User:		N/A
Computer:		<servername>
Description:
The SQLSERVERAGENT service depends on the MSSQLSERVER service 
which failed to start because of the following error: 
The account name is invalid or does not exist, or the password 
is invalid for the account name specified. 

Além, o Cisco Unity detecta o problema e registra este evento no log de eventos do aplicativo. Recomenda-se que você cria o email ou as notificações de pager baseado neste evento usando todo o serviço do monitoramento de evento. Por exemplo, o serviço do monitoramento de evento do Cisco Unity.

Event Type:	Warning
Event Source:	CiscoUnity_NodeMgr
Event Category:	Run 
Event ID:		1006
Date:		1/1/2007
Time:		9:00:00 AM
User:		N/A
Computer:		<servername> 
Description:
The SQL Server Agent service is not running. It must be running 
in order for replication to take place. 

Use o log de eventos para monitorar trabalhos da replicação

Quando os trabalhos que o serviço SQLSERVERAGENT executa a falha para começar, à revelia, nenhum evento forem entrados o log de eventos. Cisco recomenda que você:

Configurar o servidor SQL para registrar um evento quando um trabalho da replicação não começa

Conclua estes passos:

  1. Comece a enterprise manager do servidor SQL.

  2. No painel esquerdo da enterprise manager, expanda o Microsoft SQL servers > o grupo de servidor SQL > (local) (Windows NT) > agente do Gerenciamento > do servidor SQL, e clique trabalhos.

  3. No painel correto, clicar com o botão direito o nome do trabalho e escolha propriedades > notificações.

    Veja a tabela 1 para uma lista dos trabalhos da replicação começada pelo serviço SQLSERVERAGENT.

  4. Na caixa de diálogo das propriedades do <job>, vá à aba das notificações.

  5. Verifique a escrita à caixa de verificação do log de eventos do aplicativo do Windows.

  6. Clique a APROVAÇÃO para fechar a caixa de diálogo das propriedades do <job>.

  7. Repita etapas 3 com 6 para o resto dos trabalhos para que você quer registrar eventos.

Tabela 1 — Trabalhos da replicação começados pelo serviço SQLSERVERAGENT

Trabalho da replicação Descrição Categoria
Reinitialize as assinaturas que têm falhas da validação de dados. Reinitializes todas as assinaturas que têm falhas da validação de dados. Resposta REPL-alerta
Controle dos agentes da replicação Detecta os agentes da replicação que não registram a história ativamente. REPL-controle
SVRNAME-UnityDb-UnityDbPublication-SVRNAME-3 Distribuição do UnityDb REPL-distribuição
A distribuição limpa: UnityDistributionDb Removes replicated transações do base de dados da distribuição. Limpeza da REPL-distribuição
A história do agente limpa: UnityDistributionDb Remove a história do agente da replicação do base de dados da distribuição. Limpeza da REPL-história
SVRNAME-UnityDb-3 UnityDb LogReader REPL-LogReader
[SVRNAME].9 Lê filas para assinaturas de atualização enfileiradas. REPL-QueueReader
SVRNAME-UnityDb-UnityDbPublication-3 Instantâneo do UnityDb REPL-instantâneo
A assinatura expirada limpa Detecta e remove assinaturas expiradas dos bases de dados publicados. Limpeza da REPL-assinatura

Use a enterprise manager do servidor SQL para monitorar trabalhos da replicação SQLSERVERAGENT

Use a enterprise manager para determinar se os trabalhos da replicação sucedem

Conclua estes passos:

  1. No servidor primário, comece a enterprise manager do servidor SQL.

  2. No painel esquerdo da enterprise manager, expanda o Microsoft SQL servers > o grupo de servidor SQL > (local) (Windows NT) > agente do Gerenciamento > do servidor SQL e clique trabalhos.

  3. No painel correto, cada trabalho tem um ícone que indique sua sucesso ou falha. Todo o trabalho com um ícone do vermelho-ponto falhou. Para alguns trabalhos que falharem, se o valor da coluna de status é:

    • Execução — O ícone vermelho-doc não foi atualizado com o status final. Espere até que o ícone esteja atualizado.

    • Para todo o outro valor, clicar com o botão direito no nome do trabalho, e clique a história de trabalho da vista a fim indicar a razão que o trabalho falhou.

Determine se durante a replicação as transações estão sendo processadas

Durante uma indisponibilidade da replicação, as transações da replicação podem acumular até que haja mais do que pode ser processado quando o sistema segurar um volume da chamada normal. (A maioria de exemplo comum deste é um intervalo ODBC em que os server preliminares e secundários do Cisco Unity tentarem conectar a um outro.) Após a indisponibilidade, quando você permite os trabalhos da replicação ser executado durante uma estadia relativamente lenta (tal como a noite excedente ou sobre um fim de semana), os trabalhos da replicação podem frequentemente claro a reserva de transações unreplicated. Contudo, se há muitas transações unreplicated, as tentativas pelo servidor SQL de replicate os dados podem conduzir a um intervalo. Se a replicação está funcionando mas o número de transações unreplicated não deixou cair significativamente para o fim de um fim de semana, você pôde precisar de desabilitar e re-permitir então a replicação. Veja o desabilitação e Re-permita a seção da replicação deste documento para mais informação.

Use os comandos OSQL nesta seção determinar se o número de transações unreplicated é raramente grande após uma indisponibilidade e se as transações as mais velhas estão sendo processadas. (Para um sistema com um grande número assinantes de Cisco Unity e muita atividade, as transações que variam nas centenas podem ser comuns. As transações que variam nos milhares são motivo de preocupação.)

cuidado Cuidado: Se o número de transações unreplicated é muito grande, os comandos OSQL puderam tomar um muito tempo terminar e pôr a carga adicional considerável sobre o server.

Termine estas etapas a fim indicar uma lista requisitada das datas nos registros pendentes da replicação, que você pode usar para determinar como velho a transação a mais velha é:

  1. No servidor secundário, escolha o Iniciar > Executar.

  2. Execute o Cmd.

  3. No comando prompt, execute este comando a fim começar o OSQL e perguntar o base de dados Unitydb:

    Nota: Este comando é envolvido a uma segunda linha devido às razões espaciais.

    OSQL -E -d Unitydb -Q "SELECT distinct insertdate 
    FROM MSreplication_queue ORDER BY insertdate"
    

Nota: O Switches OSQL é diferenciando maiúsculas e minúsculas (por exemplo, - E).

Termine estas etapas a fim obter um contagem total de registros pendentes da replicação. Você pode executar estes registros diariamente para determinar se o número de transações unreplicated é crescente ou shrinking:

  1. No servidor secundário, escolha o Iniciar > Executar.

  2. Execute o Cmd.

  3. No comando prompt, execute este comando a fim começar o OSQL e perguntar o base de dados Unitydb:

    OSQL -E -d Unitydb -Q "SELECT count(*) FROM MSreplication_queue"
    

    Nota: O Switches OSQL é diferenciando maiúsculas e minúsculas (por exemplo, - E).

Termine estas etapas a fim determinar se os dados do servidor primário replicated ao servidor secundário:

  1. No servidor primário, escolha o Iniciar > Executar.

  2. Execute o Cmd.

  3. No comando prompt, execute este comando a fim começar o OSQL e perguntar o base de dados de UnityDistributionDb:

    Nota: Este comando é envolvido a uma segunda linha devido às razões espaciais.

    OSQL -E -d UnityDistributionDb -Q "SELECT SUM(UndelivCmdsInDistDB) 
    FROM MSdistribution_status"
    

Trabalhos da replicação do reinício

Geralmente, se o serviço SQLSERVERAGENT ou esse dos trabalhos da replicação não começam, é devido a uma questão de cronometragem durante a partida. Você pode geralmente restaurar a replicação quando você começa todos os trabalhos que não começaram.

Comece os trabalhos da replicação que não começaram

Conclua estes passos:

  1. Comece a enterprise manager do servidor SQL.

  2. No painel esquerdo da enterprise manager, expanda o Microsoft SQL servers > o grupo de servidor SQL > (local) (Windows NT) > agente do Gerenciamento > do servidor SQL e clique trabalhos.

  3. Clicar com o botão direito o trabalho que não começou e não clicou o trabalho do começo.

  4. Se o valor da coluna de status não muda à execução, reveja a história de trabalho. Clicar com o botão direito o trabalho, e clique a história de trabalho da vista. Quando a causa da falha é corrigida, repita etapa 3 a fim começar o trabalho.

Desabilite e Re-permita a replicação

Se o número de transações unreplicated é tão grande que os trabalhos da replicação cronometram repetidamente para fora, e se este impede que a replicação reduza significativamente o número de registros unreplicated, você deve desabilitar e então re-permitir a replicação. Termine estes três procedimentos a fim realizar isto:

  1. Desabilite o failover automático, e pare o arquivo e a replicação de SQL

  2. Configurar o Failover no servidor primário

  3. Configurar o Failover no servidor secundário

cuidado Cuidado: Se você desabilita e re-permite a replicação, as transações unreplicated (eventualmente) no preliminar e em servidores secundários estão suprimidas, e o base de dados do Cisco Unity no servidor primário replicated ao servidor secundário. Se há alguma mudança unreplicated no servidor secundário, aquelas mudanças estão perdidas.

Failover automático do desabilitação, e arquivo e replicação de SQL da parada

Conclua estes passos:

  1. Se o servidor primário é ativo, continue pisar 5.

    Se o servidor primário não é ativo, no servidor secundário escolha o Start > Programs > o monitor do Cisco Unity > do Failover.

  2. Clique o failback.

  3. Clique a APROVAÇÃO para confirmar que você quer falhar de volta ao servidor primário.

  4. Feche o monitor do Failover.

  5. No servidor primário, no menu iniciar do Windows, escolha programas > monitor do Cisco Unity > do Failover.

  6. Clique avançado.

  7. Verifique a caixa de verificação do failover automático e do failback do desabilitação.

  8. Clique a APROVAÇÃO e feche o monitor do Failover.

  9. No servidor primário, no menu iniciar do Windows, escolha o programas > ferramentas administrativas > serviços.

  10. No painel correto, fazer duplo clique AvCsNodeMgr.

  11. No tab geral, clique a parada.

  12. No tipo Startup lista, clique deficiente.

  13. Clique em OK.

  14. Feche o indicador dos serviços.

    cuidado Cuidado: Porque o serviço de Node Manager é desabilitado, a replicação de arquivo para. A replicação re-é permitida quando a operação do failover normal recomeça.

  15. No servidor secundário, no menu iniciar do Windows, escolha o programas > ferramentas administrativas > serviços.

  16. No painel correto, fazer duplo clique AvCsNodeMgr.

  17. No tab geral, clique a parada.

  18. No tipo Startup lista, clique deficiente.

  19. Clique em OK.

  20. Feche o indicador dos serviços.

  21. No servidor primário, no menu iniciar do Windows, escolha o Programas > Microsoft SQL Server > Enterprise Manager.

  22. No painel esquerdo do indicador do fundamento de console, consulte ao nó da replicação para o servidor primário. Tipicamente, o nó é três níveis sob o nó do Microsoft SQL servers.

  23. Clicar com o botão direito o nó da replicação, e clique a publicação do desabilitação. O assistente da publicação e da distribuição do desabilitação aparece.

  24. Na página de boas-vindas, clique em seguida.

  25. No desabilitação que publica a página, clique sim, a seguir clique em seguida.

  26. Ao deixar cair da confirmação das publicações pagine, clique em seguida.

  27. Na página de terminação, clique o revestimento.

  28. Quando o processo está completo, clique a APROVAÇÃO.

  29. Feche o indicador do fundamento de console.

  30. Retire a enterprise manager.

Configurar o Failover no servidor primário

Conclua estes passos:

  1. No Windows Explorer, consulte ao diretório CommServer.

  2. Clique duas vezes FailoverConfig.exe para começar o wizard de failover do Cisco Unity configurar.

  3. Na página de boas-vindas, clique em seguida.

  4. No papel do servidor da página da especificação, clique o servidor primário, e clique-o em seguida.

  5. Na entrada o nome de sua página do servidor, clique consulta, seleciona o nome do servidor secundário, e clica a APROVAÇÃO. O endereço IP de Um ou Mais Servidores Cisco ICM NT para o servidor secundário é preenchido automaticamente.

  6. Clique em Next.

  7. Na página da informação de conta do Failover da entrada, o clique consulta, e faz duplo clique o nome da conta de serviços do armazenamento de mensagens. Esta é a conta que o serviço do Failover entra como.

    A conta que você seleciona deve ter o direito de atuar como parte do sistema operacional e de entrar como um serviço, e deve ser um membro do grupo dos administradores locais.

    cuidado Cuidado: Você deve especificar a mesma conta no preliminar e em servidores secundários.

  8. No campo de senha, incorpore a senha para a conta que o serviço do Failover entra como, e o clique em seguida.

  9. No começo que configura sua página do servidor, o clique configura. O assistente verifica ajustes e configura o Failover no servidor primário.

    Se o assistente não termina a configuração com sucesso, um Mensagem de Erro explica porque o assistente falhou. Retire o assistente, corrija o problema, e o clique configura outra vez.

  10. Na página de terminação, revestimento do clique.

Configurar o Failover no servidor secundário

Conclua estes passos:

  1. Na barra de tarefas do Windows, fazer duplo clique o relógio de sistema. A caixa de diálogo das propriedades da data/hora aparece.

  2. Ajuste a hora à mesmos hora e minuto como mostrado no servidor primário, e a APROVAÇÃO do clique.

  3. No Windows Explorer, consulte ao diretório CommServer.

  4. Clique duas vezes FailoverConfig.exe para começar o wizard de failover do Cisco Unity configurar.

  5. Na página de boas-vindas, clique em seguida.

  6. No papel do servidor da página da especificação, clique o servidor secundário, e clique-o em seguida.

  7. Na entrada o nome de sua página do servidor, clique consulta, seleciona o nome do servidor primário, e clica a APROVAÇÃO. O endereço IP de Um ou Mais Servidores Cisco ICM NT para o servidor primário é preenchido automaticamente.

  8. Clique em Next.

  9. Na página da informação de conta do Failover da entrada, o clique consulta, e faz duplo clique o nome da conta de serviços do armazenamento de mensagens. Esta é a conta que o serviço do Failover entra como.

    A conta que você seleciona deve ter o direito de atuar como parte do sistema operacional e de entrar como um serviço, e deve ser um membro do grupo dos administradores locais.

    cuidado Cuidado: Você deve especificar a mesma conta no preliminar e em servidores secundários.

  10. No campo de senha, incorpore a senha para a conta que o serviço do Failover entra como e clique em seguida.

  11. No começo que configura sua página do servidor, o clique configura. O assistente verifica ajustes e configura o Failover no servidor secundário.

    Se o assistente não termina a configuração com sucesso, um Mensagem de Erro explica porque o assistente falhou. Retire o assistente, corrija o problema, e o clique configura outra vez.

  12. Na página de terminação, revestimento do clique.

Edição do failover do Unity

Problema: Receba erros da replicação de SQL cada 10-15 minutos

No visualizador de eventos, este Mensagem de Erro é recebido:

Event Type:	Warning
Event Source:	CiscoUnity_NodeMgr
Event Category:	Run 
Event ID:	1014
Date:		6/25/2010
Time:		12:32:37 PM
User:		N/A
Computer:	AXLDUM01
Description:
Error getting status of SQL Server replication between the primary and 
secondary machines. Unable to get status of SQL Server subscription to 
publication UnityDbPublication for AXLDUM02. Error = 0x80045510.  This may 
be a temporary condition. If not, recreate the subscription and the 
publication snapshot to restore replication.

Solução

Execute estas etapas para resolver esta edição:

  1. No menu iniciar do Windows do servidor primário, vá ao Programas > Microsoft SQL Server > Enterprise Manager.

  2. No painel esquerdo, expanda o Microsoft SQL servers > o grupo de servidor SQL.

  3. No painel esquerdo, sob o grupo de servidor SQL, clique o <servername>.

  4. No menu das ferramentas da enterprise manager do servidor SQL, clique a replicação > a publicação e a distribuição do desabilitação.

  5. Na boa vinda ao wizard do assistente da publicação e da distribuição do desabilitação, clique em seguida.

  6. No desabilitação que publica a caixa de diálogo, clique sim, desabilite a publicação no <servername>, e clique-a em seguida. Então, execute as etapas que aparecem na tela a fim desabilitar a publicação no servidor primário.

  7. Torne a colocar em funcionamento o assistente da configuração de failover do Cisco Unity no servidor primário.

    Nota: Seja certo usar a conta correta do Cisco Unity (o Unity instala) para executar o FCW.

  8. Vá aos programas > ao Microsoft SQL server > à utilidade de rede cliente no servidor primário.

  9. Sob o tab geral, confirme que os protocolos permitidos pela ordem são do TCP/IP e das tubulações nomeada como mostrado aqui:

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-01.gif

  10. Sob a aba do pseudônimo, o clique adiciona, ajusta o nome de máquina do servidor de unidade secundário no server aliás, e a APROVAÇÃO do clique.

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-02.gif

    http://www.cisco.com/c/dam/en/us/support/docs/unified-communications/unity/91961-sql-svr-rep-cu-failover-03.gif

  11. Similarmente, execute as etapas de 8 ao 10 para o servidor secundário. Aqui no servidor secundário sob a aba do pseudônimo, o clique adiciona e ajusta o nome do servidor de unidade preliminar como o server aliás, e a APROVAÇÃO do clique.

  12. Torne a colocar em funcionamento o assistente da configuração de failover do Cisco Unity no servidor secundário.

Mude que explica para possuir trabalhos da replicação

À revelia, o domínio do Windows explica para possuir trabalhos da replicação. Isto adiciona alguma complexidade introduzindo dependências na autenticação do Windows e em uma comunicação dos trabalhos em rede. O servidor SQL tem duas contas incorporados que não são contas do domínio do Windows e são originais ao servidor SQL. A fim reduzir dependências, mude a posse dos trabalhos da replicação a uma destas contas do servidor SQL:

  • A conta sa é a conta administrativa do servidor SQL incorporado. Esta conta tem um nível alto do acesso.

  • A conta do distributor_admin é criada quando a replicação é configurada. Esta conta tem um nível inferior do acesso do que a conta sa.

Mude a conta que possui trabalhos da replicação

Conclua estes passos:

  1. Comece a enterprise manager do servidor SQL.

  2. No painel esquerdo da enterprise manager, expanda o Microsoft SQL servers > o grupo de servidor SQL > (local) (Windows NT) > agente do Gerenciamento > do servidor SQL, e clique trabalhos.

  3. Para o primeiro trabalho da replicação alistado na tabela 1, clicar com o botão direito no trabalho, e clique propriedades.

  4. No tab geral, na lista do proprietário, clique o nome da conta que você quer possuir o trabalho. Cisco recomenda que você escolhe a conta do distributor_admin.

  5. Clique a APROVAÇÃO para fechar a caixa de diálogo das propriedades do <job>.

  6. Repita etapas 3 com 5 para o resto dos trabalhos na tabela 1.

  7. Reinicie todos os trabalhos da replicação:

    1. Para o primeiro trabalho da replicação alistado na tabela 1, clicar com o botão direito o trabalho e clique o trabalho da parada.

    2. Clicar com o botão direito o trabalho e clique o trabalho do começo.

    3. Repita as etapas a e b para o resto dos trabalhos na tabela 1.

Melhorias mais adicionais para a monitoração da replicação

Uma edição proeminente com trabalhos da replicação do servidor SQL da monitoração é que alguns trabalhos começam somente uma vez, quando o servidor SQL e o serviço SQLSERVERAGENT são começados. Em consequência, se os trabalhos falham, fazem com somente que um evento seja registrado. (Outros trabalhos da replicação começam, parada “vão dormir,” e reiniciar então. Estes trabalhos registram um erro cada vez que não começam.)

Monitore continuamente o estado dos trabalhos que começam somente uma vez, o grupo de engenharia do Cisco Unity adiciona a monitoração de trabalhos da replicação à monitoração existente do serviço SQLSERVERAGENT, como descrita mais cedo neste documento. Esta melhoria é seguida com identificação de bug Cisco CSCsi50517 (clientes registrados somente).

SQLSERVERAGENT: 208: '''' Programado servidor SQL do controle dos agentes da replicação do '''' do trabalho

No visualizador de eventos, este messge do erro é recebido:

SQLSERVERAGENT: 208: SQL Server Scheduled Job ''''Replication agents checkup''''
(0x8666D34A10837246B4030EA4E93E50BC) - Status: Failed - Invoked on: 2009-08-19 
03:30:01 - Message: The job failed. The owner () of job Replication agents 
checkup does not have server access.

Siga estes passos para resolver esse problema:

  1. Abra o parâmetro empresarial SQL e verifique os trabalhos que falham.

  2. Abra propriedades e verifique que o proprietário é distributor_admin somente.

  3. Reinicie os trabalhos.


Informações Relacionadas


Document ID: 91961