Gerenciando a 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: 2009-06-10
Além das tarefas de gerenciamento e administração diárias de uma organização do Exchange, há tarefas que são específicas do gerenciamento de um ambiente de CCR (Replicação Contínua em Cluster). Em geral, as tarefas administrativas para CCR são agrupadas em duas categorias:
Tarefas relacionadas a um servidor de caixas de correio clusterizadas
Tarefas relacionadas a grupos de armazenamento e bancos de dados em um servidor de caixas de correio clusterizadas
Tarefas relacionadas a um servidor de caixas de correio clusterizadas
As tarefas administrativas associadas a um servidor de caixas de correio clusterizadas em um ambiente de CCR incluem o seguinte:
Gerenciamento de volumes de discos
Exibindo definições de configuração
Monitorando a atividade de replicação
Exibir e coletar dados de desempenho
Gerenciar servidores de caixas de correio clusterizadas, incluindo colocá-los online, colocá-los offline e mover servidores de caixas de correio clusterizadas entre nós
Gerenciar a repetição e a replicação do arquivo de log
Gerenciar volumes de discos
Durante o gerenciamento de um ambiente de CCR, pode ser necessário gerenciar volumes de discos que estão associados ao seu cluster de CCR. Por exemplo, talvez seja necessário desconectar temporariamente o sistema para manutenção ou por outros motivos. Se isso for necessário no grupo de armazenamento ou banco de dados ativo, os bancos de dados do grupo de armazenamento deverão ser desmontados. Se essa operação for executada na cópia passiva do grupo de armazenamento ou banco de dados, todas as entradas/saídas (E/S) de replicação para o volume deverão ser paradas pela interrupção da replicação.
Para obter mais informações sobre como gerenciar volumes de discos, consulte Como se preparar para atividades de gerenciamento de volume de disco de uma cópia de CCR.
Exibindo definições de configuração
Depois que a CCR tiver sido habilitada para um servidor, você poderá usar o Console de Gerenciamento do Exchange e o Shell de Gerenciamento do Exchange para exibir as definições de configuração para grupos de armazenamento e bancos de dados no servidor.
As informações de configuração incluem os locais do grupo de armazenamento e arquivos de banco de dados. Além disso, você pode rever a configuração relacionada ao servidor de caixas de correio clusterizadas usando o Shell de Gerenciamento do Exchange.
Para obter etapas detalhadas sobre como exibir informações de configuração de controle de failover de CCR, consulte Como exibir a configuração de controle de failover.
Monitorando a atividade de replicação
A cópia passiva de um banco de dados só será útil se ela for mantida atualizada. Embora a CCR 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 Microsoft Exchange Server 2007 para Microsoft Operations Manager 2005 inclui alertas para vários problemas críticos relacionados a ambientes de CCR:
O serviço de Replicação do Microsoft Exchange não está sendo executado no nó passivo. 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 passiva está em um estado de Falha.
A cópia passiva está em um estado Adequado, mas está significativamente atrasada na cópia ou repetição de log.
Recomendamos também adicionar uma regra de evento personalizada ao Microsoft Operations Manager que é acionada quando um nó passivo não é detectado como estando em execução e sendo parte do cluster que contém um nó ativo. Quando essa condição ocorre, o serviço de Cluster registra um evento no log de eventos do Sistema. Recomendamos usar os seguintes critérios para a regra de evento, que será parte do evento registrado pelo serviço de Cluster:
Origem do Evento: ClusSvc
ID do Evento: 1135
Para obter mais informações sobre como criar regras de eventos no Microsoft Operations Manager, consulte Monitorando eventos de segurança com o MOM (página em inglês).
Você deve investigar e resolver o mais rápido possível qualquer um dos alertas anteriores gerados pelo Pacote de Gerenciamento do Exchange 2007 ou por uma regra de evento personalizada.
Uma alternativa ao uso do Pacote de Gerenciamento do Exchange 2007 para o Microsoft Operations Manager 2005 é acionar regularmente um script que execute o cmdlet Get-StorageGroupCopyStatus no Shell de Gerenciamento do Exchange. O cmdlet Get-StorageGroupCopyStatus fornece comprimentos de fila que incorporam o número de logs gerados pelo nó ativo. Por motivos de desempenho, os contadores de desempenho de comprimento de fila relatam apenas informações conhecidas para o serviço de Replicação do Microsoft Exchange. Em condições raras isso pode ser inconsistente com o estado do nó ativo. Para obter mais informações sobre o cmdlet Get-StorageGroupCopyStatus, consulte "Exibindo o status de cópias de grupo de armazenamento" posteriormente neste tópico.
Exibir e coletar dados de desempenho
Você pode determinar o andamento da replicação usando os contadores de desempenho. Para obter mais informações sobre o uso de contadores de desempenho para CCR, consulte Como exibir contadores de desempenho para Replicação Contínua em Cluster.
Gerenciar servidores de caixas de correio clusterizadas
As três principais tarefas administrativas para o gerenciamento de um servidor de caixas de correio clusterizadas são colocar o servidor online, colocar o servidor offline e movê-lo entre nós no cluster. Pode também envolver o desligamento ou a reinicialização de um dos nós no cluster como parte do gerenciamento de atualização ou outras operações de manutenção.
Iniciando e parando um servidor de caixas de correio clusterizadas
A ferramenta de Gerenciamento de Cluster de Failover (Windows Server 2008), o Administrador de Cluster (Windows Server 2003) e a ferramenta de linha de comando Cluster.exe (em ambos os sistemas operacionais) podem colocar recursos online e offline. Colocar um servidor de caixas de correio clusterizadas offline é chamado parar e colocar um servidor de caixas de correio clusterizadas online é chamado iniciar. A forma recomendada de iniciar um servidor de caixas de correio clusterizadas é usar o cmdlet Start-ClusteredMailboxServer. A forma recomendável para parar um servidor de caixas de correio em cluster é usar o cmdlet Stop-ClusteredMailboxServer. No Exchange 2007 Service Pack 1 (SP1), você também pode usar o Assistente para Gerenciar Servidor de Caixas de Correio em Cluster no Console de Gerenciamento do Exchange para iniciar ou parar um servidor de caixas de correio em cluster.
Para obter as etapas detalhadas sobre como colocar o servidor de caixas de correio clusterizadas online, consulte Como iniciar um servidor de caixas de correio em cluster. Para obter as etapas detalhadas sobre como colocar o servidor de caixas de correio clusterizadas offline, consulte Como parar um servidor de caixas de correio em cluster.
Movendo um servidor de caixas de correio clusterizadas entre nós
A movimentação manual de um servidor de caixas de correio clusterizadas entre nós é chamada handoff ou interrupção agendada. Para mover um servidor de caixas de correio clusterizadas, use o cmdlet Move-ClusteredMailboxServer. No Exchange 2007 SP1, você também pode usar o assistente para Gerenciar Servidores de Caixas de Correio Clusterizadas do Console de Gerenciamento do Exchange para realizar um handoff de um servidor de caixas de correio clusterizadas. Embora a ferramenta de Gerenciamento de Cluster de Failover (Windows Server 2008), o Administrador de Cluster (Windows Server 2003) e a ferramenta de linha de comando Cluster.exe (em ambos os sistemas operacionais) possam ser usados para mover um servidor de caixas de correio clusterizadas entre os nós, recomendamos que uma das ferramentas de gerenciamento do Exchange seja usada para mover um servidor de caixas de correio do nó ativo para o nó passivo, porque elas permitem que você especifique o motivo do handoff. Além disso:
A utilização das ferramentas de cluster ignora a verificação da integridade ou do estado da cópia passiva realizada pelas ferramentas de gerenciamento do Exchange. Portanto, seu uso pode resultar em uma interrupção estendida enquanto o nó executa as operações necessárias para tornar o banco de dados montável.
A utilização das ferramentas de cluster também pode manter um banco de dados offline indefinidamente, porque a integridade da ferramenta de replicação está comprometida e as ferramentas de cluster, diferentemente das ferramentas de gerenciamento do Exchange, não conseguem determinar o estado de replicação antes de mover o grupo de recursos.
Dica
Mover um servidor de caixas de correio clusterizadas entre nós resultará em uma breve interrupção do serviço. Além disso, todos os backups de qualquer grupo de armazenamento no servidor de caixas de correio clusterizadas serão cancelados.
Se uma replicação estiver com sua integridade comprometida ou se essas verificações determinarem que o nó passivo não está em um estado aceitável para um handoff, as Ferramentas de Gerenciamento do Exchange não realização o handoff. Se isso acontecer e você ainda precisar mover o CMS para o nó passivo, utilize as ferramentas de gerenciamento de cluster.
Ao mover um servidor de caixas de correio clusterizadas em um cluster de failover no qual haja latência de rede entre os nós, recomenda-se executar a operação de movimentação do nó passivo.
Para obter as etapas detalhadas sobre como mover o servidor de caixas de correio entre nós, consulte Como mover um servidor de caixas de correio clusterizadas em um ambiente CCR.
Executando a manutenção no cluster
A manutenção deve sempre ser executada no nó passivo do cluster. Atualizações, hotfixes e outros aplicativos geralmente não devem ser instalados no nó ativo (um nó que no momento possua um servidor de caixas de correio clusterizadas). Para obter etapas detalhadas sobre como instalar pacotes cumulativos de atualizações do Exchange em um ambiente de CCR, consulte Aplicando os pacotes cumulativos de atualização do Exchange 2007 em servidores de caixas de correio clusterizadas.
Se for necessário realizar uma manutenção no nó ativo, primeiro o servidor de caixas de correio clusterizadas deverá ser movido para um nó passivo, utilizando-se o cmdlet Move-ClusteredMailboxServer. Depois de mover o servidor de caixas de correio clusterizadas, o nó anteriormente ativo se torna o nó passivo e o nó anteriormente passivo se torna o nó ativo. A manutenção pode então ser executada, e pode ser executado um handoff que move o servidor de caixas de correio clusterizadas na direção oposta.
Os ambientes de CCR permitem que você agende uma interrupção de sistema de um nó específico sem uma interrupção do servidor de caixas de correio clusterizadas. Em um ambiente de CCR, apenas um nó pode ser colocado offline de cada vez. Colocar mais de um nó offline resultará em uma interrupção no serviço.
Uma interrupção agendada é iniciada através do cmdlet Move-ClusteredMailboxServer do Shell de Gerenciamento do Exchange. O tópico Como mover um servidor de caixas de correio clusterizadas em um ambiente CCR fornece um procedimento para executar uma interrupção agendada.
Antes de desligar ou reiniciar qualquer nó em um ambiente de CCR, recomendamos que você verifique qual nó está hospedando no momento o servidor de caixas de correio clusterizadas. Essas informações podem ser obtidas usando o cmdlet Get-ClusteredMailboxServerStatus.
Executando a manutenção no cluster
A manutenção deve sempre ser executada no nó passivo do cluster. Atualizações, hotfixes e outros aplicativos geralmente não devem ser instalados no nó ativo (o nó que atualmente possui o servidor de caixas de correio clusterizadas). Para obter etapas detalhadas sobre como instalar pacotes cumulativos de atualizações do Exchange em um ambiente de CCR, consulte Aplicando os pacotes cumulativos de atualização do Exchange 2007 em servidores de caixas de correio clusterizadas.
Se for necessário realizar manutenção no nó ativo, então, primeiro, o servidor de caixas de correio clusterizadas deverá ser movido para o nó passivo usando o cmdlet Move-ClusteredMailboxServer. Depois de mover o servidor de caixas de correio clusterizadas, o nó anteriormente ativo se torna o nó passivo e o nó anteriormente passivo se torna o nó ativo. A manutenção pode então ser executada, e pode ser executado um handoff que move o servidor de caixas de correio clusterizadas na direção oposta.
Desligando nós do cluster
Se todos os nós no cluster precisarem ser desligados, inclusive o nó ativo, primeiro você deverá parar o servidor de caixas de correio clusterizadas. O processo de desligamento do Windows não é sensível ao Exchange. Por isso, é recomendável que você só encerre nós passivos. Se for necessário encerrar ou reiniciar um nó ativo, recomendamos que você mova o servidor de caixas de correio clusterizadas para outro nó disponível. Para obter etapas detalhadas que explicam como mover um servidor de caixas de correio clusterizadas para outro nó, consulte Como mover um servidor de caixas de correio clusterizadas em um ambiente CCR.
Se o servidor não puder ser movido para o nó passivo (talvez porque o nó passivo já tenha sido desligado), então ele deverá ser interrompido antes de o nó ativo ser desligado.
Caso seja necessário reiniciar ou desligar o nó arivo e não for possível mover o servidor de caixas de correio clusterizadas para o nó passivo, recomenda-se o uso da Diretiva de Grupo para garantir que o servidor de caixas de correio clusterizadas seja parado antes de reiniciar ou desligar um nó ativo. O Windows Server fornece um conjunto de scripts de encerramento de computador baseados em diretivas que você pode gerenciar usando o snap-in Diretiva de Grupo. Esse snap-in inclui extensões que permitem especificar um script que será executado quando você desligar o computador.
Por exemplo, é possível criar um script de encerramento que execute o cmdlet Move-ClusteredMailboxServer ou o cmdlet Stop-ClusteredMailboxServer, com os parâmetros adequados. Também é recomendável a utilização de um script de encerramento porque ele minimiza a chance de um sistema ser encerrado ou reiniciado por um administrador que não tenha ciência da necessidade de mover ou interromper o servidor de caixas de correio clusterizadas antes de encerrar o nó ativo.
Importante
Esses scripts são executados na conta Sistema Local. Antes que esses scripts possam ser executados com êxito, é preciso conceder a permissão de conta do Sistema Local (a conta do computador do nó local) para gerenciar o servidor de caixas de correio em cluster.
Gerenciar a repetição e a replicação do arquivo de log
Gerenciar a replicação em um ambiente de CCR envolve as seguintes atividades principais:
Controle de failovers quando a replicação for interrompida
Interromper e reiniciar a replicação para cópias de grupo de armazenamento
Configurando uma ou mais redes redundantes para replicação
Controle de failovers quando a replicação for interrompida
A interrupção da replicação pára toda a propagação das alterações no grupo de armazenamento ativo da cópia no período da suspensão. Se ocorrer um failover nesse momento, a cópia do grupo de armazenamento não terá as alterações mais recentes. Dependendo do volume de alterações ocorridas no nó ativo, a falta das alterações mais recentes provavelmente impedirá que o sistema monte a cópia no computador passivo. Além disso, você pode usar a versão disponível do grupo de armazenamento do nó passivo ou aguardar até que o servidor original se recupere. É importante minimizar o tempo que a replicação fica interrompida para minimizar essa exposição.
Se você não montar a versão dos dados no nó passivo quando o computador original se tornar disponível, o sistema de replicação copiará os logs ausentes e montará automaticamente a cópia do banco de dados no novo nó ativo.
Um failover que ocorre após a continuação da replicação poderia ocorrer no momento em que a cópia passiva ainda tivesse logs ausentes ou depois que tivesse todos os logs, mas antes que eles tenham sido repetidos. Se os logs forem copiados, mas não repetidos, um failover disparará a repetição dos logs pendentes no banco de dados. Além disso, esse grupo de armazenamento detectará um tempo de recuperação estendido como parte do failover, embora outros grupos de armazenamento não sejam afetados. Entretanto, se logs suficientes estiverem disponíveis para atender aos critérios de montagem automática configurados, o sistema acabará montando o banco de dados com os dados mais recentes disponíveis. Há um risco neste processo: Um dos logs a serem repetidos pode estar danificado e não permitir a repetição bem-sucedida. Nesse caso, a repetição resultará em um erro e toda atividade de repetição adicional será bloqueada. Quando isso acontece, a cópia do grupo de armazenamento fica em estado de erro, indicado como Falha. Nesse estado de erro, talvez você possa realizar uma recuperação, usando a versão do banco de dados até esse ponto. Caso contrário, você precisará aguardar até que o servidor original fique disponível e o log não danificado seja copiado novamente.
Interromper e reiniciar a replicação para cópias de grupo de armazenamento
Ocasionalmente, pode ser necessário controlar as atividades da cópia passiva. Talvez haja a necessidade de interromper e reiniciar a atividade de replicação. A replicação é controlada no nível do grupo de armazenamento. Como um grupo de armazenamento pode conter apenas um banco de dados, a replicação é localizada para um banco de dados.
A replicação ocorre quando os dois nós do cluster estão em operação, o serviço de Replicação do Microsoft Exchange está sendo executado no nó de destino e a cópia do grupo de armazenamento está com a cópia habilitada. Se o local de origem ou de destino de CCR tornar-se indisponível, será necessário parar a replicação. Além disso, algumas tarefas de administração de CCR, como propagação, execução de verificações de integridade ou reconfiguração de armazenamento, exigem que uma cópia do grupo de armazenamento tenha sua replicação interrompida. Se você precisar parar todo o acesso aos arquivos de log e o diretório de log de destino, será preciso interromper a replicação.
O Exchange 2007 exige que todas as atividades de replicação sejam interrompidas quando o local do grupo de armazenamento ou banco de dados estiver sendo alterado.
Para obter mais informações sobre a interrupção de atualizações de cópias do banco de dados, consulte Como interromper a replicação em uma cópia de replicação contínua em cluster. Para obter mais informações sobre o reinício de atualizações de cópias do banco de dados, consulte Como reiniciar a replicação em uma cópia de replicação contínua em cluster.
Para obter mais informações sobre como executar uma verificação de integridade nos logs de transações de CCR e nos arquivos de banco de dados, consulte Como verificar uma cópia de Replicação Contínua em Cluster usando Eseutil.
Configurando uma ou mais redes redundantes para replicação
O Exchange 2007 SP1 permite que você configure redes em cluster redundantes que podem ser usadas para propagação e envio de logs em um ambiente de CCR. A rede redundante deve ser configurada como uma rede de cluster mista. Uma rede de cluster mista é qualquer rede de cluster configurada tanto para o tráfego de acesso de cluster (pulsação) quanto para o de cliente.
Quando uma rede em cluster mista tiver sido configurada com nomes de host de replicação contínua e endereços IP, o Exchange 2007 usará essa rede para o envio de logs. Além disso, a rede configurada fica disponível para propagação iniciada por administrador com o cmdlet Update-StorageGroupCopy. Várias redes mistas podem ser especificadas e, se mais de uma rede estiver disponível, o Exchange 2007 selecionará uma delas aleatoriamente. Se a rede em uso no momento ficar indisponível, o Exchange 2007 selecionará automaticamente outra rede disponível.
O suporte a envio de logs em uma rede mista é configurado com o cmdlet Enable-ContinuousReplicationHostName. Da mesma forma, a desativação desse recurso é feita com o cmdlet Disable-ContinuousReplicationHostName. Depois que um servidor de caixas de correio clusterizadas existe em um ambiente de CCR, um administrador pode executar Enable-ContinuousReplicationHostName nos dois nós do cluster e especificar dois endereços IP e nomes de host. Depois de fazer isso, o sistema seleciona aleatoriamente uma rede mista para cópia do log após a configuração bem-sucedida e confirmação de que a rede mista está operacional.
A propagação e a repropagação em um ambiente de CCR são executadas com o cmdlet Update-StorageGroupCopy. No Exchange 2007 SP1, esse cmdlet foi estendido para incluir um novo parâmetro chamado DataHostNames. Esse parâmetro é usado para especificar qual rede deve ser utilizada para propagação ou repropagação. O valor é uma lista de dois nomes: um FQDN (nome de domínio totalmente qualificado) ou um nome de host. Um desses nomes deve identificar o nó passivo.
Para obter mais informações sobre como configurar redes redundantes para propagação e envio de logs, consulte estes tópicos:
CCR no Windows Server 2008:
CCR no Windows Server 2003:
Tarefas relacionadas a grupos de armazenamento e bancos de dados em um servidor de caixas de correio clusterizadas
As tarefas administrativas associadas aos grupos de armazenamento e bancos de dados em um servidor de caixas de correio clusterizadas em um ambiente de CCR incluem o seguinte:
Mover o local de um grupo de armazenamento ou banco de dados
Exibir o status das cópias do grupo de armazenamento
Montagem e desmontagem de bancos de dados
Verificar a integridade de uma cópia de grupo de armazenamento
Recuperar danos em um grupo de armazenamento de produção ou uma cópia de grupo de armazenamento
Restaurar a CCR depois de uma falha ou algum tipo de dano nos dados
Exceto para o grupo de armazenamento de recuperação, que é um tipo especial de grupo de armazenamento, todos os grupos de armazenamento e bancos de dados de um ambiente de CCR são automaticamente habilitados para replicação contínua. Embora a replicação e a repetição possam ser suspensas, não é possível desabilitar a replicação de um ou mais grupos de armazenamento em um ambiente de CCR, pois isso permitiria que uma interrupção impedisse o acesso a bancos de dados específicos.
Ao criar um novo grupo de armazenamento em um ambiente de CCR, a propagação da cópia do banco de dados no nó passivo deve ocorrer automaticamente. Se, por alguma razão, a propagação não ocorrer automaticamente, você deverá propagar manualmente a cópia do banco de dados Para obter etapas detalhadas sobre como propagar a cópia de um banco de dados, consulte Como propagar uma cópia de Replicação Contínua em Cluster.
Mover o local dos arquivos do grupo de armazenamento ou de um banco de dados
Pode ser necessário mover o local dos arquivos de grupo de armazenamento ou o local de um banco de dados em um ambiente de CCR. O tempo necessário para mover os locais do arquivo depende do tamanho do banco de dados e do número de arquivos de log de transações que estão sendo movidos, além das características de desempenho do armazenamento. Durante qualquer movimentação, o banco de dados será desmontado.
Em um ambiente de CCR, a realocação de um grupo de armazenamento exige que as duas cópias sejam realocadas de maneira consistente, pois o local dos arquivos nos nós ativo e passivo deve ser o mesmo. Para que um grupo de armazenamento ou seu banco de dados possa ser movido, você deve desmontar o banco de dados e suspender a replicação. Na cópia ativa, isso pode ser feito com o cmdlet Dismount-Database no Shell de Gerenciamento do Exchange. Para o serviço de Replicação do Microsoft Exchange, use o cmdlet Suspend-StorageGroupCopy e o cmdlet Resume-StorageGroupCopy.
Dica
O serviço de Replicação do Microsoft Exchange monitora constantemente os arquivos no local da cópia e os logs no nó ativo. Assim, se você manipular logs ativos de alguma maneira, deverá suspender a atividade desse grupo de armazenamento, usando o cmdlet Suspend-StorageGroupCopy, que interrompe a replicação.
Para obter etapas detalhadas sobre como mover o local dos arquivos do grupo de armazenamento em um ambiente de CCR, consulte Como mover um grupo de armazenamento em um ambiente CCR. Para obter etapas detalhadas sobre como mover o local de um banco de dados em um ambiente de CCR, consulte Como mover um banco de dados em um ambiente CCR.
Exibir o status das cópias do grupo de armazenamento
Na RTM (Versão de Produção) do Microsoft Exchange 2007, você só pode visualizar as informações de status de CCR usando o Shell de Gerenciamento do Exchange. No Microsoft Exchange 2007 SP1, algumas das informações de status listadas na tabela a seguir podem ser visualizadas no Console de Gerenciamento do Exchange.
O Exchange 2007 publica diversas informações de status para cópias de grupo de armazenamento. A tabela a seguir descreve as informações de status disponíveis. Na tabela a seguir, os atributos são listados na ordem em que aparecem na saída completa do cmdlet Get-StorageGroupCopyStatus. Para obter etapas detalhadas sobre como exibir as informações de status, consulte Como exibir o status de uma cópia de replicação contínua de cluster usando o Shell de Gerenciamento do Exchange.
Informações de status disponíveis para grupos de armazenamento habilitados para CCR
| Atributo | Descrição |
|---|---|
Identity |
Identidade do grupo de armazenamento consultado. Este atributo apresenta o <ServerName>\<StorageGroupName>. |
StorageGroupName |
Nome do grupo de armazenamento consultado. Esse atributo apresenta o nome do grupo de armazenamento. |
SummaryCopyStatus |
Status geral atual da cópia passiva. Os valores possíveis são:
O Exchange 2007 SP1 adiciona os seguintes valores de status adicionais:
|
Failed |
A verificação do banco de dados ou dos logs, que identificou uma inconsistência que impede a replicação. Como alternativa, há um problema de configuração ou acesso com a cópia ativa ou passiva. Os valores possíveis são True e False. |
FailedMessage |
Mensagem de texto que identifica a condição que causou a falha de replicação. Essa pode não ser a única área com problema de replicação. |
Seeding |
Indica que a propagação está em andamento. Os valores possíveis são True e False. |
Suspend |
Indica que a replicação foi interrompida para a cópia passiva. Esse estado impede que o banco de dados avance e que os logs sejam copiados. Os valores possíveis são True e False. |
SuspendComment |
Área de comentários opcional na qual um administrador pode fornecer um motivo ou uma nota explicando porque a atividade de replicação foi interrompida. |
CopySuspend |
Indica que a cópia de logs foi interrompida para a cópia passiva. Isso evita a alteração do diretório de cópia de logs. Os valores possíveis são True e False. |
CopySuspendComment |
Comentário opcional do administrador com um motivo ou uma anotação que explica porque a atividade de cópia de logs foi interrompida. |
CopyQueueLength |
Número de arquivos de log de transações que aguardam para serem copiados na pasta de arquivos de log da cópia passiva. Enquanto não for verificado se há danos na cópia, ela não será considerada concluída. |
ReplayQueueLength |
Número de arquivos de log de transações que aguardam para serem repetidos na cópia passiva. |
LatestAvailableLogTime |
Carimbo de hora no grupo de armazenamento de origem do novo arquivo de log de transações recém-detectado. |
LastCopyNotificationedLogTime |
Hora associada ao último novo log gerado pelo grupo de armazenamento ativo e conhecido pela cópia. |
LastCopiedLogTime |
Carimbo de hora no grupo de armazenamento de origem da última cópia bem-sucedida de um arquivo de log de transações. |
LastInspectedLogTime |
Carimbo de hora no grupo de armazenamento de destino da última verificação bem-sucedida de um arquivo de log de transações. |
LastReplayedLogTime |
Carimbo de hora no grupo de armazenamento de destino da última repetição bem-sucedida de um arquivo de log de transações. |
LastLogGenerated |
Último número de log que se soube ter sido gerado na cópia ativa do grupo de armazenamento. |
LastLogCopied |
Último número de geração de log que foi copiado com êxito na pasta de logs da cópia passiva. |
LastLogNotified |
Último número de log que foi gerado pelo grupo de armazenamento ativo e conhecido pela cópia. |
LastLogInspected |
Último número de geração de log cuja consistência e dados foram verificados. |
LastLogReplayed |
Último número de geração de log que foi repetido com êxito na cópia passiva do banco de dados. |
LatestFullBackupTime |
Hora do último backup completo. |
LastestIncrementalBackupTime |
Hora do último backup incremental. |
SnapshotBackup |
Indica se o último backup completo obtido era um backup de streaming herdado ou um instantâneo de backup do VSS (Serviço de Cópias de Sombra de Volume). |
SnapshotLatestFullBackup |
Hora do último backup completo de instantâneo. |
SnapshotLatestIncrementalBackup |
Hora do último backup incremental de instantâneo. |
SnapshotLatestDifferentialBackup |
Hora do último backup diferencial de instantâneo. |
SnapshotLatestCopyBackup |
Hora do último backup de cópia de instantâneo. |
OutstandingDumpsterRequests |
Solicitações pendentes e o intervalo de tempo (baixo-alto) das solicitações pendentes. |
DumpsterStatistics |
Estatísticas de transporte de reciclador de todos os servidores de Transporte de Hub acessíveis. Esse valor é exibido somente quando o parâmetro DumpsterStatistics for usado com o comando Get-StorageGroupCopyStatus. |
DumpsterStatisticsNotAvailable |
Lista de servidores de Transporte de Hub inacessíveis. |
Você pode avaliar rapidamente a integridade de uma cópia de um grupo de armazenamento verificando os valores de SummaryCopyStatus, CopyQueueLength, ReplayQueueLength e LastInspectedLogTime. Esses atributos mostram se a cópia do grupo de armazenamento está funcionando corretamente e se ela está 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 não está em um estado íntegro.
O comprimento da fila de cópias é maior que cinco.
O comprimento da fila de repetição é maior que vinte.
A hora da última inspeção de log não é recente. A inatividade no grupo de armazenamento poderia provocar essa situação, mas também poderia indicar que o serviço de Replicação do Microsoft Exchange foi interrompido.
Você pode calcular os dois números de fila em unidades de horário da seguinte forma:
Fila de cópia no horário = LatestAvailableLogTime – LastCopiedLogTime
Fila de repetição no horário = LatestCopiedLogTime – LastInspectedLogTime
O comprimento de fila de repetição e os valores de comprimento de fila de cópia estão disponíveis como contadores de desempenho. São os contadores de desempenho CopyQueueLength e ReplayQueueLength no objeto de desempenho do serviço de Replicação do Microsoft Exchange.
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 continuarão a crescer.
Em algumas condições muito raras, um log pode ser verificado com êxito, mas a repetição pode falhar mesmo assim. Nessa situação, o sistema alternará entre os estados com falha e adequado, à medida que tentar recuperar. As filas de repetição e de cópia continuarão a crescer.
Dica
No Exchange 2007 SP1, também é possível usar um novo cmdlet chamado Test-ReplicationHealth para verificar a integridade e o status dos grupos de armazenamento habilitados para replicação contínua. Para obter mais informações sobre o cmdlet Test-ReplicationHealth, consulte Test-ReplicationHealth.
Montar e desmontar bancos de dados
Ocasionalmente, pode ser necessário montar ou desmontar bancos de dados em um ambiente de CCR. 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 é desmontado, ele fica congelado para alterações adicionais. Nem o banco de dados nem os arquivos de log serão alterados enquanto o banco de dados estiver desmontado.
Para obter mais informações sobre como montar bancos de dados em um ambiente de CCR, consulte Como montar um banco de dados em um ambiente de Replicação Contínua em Cluster. Para obter mais informações sobre como desmontar bancos de dados em um ambiente de CCR, consulte Como desmontar um banco de dados em um ambiente de Replicação Contínua em Cluster.
Verificar a integridade de uma cópia de grupo de armazenamento
Ao usar a CCR, recomendamos que você verifique a integridade da cópia passiva 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 o Utilitário de Banco de Dados (Eseutil.exe) do Exchange Server. Para obter etapas detalhadas sobre como usar 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 Cluster usando Eseutil.
Dica
Antes de executar uma verificação de consistência física em um banco de dados, suspenda temporariamente todas as atividades de replicação em relação à cópia do grupo de armazenamento. Você pode suspender as atividades de repetição do log de transações, usando o cmdlet Suspend-StorageGroupCopy no Shell de Gerenciamento do Exchange. Quando a verificação de consistência tiver sido concluída, você poderá retomar a atividade de repetição do log de transações, usando o cmdlet Resume-StorageGroupCopy.
Recuperação de danos em um ambiente de CCR
A CCR permite recuperar danos ou falhas em um grupo de armazenamento de produção inicializando uma interrupção agendada. Se os arquivos de log não estiverem danificados, nenhuma perda de dados deverá ocorrer devido à recuperação. Entretanto, se os arquivos de log não estiverem disponíveis, a recuperação poderá retornar ao grupo de armazenamento somente em um ponto no tempo compatível com o último conjunto de alterações não danificado recebido pela cópia. Uma restrição adicional é que não pode haver nenhum dado de alteração ausente ou danificado nesse ponto no tempo.
Para obter as etapas detalhadas que explicam como recuperar de corrupção ou falhas em um ambiente de CCR, consulte os seguintes tópicos:
Como restaurar o acesso ao banco de dados de produção após uma falha em um único banco de dados
Como restaurar o acesso ao banco de dados de produção após uma falha em um servidor
Restauração de CCR após a ocorrência de uma falha ou dano
A CCR oferece a funcionalidade de recuperação automática depois de uma falha. Entretanto, ainda existem casos nos quais a recuperação manual é necessária. São eles:
O arquivo do banco de dados está danificado na cópia passiva Para obter etapas detalhadas que explicam como restaurar a CCR após a ocorrência de danos no banco de dados, consulte Como restaurar após danificação do banco de dados.
O banco de dados ou um volume de log falhou na cópia passiva Para obter etapas detalhadas que explicam como restaurar a CCR após a ocorrência de uma falha em um volume, consulte Como restaurar após uma falha de volume.
O banco de dados falhou ou divergiu A CCR detecta e informa quando ocorre divergência no banco de dados como resultado de uma falha. Em geral, isso ocorre quando uma cópia do banco de dados é disponibilizada e a cópia com falha tem mais alterações do que o critério de montagem automática aceitável permite. Para obter etapas detalhadas que explicam como restaurar a CCR após a ocorrência de uma falha ou divergência de banco de dados, consulte Como restaurar a funcionalidade da CCR após uma falha ou divergência.