Planejando a replicação contínua em espera

  • Artigo

 

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

Tópico modificado em: 2008-09-11

Embora a implantação de SCR (replicação contínua em espera) seja similar à implantação de LCR (replicação contínua local), há diferenças importantes que você deve considerar. Há vários requisitos que devem ser atendidos para SCR.

Requisitos gerais para replicação contínua em espera

Antes de habilitar qualquer grupo de armazenamento para SCR, recomendamos que você se familiarize com os seguintes requisitos para origens e destinos da SCR:

  • Uma origem pode ter vários destinos. Por exemplo, uma origem pode ter um destino no mesmo datacenter de origem, e um segundo destino que existe em um datacenter separado. Não há limite para o número de destinos que você pode ter para cada origem. Entretanto, recomenda-se não usar mais de quatro destinos por origem. O impacto adicional no servidor de origem precisa ser verificado e planejado, caso sejam configurados mais de quatro destinos.

  • Cada destino pode ter vários servidores de origem. Tanto o sistema de origem como o de destino devem estar executando o Exchange 2007 SP1. O sistema operacional pode ser qualquer um aceito pelo Exchange 2007 SP1 (por exemplo, Windows Server 2008 ou Windows Server 2003); entretanto, todos os computadores de destino da SCR devem executar o mesmo sistema operacional que seus computadores de origem da SCR. Não há suporte para o uso de diferentes sistemas operacionais para uma origem de SCR e seus destinos (por exemplo, onde uma origem de SCR é Windows Server 2003 e o destino de SCR é Windows Server 2008, ou vice-versa).

  • O computador de destino da SCR deve ter a função de servidor Caixa de Correio do Exchange 2007 SP1 instalada. Se o computador de destino da SCR for um nó de cluster, o nó deve ser um nó passivo (por exemplo, a função de caixa de correio em cluster passivo é instalada) e o cluster não pode conter servidores de caixas de correio em cluster.

  • Você deve planejar os caminhos de instalação do Exchange Server com mais cuidado ao usar a SCR, caso pretenda usar um cluster em espera e o recurso de recuperação do servidor de caixas de correio em cluster (Setup /RecoverCMS) como parte do processo de ativação do destino da SCR. Para usar o processo de recuperação do servidor, o caminho de instalação do Exchange Server deve ser o mesmo para os computadores de origem e de destino da SCR. Se o Exchange Server estiver instalado em %ProgramFiles%\Microsoft\Exchange Server no computador de origem da SCR, ele também deverá estar instalado em %ProgramFiles%\Microsoft\Exchange Server em todos os computadores que serão destinos da SCR para o servidor de origem da SCR. Se esses caminhos de instalação não corresponderem, Setup /RecoverCMS falhará, pois o caminho de instalação no Registro não corresponderá ao valor do atributo msExchInstallPath do objeto de servidor de Caixa de Correio no serviço de diretório do Active Directory.

  • Se seu processo de ativação incluir a recuperação de um servidor de caixas de correio em cluster, você deve desabilitar a SCR para todos o(s) grupo(s) de armazenamento no servidor de caixas de correio em cluster antes de usar Setup /RecoverCMS como parte do processo de ativação. Se a SCR não for desabilitada para todos os grupos de armazenamento, ocorrerá falha em Setup /RecoverCMS.

  • O grupo de armazenamento e caminhos de banco de dados na origem e em todos os destinos da SCR não devem estar em conflito com nenhum outro grupo de armazenamento ou caminho de banco de dados. Você deve planejar os caminhos do grupo de armazenamento e do banco de dados cuidadosamente ao usar SCR, pois o caminho do grupo de armazenamento e do banco de dados usado por uma origem de SCR será usado para a cópia do grupo de armazenamento e do banco de dados em todos os destinos de SCR da origem.

  • Os computadores de origem e de destino de SCR devem estar no mesmo domínio do Active Directory, mas podem estar no mesmo site do Active Directory ou em sites diferentes.

  • Cada computador de destino aceita no máximo 50 destinos de SCR (50 grupos de armazenamento replicados) ao usar a Enterprise Edition do Exchange 2007 e no máximo 5 destinos de SCR ao usar a Standard Edition do Exchange 2007.

Restrições sobre computadores de destino da SCR

Quando um nó passivo ou um servidor de Caixas de Correio autônomo é configurado como destino da SCR, os seguintes recursos são bloqueados:

  • Um servidor de Caixa de Correio autônomo que é designado como destino da SCR não pode ter a LCR habilitada para nenhum grupo de armazenamento. O Serviço de Replicação do Microsoft Exchange não foi projetado nem modificado para manipular o gerenciamento da LCR e da replicação de outra origem.

  • Um nó passivo que é projetado como destino da SCR deve ser membro de um cluster de failover que não tenha nenhum servidor de caixas de correio em cluster. Isso é chamado de cluster de standby. Para obter mais informações sobre clusters de standy, consulte Alta disponibilidade.

SCR e bancos de dados de pasta pública

A SCR e a replicação de pasta pública são duas formas muito diferentes de replicação incorporadas ao Exchange. Devido a limitações de interoperabilidade entre a replicação contínua e a replicação de pasta pública, se mais de um servidor de Caixas de Correio na organização do Exchange tiver um banco de dados de pasta pública, a replicação de pasta pública será habilitada e os bancos de dados de pasta pública não deverão ser armazenados em ambientes de SCR.

Dica

Como a portabilidde de banco de dados pode ser usada somente com bancos de dados de caixa de correio, a ativação de uma cópia de destino de SCR de um banco de dados de pasta pública só pode ser realizada como parte de um servidor ou operação de recuperação de servidor de caixas de correio em cluster (por exemplo, Setup /m:recoverServer ou Setup /recoverCMS).

As configurações a seguir são as recomendadas para usar bancos de dados de pasta pública e SCR na organização do Exchange:

  • Se você tiver um único servidor de caixas de correio na organização do Exchange e esse servidor de Caixas de Correio for um servidor autônomo ou um servidor de caixas de correio em cluster em um SCC, o servidor de Caixas de Correio poderá hospedar um banco de dados de pasta pública e o grupo de armazenamento que contém o banco de dados de pasta pública poderá ser habilitado para SCR, desde que o grupo de armazenamento não seja habilitado para LCR. Nessa configuração, existe somente um banco de dados de pasta pública na organização do Exchange. Portanto, a replicação de pasta pública está desabilitada. Nesse cenário, a redundância do banco de dados de pasta pública é obtida usando a SCR; a SCR mantém duas cópias do seu banco de dados de pasta pública.

  • Se houver diversos servidores de caixas de correio e somente um deles contiver um banco de dados de pasta pública e esse mesmo servidor for autônomo ou de caixas de correio em cluster em um SCC, o servidor de caixas de correio poderá hospedar um banco de dados de pasta pública e o grupo de armazenamento que contém o banco de dados de pasta pública poderá ser habilitado para SCR, desde que o grupo de armazenamento não seja habilitado para LCR. Nessa configuração, existe somente um banco de dados de pasta pública na organização do Exchange. Portanto, a replicação de pasta pública está desabilitada. Neste cenário, a redundância do banco de dados de pasta pública também é obtida usando a SCR.

  • Se você estiver migrando dados de pasta pública para um um grupo de armazenamento habilitado para SCR, você poderá usar a replicação de pasta pública para mover o conteúdo de um banco de dados de pasta pública de um servidor autônomo ou de um servidor de caixas de correio em cluster em um SCC para o grupo de armazenamento habilitado para SCR. Quando a replicação tiver terminado com sucesso, todos os bancos de dados de pasta pública fora dos grupos de armazenamento habilitados para SCR deverão ser removidos e você não deverá hospedar quaisquer outros bancos de dados de pasta pública na organização do Exchange.

  • Se você estiver migrando dados de pasta pública para fora de um grupo de armazenamento habilitado para SCR, você poderá usar a replicação de pasta pública para mover o conteúdo de um banco de dados de pasta pública de grupo de armazenamento para um servidor de Caixas de Correio autônomo ou um servidor de caixas de correio em cluster em um SCC. Quando a replicação tiver sido realizada com êxito, todos os bancos de dados de pasta pública dentro de todos grupos de armazenamento habilitados para SCR deverão ser removidos e todos os bancos de dados de pasta pública subseqüentes não deverão ser hospedados em grupos de armazenamento habilitados para SCR.

Durante qualquer período em que exista mais de um banco de dados de pasta pública na organização do Exchange e um ou mais bancos de dados de pasta pública estiverem hospedados em um grupo de armazenamento habilitado para SCR, se ocorrer uma falha no grupo de armazenamento de origem de SCR e um banco de dados de pasta pública de destino de SCR precisar ser ativado, ele somente poderá ser montado se todos as logs do grupo de armazenamento que hospede o banco de dados de pasta pública estiverem disponíveis. Se algum log estiver ausente ou não estiver disponível como resultado de uma falha da origem de SCR, você não poderá ativar a cópia de destino de SCR do banco de dados de pasta pública. Nesse caso, a origem de SCR deverá ser colocada online para garantir que não haja perda de dados, ou o banco de dados de pasta pública deverá ser recriado na origem de SCR e seu conteúdo deverá ser recuperado usando a replicação da pasta pública a partir de um banco de dados de pasta pública que não seja a cópia de destino de SCR.

SCR e backups

Você não pode fazer backup de uma cópia de destino de SCR. LCR e CCR aceitam backups das cópias ativa e passiva. A SCR aceita backups da origem da SCR apenas. Os cabeçalhos de bancos de dados de um destino da SCR serão atualizados, e os arquivos de log serão truncados quando um backup aceito for executado mediante o grupo de armazenamento de origem da SCR. Se o grupo de armazenamento de origem da SCR estiver habilitado para CCR ou LCR, os cabeçalhos de banco de dados do destino da SCR serão atualizados, e os arquivos de log serão truncados quando forem feitos backups mediante as cópias ativas ou passivas do grupo de armazenamento de origem da SCR.

SCR e restaurações

Quando um banco de dados de origem da SCR é substituída por uma versão anterior do banco de dados, você deve suspender e continuar a replicação do grupo de armazenamento usando Suspend-StorageGroupCopy e Resume-StorageGroupCopy, respectivamente. Esse processo é necessário para atualizar o Serviço de Replicação do Microsoft Exchange com as informações corretas de geração de log. Se a replicação contínua não for suspensa e continuada, o Serviço de Replicação terá informações desatualizadas da geração de log e parará de replicar os arquivos de log.

SCR e truncamento de arquivo de log

No Exchange 2007 RTM, as regras são impostas de maneira que, em um ambiente de replicação contínua, um arquivo de log não seja excluído, a menos que haja backup e que ele tenha sido reproduzido na cópia do banco de dados. Essa regra é modificada ao usar SCR. A SCR (que introduz o conceito de várias cópias de banco de dados) permite o truncamento de arquivos de log na origem da SCR assim que eles são inspecionados por todos os computadores de destino da SCR. O truncamento de log na origem da SCR não espera todos os logs serem reproduzidos em todos os destinos da SCR, porque as cópias do destino da SCR podem ser configuradas com grandes atrasos de repetição de log. Porém, a truncagem do log em uma origem de SCR não ocorrerá se um ou mais destinos de SCR para um grupo de armazenamento estiverem inativos. Para que os logs sejam truncados em uma origem de SCR, o(s) computador(es) de SCR deve estar online e acessível pela origem.

Em um destino de SCR, um thread em segundo plano é executado a cada três minutos para determinar se algum arquivo de log precisa ser truncado. Se os três critérios a seguir forem atendidos, um arquivo de log será truncado no destino de SCR:

  • O arquivo de log foi truncado na origem da SCR.

  • A seqüência de geração de arquivo de log está abaixo do ponto de verificação do arquivo de log para o grupo de armazenamento.

  • O arquivo de log é mais antigo que ReplayLagTime + TruncationLagTime. (Para obter uma descrição desses parâmetros, consulte "Atualizações de cmdlet para SCR" no tópico Replicação Contínua Em Espera)

Em um ambiente de LCR ou CCR estendido com SCR, se os três critérios a seguir forem atendidos, um arquivo de log será truncado nas cópias ativa e passiva no ambiente de LCR ou CCR:

  • O backup do arquivo de log foi feito.

  • A seqüência de geração de arquivo de log está abaixo do ponto de verificação do arquivo de log para o grupo de armazenamento.

  • Todos os destinos de SCR inspecionaram o arquivo de log.

Otimizando o sistema de rede do Windows 2003 para SCR

Embora nenhuma otimização de rede seja necessária ao usar a SCR em Windows Server 2008, ao usar SCR no Windows Server 2003, recomendamos que você otimize suas configurações de TCP/IP do Windows Server da velocidade e latência de link de rede específico. Especificamente, talvez seja necessário ajustar o tamanho da janela de recebimento de protocolo TCP e as opções de escala da janela RFC (Request for Comments) 1323 em um computador de origem de SCR e seus computadores de origem de SCR. Além disso, pode ser útil definir as configurações de expiração de cache do protocolo ARP e desabilitar as opções avançadas de TCP/IP do Windows Server 2003 Scalable Networking Pack (SNP) no Registro do Windows.

Além dessas recomendações, se o seu ambiente incluir o uso do protocolo IPsec, recomendamos configurar o IPsec de forma consistente em todo o ambiente de SCR. Ou a origem de SCR e todos os seus destinos da SCR devem usar o IPsec ou nem a origem de SCR ou nenhum de seus destinos deve usar o IPSec. Se apenas um nó estiver configurado para usar IPsec, o processo de Associação de Segurança IPsec poderá causar atraso ou perda de pacotes.

Janelas de recepção TCP e opções de escala RFC 1323

O tamanho da janela de recebimento de TCP é a quantidade máxima de dados (em bytes) que pode ser recebida por vez em uma conexão. O computador de envio pode enviar apenas essa quantidade máxima de dados antes de aguardar a confirmação e uma atualização de janela de TCP do computador de recebimento. Pode ser vantajoso ajustar essa configuração para aumentar a taxa de transferência durante o envio de logs.

Para otimizar a taxa de transferência de TCP, o computador de envio deve transmitir pacotes suficientes para preencher o pipe entre o emissor e o receptor. A capacidade do pipe de rede é baseada na largura de banda do pipe e em sua latência (hora de resposta). Quanto mais alta a latência, maior a capacidade que você tem, pois há mais tempo para enviar dados entre as confirmações. Ao aumentar o tamanho da janela TCP, o sistema pode tirar proveito do tempo entre as confirmações enviando mais dados.

O padrão TCP/IP permite que uma janela receba até 65.535 octetos em tamanho, que é o valor máximo que pode ser especificado no campo de tamanho da janela de TCP de 16 bits. Para aprimorar o desempenho em larguras de banda alta e redes com grande atraso, o TCP/IP do Windows Server possui um recurso para anunciar tamanhos de janela de recepção maiores que 65.535 octetos usando janelas escalonáveis, conforme descrito no RFC 1323, Extensões TCP para alto desempenho. Ao utilizar a escala de janelas, os hosts em uma conversação podem negociar um tamanho de janela que permite vários pacotes grandes, como aqueles normalmente usados em protocolos de transferência de arquivos, fiquem pendentes nos buffers do receptor. O RFC 1323 detalha um método para aceitar tamanhos de janela de recepção maiores, permitindo que o TCP negocie um fator de escala para o tamanho de janela no estabelecimento da conexão.

Para otimizar o tamanho da janela de recepção TCP e as opções de escala da janela da RFC 1323 em um computador que esteja executando o Windows Server 2003, modifique duas entradas do Registro: TCPWindowSize e TCP1323Opts. Para obter mais informações sobre esses recursos, consulte o artigo 224829 da Base de Dados de Conhecimento da Microsoft, Description of Windows 2000 and Windows Server 2003 TCP Features (página em inglês).

Recomendamos utilizar a versão 13 ou posterior da Calculadora de requisitos de armazenamento da função de servidor Caixa de Correio do Exchange 2007 para determinar as configurações ideais para essas entradas de Registro com base no link e na latência da rede. Para baixar a calculadora, consulte Exchange 2007 Mailbox Server Role Storage Requirements Calculator (página em inglês) no Blog da Equipe do Exchange. A Calculadora de armazenamento inclui também instruções passo a passo para inserir os valores do Registro em seus servidores.

Dica

UNRESOLVED_TOKEN_VAL(exBlog)

Expiração de cache ARP

O cache ARP é uma tabela da memória que mapeia endereços IP para os endereços MAC (controle de acesso de mídia). As entradas do cache ARP são mencionadas sempre que um pacote de saída for enviado para o endereço IP da entrada. Por padrão, o Windows Server 2003 ajusta o tamanho do cache ARP automaticamente para atender às necessidades do sistema. Se uma entrada não for usada por nenhum datagrama de saída por dois minutos, ela será removida do cache ARP. As entradas que estiverem sendo mencionadas são removidas do cache ARP depois de dez minutos. As entradas adicionadas manualmente não são removidas do cache automaticamente.

O teste interno pelo departamento de TI interno da Microsoft mostrou que as configurações de expiração do cache ARP padrão resultaram na perda de pacotes em ambientes de CCR e de SCR. Quando ocorre a perda do pacote, o servidor de envio deve transmitir os dados perdidos novamente. Em um ambiente de replicação contínua, é importante que os arquivos de log sejam copiados para o nó passivo o mais rápido possível, e a nova transmissão dos dados devido à perda de pacotes pode prejudicar a taxa de transferência do envio do logs.

Você pode modificar o parâmetro TCP/IP ArpCacheMinReferencedLife no Registro do Windows para controlar a expiração do cache ARP. Esse parâmetro determina por quanto tempo as entradas mencionadas devem permanecer na tabela do cache ARP antes que sejam excluídas. Internamente, a Microsoft determinou que a configuração ideal para o valor do Registro ArpCacheMinReferencedLife era utilizar o mesmo valor que estava sendo usado para a expiração do cache ARP pelos roteadores na rede, que era de 4 horas.

Antes de modificar o valor de ArpCacheMinReferencedLife em seu ambiente, recomendamos utilizar o Microsoft Network Monitor ou uma ferramenta de captura semelhante para coletar e analisar o tráfego da rede na interface de rede que está sendo usada para copiar logs do nó ativo para o nó passivo. Para obter etapas detalhadas para modificar o valor do Registro ArpCacheMinReferencedLife, consulte o Appendix A: TCP/IP Configuration Parameters.

Recursos TCP/IP avançados do Scalable Networking Pack

O SNP (Scalable Networking Pack) do Windows Server 2003 é uma atualização separada do Windows Server 2003 que contém descarregamentos de estado e sem estado para acelerar a pilha de rede do Windows. A atualização inclui descarregamento TCP Chimney, RSS (Receive Side Scaling) e NetDMA (Network Direct Memory Access).

O TCP Chimney é um descarregamento de estado. O descarregamento TCP Chimney permite que o processamento TCP/IP seja descarregado para adaptadores de rede que podem lidar com o processamento TCP/IP no hardware.

RSS e NetDMA são descarregamentos sem estado. Quando várias CPUs residem em um único computador, a pilha de rede do Windows limita o processamento do protocolo de "recebimento" a uma única CPU. O RSS resolve esse problema permitindo que os pacotes recebidos de um adaptador de rede sejam distribuídos em várias CPUs. O NetDMA permite um mecanismo DMA (Acesso Direto à Memória) no barramento PCI. A pilha TCP/IP pode utilizar o mecanismo DMA para copiar dados em vez de interromper a CPU para lidar com a operação de cópia. Um componente relacionado, TCPA, é outra função de descarregamento em que um mecanismo DMA de hardware no barramento PCI pode ser usado para ajudar no processamento de recebimento.

Embora esses recursos possam fornecer benefícios de desempenho da rede em alguns ambientes, há alguns cenários em que eles não podem ser utilizados devido ao uso de outras tecnologias. Por exemplo, o descarregamento TCP Chimney e NetDMA não poderão ser utilizados se alguma das seguintes tecnologias for utilizada:

  • Windows Firewall

  • Protocolo IPsec

  • IPNAT (Conversão de Endereços de Rede de Protocolo IP)

  • Firewalls de terceiros

  • Drivers intermediários NDIS 5.1

Além disso, há problemas conhecidos em alguns ambientes, incluindo ambientes com o Microsoft Exchange, em que o desempenho da rede pode ser reduzido ao utilizar esses recursos. Para obter detalhes sobre alguns desses problemas, consulte a postagem do blog da Equipe do Exchange, Windows 2003 Scalable Networking pack and its possible effects on Exchange (página em inglês).

Dica

UNRESOLVED_TOKEN_VAL(exBlog)

Recomendamos desabilitar todos os recursos em ambientes de SCR que são executados no sistema operacional Windows Server 2003 para o sistema operacional e cada placa de interface de rede (NIC) do sistema. Você pode desabilitar esses recursos da seguinte maneira:

Para obter mais informações sobre o SNP, consulte o artigo 912222 da Base de Dados de Conhecimento, The Microsoft Windows Server 2003 Scalable Networking Pack release, e o site Scalable Networking.