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-10-21

Replicação contínua em espera (SCR) é um novo recurso introduzido no Microsoft Exchange Server 2007 Service Pack 1 (SP1). Como o próprio nome diz, a SCR foi projetada para cenários que usem ou habilitem o uso de servidores de recuperação em espera. A SCR estende os recursos existentes de replicação contínua encontrados na versão RTM (Versão de Produção) do Exchange Server 2007 e habilita novos cenários de disponibilidade de dados para servidores de Caixa de Correio que executam o SP1. A SCR usa a mesma tecnologia de remessa e repetição de log usada pela LCR (replicação contínua local) e pela CCR (replicação contínua em cluster) para fornecer opções e configurações de implantação adicionadas.

A SCR habilita uma separação de alta disponibilidade (incluindo disponibilidade de serviços e dados) e resiliência de site. Por exemplo, a SCR pode ser combinada com a CCR para replicar grupos de armazenamento localmente em um data center principal (usando CCR para alta disponibilidade) e remotamente em um data center secundário ou de backup (usando SCR para resiliência de site). O data center secundário pode conter um nó passivo em um cluster de failover que hospeda destinos SCR. Esse tipo de cluster é chamado de cluster em espera, por não conter servidores de caixas de correio clusterizadas, mas pode ser rapidamente configurado com um servidor de caixas de correio clusterizadas de substituição em um cenário de recuperação. Se o data center principal falhar ou for perdido, os destinos SCR hospedados nesse cluster em espera poderão ser rapidamente ativados.

Origens e destinos

Assim como a LCR e a CCR, a SCR usa o conceito de cópias ativas e passivas de um grupo de armazenamento, mas refere-se a elas como origens e destinos. Além disso, assim como a CCR, a SCR exige que os caminhos de arquivo de log e de banco de dados sejam os mesmos na origem e no destino.

O ponto inicial da SCR é denominado origem, que é qualquer um dos seguintes grupos de armazenamento:

• Servidor autônomo de caixa de correio

• Servidor de caixas de correio clusterizadas em um cluster de cópia única (SCC)

• Servidor de caixas de correio clusterizadas em um ambiente CCR

  Dica

  Grupos de armazenamento de recuperação não podem ser habilitados para SCR.

Assim como LCR e CCR, grupos de armazenamento habilitados para SCR não podem conter mais de um banco de dados. Você não pode habilitar a SCR para um grupo de armazenamento que contenha mais de um banco de dados, e não pode adicionar um segundo ou subseqüente banco de dados a um grupo de armazenamento habilitado para SCR.

Se o computador de origem da SCR não for clusterizado, ele também poderá hospedar outras funções de servidor, como Transporte de Hub, Acesso para Cliente e Unificação de Mensagens.

O ponto de extremidade para SCR é denominado destino, e o destino pode ser o seguinte:

• Servidor de caixa de correio autônomo que não seja habilitado para LCR em nenhum grupo de armazenamento

• Um cluster autônomo, que seja um cluster de failover onde a função Caixas de Correio em Cluster Passivas esteja instalada, mas nenhum servidor de caixa de correio em cluster (por exemplo, nenhuma função Caixas de Correio em Cluster Ativas) tenha sido instalado no cluster

Um computador de destino de SCR deve ter a função de servidor Caixa de Correio instalada, mesmo que não hospede caixas de correio de produção. A função de servidor Caixa de Correio é necessária porque inclui o serviço de Replicação do Microsoft Exchange e outros componentes necessários para a funcionalidade SCR. Se o computador de destino da SCR não for clusterizado, ele também poderá hospedar outras funções de servidor, como Transporte de Hub, Acesso para Cliente e Unificação de Mensagens.

A SCR está disponível na Standard Edition do Exchange 2007 SP1. Se um servidor de Caixa de Correio em um ambiente SCC ou CCR for usado como origem SCR, a Enterprise Edition do Exchange 2007 SP1 será necessária, por ser obrigatória ao usar clusters do Exchange 2007. Se um cluster em espera estiver sendo usado como destino SCR, a Enterprise Edition do Exchange 2007 SP1 também será obrigatória.

Comparando SCR com LCR e CCR

SCR é semelhante a LCR e CCR, mas tem suas próprias características exclusivas:

• A SCR aceita vários destinos de replicação por grupo de armazenamento. LCR e CCR aceitam somente um destino de replicação por grupo de armazenamento (a cópia passiva).

• A SCR inclui um atraso integrado para atividade de repetição e permite que o administrador especifique um atraso adicional. Isso é útil em vários cenários. Por exemplo, no caso de dano lógico de um banco de dados ativo, o atraso integrado e adicional configurado pelo administrador pode ser usado para evitar dano lógico de um banco de dados de destino SCR. LCR e CCR não têm atrasos desse tipo.

• A SCR é completamente gerenciada usando o Shell de Gerenciamento do Exchange. O Console de Gerenciamento do Exchange pode ser usado para gerenciar muitos aspectos de LCR e CCR, mas não pode ser usado para habilitar ou gerenciar nenhum aspecto da SCR.

Ativação de Cópia de SCR

O processo para utilizar um banco de dados de destino de SCR é chamado de ativação e a forma como o banco de dados é ativado depende da natureza da falha. Se um ou mais bancos de dados da origem de SCR forem afetados, você poderá usar o recurso de portabilidade de banco de dados no Exchange 2007 como parte do processo de ativação dos bancos de dados de destino de SCR. Se todos os bancos de dados em um servidor de origem de SCR forem afetados, ou se um servidor inteiro ou um servidor de caixas de correio clusterizadas estiver sendo recuperado, você poderá usar os recursos de recuperação de servidor da Instalação (Setup /m:RecoverServer para um servidor autônomo e Setup /RecoverCMS para um servidor de caixas de correio clusterizadas) como parte do processo de ativação.

Para obter mais informações sobre ativação e recuperação em um ambiente SCR, consulte Ativando destinos de replicação contínua em espera.

Cenários de implantação de SCR

A SCR permite que você use replicação contínua para replicar os dados de um servidor de Caixa de Correio autônomo ou em cluster em um ambiente SCC ou CCR. As figuras a seguir ilustram algumas das opções de configuração SCR possíveis.

Usando SCR para replicar um grupo de armazenamento de um servidor de Caixa de Correio autônomo para outro servidor de Caixa de Correio

A figura anterior ilustra o uso de SCR para replicar vários grupos de armazenamento de um servidor de Caixa de Correio em outro. Nesse exemplo, os servidores de Caixa de Correio não estão em cluster e ambos funcionam como origens e destinos SCR. Nesse exemplo, cada servidor se encontra em um data center diferente, bem como em um site do Active Directory diferente. Dependendo da natureza da falha, a recuperação de um grupo de armazenamento em qualquer dos servidores pode ser executada por meio da portabilidade de banco de dados ou da opção de instalação /RecoverServer.

Usando CCR para replicar grupos de armazenamento localmente e SCR para replicar um grupo de armazenamento em um local remoto

A figura anterior ilustra um modelo de CCR para SCR um para um. Nesse exemplo, EXCLUS1 é um servidor de caixas de correio clusterizadas em um ambiente CCR que está localizado no site REDMOND do Active Directory. EXCLUS1DR é um cluster em espera localizado no site QUINCY do Active Directory. Nesse caso, a recuperação de todos os grupos de armazenamento no destino SCR pode ser obtida usando a opção de instalação /RecoverCMS. Se nem todos os grupos de armazenamento precisarem se recuperados, um ou mais grupos de armazenamento poderão ser recuperados usando a portabilidade de banco de dados.

Usando CCR para replicar grupos de armazenamento localmente e SCR para replicar grupos de armazenamento em vários locais remotos

A figura anterior ilustra um modelo de CCR para SCR um para vários. Os computadores do lado esquerdo representam os dois nós físicos CCR no mesmo data center. Os computadores do lado direito representam dois destinos SCR em um segundo data center. Nesse exemplo, um único grupo de armazenamento está sendo replicado em vários destinos SCR em dois computadores. A recuperação do grupo de armazenamento no destino SCR pode ser obtida usando um de dois métodos:

• /RecoverCMS só pode ser usado ao recuperar grupos de armazenamento de uma única origem CCR.

• A portabilidade de banco de dados pode ser usada ao recuperar grupos de armazenamento de várias origens CCR.

Usando vários destinos de SCR remotos para um SCC

A figura anterior ilustra um modelo de SCC para SCR um para vários. Os computadores do lado esquerdo representam os dois nós físicos SCC em um único data center. Os computadores do lado direito representam dois destinos SCR em um data center separado. Nesse exemplo, um único grupo de armazenamento está sendo replicado em dois destinos autônomos em um segundo data center. A recuperação desse grupo de armazenamento no destino SCR pode ser obtida usando a opção de instalação /RecoverCMS.

Atualizações de cmdlet para SCR

A SCR é gerenciada usando o Shell de Gerenciamento do Exchange. O SP1 inclui um novo parâmetro denominado StandbyMachine para vários cmdlets do Shell de Gerenciamento do Exchange que são usados para gerenciar e configurar a replicação contínua. Especificamente, os cmdlets a seguir agora incluem suporte para SCR e o parâmetro StandbyMachine:

• Suspend-StorageGroupCopy

• Resume-StorageGroupCopy

• Update-StorageGroupCopy

• Restore-StorageGroupCopy

• Get-StorageGroup

• Get-StorageGroupCopyStatus

Além das atualizações anteriores de cmdlet, os cmdlets New-StorageGroup e Enable-StorageGroupCopy foram atualizados para aceitar SCR. No Exchange 2007 SP1, você pode usar New-StorageGroup para criar um novo grupo de armazenamento habilitado para SCR, e Enable-StorageGroupCopy, para habilitar SCR para um grupo de armazenamento existente. Esses cmdlets incluem os seguintes parâmetros atualizados:

• -StandbyMachine   Esse parâmetro especifica o nome do computador de destino SCR.

• -ReplayLagTime   Esse parâmetro é usado para especificar o tempo que o serviço de replicação do Microsoft Exchange deve esperar antes de repetir os arquivos de log que foram copiados no computador de destino SCR. O formato desse parâmetro é (Dias.Horas.Minutos:Segundos). A configuração padrão desse valor é 24 horas (1.0:0:0). A configuração máxima permitida para esse valor são 7 dias. A configuração mínima permitida é 0 segundo, embora a definição desse valor como 0 segundo elimine efetivamente qualquer atraso na atividade de repetição de log acima do atraso padrão de 50 arquivos de log. Uma vez definido o valor desse parâmetro, não será possível alterá-lo sem desabilitar e reabilitar a SCR.

• -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 é iniciado depois do log ser repetido com êxito na cópia do banco de dados. O formato desse parâmetro é (Dias.Horas.Minutos:Segundos). A configuração máxima permitida para esse valor são 7 dias. A configuração mínima permitida é 0 segundos, mas definir esse valor como 0 elimina efetivamente qualquer atraso nas atividades de truncagem de log. Uma vez definido o valor desse parâmetro, não será possível alterá-lo sem desabilitar e reabilitar a SCR.

Além do atraso de repetição configurado pelo administrador, que é especificado usando o parâmetro ReplayLagTime, o Exchange também evitará que um número fixo de arquivos de log seja repetido em um destino SCR, independentemente do valor de ReplayLagTime, usando a fórmula Máximo de ("valor de ReplayLagTime" ou "X arquivos de log") onde X=50. Essa é uma garantia adicional contra a necessidade de propagar novamente um grupo de armazenamento nas situações em que uma origem SCR que está em um ambiente de replicação contínua (por exemplo, LCR ou CCR) experimenta um failover com perdas e se torna online usando o cmdlet Restore-StorageGroupCopy. Ao atrasar a atividade de repetição nos destinos SCR, quando ocorrer um failover com perdas em uma origem SCR, as chances de precisar propagar novamente as cópias SCR serão minimizadas, pois a natureza da perda de dados na origem SCR aproxima mais as duas cópias em relação ao tempo.

Atualizações de instalação para SCR

A SCR foi projetada amplamente para falhas significativas, como uma falha completa do site. Esses tipos de cenários de falha envolvem atividades manuais, como ativação de um data center de backup, bem como o retorno a um data center principal.

Com a figura Usando vários destinos de SCR remotos para um SCC mostrada anteriormente neste tópico como exemplo, considere o que acontece quando o data center principal (o site que contém o SCC) falha, e a decisão tomada é ativar o segundo data center como site principal substituto. Quando o segundo data center é ativado, a configuração do data center original permanece no Active Directory, e essa configuração é usada pelo segundo data center após sua ativação. A configuração do servidor de caixas de correio clusterizadas do SCC também permanece no cluster original. Para que o cluster original fique novamente online, a configuração do servidor de caixas de correio clusterizadas deve ser removida dos nós do cluster sem afetar a configuração do servidor de caixas de correio clusterizadas no Active Directory (que está sendo usada pelo segundo data center).

Para facilitar este e outros cenários de resiliência de site, a instalação foi modificada no Exchange 2007 SP1. Especificamente, a instalação inclui uma nova opção de linha de comando chamada /ClearLocalCMS, que é usada para limpar as informações de configuração do servidor de caixas de correio clusterizadas dos nós do cluster original sem afetar as informações de configuração armazenadas no Active Directory. Por exemplo, para limpar os dados de configuração local de um servidor de caixas de correio clusterizadas chamado EXCLUS1, você executaria o seguinte comando localmente em cada nó do cluster original:

Setup /ClearLocalCMS

Saiba que há os seguintes requisitos e restrições ao usar a opção /ClearLocalCMS:

• Essa opção só pode ser usada localmente; não pode ser usada remotamente.

• Essa opção só pode ser usada em nós que hospedam um servidor de caixa de correio em cluster (por exemplos, nós ativos); ela não pode ser usada em nós passivos.

• Essa opção não remove os arquivos de programa do Microsoft Exchange e não atualiza nenhuma informação de configuração no Active Directory.

• Essa opção só pode ser usada quando o servidor de caixas de correio clusterizadas local está offline, e quando o nó local não está na lista RedundantMachines do servidor de caixas de correio clusterizadas local.

• A conta usada para limpar a configuração do servidor de caixas de correio clusterizadas local deve ter permissões de Administrador do Exchange Server para o servidor de caixas de correio clusterizadas.

• Se os nós do cluster estiverem em execução no Windows Server 2008, após executar Setup /ClearLocalCMS, o objeto de computador virtual (VCO) será desabilitado. Você deverá habilitar o VCO novamente.

Para obter mais informações

Para obter mais informações sobre planejamento para SCR, consulte Planejando a replicação contínua em espera. Para obter informações sobre o gerenciamento de SCR, incluindo as etapas detalhadas sobre como habilitar ou desabilitar SCR para um grupo de armazenamento, consulte Gerenciando a Replicação Contínua em Espera.