Gerenciando a Replicação Contínua em Espera

Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1

Tópico modificado em: 2008-11-19

Além das tarefas de gerenciamento e administração diárias de uma organização do Microsoft Exchange, há tarefas específicas de uma replicação contínua em espera (SCR). Geralmente, as tarefas administrativas de SCR são:

• Configurar o armazenamento em disco para SCR e gerenciar volumes de disco.

• Habilitar e desabilitar SCR.

• Monitorar a atividade de replicação.

• Montar, desmontar, criar e remover bancos de dados.

• Mover o local de armazenamento do grupo de armazenamento ou dos arquivos de banco de dados quando um grupo de armazenamento estiver habilitado para SCR.

• Verificando o funcionamento do destino de SCR.

• Gerenciar a atividade de replicação e repetição.

• Recuperar de danos.

Essas tarefas são discutidas no lembrete deste tópico.

A SCR é habilitada e gerenciada somente para uso no Shell de Gerenciamento do Exchange. O Console de Gerenciamento do Exchange não pode ser usado para habilitar ou desabilitar a SCR, visualizar o status da SCR ou gerenciar quaisquer aspectos da SCR.

Configurando o armazenamento em disco para replicação contínua em espera

A SCR não exige configuração especial de armazenamento em disco. A SCR exige armazenamento que oferece capacidade adequada. Soluções de armazenamento equivalentes devem ser configuradas para todos os destinos da SCR configurados para o mesmo grupo de armazenamento. Recomenda-se seguir os procedimentos de configuração indicados pelo fornecedor de armazenamento, para concluir a configuração.

Gerenciamento de volumes de discos em um ambiente de SCR

Durante o gerenciamento de um ambiente de SCR, pode ser necessário gerenciar volumes de discos que estejam conectados ao servidor Exchange. Por exemplo, talvez seja necessário desconectar temporariamente o sistema para manutenção ou por outros motivos. Se a manutenção precisar ser executada no volume de disco que contém a cópia ativa do grupo de armazenamento, o banco de dados na cópia ativa do grupo de armazenamento deverá ser desmontado. Se a manutenção tiver de ser executada nos volumes de discos que contenham a cópia passiva do grupo de armazenamento, toda a E/S (entrada/saída) para o volume deverá ser parada, interrompendo a replicação. Para obter mais informações sobre como gerenciar volumes de discos, consulte Como preparar atividades de gerenciamento de disco ao usar a SCR.

Habilitando a replicação contínua em espera

A SCR é habilitada para uso no Shell de Gerenciamento do Exchange executando o cmdlet New-StorageGroup ou o cmdlet Enable-StorageGroupCopy. Esses dois cmdlets incluem alguns parâmetros novos que são introduzidos com o Microsoft Exchange Server 2007 Service Pack 1 (SP1):

• -StandbyMachine   Esse parâmetro é usado para especificar o nome do computador que conterá o destino da SCR. O valor desse parâmetro é definido como parte do valor do atributo msExchStandbyCopyMachines do grupo de armazenamento que está sendo habilitado para SCR. O atributo msExchStandbyCopyMachines é uma cadeia de caracteres com vários valores Unicode que é adicionado ao esquema de serviço de diretório do Active Directory quando o Exchange 2007 SP1 é introduzido na organização do Exchange.

• -ReplayLagTime   Esse parâmetro é usado para especificar o tempo que o serviço de replicação do Microsoft Exchange aguarda antes de repetir os arquivos de log que foram copiados para o computador de destino de SCR. O formato desse parâmetro é (Dias.Horas:Minutos:Segundos). A definição padrão para esse valor é de 24 horas. A definição máxima permitida para esse valor é de 7 dias. A definição mínima permitida é de 0 segundos, embora a definição desse valor como 0 segundos não afete o atraso padrão na atividade de repetição do log de 50 arquivos de log. Depois de definido, o valor desse parâmetro não pode ser alterado sem que a SCR seja desabilitada e reabilitada.

• -TruncationLagTime   Esse parâmetro é usado para especificar o tempo que o serviço de replicação do Microsoft Exchange deve aguardar antes de truncar os arquivos de log que foram copiados no computador de destino SCR e repetidos na cópia do banco de dados. O período de tempo começa depois que o log foi repetido com êxito na cópia do banco de dados. O formato desse parâmetro é (Dias.Horas:Minutos:Segundos). A definição máxima permitida para esse valor é de 7 dias. A definição mínima permitida é de 0 segundos, embora a definição desse valor como 0 segundos elimine efetivamente qualquer atraso na atividade de truncamento do log. Depois de definido, o valor desse parâmetro não pode ser alterado sem que a SCR seja desabilitada e reabilitada.

• -SeedingPostponed   Esse parâmetro pode ser usado para ignorar a propagação inicial do destino de SCR. Se esse parâmetro for usado, o administrador deverá propagar manualmente o destino de SCR usando o cmdlet Update-StorageGroupCopy. Esse parâmetro está disponível somente com o cmdlet Enable-StorageGroupCopy. Ele não está disponível com o cmdlet New-StorageGroup, pois não existe um banco de dados de origem nesse ponto.

  Importante

  Para alterar as configurações de atraso de truncamento ou repetição, você deve primeiro desabilitar a SCR e, em seguida habilitá-la usando os novos valores dessas configurações.

Além do atraso de repetição configurado pelo administrador que é especificado com o parâmetro ReplayLagTime, o Exchange impede também que um número fixo de arquivos de log sejam repetidos em um destino de SCR, independentemente do valor de ReplayLagTime, usando a seguinte fórmula:

Máximo de ("valor de ReplayLagTime" ou "X arquivos de log")

em que X=50. Essa é uma proteção contra a necessidade de repropagar um grupo de armazenamento em situações em que uma origem de SCR que esteja em um ambiente de replicação contínua, por exemplo, LCR (replicação contínua local) ou CCR (replicação contínua em cluster), experimenta um failover com perdas e é colocado online usando o cmdlet Restore-StorageGroupCopy. Com o atraso da atividade de repetição nos destinos de SCR, quando ocorre um failover com perdas para uma origem de SCR, as chances de precisar repropagar as cópias de SCR são minimizadas, pois a natureza da perda de dados na origem de SCR coloca as duas cópias próximas no tempo.

Quando você habilitar a SCR para um grupo de armazenamento, uma cópia do grupo de armazenamento (arquivos do sistema, arquivos de log e o arquivo do banco de dados) será automaticamente criada e mantida no computador de destino de SCR, usando os mesmos caminhos do grupo de armazenamento na origem de SCR.

Depois que a SCR tiver sido habilitada, recomendamos monitorar a integridade e o status de cada grupo de armazenamento usando o cmdlet Test-ReplicationHealth. Para obter etapas detalhadas sobre como habilitar uma SCR, consulte Como habilitar a Replicação Contínua Em Espera para um grupo de armazenamento existente e Como habilitar a replicação contínua em espera para um novo grupo de armazenamento.

SCR e truncamento de log

Como não é possível fazer backups de um banco de dados de destino de SCR, o truncamento de log de SCR não se baseia nos tempos de backup. Em vez disso, o truncamento de log é determinado pelo ponto de verificação na origem de SCR e no valor do TruncationLagTime.

Se a origem de SCR for um CMS (servidor de caixas de correio clusterizadas) em um ambiente de CCR, a lógica de truncamento de log incluirá a cópia e a inspeção bem-sucedidas dos arquivos de log por todos os destinos de SCR. Isso significa que se um destino de SCR não estiver disponível, o truncamento de log não ocorrerá na origem de SCR mesmo se forem feitos backups.

Em um ambiente de SCR, um destino de SCR que é desabilitado e então reabilitado poderá não precisar ser repropagado se todos os arquivos de log necessários estiverem disponíveis, com base no seguinte:

• Se o Iog circular estiver habilitado para o grupo de armazenamento, então a exclusão do log resultará no destino de SCR reabilitado, exigindo uma repropagação devido a intervalos na seqüência de logs.

• Se um backup for feito incluindo o truncamento do arquivo de log, então a exclusão do log resultará no destino de SCR reabilitado, exigindo uma repropagação devido a intervalos na seqüência de logs.

Se os arquivos de log não estiverem truncados por um dos meios descritos anteriormente, a desabilitação e a habilitação de SCR não deverá exigir uma repropagação. Nesse caso, os arquivos de log no destino de SCR precisarão ser excluídos, mas serão novamente replicados com base na origem de SCR.

Se você planeja reabilitar um destino de SCR que foi anteriormente desabilitado, como melhor prática, recomendamos não executar nenhuma operação de truncamento de log (por exemplo, habilitando o log circular ou executando backups de truncamento de log) até que o destino de SCR seja reabilidado e a alteração na configuração que exigiu a habilitação esteja replicada em todo o Active Directory.

Desabilitando a replicação contínua em espera

A SCR é desabilitada somente usando o cmdlet Disable-StorageGroupCopy e o parâmetro StandbyMachine. Ao desabilitar a SCR, é importante que você inclua o valor apropriado para o parâmetro StandbyMachine. Se o grupo de armazenamento de SCR também tiver a LCR habilitada e você não incluir o parâmetro StandbyMachine como parte desse comando, a LCR será desabilitada para o grupo de armazenamento.

Desabilitar a SCR é necessário para alterar o valor dos parâmetros ReplayLagTime ou TruncationLogDelay. Esses valores não podem ser modificados enquanto a SCR estiver habilitada. Portanto, para alterar as configurações de atraso de truncamento ou de repetição, você deve primeiro desabilitar a SCR e depois habilitá-la novamente usando os novos valores dessas configurações.

Para obter etapas detalhadas sobre como desabilitar a SCR para um grupo de armazenamento, consulte Como desabilitar a replicação contínua em espera para um grupo de armazenamento.

Monitorando a atividade de replicação

Embora a SCR não exija nenhum monitoramento especial, recomendamos o monitoramento regular de cada grupo de armazenamento para verificar se ele está replicando corretamente os arquivos de log. O Pacote de Gerenciamento do Exchange Server 2007 para o Microsoft Operations Manager 2005 inclui alertas para vários problemas críticos relacionados a ambientes de SCR:

• O serviço de Replicação do Microsoft Exchange não está sendo executado. Observe que o evento que gera esse alerta não é exibido repetidamente depois que o serviço é parado, portanto qualquer alerta associado a ele seria perdido, caso ele fosse apagado.

• A cópia de destino de SCR está em um estado de Falha.

• A cópia de destino de SCR está em um estado Adequado, mas está atrasada na cópia de log.

Você deve investigar e resolver todos os alertas anteriores gerados pelo Pacote de Gerenciamento do Exchange 2007 o mais rápido possível.

Cmdlet Test-ReplicationHealth

O Exchange 2007 SP1 apresenta um novo cmdlet chamado Test-ReplicationHealth. Esse cmdlet é projetado para monitoramento proativo de replicação contínua (LCR, CCR e SCR) e da pipeline de replicação contínua. O cmdlet Test-ReplicationHealth verifica todos os aspectos da replicação, os serviços de cluster, a replicação do grupo de armazenamento e o status de repetição para fornecer uma visão geral completa do sistema de replicação. Especificamente, o cmdlet Test-ReplicationHealth executa os testes descritos na tabela a seguir.

Testes executados pelo cmdlet Test-ReplicationHealth

Montar e desmontar bancos de dados

Ocasionalmente, pode ser necessário montar ou desmontar bancos de dados em um ambiente de SCR. Se o grupo de armazenamento de origem de SCR ou o banco de dados precisar de reconfiguração ou manutenção, será necessário bloquear os serviços que interagem com ambos enquanto a atividade estiver em andamento. Isso pode ser necessário para executar uma reconfiguração ou corrigir problemas com o servidor ou o banco de dados. Quando o banco de dados estiver desmontado, ele está inacessível.

Movendo o local do grupo de armazenamento e dos arquivos de banco de dados

Você pode alterar o local de um banco de dados em um grupo de armazenamento habilitado para SCR. Em um ambiente de SCR, há dois arquivos de bancos de dados, um para cada cópia. Ao movimentar os arquivos do grupo de armazenamento ou o arquivo de banco de dados, os locais das duas cópias deverá ser alterado em tandem.

Procedimentos semelhantes são usados para reconfigurar o local de um log de grupos de armazenamento e arquivos de sistema e o local dos arquivos de banco de dados em um ambiente de SCR. Para obter etapas detalhadas de como alterar o local de arquivos de log e arquivos de sistema de um grupo de armazenamento habilitado para SCR, consulte Como mover um grupo de armazenamento em um ambiente de Replicação Contínua em Espera. Para obter etapas detalhadas de como alterar o local dos arquivos de banco de dados em um ambiente de SCR, consulte Como mover um banco de dados em um ambiente de replicação contínua em espera.

Exibindo informações de status

Todo o monitoramento e o status é executado usando o Shell de Gerenciamento do Exchange. O Console de Gerenciamento do Exchange não exibe o status da cópia ou nenhuma outra informação sobre SCR. Depois de habilitada a SCR de um grupo de armazenamento, você pode usar o Shell de Gerenciamento do Exchange para exibir as definições de configuração específicas de SCR do grupo de armazenamento e do seu banco de dados.

Informações de status para replicação contínua em espera

O Exchange 2007 publica diversas informações de status para cópias de SCR. A tabela a seguir descreve as informações de status disponíveis para grupos de armazenamento habilitados para SCR. Para obter etapas detalhadas que explicam como obter informações de status, consulte Como exibir o status de replicação contínua em espera.

Informações de status disponíveis para grupos de armazenamento habilitados para SCR

Você pode avaliar rapidamente a condição de uma cópia de SCR verificando os valores de SummaryCopyStatus, CopyQueueLength, ReplayQueueLength e LastInspectedLogTime. Essas três propriedades mostram se a cópia de SCR está funcionando corretamente e relativamente atualizada nos logs de cópia e de repetição. Se as seguintes condições ocorrerem, você deverá determinar a causa e corrigir o problema:

• A cópia está permanecendo um tempo significativo em um estado insatisfatório.

• O comprimento da fila de cópias é maior que cinco.

• O comprimento da fila de repetição é maior que 20.

• A hora da última verificação de logs não mostra uma hora atual. Há duas razões prováveis que poderiam causar isso: o grupo de armazenamento não está tendo muitas alterações ou o servidor de replicação está parado.

O comprimento da fila de repetição e os valores de comprimento da fila de cópia estão disponíveis como contadores de desempenho. São os contadores CopyQueueLength e ReplayQueueLength no objeto de desempenho Replicação do MSExchange.

Existem alguns raros cenários em que o status da replicação pode ficar confuso. A seguir, está uma lista desses cenários:

• Um grupo de armazenamento inativo (ou seja, que não esteja alterando) pode informar que está adequado quando, na verdade, não está. Esse cenário poderia ocorrer devido a uma condição inadequada não poder ser detectada até que um log seja repetido.

• Durante a inicialização da replicação, o status da replicação está sendo avaliado e pode não ser preciso. Quando a inicialização estiver concluída, o status será atualizado.

• O valor do campo LastLogGenerated pode estar errado quando um banco de dados é desmontado. No entanto, todos os logs com conteúdo do usuário final serão replicados se a cópia do grupo de armazenamento estiver replicando.

• Quando há um ou mais logs ausentes no meio de um fluxo de logs, a cópia passiva continua tentando fazer a recuperação. Ao fazer isso, o status da replicação aIterna entre os estados de falha e adequado. As filas de repetição e de cópia continuam a crescer.

• Em algumas condições muito raras, um log pode ser verificado com êxito, mas a repetição ainda pode falhar. Nessa situação, o sistema alterna entre os estados com falha e adequado, à medida que tentar recuperar. As filas de repetição e de cópia continuam a crescer.

Verificando a integridade de um destino de SCR

Ao usar a SCR, é recomendável verificar a integridade de cada cópia de destino de SCR periodicamente, executando uma verificação de consistência física no banco de dados e nos arquivos de log de transações. Uma verificação de consistência física examina os arquivos de logs de transação e de bancos de dados em busca de danos. Você pode executar a verificação usando a versão da linha de comando da ferramenta Serviço de Cópias de Sombra de Volume do Microsoft (VSSAdmin.exe) e os Utilitários do Banco de Dados do Exchange Server (Eseutil.exe). Para obter etapas detalhadas sobre como usar o VSSAmin e o Eseutil para verificar danos físicos nos logs de transações e nos arquivos de banco de dados, consulte Como verificar uma cópia de replicação contínua em espera.

Gerenciando a replicação e a repetição

O gerenciamento da replicação e da repetição de arquivos de log em um ambiente de SCR envolve as seguintes atividades principais:

• Interromper a replicação da cópia de grupo de armazenamento

• Reiniciar a replicação da cópia de grupo de armazenamento

• Repropagar um grupo de armazenamento

Interromper e reiniciar alterações na cópia de grupo de armazenamento e no banco de dados

Por vários motivos, pode ser necessário interromper e reiniciar a atividade de replicação de log de transações. A replicação do log de transações ocorre quando o serviço de Replicação do Microsoft Exchange está sendo executado, um grupo de armazenamento foi habilitado para SCR e a origem e o destino de SCR estão operacionais. Se a origem ou o destino de SCR tornar-se indisponível, será necessário parar a replicação. Além disso, algumas tarefas administrativas, como propagação, exigem a suspensão da replicação de um grupo de armazenamento habilitado para SCR. Se você precisar interromper todos os acessos para os arquivos de dados de destino, suspenda a replicação.

Ocasionalmente, pode ser necessário controlar as atividades do destino de SCR. Isso pode ser necessário para executar uma reconfiguração ou corrigir problemas com o servidor ou o banco de dados. A interrupção da repetição de log também é necessária para executar uma verificação de consistência física do destino de SCR. Quando for necessário controlar as atualizações de cópia do banco de dados, a replicação deverá ser interrompida para o destino de SCR. Também pode ser necessário interromper a replicação quando os logs de destino de SCR estiverem sendo manipulados por algum motivo.

Para obter mais informações sobre como interromper alterações de replicação nas cópias de SCR, consulte Como suspender alterações feitas em um destino de replicação contínua em espera. Para obter mais informações sobre como reiniciar alterações de replicação nas cópias de SCR, consulte Como continuar a replicação em um destino de replicação contínua em espera. Para obter mais informações sobre como executar uma verificação de integridade nos logs de transações da cópia passiva e no arquivo de banco de dados, consulte Como verificar uma cópia de replicação contínua em espera.

Propagando e repropagando uma cópia do grupo de armazenamento

A propagação e a repropagação de uma cópia de grupo de armazenamento em um ambiente de SCR é executada usando o cmdlet Update-StorageGroupCopy com o parâmetro StandbyMachine, que é um novo parâmetro adicionado no Exchange 2007 SP1.

Para obter etapas detalhadas sobre como propagar ou repropagar um destino de SCR, consulte Como propagar um destino de replicação contínua em espera.

Recuperação após danos pela avaliação do status da replicação no momento do dano

Após uma falha ou dano de uma cópia do banco de dados, será necessário avaliar se você deseja continuar a operação imediatamente usando uma cópia de SCR. A SCR fornece os principais elementos de informações para auxiliar nessa decisão:

• Condições da cópia no momento da falha

• Filas de cópia e repetição no momento da falha

• Hora da última verificação de log no momento da falha

As informações podem ser obtidas usando o cmdlet Get-StorageGroupCopyStatus. Para obter etapas detalhadas sobre como obter essas informações, consulte Como exibir o status de replicação contínua em espera.

O comprimento da fila de cópia inclui as melhores informações disponíveis da origem de SCR no momento da falha. Com base nessas informações e em sua avaliação do tempo de recuperação do banco de dados danificado, você poderá decidir se o destino de SCR disponível será ativado:

• Se o comprimento da fila de repetição for significativo, a recuperação poderá levar tempo, mas não será um indicador de que uma perda de dados significativa ocorrerá.

• Se o comprimento da fila de cópias for significativa, vários logs poderão ser perdidos. Se o banco de dados estiver ativado, ele será restaurado para um período de aproximadamente o último log copiado (também fornecido pelo cmdlet Get-StorageGroupCopyStatus).

• Se a hora da última verificação de log for significativamente anterior à hora da falha, será bem provável que o serviço de Replicação do Microsoft Exchange esteja parado e que as outras informações da fila não sejam exatas.

  Dica

  Devido à natureza da SCR, bem como às latências e falhas de comunicação, é possível que o comprimento da fila de cópia não seja exato, porque o estado atual da cópia ativa é atualizado de forma assíncrona. Em geral, a imprecisão está limitada às atividades ocorridas aproximadamente um minuto antes e após a falha.

  Dica

  Um banco de dados com falha não pode ser usado para propagar um destino de SCR.