Planejando 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: 2008-07-23

Embora a implantação da CCR (Replicação Contínua em Cluster) seja semelhante à da LCR (Replicação Contínua Local) e à de um SCC (Cluster de Cópia Única), há diferenças importantes que você deve considerar. Existem requisitos gerais que devem ser atendidos para CCR, como requisitos de hardware, software, rede e cluster.

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

Antes de implantar a CCR, verifique se os seguintes requisitos de todo o sistema são atendidos:

• Deve ser usado um único banco de dados por grupo de armazenamento. Quando um grupo de armazenamento é criado em um ambiente de CCR, ele pode conter apenas um único banco de dados. Esse método cria uma topologia de armazenamento do Microsoft Exchange mais fácil de gerenciar, o que aumenta a capacidade de recuperação.

• O DNS (Sistema de Nome de Domínio) deve estar em execução. O ideal é que o servidor DNS aceite atualizações dinâmicas. Se o servidor DNS não aceitar atualizações dinâmicas, você deverá criar um registro de host DNS (A) para cada servidor de caixas de correio clusterizadas e outro para o próprio cluster. Caso contrário, o Exchange não funcionará corretamente. Para obter mais informações sobre como configurar o DNS para o Exchange, consulte o artigo 322856 da Base de Dados de Conhecimento Microsoft, COMO FAZER: Configure DNS para Ser Usado com o Exchange Server.

• Se seus nós de cluster pertencerem a uma zona de serviço de nome de diretório que tenha um nome diferente do nome de domínio do serviço de diretório do Active Directory em que o computador ingressou, a propriedade DNSHostName não incluirá o nome de subdomínio por padrão. Nessa situação, você pode precisar alterar a propriedade do DNSHostName para garantir que alguns serviços, como o FRS (Serviço de Replicação de Arquivo), funcionem corretamente. Para obter mais informações, consulte o artigo 240942 da Base de Dados de Conhecimento, Propriedade DNSHostName do Active Directory não inclui subdomínio.

• Todos os nós de cluster devem ser servidores membros no mesmo domínio. Não há suporte para o Microsoft Exchange Server 2007 em nós que também sejam servidores do Active Directory ou em nós que sejam membros de domínios diferentes do Active Directory.

• O cluster deve estar formado antes da instalação do Exchange 2007. Para obter informações sobre como formar um cluster de failover do Windows Server 2008, consulte Instalando replicação contínua em cluster no Windows Server 2008. Para obter informações sobre formação de um cluster de failover do Windows Server 2003, consulte Instalando um cluster de cópia única.

• Os nomes do CMS (Servidor de Caixas de Correio Clusterizadas) deve ter 15 caracteres ou menos.

• O cluster no qual o Exchange 2007 está instalado não pode conter Exchange Server 2003, Exchange 2000 Server nem nenhuma outra versão com detecção de cluster do Microsoft SQL Server. Não há suporte para a execução do Exchange 2007 em um cluster com qualquer desses outros aplicativos. A execução do Exchange 2007 em um cluster com o SQL Server 2005 Express Edition ou outro aplicativo de banco de dados (como o Microsoft Office Access) é permitida, desde que o aplicativo de banco de dados não esteja clusterizado.

• Antes de instalar o Exchange 2007, verifique se a pasta em que você instalará os dados do Exchange está vazia.

• Você deve instalar a mesma versão do Exchange 2007 em todos os nós do cluster que estão configurados como hosts de um servidor de caixas de correio clusterizadas. Além disso, os arquivos do sistema operacional e do Exchange devem estar instalados nos mesmos caminhos e unidades para todos os nós do cluster. Isso requer que todos os computadores tenham uma configuração de disco similar, embora não idêntica.

• A conta do Serviço de cluster deve ser membro do grupo de administradores local em todos os nós que puderem hospedar um servidor de caixas de correio clusterizadas.

• Não instale, crie ou mova recursos do grupo de cluster padrão para o grupo de recursos que contém o servidor de caixas de correio clusterizadas. Além disso, não instale, crie ou mova recursos do grupo que contém o servidor de caixas de correio clusterizadas para o grupo de cluster padrão. O grupo de cluster padrão deve conter apenas os recursos de endereço IP, nome da rede e quorum. Não há suporte para a movimentação ou combinação de recursos para ou com o grupo de cluster padrão.

  Importante

  Clusters que executam versões anteriores do Exchange exigem uma instância clusterizada do Coordenador de transações distribuídas da Microsoft (MSDTC). O Exchange 2007 remove a exigência para o recurso de MSDTC clusterizado. Servidores de caixas de correio clusterizadas em um ambiente de CCR não devem usar e nem precisam do recurso MSDTC instalado no cluster de failover. Aplicativos de terceiros podem exigir um recurso do MSDTC devido às dependências COM+. No Windows Server 2003, o recurso de cluster do MSDTC exige o uso de armazenamento compartilhado no cluster. Não é recomendado adicionar o armazenamento compartilhado em um ambiente de CCR. O Windows Server 2008 fornece uma instância de MSDTC local não clusterizada que remove o requisito para armazenamento compartilhado em cluster de failover do Windows Server 2008. Para obter mais informações sobre alterações do MSDTC no Windows Server 2008, consulte a Ajuda do Windows Server 2008.

Requisitos de hardware para replicação contínua em cluster

Para obter informações gerais sobre planejamento de hardware, consulte Planejando Configurações do Processador e Planejando o armazenamento em disco. Os requisitos de hardware específicos para ambientes de CCR são os seguintes:

• Ao usar o quorum de MNS (Conjunto de Nós Principais) com testemunha de compartilhamento de arquivos no Windows Server 2003, somente dois nós podem existir no cluster. Se um nó ou mais de dois existirem no cluster, o recurso de quorum de MNS com testemunha de compartilhamento de arquivo não poderá ser usado. Em vez disso, deve ser usado um quorum de MNS tradicional, que exige três ou mais nós no cluster.

• Quando você usar o quorum de Maioria dos Nós e Compartilhamentos de Arquivos no Windows Server 2008, somente dois nós poderão existir no cluster. Se um nó ou mais de dois existirem no cluster, o quorum de Maioria dos Nós e Compartilhamentos de Arquivos não poderá ser usado. Em vez disso, deve ser usado um quorum de Nós Principais, que exige três ou mais nós no cluster.

  Dica

  Recomenda-se o uso de um cluster de failover de dois nós que use o quorum de MNS com testemunha de compartilhamento de arquivos ou o quorum de Maioria dos Nós e Compartilhamentos de Arquivos. Isso elimina a necessidade da existência de um terceiro nó eleitor no cluster.

• Os servidores devem estar listados no Catálogo de Produtos Testados do Microsoft Windows Server do sistema operacional em que serão instalados. Entretanto, se não for usado armazenamento compartilhado no cluster, os servidores não precisarão estar listados na categoria de cluster.

• Os dois servidores que hospedam as funções de servidor Caixa de Correio devem ser comparáveis, mas não idênticos em:

  • CPU

  • Memória

  • Recurso de Entrada/Saída (E/S)

  • Sistema de rede

  • Fornecedor

  • Disponibilidade de armazenamento em disco, que inclui recursos de operações de E/S e espaço

Requisitos de quorum para replicação contínua em cluster

Normalmente, aplicativos clusterizados desconhecem o tipo de quorum usado pelo cluster em que eles estão instalados. Ao projetar o componente de quorum do ambiente CCR, esteja ciente das recomendações e dos requisitos a seguir:

• No Windows Server 2008, um quorum de Maioria dos Nós e Compartilhamentos de Arquivos é o tipo de quorum mais recomendado para CCR.

• No Windows Server 2003, um quorum de MNS com testemunha de compartilhamento de arquivos é o tipo de quorum mais recomendado para CCR.

Se um dos tipos de quorum anteriores for usado para CCR, os nós não precisarão estar listados no Catálogo de Produtos Testados do Microsoft Windows Server.

Se um quorum de armazenamento compartilhado for usado para CCR, todo o sistema deverá estar listado no Catálogo de Produtos Testados do Microsoft Windows Server.

No Exchange Server 2007 Service Pack 1 (SP1), a instalação bloqueia configurações de cluster de dois nós quando uma testemunha de compartilhamento de arquivos ou um Compartilhamento de Arquivos Principais não está configurado. Isso acontece porque essa configuração não poderia perder um nó do cluster (porque os principais não seriam mantidos), o que resulta na desconexão do cluster.

Requisitos de software para replicação contínua em cluster

Os requisitos de software para ambientes de CCR são os seguintes:

• Ambos os nós do cluster devem ter o sistema operacional Windows Server 2008 Enterprise ou Windows Server 2003 Enterprise Edition instalado em cada nó do cluster usando as mesmas letras da unidade de inicialização e do sistema. Não é possível ter um cluster com um nó executando o Windows Server 2008 e o outro nó executando o Windows Server 2003. Não é possível misturar versões de sistema operacional em um cluster de failover.

• Se você estiver criando um ambiente de CCR usando a versão RTM do Exchange 2007 no Windows Server 2003, os dois nós do cluster de failover devem ter o Windows Server 2003 Service Pack 2 (SP2) ou o Windows Server 2003 SP1 e o hotfix do artigo 921181 da Base de Dados de Conhecimento, Está disponível uma atualização que adiciona um recurso de testemunha de compartilhamento de arquivos e um recurso de pulsações de cluster configuráveis aos clusters de servidor baseados no Windows Server 2003 Service Pack 1, instalados. Esse hotfix está incluído no Windows Server 2003 SP2. Se você estiver criando um ambiente de CCR usando o Exchange 2007 SP1 no Windows Server 2003, os dois nós no cluster de failover devem ter o Windows Server 2003 SP2 instalado.

• O cluster deve ser um cluster de três nós com um quorum de MNS tradicional ou um cluster de dois nós com um quorum de MNS com testemunha de compartilhamento de arquivos. Normalmente, supõe-se que, no Windows Server 2003, será usado um cluster de dois nós que use um quorum MNS com testemunha de compartilhamento de arquivo, e que no Windows Server 2008 será usado um cluster de dois nós com um quorum de Maioria dos Nós e Compartilhamentos de Arquivos.

• A testemunha de compartilhamento de arquivos para o quorum do MNS ou do Compartilhamento de Arquivo Principal não precisa estar em um computador dedicado. Ela pode estar em qualquer computador que esteja executando o Windows Server. Porém, recomendamos hospedar a testemunha de compartilhamento de arquivos em um servidor de Transporte de Hub (ou outro servidor Exchange) para que fique sob o controle do administrador do Exchange.

• Somente a função de servidor Caixa de Correio pode ser instalada em um cluster. Nenhuma outra função de servidor pode ser instalada em um computador que faça parte de um cluster de failover.

Requisitos de rede para replicação contínua em cluster

É importante que as redes usadas para as comunicações de cluster e cliente estejam configuradas corretamente. Esta seção fornece links para os procedimentos necessários para verificar se a configuração de rede pública e particular estão configuradas corretamente. Além disso, você deve verificar se a ordem da conexão de rede está configurada corretamente para o cluster. Considere o seguinte ao projetar a infra-estrutura de rede para seu ambiente de CCR:

• Cada nó deve ter no mínimo dois adaptadores de rede disponíveis para o Cluster do Windows. Os clientes e outros servidores precisam ser capazes de acessar apenas os nós de um dos dois adaptadores de rede. Os outros adaptadores de rede são usados para comunicação dentro do cluster. A configuração recomendada é ter a rede privada dedicada a comunicações internas do cluster e a rede pública designada como mista.

• A rede pública de cluster deve fornecer conectividade aos outros servidores Exchange e outros serviços, como Active Directory e DNS. Você pode impedir que esse seja um ponto de falha único usando um agrupamento de adaptador de rede ou uma tecnologia semelhante.

• É necessário fornecer uma rede privada de cluster separada. A rede privada é usada para pulsação de cluster. A rede privada não exige DNS.

• Os requisitos de pulsação podem não ser os requisitos mais restritos de latência e de largura de banda de rede pública para uma configuração de duas centrais de dados. Avalie a carga de rede total, que inclui acesso para cliente, Active Directory, transporte, replicação contínua e outros tráfegos de aplicativo, para determinar os requisitos de rede necessários para o ambiente.

• Recomenda-se usar o Gigabit Ethernet para ambientes de CCR para maximizar o tempo de nova propagação. Para obter mais informações sobre qual Gigabit Ethernet é recomendado, consulte "Tamanho do banco de dados e Replicação Contínua em Cluster", posteriormente neste tópico.

• No Exchange 2007 RTM, um grupo de recursos que contém um servidor de caixas de correio clusterizadas pode ter somente um recurso de Nome de Rede. Não há suporte no Exchange 2007 RTM para mais de um recurso de Nome de Rede em um grupo de recursos que contenha um servidor de caixas de correio clusterizadas. Entretanto, essa limitação não existe no Exchange 2007 SP1. Quando o servidor de caixas de correio clusterizadas tiver sido atualizado para o Exchange 2007 SP1, mais de um recurso de nome de rede poderá existir no grupo de recursos que contém o servidor de caixas de correio clusterizadas.

Requisitos de rede para instalação da CCR no Windows Server 2008

Os requisitos de rede para instalação da CCR no Windows Server 2008 são ligeiramente diferentes dos requisitos para a instalação da CCR no Windows Server 2003. Como no Windows Server 2003, se você estiver instalando a CCR no Windows Server 2008, deverá ter endereços IP suficientes disponíveis para os dois nós e para o CMS (Servidor de Caixas de Correio Clusterizadas). Porém, há algumas opções adicionais disponíveis no Windows Server 2008 que não estão disponíveis no Windows Server 2003:

• Os nós de cluster podem residir em sub-redes diferentes. No Windows Server 2003, a interface de rede para cada rede em cada nó deve estar na mesma sub-rede que a rede correspondente no outro nó. Este requisito não existe no Windows Server 2008. Como resultado, os nós dentro de um cluster de failover podem se comunicar por roteadores de rede e a tecnologia VLAN (LAN virtual) não precisa ser usada para conectar os nós.

• Ao usar várias sub-redes em um ambiente de CCR, a replicação de DNS pode afetar a capacidade de um cliente de se reconectar a um CMS depois que ocorrer um failover ou handoff do CMS entre nós. Os clientes e outros servidores que se comuniquem com um servidor de caixas de correio clusterizadas que tenha alterado os endereços IP não poderão restabelecer as comunicações com o servidor de caixas de correio clusterizadas até que o DNS tenha sido atualizado com o novo endereço IP e quaisquer caches DNS locais tenham sido atualizados. Para minimizar o período de tempo necessário para que as alterações do DNS sejam levadas ao conhecimento dos clientes e de outros servidores, recomendamos definir um valor de TTL (Vida Útil) de DNS de cinco minutos para o recurso de Nome da Rede do servidor de caixas de correio clusterizadas. Na maioria dos ambientes, é recomendável configurar o valor de TTL de DNS apenas para o recurso de nome de rede do CMS. Entretanto, em ambientes com ferramentas de gerenciamento que não sejam do Exchange e que se conectem ao cluster com o respectivo nome para fins de gerenciamento, recomendamos configurar um valor de TTL mais baixo no recurso de Nome de Rede do cluster. Para obter etapas detalhadas sobre como configurar os valores de TTL de DNS dos recursos de Nome de Rede a serem usados em um CMS com várias sub-redes ou na implantação de clusters em espera, consulte Como configurar valores de TTL de DNS para recursos de nome de rede.

• No cluster de failover do Windows Server 2008, o recurso existe onde os recursos de Endereços IP de cluster podem obter o endereçamento dos servidores de protocolo DHCP, como também por entradas estáticas. Se os próprios nós de cluster forem configurados para obter seus endereços IP de um servidor DHCP, o comportamento padrão será obter um endereço IP automaticamente para todos os recursos de Endereço IP de cluster. Se o nó de cluster tiver endereços IP atribuídos estaticamente, os recursos de Endereço IP do cluster devem ser configurados com endereços IP estáticos também. Assim, a atribuição de endereço IP do recurso Endereço IP segue a configuração do nó físico e cada interface especifica no nó. Não recomendamos usar o DHCP para servidores de caixas de correio clusterizadas. Recomendamos considerar o seguinte antes de usar o DHCP para um CMS:

  • O Serviço de cluster não colocará online um recurso de Endereço IP habilitado para DHCP se houver alterações do endereço IP.

  • Os servidores DHCP devem ser configurados para conceder uma licença ilimitada para todos os endereços atribuídos por DHCP usados por servidores de caixas de correio clusterizadas.

• O Windows Server 2008 e seu Serviço de cluster também oferece suporte ao IPv6. Isso inclui ser capaz de oferecer suporte a recursos de Endereços IP IPv6 e recursos de Endereços IP IPv4 sozinho ou em combinação em um cluster. Além disso, os clusters de failover também oferecem suporte ao protocolo ISATAP e aceitam somente endereços IPv6 que permitem o registro dinâmico em DNS (registros de host AAAA e a zona de pesquisa reversa IP6.ARPA). Usando endereços IPv6 e intervalos de endereço IP é aceito somente quando o Exchange 2007 SP1 é implantado em um computador que está executando o Windows Server 2008, tanto o IPv6 e o IPv4 são habilitados nesse computador e a rede oferece suporte para ambas as versões de endereço IP. Se o Exchange 2007 SP1 for implantado nesta configuração, todas as funções de servidor poderão enviar e receber dados de dispositivos, servidores e clientes que usarem endereços IPv6. Uma instalação padrão do Windows Server 2008 permite suporte para IPv4 e IPv6. Se o Exchange 2007 SP1 estiver instalado no Windows Server 2003, os endereços IPv6 não serão aceitos. Para obter mais informações sobre o suporte do Exchange 2007 SP1 para endereços IPv6, consulte Suporte a IPv6 no Exchange 2007 SP1 e SP2.

Requisitos de rede para instalação da CCR no Windows Server 2003

Se você estiver instalando a CCR no Windows Server 2003, será necessário possuir um número suficiente de endereços IP estáticos disponíveis ao criar servidores de caixas de correio clusterizadas em um ambiente de CCR de dois nós. Um endereço IP é necessário para o cluster e para o servidor de caixas de correio clusterizadas. Além disso, os endereços IP são necessários para redes pública e privada em cada nó:

• Endereços particulares   Cada nó exige um endereço IP estático para cada adaptador de rede que será usado para a rede privada de cluster. Você deve usar endereços IP estáticos que não estejam na mesma sub-rede ou rede que uma das redes públicas. Recomendamos usar 10.10.10.10 e 10.10.10.11, com uma máscara de sub-rede igual a 255.255.255.0, como endereços IP privados para os dois nós, respectivamente. Se sua rede pública usar uma rede 10.x.x.x e uma máscara de sub-rede 255.255.255.0, recomendamos usar endereços IP e máscara de sub-rede de rede privada alternativos. Se você configurar mais de uma rede privada, endereços e sub-redes exclusivos serão exigidos para cada adaptador de rede e rede privada.

• Endereços públicos   Cada nó exige um endereço IP estático para cada adaptador de rede que será usado para a rede pública de cluster. Além disso, endereços IP estáticos são necessários para o cluster de servidor e o servidor de caixas de correio clusterizadas, de forma que eles possam ser acessados por clientes e administradores. Você deve usar endereços IP estáticos que não estejam na mesma sub-rede ou rede que uma das redes privadas.

A rede privada de todos os nós em um cluster deve estar na mesma sub-rede, mas você pode usar opções de LAN virtual (VLAN) nas interconexões entre dois nós. Se você usar uma VLAN, a latência completa de ponto a ponto deverá ser menor que 0,5 segundos. Além disso, o link entre dois nós deve aparecer como uma única conexão ponto a ponto da perspectiva do sistema operacional Windows Server 2003 executado nos nós. Para evitar pontos de falha únicos, use um hardware de VLAN independente para diferentes caminhos entre os nós. A mesma restrição de sub-rede não se aplica a clusters de failover executados no Windows Server 2008.

As redes públicas de todos os nós do cluster também devem estar na mesma sub-rede, e usar uma sub-rede diferente da sub-rede usada para as redes privadas. A mesma restrição de sub-rede não se aplica a clusters de failover executados no Windows Server 2008.

A ordem de conexão de rede de cluster no Windows deve ser configurada para que as redes públicas estejam no topo da lista de ordem de conexão, e a prioridade de rede no cluster deve ser configurada com as redes privadas listadas na parte superior da ordem de prioridade.

Se você estiver instalando a CCR no Windows Server 2003 em uma configuração de várias centrais de dados:

• Todas as redes usadas em acesso para cliente devem fornecer largura de banda adequada e latência suficientemente baixa para permitir que os clientes acessem o servidor de caixas de correio clusterizadas de qualquer das centrais de dados.

• Todas as redes usadas para replicar logs de transações devem fornecer largura de banda adequada e latência suficientemente baixa para copiar os arquivos de log em tempo hábil, de modo que, sempre que possível, não haja registros posteriores de arquivos de log.

• As redes usadas para a pulsação de cluster devem ser capazes de enviar e receber um pacote de pulsação no número necessário de novas tentativas configuradas. Se você estiver instalando a CCR no SP 2 do Windows Server 2003 ou no SP 1 do Windows Server 2003 e o hotfix do artigo 921181 da Base de Dados de Conhecimento, Está disponível uma atualização que adiciona um recurso de testemunha de compartilhamento de arquivos e um recurso de pulsações de cluster configuráveis aos clusters de servidor baseados no Microsoft Windows Server 2003 Service Pack 1, as novas tentativas de pulsação da interface e as novas tentativas de pulsação de nó perdidas serão expostas como propriedades de configuração de cluster. Se você estiver instalando a CCR no Windows Server 2008, essa atualização não será necessária. Em qualquer dos casos, as pulsações continuam a ser enviadas a cada 1,2 segundos, mas o cluster pode ser configurado de modo que mais perdas devam ocorrer (seja de pacotes eliminados, latência excessiva, falha de interface ou falha de nó) antes que qualquer ação de recuperação seja executada. Os valores de propriedade estão em unidades de pulsações perdidas e não em tempo decorrido. Portanto, o cluster não pode ser configurado para suspeitar de uma falha de interface após cinco segundos. Ele pode ser configurado para suspeitar de uma falha de interface após cinco erros e, dependendo de quando a falha realmente ocorrer no período de pulsação, cinco erros serão equivalentes a aproximadamente entre cinco e seis segundos. Ambas as configurações têm um mínimo permitido de 2 segundos e um máximo permitido de 20 segundos.

Otimizando a rede do Windows 2003 para CCR

Ao utilizar CCR no Windows Server 2003, recomendamos otimizar as configurações TCP/IP do Windows Server da velocidade e latência dos links de rede específicos. 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 nos nós ativo e passivo. 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 CCR. Os dois nós devem usar IPsec ou nenhum nó deve usar 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 recebimento de TCP e opções de escala do 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 a canalização entre o emissor e o receptor. A capacidade de canalização da rede baseia-se na largura de banda da canalização e em sua latência (tempo de ida e volta). Quanto maior a latência, maior a capacidade da canalização da rede, pois haverá mais tempo para enviar os dados entre as confirmações. Aumentando o tamanho da janela de TCP, o sistema poderá aproveitar o tempo entre as confirmações para enviar 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.

Você pode otimizar o tamanho da janela de recebimento de TCP e das opções de escala da janela do RFC 1323 em um computador que esteja executando o Windows Server 2003, modificando as entradas do Registro: TCPWindowSize e TCP1323Opts. Para obter mais informações sobre esses recursos, consulte o artigo 224829 da Base de Dados de Conhecimento do Microsoft, Descrição dos recursos TCP Windows 2000 e Windows Server 2003.

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. Você pode baixar a calculadora do Blog da Equipe do Exchange aqui (página em inglês). A Calculadora de armazenamento inclui também instruções passo a passo para inserir os valores do Registro em seus servidores.

Expiração do 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 (página em inglês).

Recursos TCP/IP avançados do SNP (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. 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.

Esses recursos podem fornecer benefícios de desempenho da rede em alguns ambientes; entretanto, 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

• Segurança de Protocolo IPsec

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

• 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 o Blog da Equipe do Exchange lançado, o pacote Windows 2003 Scalable Networking e seus possíveis efeitos no Exchange.

Recomendamos desabilitar todos os recursos em ambientes CCR 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 desta forma:

• Para desabilitar o recurso de descarregamento TCP Chimney, abra um prompt de comando e execute o seguinte comando: Netsh int ip set chimney DISABLED

• Para desabilitar os outros recursos SNP, você pode definir os valores para os parâmetros de Registro TCP/IP EnableRSS e EnableTCPA como 0 no Registro do Windows. Para obter etapas detalhadas para fazer isso, consulte o artigo 936594 da Base de Dados de Conhecimento Microsoft, Você pode ter problemas relacionados à rede depois de instalar o Windows Server 2003 SP2 ou o Scalable Networking Pack em um computador baseado em Windows Server 2003.

• Para desabilitar esses recursos na(s) NIC(s) do sistema, consulte as instruções fornecidas com a NIC ou consulte o fornecedor do hardware.

Para obter mais informações sobre o SNP, consulte o artigo 912222 da Base de Dados de Conhecimento, A versão do Microsoft Windows Server 2003 Scalable Networking Pack e o site do Scalable Networking (página em inglês).

Comportamento do Outlook após o failover de Servidor de Caixas de Correio em Cluster em um cluster de failover de várias sub-redes

Quando ocorrer uma movimentação ou um failover para um CMS implantado em um cluster de failover geograficamente disperso e com várias sub-redes, o nome do CMS será mantido. No entanto, o endereço IP atribuído a esse nome não será mantido. A disponibilidade deste servidor para clientes e outros servidores depende da propagação do novo endereço IP em todo o DNS. Pode levar algum tempo para que a propagação de DNS ocorra. Por esse motivo, é recomendável que você defina o valor de vida útil (TTL) do registro de host DNS do CMS como 5 minutos (300 segundos). Para obter as etapas detalhadas da configuração do valor de TTL do DNS do CMS, consulte Como configurar valores de TTL de DNS para recursos de nome de rede. Depois de definir o valor TTL do DNS do CMS, você deve parar e, em seguida, iniciar o CMS para que a alteração entre em vigor.

Embora os clientes internos do Microsoft Office Outlook não precisem de perfis novos ou reconfigurados para se conectarem usando o novo endereço IP, eles precisam aguardar até que seus caches DNS locais sejam limpos para que a resolução de nomes do CMS seja movida do endereço IP antigo para o novo endereço IP. Depois que o endereço IP tiver sido propagado para os servidores DNS apropriados, você poderá limpar o cache DNS dos clientes Outlook executando o seguinte comando em um prompt de comandos do cliente:

ipconfig /flushdns

As seções a seguir ilustram o comportamento do Outlook em diferentes configurações.

CCR estendido no Windows Server 2003 (uma sub-rede)

Nessa configuração, existe um recurso Nome da Rede e um recurso Endereço IP no qual o recurso Nome da Rede é dependente. No DNS, o nome da rede está associado ao endereço IP. Todos os recursos, incluindo o recurso Endereço IP podem se mover entre os dois nós do cluster. Na perspectiva do Outlook, não ocorre nenhuma alteração no endereço IP, uma vez que a única alteração de rede no failover é a associação do endereço IP ao endereço MAC da máquina, que é transparente para os clientes.

CCR estendido no Windows Server 2008 (duas sub-redes, supondo IPv4)

Nessa configuração, existe um recurso Nome da Rede e dois endereços IP nos quais o Nome da Rede é dependente, como uma lógica "OR". No DNS, o nome da rede está associado ao endereço IP online atual. Durante o failover, à medida que o recurso Nome da Rede fica online, o serviço de Cluster atualiza a entrada de DNS para o Nome da Rede com o segundo endereço IP, que corresponde à outra sub-rede. A atualização do registro deve se propagar por todo o DNS. Na perspectiva do Outlook, o Outlook não precisa de um perfil novo ou reconfigurado, mas precisa aguardar a liberação do seu cache de DNS local para permitir que o Nome da Rede seja resolvido no outro endereço IP. Isso pode ser executado manualmente no cliente, digitando:

IPConfig /flushdns

CCR local com SCR no site remoto (uma ou duas sub-redes)

Nessa configuração, existe um recurso Nome da Rede e um recurso Endereço IP no qual o Nome da Rede é dependente. Todos os recursos, incluindo o Endereço IP, podem se mover entre os dois nós do cluster. No failover do site no qual o destino de SCR é ativado executando Setup.com /recoverCMS, o CMS é movido para um site/cluster diferente. Ao executar esse comando, você fornece o endereço IP que deveria estar associado ao Nome da Rede no site remoto. A configuração cria os recursos Nome da Rede e Endereço IP, e o serviço de Cluster atualiza o DNS com o novo endereço IP. A atualização do DNS deve se propagar por todo o DNS. Na perspectiva do Outlook, o Outlook não precisa de um perfil novo ou reconfigurado, mas precisa aguardar a liberação do seu cache de DNS local para permitir que o Nome da Rede seja resolvido no outro endereço IP. Isso pode ser executado manualmente no cliente, digitando:

IPConfig /flushdns

Requisitos de armazenamento para replicação contínua em cluster

A CCR é projetada para eliminar a necessidade de armazenamento compartilhado em um cluster do Windows. O armazenamento compartilhado foi um requisito de versões anteriores do Exchange. Os únicos requisitos de armazenamento da CCR são desempenho e capacidade suficientes do armazenamento aceito pelo Windows.

A CCR não faz considerações de E/S adicionais sobre o armazenamento usado pelos bancos de dados e grupos de armazenamento. Ao projetar sua solução de armazenamento de CCR, é recomendável que você siga estas práticas:

• Os locais dos grupos de armazenamento e dos bancos de dados devem ser idênticos em todos os nós de cluster.

• Armazene os arquivos de banco de dados e arquivos de log de transações em LUNs (números de unidades lógicas) diferentes.

• Use os pontos de montagem de volume do sistema de arquivo NTFS para reproduzir os volumes no sistema operacional.

• Use nomes reconhecíveis que possam ser ligados de forma direta e óbvia ao grupo de armazenamento ou banco de dados hospedado. Se volumes diferentes forem usados para logs e bancos de dados, os caminhos deverão identificar os tipos de dados. Esse método pode ajudar a evitar erros humanos à medida que aumenta o número de bancos de dados e grupos de armazenamento. Se a instalação padrão for executada, o grupo de armazenamento e os bancos de dados serão criados no local de instalação do Exchange 2007.

  Dica

  O Exchange 2007 não oferece suporte para a colocação de logs de transações ou arquivos de banco de dados na raiz de um volume.

Um ambiente de CCR exige armazenamento que forneça desempenho e capacidade adequados. Um armazenamento equivalente para desempenho e capacidade do sistema deve ser configurado nos dois nós usando o mesmo local (letra da unidade e caminhos) para cada grupo de armazenamento e banco de dados.

Tamanho do banco de dados e replicação contínua em cluster

A primeira linha de defesa contra falha de armazenamento catastrófica ou dano físico do banco de dados com CCR é reverter para a cópia passiva dos dados e não restaurar do backup. Isso diminui a importância de se ter RTOs (Recovery Time Objectives) curtos com base na restauração de arquivo ou fita. Em vez de restaurar pela fita, você ativa a cópia passiva de um banco de dados e os dados ficam disponíveis aos clientes em minutos, em vez de horas. Nesse sentido, a CCR pode ser considerada um mecanismo de recuperação rápida, colocando-a na mesma categoria de instantâneos baseados em hardware e clones criados com o VSS (Serviço de Cópias de Sombra de Volume) no Exchange Server 2003.

Não é incomum para um administrador ter de executar operações de banco de dados offline, como reparos, devido a backups inválidos (por exemplo, uma fita inválida ou falha na restauração). Com a CCR, essa situação é evitada e há muito menos chance de ser necessário executar reparos em um banco de dados. Embora a porcentagem de situações nas quais o reparo seja necessário deva diminuir consideravelmente, ainda haverá momentos em que ele será necessário. Verifique sua tolerância ao pior caso de inatividade ao decidir sobre o tamanho do banco de dados.

A CCR permite que você tenha janelas de manutenção online maiores. Como a CCR permite que você faça um backup pela cópia passiva de um grupo de armazenamento, você pode estender seu intervalo de manutenção online no nó de cluster ativo. Em muitos casos, é possível duplicar o intervalo de manutenção online, permitindo que você tenha caixas de correio e bancos de dados maiores.

Outro recurso do Exchange 2007, chamado LLR (Resiliência de Log Perdido), reduz drasticamente a ocorrência de inconsistência do banco de dados devido à perda de logs. Geralmente, o motivo mais comum para que um administrador repare um banco de dados é deixá-lo em um estado consistente quando houver perda ou dano de logs necessários, evitando, assim, a montagem do banco de dados. A LLR oferece resiliência para muitas dessas situações de log perdido e danificado, permitindo que um banco de dados seja montado sem a necessidade de executar reparo. Para obter mais informações sobre LLR, consulte Resiliência de log perdido e atividade do log de transações no Exchange 2007.

Nesse ponto, pode parecer que a replicação contínua permite que você aumente os bancos de dados o quanto desejar, sem nenhum risco. No entanto, não é isso o que acontece. A manutenção online concluída em um tempo razoável por banco de dados ainda é um fator limitante para o tamanho do banco de dados. Mas com a CCR, a possibilidade de precisar propagar novamente os bancos de dados também é um fator limitante. A CCR fornece redundância de banco de dados, de modo que, se a cópia ativa de um banco de dados for perdida ou danificada, a recuperação poderá ser realizada rapidamente ativando a cópia passiva do banco de dados. A CCR fornece ativação automática por meio do processo conhecido como failover.

Depois de ocorrer o failover, apenas uma cópia do banco de dados permanecerá, a nova cópia ativa. Como a cópia passiva não existirá mais, a resiliência do banco de dados poderá ficar comprometida. No entanto, você ainda terá seu backup. Para reabilitar a resiliência, o banco de dados perdido ou danificado precisará ser removido, e uma nova cópia passiva do banco de dados precisará ser criada e novamente propagada a partir da cópia ativa. Dependendo do tamanho do banco de dados, isso poderá levar muito tempo. A pior situação é a perda ou dano de todas as cópias ativas, em que todas as cópias passivas precisam ser novamente propagadas. Essa situação é uma das razões pelas quais recomendamos Gigabit Ethernet para ambientes de CCR.

Em um ambiente de CCR, as seguintes taxas no Gigabit Ethernet sem afunilamentos de disco ou processador são esperadas:

• Nova propagação em um único banco de dados: aproximadamente 25 megabytes (MB) por segundo

• Nova propagação em vários bancos de dados (em paralelo): aproximadamente 100 MB por segundo (limitado pela largura de banda da rede)

É possível um tamanho máximo de banco de dados maior quando a replicação contínua é usada. Recomendamos usar os seguintes tamanhos máximos de bancos de dados para o Exchange 2007:

• Bancos de dados hospedados em um servidor de Caixa de Correio sem replicação contínua: 100 gigabytes (GB)

• Bancos de dados hospedados em um servidor de Caixa de Correio com replicação contínua e Gigabit Ethernet: 200 GB

  Dica

  Bancos de dados grandes também podem exibir tecnologia de armazenamento mais recente para maior largura de banda para acomodar situações de reparo.

  Importante

  O tamanho máximo real para bancos de dados deve ser ditado pelo SLA (acordo de nível de serviço) vigente em sua organização. A determinação do banco de dados de maior tamanho cujo backup e restauração poderão ser feitos dentro do período especificado no SLA da organização é a forma de determinar o tamanho máximo de seus bancos de dados.

Requisitos do Active Directory para replicação contínua em cluster

A CCR tem todos os mesmos requisitos de infra-estrutura do Active Directory que um servidor independente tem, além de requisitos adicionais. Em uma solução de várias centrais de dados, as duas centrais de dados devem ter suporte de infra-estrutura de Active Directory adequado porque, a qualquer momento, qualquer uma das centrais de dados pode hospedar o servidor de caixas de correio clusterizadas. Esse recurso precisa estar presente mesmo se outras centrais de dados não estiverem disponíveis. Além disso, todos os nós do cluster devem estar no mesmo domínio, e a conta de Serviço de cluster deve ter as permissões apropriadas.

Requisitos de conta do serviço para replicação contínua em cluster

Se você estiver instalando a CCR no Windows Server 2008, a conta do Serviço de cluster será executada na conta LocalSystem (SYSTEM).

Se você estiver instalando a CCR no Windows Server 2003, use uma conta de domínio como a conta do Serviço de cluster. Todos os nós no cluster devem ser membros do mesmo domínio e devem usar a mesma conta de Serviço de cluster. A conta de Serviço de cluster também deve ser membro do grupo de administradores local em todos os nós que puderem hospedar um servidor de caixas de correio clusterizadas.

A conta de Serviço de cluster é responsável pela criação e manutenção da conta do computador, identificada pelo recurso Nome da Rede do cluster de failover e associada a ele, quando esse recurso fica online. Para verificar se a conta de Serviço de cluster possui as permissões apropriadas, consulte o artigo 307532 da Base de Dados de Conhecimento, Como solucionar problemas da conta do Serviço de cluster ao modificar objetos do computador. Informações adicionais podem ser encontradas no artigo 251335 da Base de Dados de Conhecimento, Usuários de domínio não podem ingressar em uma estação de trabalho ou o servidor em um domínio.

Replicação contínua de cluster e bancos de dados de pasta pública

A CCR e a replicação de pasta pública são duas formas 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 hospedados nos ambientes de CCR.

A seguir estão as configurações recomendadas para uso de bancos de dados de pasta pública e da CCR em sua organização do Exchange:

• Se você tiver um único servidor de Caixas de Correio em sua organização do Exchange e ele for um servidor de caixas de correio clusterizadas em um ambiente de CCR, o servidor de Caixas de Correio poderá hospedar um banco de dados de pasta pública. 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 CCR; a CCR mantém duas cópias do seu banco de dados de pasta pública.

• Se você tiver vários servidores de Caixa de Correio, poderá hospedar um banco de dados de pasta pública em um ambiente CCR desde que haja apenas um banco de dados de pasta pública em toda a organização do Exchange. Neste cenário, a redundância do banco de dados de pasta pública também é obtida usando a CCR. 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.

• Se você estiver migrando dados de pasta pública em um ambiente de CCR, 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 de caixas de correio autônomo ou em servidor de caixas de correio clusterizadas em um SCC para um servidor de caixas de correio clusterizadas em um ambiente de CCR. Depois que você criar um banco de pasta pública em um ambiente de CCR, os bancos de dados de pasta pública adicionais devem estar presentes somente se seus dados de pasta pública tiverem sido replicados completamente para o ambiente de CCR. Quando a replicação tiver sido concluída com êxito, todos os bancos de dados de pasta pública fora do ambiente de CCR devem ser removidos e você não deve hospedar nenhum banco de dados de pasta pública na organização do Exchange.

• Se você estiver migrando dados de pasta pública de um ambiente de CCR, 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 de caixas de correio clusterizadas em um ambiente de CCR para um servidor de caixas de correio autônomo ou um servidor de caixas de correio clusterizadas em um SCC. Depois de criar o banco de dados de pasta pública adicional fora do ambiente de CCR, o banco de dados de pasta pública no ambiente de CCR somente deve estar presente até que os dados de pasta pública tenham sido completamente replicados para os bancos de dados de pasta pública adicionais. Quando a replicação tiver sido concluída com êxito, todos os bancos de dados de pasta pública dentro de todos os ambientes de CCR devem ser removidos e todos os banco de dados de pasta pública subseqüentes não devem ser hospedados em grupos de armazenamento que estejam habilitados para replicação contínua.

Durante qualquer período em que mais de um banco de dados de pasta pública existir na organização do Exchange e um ou mais bancos de dados de pasta pública forem hospedados em um ambiente de CCR (como cenários de migração descritos anteriormente), considere as diferenças em comportamento para interrupções agendadas (sem perda) ou não agendadas (com perdas):

• Se ocorrer uma interrupção agendada sem perdas bem-sucedida, o banco de dados de pasta pública ficará online e a replicação de pasta pública continuará como esperado.

• Se ocorrer uma interrupção não agendada, o banco de dados de pasta pública não ficará online até que o servidor original esteja disponível e todos os logs do grupo de armazenamento que hospeda o banco de dados de pasta pública estiverem disponíveis. Se algum dado for perdido como resultado da interrupção, a CCR não permitirá que o banco de dados de pasta pública fique online quando a replicação de pasta pública estiver habilitada. Nesse caso, o nó original deve ser colocado online para garantir que não haja perda de dados, ou o banco de dados de pasta pública deve ser recriado no servidor de caixas de correio clusterizadas no ambiente de CCR e seu conteúdo deve ser recuperado usando a replicação de pasta pública de bancos de dados de pasta pública que estão fora do ambiente de CCR.

Backup, restauração e replicação contínua em cluster

Os backups sensíveis ao Exchange são aceitos em bancos de dados e grupos de armazenamento de cópia e de produção usando a tecnologia VSS. Backups de streaming têm suporte apenas no nó ativo.

As restaurações sensíveis ao Exchange para a cópia ativa também podem ser feitas usando streaming ou soluções de backup do VSS. As restaurações sensíveis ao Exchange não têm suporte para a cópia passiva.

Depois de restaurar um banco de dados a partir do backup em um grupo de armazenamento em um ambiente de CCR, você deve suspender e, em seguida, continuar a replicação contínua 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 do Microsoft Exchange terá informações desatualizadas da geração de log e parará de replicar os arquivos de log.

Somas de verificação de manutenção on-line e limpeza de página de banco de dados no Exchange 2007 SP1

Soma de verificação é o processo que verifica a integridade do banco de dados. Limpeza de página é o processo que zera os bancos de dados ao final de um backup de streaming. O Exchange 2007 RTM efetua somas de verificação de um banco de dados inteiro quando é feito um backup completo de streaming online de um banco de dados. Conforme mencionado anteriormente, em um ambiente de replicação contínua, os backups de streaming só podem ser feitos mediante a cópia ativa de um banco de dados. Não é possível fazer um backup de streaming de uma cópia passiva do banco de dados. O VSS pode ser usado para tirar instantâneos completos ou fazer clones completos de uma cópia passiva; além disso, é possível efetuar soma de verificação de instantâneos e clones completos. Normalmente, entretanto, em um ambiente de replicação contínua, apenas uma das cópias do banco de dados (a ativa ou a passiva) pode passar pela soma de verificação sem intervenção do administrador e tempo de inatividade. Isso ocorre porque:

• É complicado fazer backups de streaming de uma cópia ativa de um banco de dados e também fazer backups VSS da cópia passiva do mesmo banco de dados.

• Apesar de ser possível usar VSS para cópias ativas e passivas do banco de dados, isso contraria a recomendação de reduzir a carga das operações de backup da cópia ativa para a cópia passiva.

• A resiliência pode ser comprometida temporariamente porque a execução manual de verificações de integridade usando o Exchange Server Database Utilities (Eseutil) requer a suspensão da replicação contínua.

Para habilitar a limpeza de página e as somas de verificação em todas as cópias do banco de dados sem ter de experimentar ou ter de lidar com as questões mencionadas anteriormente, o Exchange 2007 SP1 apresenta dois novos recursos: Soma de verificação de banco de dados de manutenção online e Limpeza de página de banco de dados de manutenção online. Esses recursos permitem que um administrador efetue limpeza de páginas e somas de verificação de um banco de dados, em segundo plano. É possível habilitar cada um desses recursos separadamente ou em seqüência configurando manualmente valores de Registro no servidor de Caixa de Correio que contém os bancos de dados a serem examinados e, em seguida, reiniciando o serviço de Armazenamento de Informações do Microsoft Exchange. Os valores de Registro são configurados no nível de Armazenamento de Informações do Microsoft Exchange. Dessa forma, após a habilitação, todos os bancos de dados do servidor de Caixa de Correio executam a atividade de segundo plano configurada. As entradas de Registro disponíveis são descritas posteriormente neste tópico.

Habilitar a soma de verificação de banco de dados de manutenção online

Local: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Nome: Soma de verificação de manutenção online Tipo: REG_DWORD Valor: 0x00000001

Habilitar limpeza de página de banco de dados de manutenção online

Local: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Nome: Anular Páginas de Banco de Dados Durante a Soma de Verificação Tipo: REG_DWORD Valor: 0x00000001

Otimizar soma de verificação de banco de dados de manutenção online

Local: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Nome: Otimizar Soma de Verificação Tipo: REG_DWORD Valor: 0x00000000 (milissegundos)