Como solucionar problemas de replicação contínua em cluster
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Tópico modificado em: 2008-01-14
Este tópico discute soluções de problemas relacionados à CCR (replicação contínua em cluster). Para obter mais informações sobre ferramentas que podem auxiliá-lo na solução de problemas de CCR, consulte Ferramentas para solução de problemas de implantações de alta disponibilidade.
Os procedimentos deste tópico tratam dos seguintes problemas em um ambiente de CCR:
Get-StorageGroupCopyStatus relata que o banco de dados está no estado “Falha” e não é propagado.
Get-StorageGroupCopyStatus relata que o banco de dados está no estado “Falha”. O valor FailedMessage indica que a cópia do grupo de armazenamento está diferente.
Get-StorageGroupCopyStatus relata que o banco de dados está no estado “Falha”. O valor FailedMessage fornece informações específicas sobre a origem da falha.
Alertas, contadores de desempenho ou Get-StorageGroupCopyStatus indicam que backups de filas de cópia ou de repetição são feitos para uma cópia do grupo de armazenamento.
Get-StorageGroupCopyStatus relata um horário obsoleto para LastInspectedLogTime.
Failover ou Move-ClusteredMailboxServer são bem-sucedidos, mas os bancos de dados não são montados.
Failover bem-sucedido, mas alguns bancos de dados não são montados automática ou manualmente. Como alternativa, o Get-ClusteredMailboxServerStatus também relata um ou mais bancos de dados que falharam.
A montagem de um banco de dados falha na inicialização em um ambiente de CCR.
O evento MSExchangeRepl 2073 é registrado alertando que o Serviço de Replicação do Microsoft Exchange não pode localizar um diretório.
Move-ClusteredMailboxServer não inicia uma interrupção agendada devido a um problema de replicação.
A replicação não é ressincronizada após um failover em um ou mais grupos de armazenamento.
A propagação está falhando.
Quando ocorre uma falha que não esteja listada aqui, olhe o log de eventos em ambos os nós para determinar a causa e use as informações nos logs para determinar quais ações de recuperação devem ser executadas. Quando você tiver identificado a hora em que a falha ocorreu, outros logs de evento podem ajudar você a compreender melhor o problema. Caso essa informação seja insuficiente, o conhecimento da hora em que o problema ocorreu pode ser usado para restringir sua análise e o tamanho da janela de consulta no cluster.log. O log de cluster fornece informações sobre o nível de rastreamento das ações executadas pelo sistema de gerenciamento de cluster.
Antes de começar
Para executar esse procedimento, você deve usar a conta à qual esteja delegada a função Administrador do Exchange Server e o grupo Administradores local do servidor de destino. Para obter mais informações sobre permissões, delegação de funções e os direitos necessários para administrar o Microsoft Exchange Server 2007, consulte Considerações sobre permissão.
Procedimento
Get-StorageGroupCopyStatus relata que o banco de dados está no estado de “Falha” e não é propagado
Possíveis Causas Um problema de configuração ou a cópia de replicação não tem um banco de dados de linha de base válido. Esse problema pode ser causado pela não propagação da cópia do grupo de armazenamento quando o nó passivo foi adicionado.
Resolução
Verifique se o armazenamento da cópia está configurado corretamente e em operação. Se você encontrar um erro, poderá acionar uma nova verificação da cópia suspendendo e retomando o grupo de armazenamento.
Verifique se o grupo de armazenamento e os caminhos de banco de dados estão corretamente configurados com relação ao armazenamento no servidor passivo. Você pode fazer isso executando o cmdlet Get-StorageGroup no Console de Gerenciamento do Exchange.
Use o cmdlet Update-StorageGroupCopy para propagar a cópia do grupo de armazenamento.
Get-StorageGroupCopyStatus relata que o banco de dados está no estado de "Falha" e o valor FailedMessage indica que houve divergência na cópia do grupo de armazenamento
Possíveis Causas Ocorre quando há um failover e os logs suficientes são perdidos quando o banco de dados no servidor ativo anterior não pode ser ressincronizado com o banco de dados ativo atual sem uma nova propagação completa. Essa situação não pode ocorrer em LCR.
Resolução Use o cmdlet Update-StorageGroupCopy para propagar a cópia do grupo de armazenamento.
Get-StorageGroupCopyStatus relata que o banco de dados está no estado de "Falha" e o valor FailedMessage fornece informações específicas sobre a origem da falha
Causas Possíveis Várias causas possíveis poderiam resultar em uma cópia do grupo de armazenamento sendo determinada como falha. Os casos anteriores, não ser propagado e ser diferente, são dois exemplos. O valor de FailedMessage identifica especificamente o problema detectado.
Resolução Execute o cmdlet Get-StorageGroupCopyStatus para obter o valor completo de FailedMessage, que identifica o problema específico detectado. Analise as informações fornecidas pelo valor de FailedMessage e resolva as condições relatadas. Se a condição relatada for um log ausente ou danificado, tente encontrar um log não danificado com o número de geração correto. Se o log correto não puder ser encontrado, use o cmdlet Update-StorageGroupCopy para propagar novamente. Se a mensagem indicar que os logs na origem não estão disponíveis, remova o compartilhamento do diretório de log de origem e reinicie o serviço de replicação nesse nó.
Alertas, contadores de desempenho ou Get-StorageGroupCopyStatus indicam que backups de filas de cópia ou de repetição são feitos para uma cópia do grupo de armazenamento
Possíveis Causas Um registro posterior de cópia ou repetição de log poderia indicar um problema ou uma condição transicional em um processo de recuperação. Uma situação transicional ocorre quando um nó passivo offline anteriormente é colocado online ou uma cópia do grupo de armazenamento foi recentemente continuada após ser suspensa por um período significativo. Interromper o Serviço de Replicação do Microsoft Exchange no nó passivo tem efeito similar à suspensão de todas as cópias do grupo de armazenamento no nó. Se a situação não for transicional, ela poderá ter sido ser causada por uma das seguintes razões:
Problema na configuração.
Cópia de armazenamento suspensa.
O serviço de repetição está parado.
Falha no armazenamento ou o armazenamento está offline.
O nó passivo está offline.
Resolução Determine se há um problema real ou uma situação transicional:
Determine se o Serviço de Replicação do Microsoft Exchange está sendo executado nos dois nós. Você pode fazer isso utilizando o snap-in Serviços. Se o serviço estiver interrompido em um dos nós, você deverá iniciá-lo.
Execute o cmdlet Get-StorageGroupCopyStatus do Shell de Gerenciamento do Exchange com a opção fl (lista formatada) e determine se a cópia passiva está suspensa. Se estiver suspensa, verifique se os arquivos da cópia passiva estão devidamente presentes e continue a cópia do grupo de armazenamento usando o cmdlet Resume-StorageGroupCopy.
Execute o cmdlet Get-StorageGroupCopyStatus com a opção fl e determine se a cópia é “Adequada”. Se o status da cópia for “Falha”, reveja a lista de campos de status para determinar a ação corretiva necessária.
Observe os contadores de desempenho de replicação por um período de vários minutos para determinar se está havendo progresso. Especificamente, consulte o número de geração de repetição e o número de geração de inspeção. Se o comprimento da fila de cópias continuar aumentando, mas comprimento da fila de repetições for curto ou estiver diminuindo, poderá haver um problema com o compartilhamento de arquivo de rede no servidor ativo ou com o próprio servidor ativo. Verifique se o diretório de log da cópia do grupo de armazenamento ativo possui um compartilhamento de arquivo de rede definido nele, usando o comando "net share", o Windows Explorer ou o snap-in Gerenciamento de Computador. Você pode determinar a GUID do grupo de armazenamento usando o cmdlet Get-StorageGroup com a opção fl no Shell de Gerenciamento do Exchange.
Get-StorageGroupCopyStatus relata um horário antigo para LastInspectedLogTime
Possíveis Causas Há três possíveis causas desse sintoma:
O banco de dados da cópia do grupo de armazenamento ativo está desmontado.
A cópia do grupo de armazenamento ativo está montada, mas não está sendo alterada em uma taxa significativa. Portanto, os logs não estão sendo produzidos pela cópia do grupo de armazenamento ativo.
O Serviço de Replicação do Microsoft Exchange não está sendo executado no nó passivo.
Resolução Determine quais das três causas está ocorrendo fazendo o seguinte:
Determine se o banco de dados está desmontado usando o Console de Gerenciamento do Exchange ou executando o cmdlet Get-StorageGroupStatus no Shell de Gerenciamento do Exchange. Se estiver desmontado, você deverá montar o banco de dados e realizar alterações no banco de dados (por exemplo, atividade dentro do banco de dados) para alterar LastInspectedLogTime.
Verifique se o Serviço de Replicação do Microsoft Exchange está sendo executado no nó passivo. Se o serviço estiver parado, você deverá iniciá-lo.
Depois de verificar se o banco de dados está montado, verifique se o banco de dados está gerando logs. Procure no diretório de log do banco de dados ativo e identifique o arquivo de log com o maior número de geração. Verifique o carimbo de hora no log; ele deve corresponder ao valor em LastInspectedLogTime.
Failover ou Move-ClusteredMailboxServer são bem-sucedidos, mas os bancos de dados não são montados
Possíveis Causas A causa típica deste problema é que a conta do serviço de cluster não tem a autoridade necessária para montar o banco de dados. Como alternativa, o failover resulta em mais logs perdidos que o permitido pelas definições de configuração de montagem automática. A outra causa típica no caso de failover é que as cópias passivas não eram adequadas no momento da falha.
Resolução Problemas de permissão com a conta de Serviço de cluster normalmente ocorrem durante a instalação. Se os bancos de dados não forem montados no final da instalação, normalmente isso indica que não foram concedidas à conta de Serviço de cluster as permissões adequadas. Para resolver o problema, conceda as permissões adequadas à conta de Serviço de cluster e execute um desligamento e uma reinicialização organizada de todo o cluster. Você pode fazer isso (1) colocando o servidor de caixas de correio clusterizadas offline, (2) desligando o nó passivo, (3) desligando o nó ativo; (4) iniciando o nó ativo; (5) iniciando o nó passivo e (6) colocando o servidor de caixas de correio clusterizadas online.
- Analise o log de eventos para determinar se o failover perdeu mais logs que o permitido pelas definições de configuração de montagem automática. Depois de determinado o status do banco de dados da cópia do grupo de armazenamento, você poderá montá-lo explicitamente executando o cmdlet Restore-StorageGroupCopy no Shell de Gerenciamento do Exchange. Por fim, execute o cmdlet Get-StorageGroupCopy e verifique o valor SummaryCopyStatus para identificar se há problemas com a cópia ativa que anteriormente impediu a montagem. Se houver problemas, analise o log de eventos para identificar a causa do problema e execute as etapas para resolver o problema.
Failover bem-sucedido, mas alguns bancos de dados não são montados automática ou manualmente. Como alternativa, Get-ClusteredMailboxServerStatus relata um ou mais bancos de dados que falharam
Possíveis Causas Um failover recente resultou em mais log perdidos que o permitido pelas definições de configuração de montagem automática. A outra causa típica no caso de failover é que a cópia passiva não era adequada no momento da falha.
Dica
Os bancos de dados podem ser brevemente marcados como falha ou offline durante uma interrupção agendada ou não agendada. Esse estado é transicional e ocorre enquanto o serviço de replicação está tentando fazer uma cópia final de todos os logs disponíveis.
Resolução Analise o log de eventos para determinar por que o banco de dados falhou na montagem. O banco de dados pode falhar na montagem devido a danos nos logs ou nos arquivos do banco de dados. Caso o evento indique isso, restaure o acesso ao banco de dados movendo o servidor ativo para outro nó. Você pode determinar se o banco de dados falhou analisando o log de eventos. Depois de determinado o status do banco de dados da cópia do grupo de armazenamento, você poderá montá-lo explicitamente executando o cmdlet Restore-StorageGroupCopy no Shell de Gerenciamento do Exchange. Em seguida, execute o cmdlet Get-StorageGroupCopyStatus e verifique o valor SummaryCopyStatus para identificar se há problemas com a cópia ativa que anteriormente impediu a montagem. Se o status mostrar que a cópia do grupo de armazenamento é muito antiga para ser ativada, o banco de dados pode ser restaurado quando o nó com falha retornar ao serviço e mais logs estiverem disponíveis. Os logs são copiados automaticamente e não é necessária nenhuma ação do usuário.
A montagem de um banco de dados falha na inicialização em um ambiente de CCR.
Possíveis Causas A falha da montagem do banco de dados pode ser resultado de uma ação explícita do administrador. Se um banco de dados for desmontado explicitamente, e o servidor de caixas de correio clusterizadas for colocado offline, o banco de dados não será colocado online na próxima inicialização. Outra causa possível poderia ser que mais logs que o aceitável foram perdidos durante um failover.
Resolução Você pode executar o cmdlet Get-ClusteredMailboxServerStatus no Shell de Gerenciamento do Exchange para verificar se o armazenamento está em funcionamento no nó. Use o Console de Gerenciamento do Exchange ou o Shell de Gerenciamento do Exchange para tentar uma operação de montagem da cópia do banco de dados afetado. Para obter mais informações sobre como montar a cópia do banco de dados, consulte Como montar um banco de dados em um ambiente de Replicação Contínua em Cluster. Analise o log de eventos após a operação de montagem para determinar se foram relatados erros.
O evento de cluster MSExchangeRepl 2073 é registrado alertando que o Serviço de Replicação do Microsoft Exchange não pode localizar um diretório especificado
Causas Possíveis O evento de erro indica que não foi possível para o Serviço de Replicação do Microsoft Exchange criar o diretório que é especificado pelo evento. O Serviço de Replicação do Microsoft Exchange tenta criar vários diretórios necessários se eles ainda não existirem. Entre eles estão os caminhos de diretório para arquivos de log de origem, arquivos de log de destino, arquivos de sistema de destino e o caminho para a inspeção de arquivo de log.
O Serviço de Replicação do Microsoft Exchange talvez não possa criar o diretório especificado devido a um problema de permissão, uma falha de hardware ou uma falha de configuração.
Resolução Examine o código de erro retornado pelo evento. Verifique se o local do diretório está disponível e se pode ser acessado. Verifique as permissões do sistema de arquivo. Verifique se o armazenamento está configurado corretamente e se o hardware está sendo operado corretamente.
Move-ClusteredMailboxServer não inicia uma interrupção agendada devido a um problema de replicação
Possíveis Causas O cmdlet Move-ClusteredMailboxServer do Shell de Gerenciamento do Exchange inclui verificações de validação para evitar uma interrupção agendada de um nó passivo se a replicação não estiver completamente adequada em todas as cópias do grupo de armazenamento. Esse comportamento verifica se as interrupções agendadas não foram estendidas por uma duração de tempo inadequada.
Resolução Identifique os grupos de armazenamento específicos com o problema e corrija os problemas. A mensagem de erro do cmdlet Move-ClusteredMailboxServer identifica uma cópia problemática do grupo de armazenamento. Se você deseja mover e ignorar a verificação da validação, verifique se apenas o banco de dados da cópia do grupo de armazenamento com falha foi desmontado. Repita a operação de movimentação e use o parâmetro -IgnoreDismounted. O parâmetro IgnoreDismounted indica que os grupos de armazenamento desmontados devem ser ignorados com o objetivo de verificações de integridade de replicação.
A replicação não é ressincronizada após um failover em um ou mais grupos de armazenamento
Possíveis Causas A mensagem de falha retornada pelo cmdlet Get-StorageGroupCopyStatus indica que houve divergência no banco de dados. Essa situação se deve a um failover quando o servidor ativo antigo não possuía logs replicados suficientes antes do failover.
Resolução Refaça a propagação do banco de dados usando o cmdlet Update-StorageGroupCopy no Shell de Gerenciamento do Exchange.
A propagação está falhando
Possíveis Causas Um backup está em progresso no servidor ativo ou há um problema de comunicação.
Resolução Verifique se um backup da cópia ou do banco de dados do grupo de armazenamento afetado não está em andamento. Verifique se o nó ativo está online.
Para obter mais informações
Para obter mais informações sobre os cmdlets do Shell de Gerenciamento do Exchange mencionados neste tópico, consulte os seguintes tópicos:
Para obter informações sobre como solucionar problemas de replicação contínua local, consulte Como solucionar problemas de replicação contínua local.