Partilhar via

Implantando a alta disponibilidade e resiliência do site

  • Artigo

 

Aplica-se a: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Tópico modificado em: 2015-03-09

Para criar um servidor de caixa de correio de alta disponibilidade em versões anteriores do Exchange, você teria que instalar o Exchange em um servidor configurado como membro de um cluster de failover do Microsoft Windows. Se você quisesse um servidor de Caixa de Correio de alta disponibilidade, tinha que criar e configurar o cluster antes de executar a Instalação do Exchange. O programa de Instalação do Exchange (e outros componentes do Exchange, como o armazenamento do Exchange e o serviço de Atendedor do Sistema do Microsoft Exchange) era sensível ao cluster e se comportava de maneira diferente de quando executado em um servidor independente. Se o Exchange já estivesse instalado em um servidor do Windows independente, não havia a possibilidade de se configurar esse servidor para a alta disponibilidade sem remover primeiro o Exchange, criar um cluster e reinstalar o Exchange usando a versão sensível ao cluster do programa de Instalação.

O Microsoft Exchange Server 2010 usa o conceito conhecido como implantação incremental tanto para alta disponibilidade quanto para resiliência de site. Ao contrário das versões anteriores, o Exchange 2010 não usa mais o modelo de recurso de cluster para alta disponibilidade. O resultado dessa mudança na arquitetura é que não há mais uma versão do programa de Instalação sensível ao cluster, e a alta disponibilidade não é mais configurada durante a Instalação. Em vez disso, você simplesmente instala os servidores do Exchange 2010 como servidores independentes e configura incrementalmente servidores de caixa de correio e bancos de dados de caixa de correio para alta disponibilidade e resiliência de site, conforme a necessidade.

Visão geral do processo de implantação

As etapas a serem seguidas em cada organização podem variar um pouco, mas o processo geral de implantação do Exchange 2010 em uma configuração de alta disponibilidade ou de resiliência de site geralmente é o mesmo. Depois de realizar as tarefas de planejamento e design para a criação e a implantação de um grupo de disponibilidade de banco de dados (DAG) e a criação de cópias de banco de dados de caixa de correio, você poderá:

  1. Criar um DAG. Para instruções detalhadas, consulte Criar um Grupo de Disponibilidade de Banco de Dados.

  2. Se necessário, configure previamente o objeto de nome de cluster (CNO). A configuração prévia do CNO é necessária quando se implanta um DAG com servidores de Caixa de Correio que executam o Windows Server 2012. Essa configuração prévia também é necessária em ambientes em que a criação da conta do computador é restrita ou em que as contas do computador são criadas em um contêiner que não seja o contêiner padrão do computador. Para obter etapas detalhadas, consulte Prepare o objeto de nome de cluster para um grupo de disponibilidade do banco de dados.

  3. Adicionar dois ou mais servidores de caixa de correio ao DAG. Para instruções detalhadas, consulte Gerenciar a Associação no Grupo de Disponibilidade de Banco de Dados.

  4. Configurar as propriedades do DAG conforme a necessidade:

    1. Uma opção é configurar a criptografia e a compactação do DAG, a porta de replicação, os endereços IP do DAG e outras propriedades do DAG. Para instruções detalhadas, consulte Configurar as Propriedades do Grupo de Disponibilidade do Banco de Dados.

    2. Se o DAG contiver três ou mais servidores de caixa de correio implantados em vários sites do Active Directory, o modo Coordenação de Ativação de Datacenter (DAC) deve ser habilitado. Para mais informações, consulte Noções Básicas Sobre o Modo Coordenação de Ativação do Datacenter.

    3. Para instruções detalhadas sobre como criar uma rede DAG, consulte Criar uma Rede de Grupo de Disponibilidade de Banco de Dados. Para gerenciar uma rede DAG, consulte Configurar Propriedades de Rede do Grupo de Disponibilidade de Banco de Dados.

  5. Adicionar cópias de banco de dados de caixa de correio entre servidores de caixa de correio no DAG. Para instruções detalhadas, consulte Adicionar uma Cópia do Banco de Dados de Caixa de Correio.

Exemplo de Implantação: DAG de Quatro membros em Dois Datacenters

Este exemplo detalha como uma organização, como a Contoso Ltd., configura e implanta um DAG de quatro membros que se estenderá por dois locais físicos: um datacenter principal, chamado de SITEA do Active Directory, e um segundo datacenter, chamado de SITEB do Active Directory. O SITEA está localizado em Redmond, Washington, e o SITEB está localizado em Dublin, Irlanda.

Infraestrutura de base

Cada local contém os elementos de infraestrutura necessários à operação de uma infraestrutura de mensagens baseada no Exchange 2010, notadamente:

  • Serviços de diretório (Active Directory ou Serviços de Domínio do Active Directory Domain Services (AD DS))

  • Resolução de nomes DNS

  • Um ou mais servidores de Acesso para Cliente do Exchange 2010

  • Um ou mais servidores de Transporte de Hub do Exchange 2010

  • Um ou mais servidores de Caixa de Correio do Exchange 2010

Dica

As funções de servidor Acesso para Cliente, Transporte de Hub e Caixa de Correio podem estar co-localizadas em um único computador. Nesta implantação de exemplo, as funções de servidor estão instaladas em computadores separados.

A figura a seguir ilustra a configuração da Contoso.

O grupo de disponibilidade de banco de dados se estende por dois sites

Grupo de Disponibilidade de Banco de Dados em Dois Sites

Exceto pelos servidores de Caixa de Correio, todos os servidores no ambiente da Contoso estão executando o sistema operacional Windows Server 2008 R2 Standard. Os servidores de Caixa de Correio, que foram planejados tendo os DAGs em mente, estão executando o Windows Server 2008 R2 Enterprise.

Além dos componentes de infraestrutura precedentes, cada local contém outros elementos de mensagens, como servidores de Transporte de Borda e servidores de Unificação de Mensagens.

Configuração de rede

Como mostra a figura anterior, a solução envolve o uso de várias redes e sub-redes. Cada servidor de Caixa de Correio no DAG tem dois adaptadores de rede em sub-redes separadas. Em cada servidor de caixa de correio, um adaptador de rede será usado para a rede MAPI (192.168.x.x) e um adaptador de rede será usado para a rede de Replicação (10.0.x.x). Apenas a rede MAPI oferece conectividade ao Active Directory, aos serviços de DNS e a outros servidores e clientes do Exchange. O adaptador usado para a rede de Replicação em cada membro oferece conectividade apenas para adaptadores de rede de Replicação em outros membros do DAG.

As configurações de cada adaptador de rede de cada nó são detalhadas na tabela a seguir.

Nome Endereço IPv4 Máscara de sub-rede Gateway padrão

MBX1A (MAPI)

192.168.1.4

255.255.255.0

192.168.1.1

MBX2A (MAPI)

192.168.1.5

255.255.255.0

192.168.1.1

MBX1B (MAPI)

192.168.2.4

255.255.255.0

192.168.2.1

MBX2B (MAPI)

192.168.2.5

255.255.255.0

192.168.2.1

MBX1A (replicação)

10.0.1.4

255.255.0.0

Nenhum

MBX2A (replicação)

10.0.1.5

255.255.0.0

Nenhum

MBX1B (replicação)

10.0.2.4

255.255.0.0

Nenhum

MBX2B (replicação)

10.0.2.5

255.255.0.0

Nenhum

Como mostra a tabela anterior, os adaptadores usados para redes de Replicação não usam gateways-padrão. Para proporcionar conectividade de rede entre cada adaptador de rede de Replicação, a Contoso usa rotas estáticas persistentes, que eles configuram usando a ferramenta Netsh.exe. Netsh.exe é uma ferramenta que pode ser usada para configurar e monitorar computadores baseados no Windows em um prompt de comando. Com a ferramenta Netsh.exe, você pode direcionar os comandos do contexto inseridos no auxiliar apropriado, e o auxiliar executa o comando. O auxiliar é um arquivo de biblioteca de link dinâmico (.dll) que amplia a funcionalidade da ferramenta Netsh.exe fornecendo configuração, monitoramento e suporte para um ou mais serviços, utilitários ou protocolos.

Para configurar o roteamento para os adaptadores de rede de Replicação em MBX1A e MBX2A, o comando a seguir foi executado em cada servidor.

netsh interface ipv4 add route 10.0.2.0/24 <NetworkName> 10.0.1.254

Para configurar o roteamento para os adaptadores de rede de Replicação em MBX1B e MBX2B, o comando a seguir foi executado em cada servidor.

netsh interface ipv4 add route 10.0.1.0/24 <NetworkName> 10.0.2.254

As seguintes configurações de rede adicionais também foram configuradas:

  • A caixa de seleção Registrar os endereços desta conexão no DNS está marcada para cada adaptador de rede MAPI do membro do DAG e desmarcada para cada adaptador de rede de Replicação.

  • Ao menos um endereço de servidor DNS está configurado para cada adaptador de rede MAPI do membro do DAG, e nenhum está configurado para os adaptadores de rede de Replicação. Para redundância, a Contoso está usando vários endereços de servidores DNS para seus adaptadores de rede MAPI.

  • A Contoso não usa IPv6 e eles desativaram o protocolo em seus servidores.

  • A Contoso não usa o Firewall do Windows e desativou-o em seus servidores.

Após a configuração dos adaptadores de rede, a Contoso está pronta para criar um DAG e adicionar servidores de caixa de correio ao DAG.

Criação e configuração do grupo de disponibilidade de banco de dados

O administrador decidiu criar um script de interface de linha de comando do Windows PowerShell que realiza várias tarefas:

Os seguintes comandos são usados no script:

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer HUB-A -WitnessDirectory C:\DAGWitness\DAG1.contoso.com -DatabaseAvailabilityGroupIPAddresses 192.168.1.8,192.168.2.8

O comando anterior cria um DAG chamado DAG1, configura o Hub-A para agir como servidor testemunha, configura um diretório testemunha específico (C:\DAGWitness\DAG1.contoso.com) e configura dois endereços IP para o DAG (um para cada sub-rede na rede MAPI).

Set-DatabaseAvailabilityGroup -Identity DAG1 -AlternateWitnessDirectory C:\DAGWitness\DAG1.contoso.com -AlternateWitnessServer HUB-B

O comando anterior configura o DAG1 para usar um servidor testemunha alternativo Hub-B e um diretório testemunha alternativo no Hub-B que usa o mesmo caminho configurado no Hub-A.

Dica

Não é necessário usar o mesmo caminho; a Contoso optou por fazer isso para padronizar a configuração.

Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX1B
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2A
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer MBX2B

Os comandos anteriores adicionam cada um dos servidores de caixa de correio, um de cada vez, ao DAG. Os comandos também instalam o componente de Cluster de Failover do Windows em cada servidor de caixa de correio (caso ainda não esteja instalado), cria um cluster de failover e ingressa cada servidor de caixa de correio no cluster recém-criado.

Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly

O comando anterior habilita o modo DAC para o DAG.

Bancos de dados de Caixas de Correio e cópias de bancos de dados de Caixas de Correio

Depois de criar o DAG e adicionar os servidores de Caixa de Correio ao DAG, a Contoso se prepara para criar bancos de dados de caixas de correio e cópias de bancos de dados de caixas de correio. Para atender ao critério de resistência a falhas, a Contoso pretende configurar cada banco de dados de caixa de correio com três cópias de banco de dados sem atraso e uma cópia de banco de dados com atraso. A cópia com atraso terá um atraso de repetição de log configurado para três dias.

Essa configuração proporciona um total de quatro cópias para cada banco de dados (uma ativa, duas passivas sem atraso e outra passiva com atraso). A Contoso pretende ter quatro bancos de dados ativos por servidor. Com quatro bancos de dados ativos por servidor e três cópias passivas de cada banco de dados, a solução da Contoso contém 16 cópias totais de banco de dados.

Como mostra a figura a seguir, a Contoso adotou uma abordagem equilibrada no layout de banco de dados.

Layout da cópia do banco de dados para a Contoso, Ltd

Layout da Cópia do Banco de Dados para a Contoso, Ltd

Cada servidor de caixa de correio hospeda uma cópia de banco de dados de caixa de correio ativa, duas cópias de banco de dados passivas sem atraso e uma cópia de banco de dados passiva com atraso. A cópia com atraso de cada banco de dados de caixa de correio ativo é hospedada em um servidor de caixa de correio no outro site.

Para criar essa configuração, o administrador executa vários comandos.

No MBX1A, execute os seguintes comandos.

Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB1 -MailboxServer MBX1B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -SuspendComment "Seed from MBX2B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB1\MBX1B -SourceServer MBX2B
Suspend-MailboxDatabaseCopy -Identity DB1\MBX1B -ActivationOnly

No MBX2A, execute os seguintes comandos.

Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB2 -MailboxServer MBX2B -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -SuspendComment "Seed from MBX1B" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB2\MBX2B -SourceServer MBX1B
Suspend-MailboxDatabaseCopy -Identity DB2\MBX2B -ActivationOnly

No MBX1B, execute os seguintes comandos.

Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2B
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX2A
Add-MailboxDatabaseCopy -Identity DB3 -MailboxServer MBX1A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -SuspendComment "Seed from MBX2A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB3\MBX1A -SourceServer MBX2A
Suspend-MailboxDatabaseCopy -Identity DB3\MBX1A -ActivationOnly

No MBX2B, execute os seguintes comandos.

Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1B
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX1A
Add-MailboxDatabaseCopy -Identity DB4 -MailboxServer MBX2A -ReplayLagTime 3.00:00:00 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -SuspendComment "Seed from MBX1A" -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB4\MBX2A -SourceServer MBX1A
Suspend-MailboxDatabaseCopy -Identity DB4\MBX2A -ActivationOnly

Nos exemplos anteriores para o cmdlet Add-MailboxDatabaseCopy, o parâmetro ActivationPreference não foi especificado. A tarefa incrementa automaticamente o número de preferência de ativação a cada cópia adicionada. O banco de dados original sempre tem um número de preferência igual a 1. A primeira cópia adicionada com o cmdlet Add-MailboxDatabaseCopy recebe automaticamente um número de preferência igual a 2. Presumindo que nenhuma cópia seja removida, a próxima cópia adicionada recebe o número 3, e assim por diante. Logo, nos exemplos anteriores, a cópia passiva no mesmo datacenter da cópia ativa tem número de preferência de ativação 2; a cópia passiva sem atraso no datacenter remoto tem número de preferência de ativação 3, e a cópia passiva com atraso no datacenter remoto tem número de preferência de ativação 4.

Embora haja duas cópias de cada banco de dados ativo ao longo da WAN no outro local, a propagação pela WAN só foi realizada uma vez. Isso acontece porque a Contoso está potencializando a capacidade do Exchange 2010 para usar uma cópia passiva de um banco de dados como origem da propagação. O uso do cmdlet Add-MailboxDatabaseCopy com o parâmetro SeedingPostponed impede que a tarefa propague automaticamente a nova cópia de banco de dados que está sendo criada. Assim, o administrador pode suspender a cópia não propagada e, usando o cmdlet Update-MailboxDatabaseCopy com o parâmetro SourceServer, pode especificar a cópia local do banco de dados como origem da operação de propagação. Como resultado, a propagação da segunda cópia de banco de dados adicionada a cada localidade acontece localmente, e não através da WAN.

Dica

No exemplo anterior, a cópia de banco de dados sem atraso é propagada através da WAN, e essa cópia é usada para propagar a cópia com atraso do banco de dados que está no mesmo datacenter que a cópia sem atraso.

A Contoso configurou uma das cópias passivas de cada banco de dados de caixa de correio como uma cópia de banco de dados com atraso para oferecer proteção contra o caso extremamente raro mas catastrófico de uma corrupção lógica de banco de dados. Como resultado, o administrador está configurando as cópias com atraso como bloqueadas para ativação usando o cmdlet Suspend-MailboxDatabaseCopy com o parâmetro ActivationOnly. Isso garante que as cópias de banco de dados com atraso não serão ativadas se um failover de banco de dados ou servidor ocorrer.

Validando a solução

Depois que a solução for implantada e configurada, o administrador realiza várias tarefas que validam a preparação da solução antes de mover caixas de correio de produção para os bancos de dados no DAG. A solução deve ser testada e inspecionada usando diversos métodos, incluindo simulações de falha. Para validar a solução, o administrador executa várias tarefas.

Para verificar a integridade geral do DAG, o administrador executa o cmdlet Test-ReplicationHealth. Esse cmdlet verifica vários aspectos do status de replicação e de repetição para oferecer informações sobre cada cópia de banco de dados e servidor de caixa de correio no DAG.

Para verificar a atividade de replicação e repetição, o administrador executa o cmdlet Get-MailboxDatabaseCopyStatus. Esse cmdlet pode oferecer informações de status em tempo real sobre uma cópia de banco de dados de caixa de correio específica ou sobre todas as cópias de banco de dados de caixa de correio em um servidor específico. Para mais informações sobre o monitoramento da integridade e do status de bancos de dados replicados em um DAG, consulte Monitorando a alta disponibilidade e resiliência do site.

Para verificar se as alternâncias ocorrem conforme o esperado, o administrador usa o cmdlet Move-ActiveMailboxDatabase para realizar uma série de alternâncias de bancos de dados e servidores. Quando essas tarefas forem concluídas com êxito, o administrador usa o mesmo cmdlet para mover as cópias de banco de dados ativas de volta aos seus locais originais.

Para verificar os comportamentos esperados em vários cenários de falha, o administrador realiza várias tarefas que simulam falhas ou que de fato causam as falhas. Por exemplo, o administrador pode:

  • Desconectar o cabo de alimentação no MBX1A, disparando um failover de servidor. O administrador verifica se o DB1 se torna ativo em outro servidor (de preferência o MBX2A, com base nos valores de preferência de ativação).

  • Desconectar o cabo de rede do adaptador de rede MAPI no MBX2A, disparando um failover de servidor. O administrador verifica se o DB2 se torna ativo em outro servidor (de preferência o MBX1A, com base nos valores de preferência de ativação).

  • Deixar offline o disco usado pela cópia ativa do DB3, disparando um failover de banco de dados. O administrador verifica se o DB3 se torna ativo em outro servidor (de preferência o MBX2B, com base nos valores de preferência de ativação).

Podem haver outros cenários de falha testados por uma organização, tendo por base as necessidades de seus negócios. Depois de simular uma única falha (como desconectar a tomada) e verificar o comportamento de recuperação da solução, o administrador pode reverter a solução de volta à configuração original. Em alguns casos, a solução pode ser testada para várias falhas simultâneas. Em última análise, seu plano de testes de solução irá ditar se a solução será revertida de volta à configuração original após a conclusão de cada simulação de falha.

Além disso, o administrador pode optar por desconectar a conexão de rede entre os dois datacenters, simulando uma falha de site. A realização de uma alternância de datacenter é um processo muito mais complexo e coordenado; no entanto, é um processo recomendado se a solução que estiver sendo implantada tiver como objetivo proporcionar resiliência de site para os dados e serviços de mensagens. Para detalhes sobre alternâncias de banco de dados, consulte Switchovers do Datacenter.

Fazendo a transição para operações

Depois que a solução for implantada, ela pode ser ampliada ainda mais, usando-se a implantação incremental. Nesse ponto, o gerenciamento da solução também faria a transição para processos de operação, com a realização das seguintes tarefas:

Para mais informações sobre o gerenciamento da solução, consulte Gerenciando a alta disponibilidade e resiliência do site.

 © 2010 Microsoft Corporation. Todos os direitos reservados.