Alta disponibilidade

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

Tópico modificado em: 2009-04-01

Esta área de conteúdo de alta disponibilidade contém tópicos que podem ser usados para projetar, criar e operar um sistema de mensagens altamente disponível com base na versão RTM do Microsoft Exchange Server 2007 e do Exchange 2007 Service Pack 1 (SP1). A documentação nessa área inclui:

• Estratégias de alta disponibilidade

• Site Resilience Configurations

• Replicação contínua local

• Replicação Contínua em Cluster

• Replicação Contínua Em Espera

• Clusters de cópia única

• Instalação delegada do servidor de caixas de correio clusterizadas

• Atualizando servidores de caixas de correio em cluster para o Exchange 2007 SP1 ou SP2

• Aplicando os pacotes cumulativos de atualização do Exchange 2007 em servidores de caixas de correio clusterizadas

• Desinstalando servidores de caixa de correio em cluster

• Monitorando a replicação contínua

• Solucionando problemas de implantações de alta disponibilidade

É recomendável que você revise a documentação aplicável antes de criar e implantar uma solução de sistema mensagens altamente disponível com base no Exchange 2007 SP1.

A documentação dessa área foi atualizada para incluir as recomendações mais recentes e as práticas recomendadas para a implantação do Exchange 2007 SP1 no Windows Server 2008 e no Windows Server 2003 Service Pack 2 (SP2).

Alta disponibilidade para o Exchange Server 2007

Embora os requisitos mínimos de tempo de ativação variem entre as organizações, cada organização visa alcançar um alto nível desse tempo. As organizações para as quais as mensagens são fundamentais para os negócios optam por projetar um sistema de mensagens com alta disponibilidade para fornecer tempo de ativação.

O Exchange 2007 RTM e o Exchange 2007 SP1 incluem os seguintes recursos internos que podem fornecer recuperação rápida, alta disponibilidade e resiliência de site a servidores de caixa de correio do Exchange 2007:

• Replicação contínua local (LCR)   A LCR é uma solução de servidor único que usa tecnologia interna assíncrona de envio de logs para criar e manter uma cópia de um grupo de armazenamento em um segundo conjunto de discos conectados ao mesmo servidor do grupo de armazenamento de produção. A LCR fornece envio de logs, repetição de logs e uma troca manual rápida para uma cópia secundária dos dados.

• Replicação contínua em cluster (CCR)   A CCR, que é uma solução de cluster de failover de armazenamento não compartilhado, é um dos dois tipos de implantação de servidor de caixas de correio clusterizadas (CMS) disponíveis no Exchange 2007. A CCR é uma solução em cluster (chamada de ambiente CCR) que usa tecnologia interna assíncrona de envio de logs para criar e manter uma cópia de cada grupo de armazenamento em um segundo servidor de um cluster de failover. A CCR é criada para ser uma solução de um ou dois data centers, fornecendo alta disponibilidade e resiliência de site. A CCR é muito diferente dos clusters das versões anteriores do Exchange Server. Para obter detalhes sobre algumas das diferenças, consulte Recursos de cluster do Exchange para servidores de caixas de correio em cluster e Comportamento de recuperação de Replicação Contínua em Cluster.

• Replicação contínua em espera (SCR)   A SCR é um novo recurso apresentado no Exchange 2007 SP1. Como o próprio nome diz, a SCR foi projetada para cenários que usem ou habilitem o uso de servidores de recuperação em espera. A SCR estende os recursos de replicação contínua existentes e permite novos cenários de disponibilidade de dados para servidores de Caixa de Correio do Exchange 2007. A SCR usa a mesma tecnologia de envio de logs e repetição usada pela LCR e pela CCR para fornecer mais configurações e opções de implantação, permitindo que o administrador crie cópias de grupos de armazenamento adicionais. A SCR pode ser usada para replicar dados de servidores de caixas de correio autônomas e servidores de caixas de correio clusterizadas.

• Clusters de cópia única (SCC)   O SCC, uma solução de cluster de failover de armazenamento compartilhado, é o outro tipo de implantação de servidor de caixas de correio clusterizadas disponível no Exchange 2007. O SCC é uma solução clusterizada que usa uma cópia única de um grupo de armazenamento compartilhado entre os nós do cluster. O SCC tem algumas semelhanças com os clusters de versões anteriores do Exchange Server. No entanto, juntamente com vários aprimoramentos, há também algumas alterações significativas. Para obter detalhes sobre algumas dessas alterações, consulte Modelo de recurso de cluster de cópia única e Comportamento da recuperação do Cluster de Cópia Única.

Para obter detalhes sobre outros recursos de disponibilidade e funcionalidade introduzidos no SP1, consulte Novos recursos de alta disponibilidade do Exchange 2007 SP1.

Alta disponibilidade para servidores de caixa de correio

Há duas opções de alta disponibilidade para servidores de caixa de correio: disponibilidade de serviço e disponibilidade de dados. A disponibilidade de serviço é fornecida por meio do uso de um cluster de failover do Windows Server. A disponibilidade de dados é fornecida por meio de um recurso interno chamado replicação contínua.

Servidores de caixas de correio clusterizadas

Tanto a CCR quanto o SCC são soluções implantadas em um cluster de failover do Windows Server. Somente a função de servidor Caixa de Correio pode ser instalada em um cluster de failover. Nenhuma outra função pode ser instalada em um cluster de failover. Um servidor de caixa de correio implantado em um cluster de failover é denominado servidor de caixas de correio clusterizadas. Os servidores de caixas de correio clusterizadas em execução em um ambiente CCR são muito diferentes dos servidores de caixas de correio clusterizadas em execução em um ambiente SCC. Além disso, os servidores de caixas de correio clusterizadas do Exchange 2007 RTM e do Exchange 2007 SP1 são muito diferentes dos servidores de caixa de correio clusterizadas de versões anteriores do Microsoft Exchange.

Você pode usar Get-MailboxServer <CMSName> | fl Name, ClusteredStorageType no Shell de Gerenciamento do Exchange para determinar se um servidor de caixas de correio clusterizadas está hospedado em um ambiente de CCR ou em um SCC. O valor NonShared indica que o servidor de caixas de correio clusterizadas está em um ambiente de CCR e o valor Shared indica que o servidor de caixas de correio clusterizadas está em um SCC. O valor Disabled indica que o servidor de Caixa de Correio é um servidor autônomo.

Você também pode verificar o Active Directory para determinar se um servidor de caixas de correio clusterizadas está hospedado em um ambiente de CCR ou em um SCC, examinando o valor do atributo msExchClusterStorageType do objeto de servidor de caixas de correio. O valor 1 para o atributo msExchClusterStorageType indica que o servidor de caixas de correio clusterizadas está hospedado em um ambiente de CCR. O valor 2 indica que o servidor de caixas de correio clusterizadas está em um SCC. O valor <Não Definido> indica que o servidor de Caixa de Correio é um servidor autônomo.

Ambientes CCR

O Exchange 2007 RTM e o Exchange 2007 SP1 oferecem suporte a no máximo dois nós com a função de servidor Caixa de Correio instalada (um ativo e um passivo) em um ambiente CCR. Também há suporte para um cluster de failover de três nós que use um nó de eleitor e um quorum de Conjunto de Nós Principais tradicional; no entanto,esse não é o modelo de cluster preferencial. Recomendamos que os clientes implantem ambientes CCR que usem apenas dois nós; e um quorum Maioria dos Nós e Compartilhamentos de Arquivos (Windows Server 2008) ou um quorum Conjunto de Nós Principais com Testemunha de Compartilhamento de Arquivos (Windows Server 2003). Portanto, a documentação sobre CCR é direcionada aos clusters de failover de dois nós que usam um desses modelos de quorum.

Clusters de Cópia Única

O Exchange 2007 RTM e o Exchange 2007 SP1 oferecem suporte a no máximo oito nós em um SCC. Combinações válidas de SCCs do Exchange 2007 SP1 em clusters de failover do Windows Server incluem:

• 7 Ativos/1 Passivo

• 6 Ativos/1 ou 2 Passivos

• 5 Ativos/1, 2 ou 3 Passivos

• 4 Ativos/1, 2, 3 ou 4 Passivos

• 3 Ativos/1, 2, 3, 4 ou 5 Passivos

• 2 Ativos/1, 2, 3, 4, 5 ou 6 Passivos

• 1 Ativo/ 0, 1, 2, 3, 4, 5, 6 ou 7 Passivos

  Dica

  A versão de 64 bits do Windows Server 2008 oferece suporte a 16 nós em um cluster de failover único. No entanto, o Exchange 2007 oferece suporte a no máximo oito nós no cluster. O cluster de failover ainda pode conter até 16 nós, mas o Exchange 2007 deve ser instalado em no máximo oito nós do cluster de failover.

Normalmente, não há necessidade de mais de um nó passivo para cada nó ativo no cluster. Como resultado, uma configuração de um nó ativo e um nó passivo é preferencial em comparação a configurações com um nó ativo e vários nós passivos. Ao usar um SCC de um único nó, você poderá usar um quorum de armazenamento compartilhado ou um quorum Conjunto de Nós Principais (tradicional, sem testemunha de compartilhamento de arquivos). Embora haja suporte para SCCs de um único nó, eles não são considerados uma solução de alta disponibilidade, pois não existe redundância no cluster.

Cluster estendido

Um cluster estendido, também conhecido como cluster disperso geograficamente, é um cluster de failover que é estendido, ou seja, abrange, mais de um data center físico. Os clusters estendidos podem ser usados como parte de um design de resiliência de site para sua organização do Exchange. Como a CCR não utiliza armazenamento compartilhado, ela pode ser facilmente implantada em um cluster de failover disperso geograficamente, incluindo um cluster estendido de várias sub-redes, no Windows Server 2008. O SCC também é aceito em um cluster estendido; no entanto, para estender o SCC é necessária tecnologia de replicação sincronizada de terceiros. Para obter mais informações sobre clusters estendidos, consulte Site Resilience Configurations.

Cluster em espera

O Exchange 2007 e o Exchange 2007 SP1 também oferecem suporte ao cluster chamado cluster em espera. Um cluster em espera é um cluster de failover do Windows Server que não contém um servidor de caixas de correio clusterizadas, mas pode ser rapidamente configurado com um servidor de caixas de correio clusterizadas de substituição caso ocorra um desastre, outra falha do cluster de failover de produção ou algum outro cenário de recuperação.

Replicação contínua

A replicação contínua, também conhecida como envio de logs, é o processo de automatização da replicação de arquivos de log de transação fechada de um grupo de armazenamento de produção para uma cópia desse grupo de armazenamento localizada em um segundo conjunto de discos no computador local ou em um servidor totalmente distinto. Depois de serem copiados para o segundo local, os arquivos de log serão repetidos na cópia do banco de dados. Dessa forma, os grupos de armazenamento permanecerão sincronizados, com um pequeno atraso.

A replicação contínua está disponível em duas formas no Exchange 2007 RTM (LCR e CCR) e em três formas no Exchange 2007 SP1 (LCR, CCR e SCR).

Alta disponibilidade para outras funções do servidor

A alta disponibilidade das funções de servidor Unificação de Mensagens, Acesso para Cliente, Transporte de Borda e Transporte de Hub é obtida por meio de uma combinação de redundância de servidor, Balanceamento de Carga da Rede (NLB), balanceamento de carga de hardware e round robin de DNS, bem como gerenciamento pró-ativo de servidor, serviço e infra-estrutura. Geralmente, você pode obter alta disponibilidade para as funções de servidor Acesso para Cliente, Transporte de Hub, Transporte de Borda e Unificação de Mensagens usando as seguintes estratégias e tecnologias:

• Transporte de Borda Você pode implantar vários servidores de Transporte de Borda e usar vários registros de troca de mensagens (MX) do DNS para equilibrar a carga de atividade entre os servidores. Também é possível usar o NLB para fornecer balanceamento de carga e alta disponibilidade para servidores de Transporte de Borda.

• Acesso para Cliente   Você pode usar o NLB ou um dispositivo de terceiros de balanceamento de carga da rede baseado em hardware para obter alta disponibilidade do servidor de Acesso para Cliente. Para obter mais informações sobre NLB, consulteWindows Server TechCenter.

• Transporte de Hub É possível implantar vários servidores de Transporte de Hub para obter alta disponibilidade de transporte interno. A resiliência foi criada na função de servidor Transporte de Hub da seguinte maneira:

  • Servidor de Transporte de Hub para servidor de Transporte de Hub (intra-org)   A comunicação de servidor de Transporte de Hub para servidor de Transporte de Hub em uma organização executa automaticamente o balanceamento de carga entre os servidores de Transporte de Hub disponíveis no site de serviços de diretório de destino do Active Directory.

  • Servidor de Caixa de Correio para servidor de Transporte de Hub (intra-sites do Active Directory)   Os serviços de Envio de Mensagens do Microsoft Exchange nos servidores de Caixa de Correio executam automaticamente o balanceamento de carga entre todos os servidores de Transporte de Hub disponíveis no mesmo site do Active Directory.

  • Servidor de Unificação de Mensagens para servidor de Transporte de Hub   O servidor de Unificação de Mensagens executa automaticamente o balanceamento de conexões entre todos os servidores de Transporte de Hub disponíveis no mesmo site do Active Directory.

  • Servidor de Transporte de Borda para servidor de Transporte de Hub   O servidor de Transporte de Borda executa automaticamente o balanceamento de carga entre o tráfego de entrada de SMTP e todos os servidores de Transporte de Hub do site do Active Directory nos quais o servidor de Transporte de Borda está inscrito.

  Para redundância adicional (por exemplo, aplicativos que exigem a relé SMTP), você pode criar um novo registro DNS (por exemplo, relay.company.com), atribuir um endereço IP e usar um balanceador de carga de hardware para redirecionar esse endereço IP para vários servidores de Transporte de Hub. No Exchange 2007 SP1, você também pode usar NLB para os conectores de cliente nos servidores de Transporte de Hub. Ao usar um balanceador de carga de hardware, você precisa confirmar que nenhum tráfego intra-org do Exchange 2007 esteja cruzando o balanceador de carga de hardware, pois o tráfego intra-org usa algoritmos internos de balanceamento de carga (como descrito anteriormente). Para obter mais informações sobre balanceamento de carga e servidores de transporte, consulte Opções de implantação de servidores de Transporte de Hub e Equilíbrio de carga e tolerância a falhas para servidores de Transporte.

• Unificação de Mensagens   Implantações de Unificação de Mensagens podem se tornar mais resilientes com a implantação de vários servidores de Unificação de Mensagens, em que dois ou mais estão em um único plano de discagem. Os gateways VoIP aceitos pela Unificação de Mensagens podem ser configurados para rotear chamadas para servidores de Unificação de Mensagens no estilo round robin. Além disso, esses gateways podem recuperar no DNS a lista de servidores de um plano de discagem. Em qualquer um dos casos, os gateways VoIP apresentarão uma chamada para um servidor de Unificação de Mensagens e, se não for aceita, será apresentada a outro, oferecendo redundância no momento em que é estabelecida a chamada.

Obtendo alta disponibilidade com redundância de dados e serviços

A premissa básica da arquitetura de alta disponibilidade do Exchange 2007 é introduzir a redundância na implantação. Uma falha é recuperada com o uso dos recursos restantes de computação para suporte aos serviços do Exchange. À medida que as falhas são reparadas, os recursos de computação são disponibilizados novamente para o Exchange e seus clientes. Nesse contexto, os recursos de computação podem ser computadores ou armazenamento para caixa de correio, ou outros dados do Exchange.

A redundância pode ser introduzida em um único data center. Geralmente, essa abordagem é usada para proteção contra falha de servidor individual. Por exemplo, a introdução de um segundo servidor de Transporte de Hub no data center principal de sua organização permitirá que o fluxo de mensagens continue se um dos dois servidores falhar.

Como alternativa, ou além disso, a redundância poderia ser introduzida em um data center secundário. Configurações de dois data centers permitem a continuidade de serviço após uma falha do data center. Se um servidor de Transporte de Hub adicional for introduzido em um data center secundário, haverá oportunidade de o segundo servidor de Transporte de Hub manipular o fluxo de mensagens quando o primeiro falhar ou quando o data center de produção estiver indisponível. Se três servidores de Transporte de Hub forem implantados, dois deles poderão ficar no data center de produção e o terceiro, no data center secundário.

O ponto de implantação mais importante é que a redundância pode evitar interrupções que, sem ela, resultam em uma série de falhas. O modo de implantação dos computadores e dos serviços de redundância determina as falhas que podem ocorrer sem afetar a disponibilidade de serviços ou dados. As organizações devem compreender suas próprias exigências e depois examinar os problemas operacionais para encontrar a melhor solução. Por exemplo, uma organização pode preferir ativar um data center de backup somente após uma falha de 20 minutos no data center de produção. Nesse caso, a organização deverá ter os processos necessários para validar regularmente a ativação e a operação do data center de backup. Outra organização pode decidir que a validação contínua do data center de backup é fundamental para seu sucesso, levando assim a uma configuração de implantação diferente para essa organização.