Exchange Server: Habilitando o SCR (Standby Continuous Replication)

Neste tutorial mostraremos como implementar o SCR em servidores Exchange Server 2007 SP1.

por Anderson Patricio

Overview

Neste tutorial vamos mostrar como implementar o SCR (Standby Continuous Replication) que é uma nova funcionalidades do Exchange Server 2007 SP1. Até a versão RTM do produto, nós tínhamos a possibilidade de ter um Clustered Mailbox Server (CMS) que podia por sua vez ter um disco central, leia-se storage e ser denominado SCC ou um com discos físicos separados que era o CCR, ainda tínhamos uma versão de cópia da database localmente que era chamado de LCR. Com todas estes opções da versão RTM ainda faltava uma lacuna onde o SCR foi desenvolvido.

Na versão RTM nos podíamos ter alta disponibilidade local (utilizando CCR ou SCC) mas não resiliência ao mesmo tempo. Para termos resiliência a única forma era usando um Cluster CCR esticado em duas subredes com o sistema operacional 2008, desta forma a base era replicada para dois sites diferentes. Para fazer isto precisamos utilizar uma mesma VLAN e sites do AD para os dois sites que terão cada nó do cluster, mas nunca teríamos uma alta disponibilidade local. O cenário mudou um pouco com o Windows 2008 que permite cluster em redes separadas, mas mesmo assim teríamos resiliencia mas nao a alta disponibilidade local do serviço.

Com o SCR conseguimos o melhor dos dois mundos, as empresas podem ter uma solução em um site de alta disponibilidade (CCR or SCC) e também, eu disse também, fazer uma replicação desta informação para um site remoto, com isto resolvemos o problema de ter um ou outro. Utilizando SCR podemos aproveitar um cluster local com toda a alta disponibiliade que o produto proporciona e se tivermos um desastre de grande magnitude podemos acionar uma cópia remota que está sendo feita pelo SCR.

Solução

O SCR trabalha com o conceito de Source (servidor origem) e Target (Servidor Destino). O servidor de origem pode ser um Mailbox, um cluster SCC ou SCR, já o destino pode ser um Mailbox sem nenhum LCR aplicado ou um cluster instalado como passivo.

Algumas informações que precisam ser sabidas sobre o SCR:

• O sistema operacional precisa ser o mesmo na origem e destino
• Exchange Server 2007 SP1 na origem e destino
• Origem e destino obrigatoriamente devem estar no mesmo domínio do Active Directory
• O destino pode ter até 50 Storage Groups na versão Enterprise e 5 Storage Groups na versão Standard
• O destino deve ter no mínimo o papel de Mailbox Server instalado
• A database da origem vai ser exatamente no destino, então um planejamento disto é muito importante. Por exemplo: empresa que tem dois sites usando Storage Group em D:\base01 não podem usar o mesmo destino, isto indica que um plano de drivers e caminhos para database tem que ser uniforme para toda empresa.
• Um servidor origem podem ter vários destinos; um destino pode ter várias origens. A regrar é n para n.
• A Microsoft recomenda não mais que 4 destinos por servidor de origem
• Um estudo da banda utilizada por este serviço é extremamente recomendado

Agora que sabemos os principais detalhes, já podemos saber se podemos ou nao usar o SCR em nossa infra-estrutura, a estrutura dele é simples podemos ver na figura abaixo. Onde o SRV-EX01 (Origem/Source) está replicado as informações para o servidor SRV-EX02 que posteriormente irá aplicar a base passiva.

Implementando o SCR..

Neste cenário vamos utilizar dois servidores (SRV-EX01 e SRV-EX02), uma cópia de uma Storage Group contida no SRV-EX01 vai ser replicada para o SRV-EX02, podemos verificar que no primeiro servidores temos o Storage Group chamado UsersSG e uma database também chamada de UserSG.

Para habilitar o SCR, devemos executar a seguinte sintaxe:

Enable-StorageGroupCopy -Identity <Storage Group> -StandbyMachine <maquina que irá receber> -ReplayLagTime <Dias.Hora:Minuto:segundos> -TruncationLagTime <Dias.Hora:Minuto:segundos>

Agora vamos a explicação dos parâmetros:

• ReplayLagTime: O tempo que os arquivos replicados para a máquina de Standby demorarão para ser aplicados a base passiva, o produto tem um número fixo no código de no mínimo uma demora de 50 arquivos de log para o servidor de produção, então este tempo será adicionado a este número interno. O valor padrão é 24 horas
• TruncationLagTime: Quanto tempo os arquivos aplicados a database passive (que obviamente está no servidor de Standby) demorarão para ser removidos

Sabendo os parametros, nos rodamos este comando em nosso ambiente como ser visto na figura abaixo:

Após alguns momentos, já podemos olhar no Event Viewer da máquina destino (em nosso exemplo um Windows Server 2008) que o Event ID 2114 nos informará que a replicação foi iniciada, como mostra a figura abaixo:

Para verificarmos o que está acontecendo, podemos rodar o cmdlet Get-StorageGroupCopyStatus com a seguinte sintaxe:

Get-StroageGroupCopyStatus -Standbymachine <Standby Server>

O resultado pode ser visto na figura abaixo, onde podemos ver que o UsersSG Storage Group está saudável (Healthy) e que a fila de aplicação de logs está com o número 6.

Devido a natureza do SCR onde o source e o target tem que ter o mesmo caminho físico, já podemos acessar as duas máquinas e notar que os arquivos estão sendo replicados, como mostra a figura abaixo. Mas podemos notar que a máquina srv-ex02 não tem a database, isto se deve ao limite do tempo especificado no ReplayLagTime e também ao número de 50 arquivos de log, antes disso a base não será vista no destino.

Finalmente, só para tirarmos uma boa parte das dúvidas do pessoal é a experiência do Administrador num ambiente SCR a cópia não é vista no Exchange Management Console do servidor standby (srv-ex02) a única forma é através do Exchange Management Shell, uma outra forma de visualização é através do caminho físico da base que devem estar os logs com a numeração semelhante em ambas as máquinas (Source/origem e Target/Destino).

Conclusão

Neste tutorial mostramos como implementar o SCR em servidores Exchange Server 2007 SP1, este procedimento pode ser utilizado com qualquer tipo de servidor origem e destino.