Compartilhar via

Instalando replicação contínua em cluster no Windows Server 2008

  • Artigo

 

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

Tópico modificado em: 2008-12-19

Embora sejam semelhantes, os processos de implantação da CCR (replicação contínua em cluster) no Windows Server 2008 e no Windows Server 2003 apresentam algumas diferenças significativas. Antes de implantar a CCR, recomendamos a revisão completa de Replicação Contínua em Cluster. Além disso, verifique se você atende a todos os requisitos especificados em Planejando a replicação contínua em cluster.

A instalação da CCR no Windows Server 2008 ocorre em diversas fases:

  1. Instalação de hardware, começando com a formação e a configuração da rede de cluster.

  2. Formação de clusters, começando com o primeiro nó e, em seguida, com o segundo.

  3. Configuração de redes de cluster e de tolerância a pulsações de cluster perdidas.

  4. Configuração e proteção da testemunha de compartilhamento de arquivos.

  5. Instalação das funções de servidor Caixa de Correio ativa e passiva no cluster. O servidor de caixas de correio clusterizadas (CMS) será criado durante a instalação da função de servidor Caixa de Correio ativa.

    Dica

    Recomendamos que você conclua cada fase antes de iniciar a próxima fase. Após você concluir todas as fases, recomendamos a verificação da solução de CCR antes de colocá-la em produção.

Você também precisa executar algumas tarefas pós-instalação:

  • Ajustando as configurações de controle de failover.

  • Ajustando a configuração padrão do dumpster de transporte.

  • Verificando a capacidade de mover um CMS entre os nós do cluster.

  • Desabilitando várias redes para a atividade de replicação contínua.

Antes de executar qualquer um dos procedimentos mencionados, certifique-se de que os computadores pretendidos possuam os componentes de sistema operacional necessários para o Windows Server 2008 instalados. Para obter as etapas detalhadas sobre como instalar os pré-requisitos do Microsoft Exchange no Windows Server 2008, consulte Como instalar os pré-requisitos do Exchange 2007 SP1 e SP2 no Windows Server 2008 ou no Windows Vista.

As seções a seguir explicam cada uma das fases de instalação com mais detalhes.

Formação e configuração da rede

Você deve ter um número suficiente de endereços IP disponíveis ao criar CMSs em um ambiente CCR de dois nós no Windows Server 2008. O cluster de failover do Windows Server 2008 apresenta novos recursos de rede que representam uma das principais modificações em relação aos clusters herdados. Por exemplo, os clusters de failover do Windows Server 2008 oferecem suporte a várias sub-redes, protocolo DHCP, protocolo IP versão 4 (IPv4) e IPv6. Quando estiver sendo executado em um cluster de failover do Windows Server 2008, o Microsoft Exchange Server 2007 SP1 (Service Pack 1) inclui suporte para clusters geograficamente dispersos para failover através de duas sub-redes. Esse suporte inclui tanto os clusters de cópia única (SCCs) quanto os servidores de caixa de correio em um ambiente CCR.

Dica

Embora DHCP IPv4 seja compatível com clusters de failover do Windows Server 2008, recomendamos a utilização de endereços IP estáticos em ambientes de produção. Se DHCP IPv4 for usado em um cluster de failover, recomendamos que você configure os servidores DHCP para conceder comprimento ilimitado.

Começando com cluster de failover do Windows Server 2008, nós de cluster individuais agora podem ser localizados em redes roteadas e separadas. Isso requer que os recursos que dependem dos recursos Endereço IP (por exemplo, os recursos Nome de Rede) implementem uma lógica OR, pois é improvável que cada nó de cluster tenha uma conexão local direta com cada rede reconhecida pelo cluster. Isso facilita que recursos de Endereço IP e Nome de Rede fiquem online quando serviços ou aplicativos fizerem failover para nós remotos.

Todos os endereços IP online associados a um recurso Nome de Rede serão registrados dinamicamente no DNS (Sistema de Nomes de Domínio) (se configurados para atualizações dinâmicas), com a lista ordenada de modo que os recursos Endereço IP online sejam retornados primeiro aos clientes. Como nós de cluster podem ser colocados em redes roteadas e diferentes e os mecanismos de comunicação foram alterados para usar protocolos de sessão confiáveis implementados por protocolo UDP (unicast), os requisitos de rede para clusters dispersos geograficamente não se aplicam mais. Como resultado, as organizações podem implantar um cluster de failover em dois data centers físicos sem precisar usar tecnologia de LAN virtual (VLAN) para expandir as sub-redes de cluster nos dois locais.

Os endereços IP são necessários para redes públicas e particulares. Estes são os requisitos relacionados a endereços públicos e particulares:

  • Endereços particulares   Cada nó exige um endereço IP para cada adaptador de rede usado para a rede privada de cluster. É possível usar um endereço IPv4 estático ou um endereço IPv6 atribuído dinamicamente. Você deve usar endereços IP 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 255.255.255.0 como os endereços IP particulares para os nós.

  • Endereços públicos   Cada nó exige um endereço IP para cada adaptador de rede usado para a rede pública de cluster, às vezes chamada de rede mista. Além disso, os endereços IP são necessários para o cluster de failover e para o CMS, para que eles possam ser acessados por clientes e administradores. Você deve usar endereços IP que não estejam na mesma sub-rede ou rede que uma das redes privadas. Você pode usar endereços IPv4 estáticos, endereços DHCP IPv4 ou endereços IPv6 estáticos.

    Importante

    Todos os adaptadores de rede para uma rede de cluster devem usar a mesma versão de TCP/IP, ou seja, todos eles devem usar apenas IPv4 ou todos devem usar tanto IPv4 como IPv6.

Práticas recomendadas de rede para servidores de caixas de correio clusterizadas

Recomendamos também que você siga estas práticas recomendadas para a rede de cluster:

  • Usar nomes significativos   A criação de um cluster dá a você muitas oportunidades de usar nomes significativos para nós de cluster, interfaces de rede de cluster, nome do cluster e nomes de CMS. Por exemplo, a rede usada para comunicação com outros servidores e clientes Exchange pode ser chamada Pública. A rede usada para comunicação entre os nós de cluster pode ser chamada Particular. Use nomes que possam ser relacionados entre si sem que seja necessário consultar um mapa de topologia. Outra convenção útil é relacionar os nós de um cluster ao nome do CMS. Por exemplo, use mbx01, mbx01-node1 e mbx01-node2 para o CMS e os dois nós, respectivamente.

  • Usar endereços IP particulares para as interfaces de rede privada   Consulte a tabela a seguir para obter uma lista de intervalos de endereços IP e máscaras de sub-rede que podem ser usados para as interfaces de rede privada em cada nó.

    Intervalos de endereços e máscaras de sub-rede para interfaces de rede privada

    Rede / nó Intervalo de endereço IP Máscara de sub-rede

    Particular/NODE1

    10.10.10.10-255

    255.255.255.0

    Particular/NODE2

    10.10.10.11-255

    255.255.255.0

Observe o seguinte:

  • Se sua rede pública usar uma rede 10.x.x.x e uma máscara de sub-rede 255.255.255.0, recomendamos que você use endereços IP e máscara de sub-rede de rede privada alternativos.

  • Recomendamos não usar nenhum tipo de adaptador com tolerância a falhas ou agrupamento para a rede privada. Se for preciso redundância para sua rede privada, use vários adaptadores de rede configurados apenas para uso de cluster. É importante verificar se a versão do firmware e do driver é a mais recente, caso você use essa tecnologia. Para obter informações sobre a compatibilidade em um cluster de servidor, entre em contato com o fabricante do adaptador de rede. Para obter mais informações sobre agrupamento de adaptadores de rede em implantações de clusters de failover, consulte o artigo 254101 da Base de Dados de Conhecimento do Microsoft, Network adapter teaming and server clustering.

Formando o cluster de failover

Um cluster de failover é formado quando o primeiro nó é adicionado ao cluster. Esse processo fornece ao cluster um nome de rede e um endereço IP de rede exclusivos. O nome de rede e o endereço IP, que compõem coletivamente a identidade da rede do cluster, movem-se entre os nós do cluster à medida que os nós ficam online e offline. Geralmente, a identidade de rede do cluster é raramente usada na administração de um CMS.

Se estiver familiarizado com a implantação de clusters de failover ou de clusters do Exchange de versões anteriores, você achará a implantação de clusters para CCR algo completamente diferente. Se não tiver experiência em soluções de cluster, você achará a implantação muito menos complexa do que as configurações típicas de cluster.

Você pode criar um novo cluster usando as instruções descritas em Como criar um cluster de failover do Windows Server 2008 para replicação contínua em cluster.

Adicionando outros nós

Depois de instalar o Serviço de cluster no primeiro nó, você verá que levará menos tempo para instalá-lo no segundo nó. Isso ocorre porque o programa de instalação usa as definições de configuração de rede configuradas no primeiro nó como base para configurar as definições de rede nos nós subseqüentes. Antes de adicionar e configurar o segundo nó, você deve validar a configuração do cluster. Verifique se o serviço de Cluster está em execução e se o cluster está operacional, executando Cluster.exe group em um prompt de comando. O resultado deverá ser semelhante ao seguinte.

C:\>cluster group
Listing status for all available resource groups:
Group                   Node            Status
------------------ ---------------      ------
Cluster Group         <NODEName>        Online

Recomendamos ainda que você revise os logs de eventos em busca de erros e avisos que possam exigir mais atenção. Para obter as etapas detalhadas sobre como adicionar o segundo nó ao cluster, consulte Como criar um cluster de failover do Windows Server 2008 para replicação contínua em cluster.

Configurando as redes de cluster

Após a adição dos dois nós ao cluster, os componentes das redes de clusters devem ser configurados. Especificamente, você deve configurar redes para cluster e acesso de cliente, e também as definições de tolerância para as pulsações de cluster perdidas. Também recomendamos que você renomeie as redes de cluster com nomes mais significativos.

A tabela a seguir descreve em detalhes as opções disponíveis para a configuração de redes para a pulsação do cluster.

Opções para configurar as redes do cluster

Opção Descrição

Permitir que o cluster use esta rede (rede privada)

Selecione essa opção apenas se desejar que o Serviço de Cluster use exclusivamente essa rede para o tráfego de comunicação entre os nós. Os clientes não poderão se conectar ao CMS usando essa rede.

Permitir que o cluster use esta rede e permitir que os clientes se conectem através dela (rede mista)

Selecione essas duas opções se desejar que o Serviço de Cluster use o adaptador de rede para comunicação entre os nós de cluster e para comunicação com os clientes externos. O Serviço de Cluster usará essa rede para comunicação entre os nós e os clientes poderão usá-la para conexão com o CMS.

Não permitir que o cluster use esta rede (rede não gerenciada)

Selecione somente esta opção se não desejar usar a rede do cluster ou permitir que o serviço de Cluster gerencie a rede. O Serviço de Cluster não poderá usar essa rede para comunicação entre os nós e os clientes não poderão usá-la para conexão com o CMS.

Para que haja suporte aos CMSs implantados em um ambiente CCR, eles precisam de pelo menos duas placas de rede em ambos os nós. No Exchange 2007 SP1, qualquer rede que for gerenciada pelo serviço de Cluster e habilitada para uso do cluster e as conexões do cliente (por exemplo, configuradas como uma rede mista) podem ser usadas para funções de replicação contínua, incluindo propagação, envio de logs e repropagação. Isso é realizado usando um novo cmdlet no Exchange 2007 SP1 denominado Enable-ContinuousReplicationHostName.

Dica

Uma opção para configurar as redes de cluster é criar uma configuração de rede preliminar e, em seguida, executar o Assistente para Validar Configuração na ferramenta de Gerenciamento de Cluster de Failover apenas com os testes de rede selecionados (por exemplo, ignorar testes de Inventário, Armazenamento e Configuração do Sistema). Quando forem executados somente os testes de rede, o processo não demorará muito tempo. Usando o relatório de validação, você pode fazer todas as correções necessárias na configuração de rede. Depois que todo o cluster tiver sido configurado, recomendamos que você execute novamente o Assistente para Validar Configuração e selecione todos os testes.

Configurando definições de tolerância para pulsações de cluster perdidas

Após a configuração da comunicação do cluster e da prioridade da rede, recomendamos que você configure definições específicas de tolerância para pulsações de cluster perdidas. Esta ação configura o serviço de cluster que monitora a conectividade da rede entre os nós de cluster para que seja tolerante a interrupções mais breves. Isso impede a ocorrência de failovers em alguns casos em que a interrupção de energia na rede é breve. Recomendamos configurar redes de cluster mistas e privadas em todos os nós para que constituam dez pulsações perdidas. Esse nível de configuração corresponde a aproximadamente 12 segundos.

Para obter etapas detalhadas sobre como configurar os componentes de rede do cluster, consulte Como configurar redes de cluster para um cluster de failover.

Configurando as definições TTL para o recurso de nome de rede do servidor de caixas de correio clusterizadas

Existem dois cenários de implantação nos quais as opções de interrupção ou recuperação envolvem uma alteração do endereço IP atribuído ao CMS:

  • Um CMS é implantado em um ambiente com várias sub-redes.

  • Um cluster em espera é usado para recuperar um cluster com falha.

Em ambos os cenários, o nome do CMS não é alterado, mas o endereço IP atribuído ao CMS é. Os clientes e os outros servidores que se comunicam com um CMS cujos endereços IP foram alterados só poderão restabelecer as comunicações com o CMS quando o DNS tiver sido atualizado com o novo endereço IP e os caches DNS locais também tiverem sido atualizados. Para minimizar o tempo gasto para informar os clientes e os outros servidores sobre as alterações do DNS, é recomendável definir o valor TTL do DNS como cinco minutos para o recurso Nome da Rede do CMS.

Dica

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 também configurar um valor de TTL de cinco minutos para o recurso de Nome de Rede do cluster.

Por padrão, o serviço de Cluster usa uma configuração de 20 minutos para o valor DNS TTL de recursos de Nome de Rede. Embora as ferramentas de gerenciamento do DNS possam ser usadas para ajustar manualmente o valor TTL para o nome do host diretamente no banco de dados DNS, o valor no banco de dados DNS será substituído e definido para o padrão de serviço de Cluster de 20 minutos cada vez que o registro de nome de rede no DNS for atualizado. A atualização do registro de nome de rede no DNS ocorrerá sempre que o CMS for iniciado, movido ou colocado novamente online após uma falha ou um failover.

No Windows Server 2008, uma nova propriedade particular foi incluída nos recursos Nome de Rede dos clusters de failover. A nova propriedade é chamada HostRecordTTL e você pode configurá-la usando o Cluster.exe.

Dica

A propriedade está disponível somente nos clusters de failover Windows Server 2008. Não existe tal propriedade nos clusters de failover Windows Server 2003. Para os clusters de failover que executam o Windows Server 2003, o padrão de serviço de Cluster de 20 minutos será sempre aplicável.

Para obter etapas detalhadas sobre como configurar os valores de TTL de DNS do recurso de Nome de Rede do CMS a ser usado 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.

Configurando o Quorum do Cluster

Depois que as redes de cluster forem configuradas, a próxima etapa será configurar o cluster de failover para usar um recurso de quorum de Compartilhamento de Arquivo e de Nó Principais. Para obter etapas detalhadas sobre como configurar um cluster de failover para usar o modelo de quorum de Compartilhamento de Arquivo Principal e Nó, consulte Como Configurar o Quorum de Compartilhamento de Nós e Arquivos Principais.

Validando o Cluster de Failover

O Windows Server 2008 inclui um novo assistente chamado Assistente para Validar Configuração que você pode usar para verificar a integridade e a configuração de um cluster de failover. Recomendamos a execução do assistente antes de instalar o Exchange 2007 no cluster. Ao executar esse assistente antes de instalar o Exchange 2007, você pode identificar e endereçar os problemas de configuração no cluster que podem impedir que o Exchange seja instalado.

O Assistente para Validar Configuração contém quatro grupos de testes que foram projetados para verificar se o cluster atende aos requisitos necessários para ser aceito pelo Microsoft. Esses requisitos são complementares ao requisito que exige que a solução de cluster possua o logotipo de compatibilidade Projetado para o Windows Server 2008.

Os quatro grupos de teste são: Estoque, Rede, Armazenamento e Configuração do Sistema. Como o CCR não usa o armazenamento compartilhado, não há a necessidade de executar o grupo de Armazenamento de testes. Se você executar o grupo de Armazenamento de testes em um cluster de failover que não possui qualquer recurso de armazenamento clusterizado, como um cluster de failover projetado para CCR, o grupo de Armazenamento de testes falhará. Todas as falhas do grupo de Armazenamento de testes podem ser seguramente ignoradas porque a falta de armazenamento compartilhado é esperada para um cluster de failover projetado para CCR.

Para obter etapas detalhadas sobre como validar o cluster de failover, consulte Como validar uma configuração de cluster de failover.

Instalação e configuração do servidor de caixas de correio clusterizadas

Você pode instalar a função de servidor Caixa de Correio em um cluster executando algumas etapas em cada nó. Depois que o cluster for formado e validado e tiver sido configurado para usar o quorum de MNS (Conjunto de Nós Principais) com a testemunha de compartilhamento de arquivos, você deverá instalar primeiro a função de servidor Caixa de Correio no nó ativo. Para obter etapas detalhadas sobre como instalar a função de servidor Caixa de Correio no nó ativo, consulte Como instalar a função de Caixas de Correio Clusterizadas Ativas em um ambiente de CCR no Windows Server 2008.

Após instalar a função de servidor Caixa de Correio e um CMS no nó ativo e verificar a configuração do primeiro grupo de armazenamento, você deverá instalar a função de servidor Caixa de Correio no nó passivo. Para obter etapas detalhadas sobre como instalar a função de servidor Caixa de Correio no nó passivo, consulte Como instalar a Função de Caixas de Correio em Cluster Passivas em um ambiente de CCR no Windows Server 2008.

Após instalar a função de servidor Caixa de Correio, opcionalmente, você poderá ajustar as configurações de failover. Para obter mais informações sobre ajuste de failover, consulte Como ajustar as configurações de montagem e de failover para replicação contínua em cluster.

Tarefas pós-instalação

Após instalar a função de servidor Caixa de Correio nos dois nós e criar um CMS, você deverá executar algumas tarefas pós-instalação. Essas tarefas incluem:

  • Habilitando várias redes para atividade de replicação contínua.

  • Ajuste de configurações de controle de failover.

  • Ajuste da configuração padrão do dumpster de transporte.

  • Verificando a capacidade de mover um CMS entre os nós do cluster.

Habilitando várias redes para atividade de replicação contínua

Na versão RTM (Versão de Fabricação) do Microsoft Exchange Server 2007, toda a cópia e propagação de arquivo de log ocorre sobre a rede pública. No Exchange 2007 SP1, qualquer rede de cluster configurada como uma rede mista pode ser habilitada para atividade de replicação contínua. Essa atividade inclui propagação e repropagação em grupo e envio de logs.

No Exchange 2007 SP1, somente as redes do cluster designadas como mistas podem ser habilitadas para replicação contínua. Uma rede mista é qualquer rede do cluster configurada para tráfego de acesso ao cluster (comunicação entre nós) e para cliente. As redes do cluster configuradas para acesso ao cluster, mas não para acesso para cliente (às vezes, chamadas de redes privadas) não podem ser habilitadas para replicação contínua.

O suporte para envio de logs sobre uma rede mista é configurado usando um novo cmdlet denominado Enable-ContinuousReplicationHostName. De maneira similar, a desativação deste recurso é realizada usando o cmdlet Disable-ContinuousReplicationHostName. Depois que um CMS é criado em um ambiente CCR, um administrador pode executar Enable-ContinuousReplicationHostName nos dois nós do cluster e especificar dois endereços IP e nomes de host. Depois de fazer isso, o sistema seleciona aleatoriamente uma rede mista para cópia do log após a configuração bem-sucedida e confirmação de que a rede mista está operacional.

Para obter etapas detalhadas sobre como habilitar redes do cluster para atividade de replicação contínua, consulte Como habilitar redes redundantes de cluster para envio e propagação de log no Windows Server 2008.

Dica

Além do nome do host, do endereço IP e do grupo de cluster que é criado no cluster de failover, toda vez que você executa o cmdlet Enable-ContinuousReplicationHostName, você também está criando uma conta de computador no domínio do Active Directory que contém o CMS. Por padrão no Windows Server 2008, o número máximo de contas de computador que pode ser adicionado por um usuário, ao qual não tenham sido delegados privilégios de administrador de domínio e ao qual não tenham sido concedidas as ACEs (entradas de controle de acesso) Criar Objetos de Computador e Excluir Objetos de Computador, é 10. Um administrador do Exchange que execute freqüentemente os cmdlets Enable-ContinuousReplicationHostName e Disable-ContinuousReplicationHostName e que não possua privilégios de administrador de domínio ou as ACEs anteriormente mencionadas poderá atingir o limite de 10 contas rapidamente. Soluções alternativas para esse problema estão documentadas no artigo 307532 da Base de Dados de Conhecimento, How to troubleshoot the Cluster service account when it modifies computer objects. Informações adicionais podem ser encontradas no artigo 251335 da Base de Dados de Conhecimento, Domain Users Cannot Join Workstation or Server to a Domain.

A propagação e a nova propagação em um ambiente CCR são executadas com o cmdlet Update-StorageGroupCopy. No Exchange 2007 SP1, esse cmdlet foi estendido para incluir um novo parâmetro chamado DataHostNames. Esse parâmetro é usado para especificar qual rede deve ser usada para propagação ou nova propagação. O valor é uma lista com vários valores de dois nomes: um FQDN (nome de domínio totalmente qualificado) ou um nome de host. Um desses nomes deve identificar o nó passivo.

Ajustando as Configurações de Controle de Failover

A CCR inclui atributos que permitem controlar o comportamento de failover de um CMS. Configure esses atributos usando o cmdlet Set-MailboxServer. Esses atributos são fornecidos para que você possa controlar os dois algoritmos de decisão a seguir:

  • Algoritmo 1 O Algoritmo 1 controla se o banco de dados está montado no momento do failover. No tempo de failover, se for detectado que o banco de dados perdeu menos do que a quantidade de logs configurada, ele será montado automaticamente. O número aceitável de logs perdidos pode ser configurado com um valor chamado AutoDatabaseMountDial. Esse parâmetro, que é representado no Active Directory por um atributo do Exchange Server chamado msExchDataLossForAutoDatabaseMount, tem três valores: Lossless, Good Availability e Best Availability. Lossless indica 0 log perdido; Good Availability indica 3 logs perdidos; e Best Availability, que é o padrão, indica 6 logs perdidos. Para obter etapas detalhadas sobre como configurar esses valores, consulte Como ajustar as configurações de montagem e de failover para replicação contínua em cluster.

  • Algoritmo 2 O Algoritmo 2 permite que você determine se é mais importante estar online com dados antigos do que estar offline. Se a montagem do banco de dados falhar com base no algoritmo 1, você poderá estabelecer o tempo para realizar uma segunda verificação. O tempo de espera é configurado pelo atributo ForcedDatabaseMountAfter. O valor é definido em unidades de horas com o padrão ilimitado.

    Importante

    Quando o valor do ForcedDatabaseMountAfter for alcançado, o banco de dados será montado independentemente da cópia do grupo de armazenamento ter 1 log perdido, 10 logs perdidos ou 1.000 logs perdidos, os quais podem resultar em significativa perda de dados. Sendo assim, esse parâmetro não deve ser usado se os SLAs (acordos de nível de serviço) garantirem uma quantidade máxima de perda de dados possíveis.

Ajustando o Dumpster de Transporte

O dumpster de transporte é um recurso da função de servidor Transporte de Hub que deve ser configurado ao usar CCR (replicação contínua de cluster) local ou CCR, e esse recurso é usado apenas por ambientes LCR e CCR. O dumpster de transporte envia emails entregues recentemente após uma interrupção não agendada. O dumpster de transporte deve estar sempre ativado ao usar a LCR ou a CCR. O dumpster de transporte é habilitado em toda a organização definindo-se a quantidade de armazenamento disponível por grupo de armazenamento e o tempo de permanência da mensagem no dumpster de transporte.

O servidor de Transporte de Hub mantém uma fila de emails que foram entregues recentemente a um CMS. No caso de um failover com perdas, a CCR solicita automaticamente que todos os servidores de Transporte de Hub no site enviem novamente os emails da fila do dumpster de transporte. Em ambientes LCR, a solicitação para reenvio é executada como parte da tarefa Restore-StorageGroupCopy. Quando ocorre o reenvio, o armazenamento de informações exclui automaticamente as duplicatas e entrega novamente as mensagens perdidas. Você pode usar o cmdlet Set-TransportConfig para alterar as definições da configuração padrão do dumpster de transporte, aplicadas no nível de grupo de armazenamento. Como alternativa, no Exchange 2007 SP1, você também pode usar o Console de Gerenciamento do Exchange para configurar os valores de dumpster de transporte.

Recomendamos que você configure o tamanho máximo por grupo de armazenamento (o parâmetro MaxDumpsterSizePerStorageGroup) para um tamanho que é 1,5 vezes o tamanho da mensagem máxima que pode ser enviada. Por exemplo, se o tamanho máximo das mensagens for 10 megabytes (MB), configure o parâmetro MaxDumpsterSizePerStorageGroup com um valor igual a 15 MB. Em organizações sem tamanho máximo de mensagem, recomendamos a configuração do tamanho máximo por grupo de armazenamento com um valor de 1,5 vezes o tamanho médio de mensagens da organização.

Também recomendamos configurar o tempo de retenção máxima por grupo de armazenamento (o parâmetro MaxDumpsterTime) para um valor 07.00:00:00, que é de 7 dias. Esse tempo é suficiente para que uma interrupção estendida ocorra sem perda de emails. Ao usar o recurso do dumpster de transporte, é necessário que haja espaço adicional em disco no servidor de Transporte de Hub para hospedar as filas do dumpster de transporte. A quantidade de espaço de armazenamento necessária é aproximadamente igual ao valor de MaxDumpsterSizePerStorageGroup multiplicado pelo número de grupos de armazenamento em todos os servidores de caixa de correio que usam a replicação contínua no site do Active Directory que contém o servidor de Transporte de Hub.

Para obter etapas detalhadas sobre como habilitar e configurar o dumpster de transporte, consulte Como configurar o dumpster de transporte.

Verificando a solução de CCR

Depois de concluir a instalação de uma solução de CCR ou de fazer alterações significativas na configuração, recomendamos que você verifique a integridade e o status do CMS e se os dois nós estão corretamente configurados para oferecer suporte ao CMS.

A maneira recomendada para verificar a integridade e o status do CMS é executar os cmdlets Test-ReplicationHealth, Get-StorageGroupCopyStatus e Get-ClusteredMailboxServerStatus:

  • O cmdlet Test-ReplicationHealth é novo no Exchange 2007 SP1. Esse cmdlet foi desenvolvido para o monitoramento proativo da replicação contínua e do pipeline de replicação contínua. O cmdlet Test-ReplicationHealth verifica todos os aspectos da replicação, os serviços de Cluster e a replicação do grupo de armazenamento e o status de repetição para fornecer uma visão geral completa do sistema de replicação. Para obter mais informações sobre o cmdlet Test-ReplicationHealth, consulte Test-ReplicationHealth.

  • O cmdlet Get-StorageGroupCopyStatus fornece informações atuais sobre o status de replicação de cada grupo de armazenamento. Para obter etapas detalhadas sobre como exibir o status de grupos de armazenamento em um ambiente CCR, consulte Como exibir o status de uma cópia de replicação contínua de cluster usando o Shell de Gerenciamento do Exchange.

  • O cmdlet Get-ClusteredMailboxServerStatus fornece o status operacional básico do CMS. Para obter etapas detalhadas sobre como saber o status operacional básico de um CMS, consulte Como exibir o status de um servidor de caixas de correio em cluster.

A maneira recomendada de verificar se os dois nós são capazes de colocar o CMS online é usar o cmdlet Move-ClusteredMailboxServer para mover o CMS para cada nó. No Exchange 2007 SP1, você também pode usar o Assistente de Gerenciamento de Servidor de Caixas de Correio Clusterizadas no Console de Gerenciamento do Exchange para mover um CMS entre nós, e assim verificar se ambos os nós podem colocar o CMS online.