Exchange Server 2013 Criando Database Availability Groups

Fernando Lugão Veltem

Dn747214.060DE5057573180CEC6D227C6D3E2207(pt-br,TechNet.10).png

Maio, 2014

Visão Geral

O Database Availability Group (DAG) é a funcionalidade de alta disponibilidade para as bases de dados do Exchange Server 2013. Um DAG é formado por um conjunto de até 16 servidores Mailbox e provê replicação das bases e recuperação no caso em falha de servidores.

Cada membro do DAG é capaz de hospedar uma cópia de uma base de dados do Exchange com um limite de 100 bases. Todas as copias das bases devem ser localizadas no mesmo caminho, e um membro do DAG somente pode possuir uma cópia de uma determinada base.

O serviço de alta disponibilidade utiliza a replicação contínua para manter todas as copias atualizadas. E as bases ativas podem ser distribuídas entre os membros do DAG e a qualquer momento uma base passiva pode se tornar ativa e servir conexão para os usuários.

Dn747214.17CB0851F4EE27D2C6FF8EF222A002FB(pt-br,TechNet.10).png

O DAG introduz um componente chamado Active Manager, que é responsável que gerencia a plataforma de alta disponibilidade e a copia das bases.

Active Manager

Este componente do DAG é executado dentro do serviço Microsoft Exchange Replication (MSExchangeRepl.exe),em todos os servidores Mailbox,mesmo os que não são membros de um Database Availability Group

Em Mailbox Server que fazem parte de um DAG este componente é executado em Primary Active Manager ou Standby Active Manager.

  • Primary Active Manager: controla quais copias das bases estão ativas e quais estão no estado passivo. É responsável por processar alterações na topologia e reagir a falhas em servidores e serviços.
  • Standby Active Manager: responsável por monitorar a saúde de todas as bases montadas da estrutura e detectar falhas no serviço Microsoft Exchange Information Store e nos acessos às bases. Quando uma falha é detectada o Standby Active Manager envia uma mensagem ao Primary Active Manager que inicia o processo de failover das bases afetadas e determina onde a copia será montada,

Se o servidor que detêm o Primary Active Manager falhar o componente é movido para o servidor que for ower do quorum do cluster. Para exibir o Primary Active Manager do cluster execute o cmdlet:

Get-DatabaseAvailabilityGroup <nome do dag> -Status | Format-List Name, PrimaryActiveManager

Dn747214.519336E0B59469BE11E938EF22377C72(pt-br,TechNet.10).png

Quorum

O Quorum de um cluster é um componente que mantem a logica do cluster determinando quais membros são ativos e quais são passivos.

O Exchange Server 2013 utiliza o componente do quorum do Windows cluster para determinar o número de nodos que o cluster pode perder e sem afetar a continuidade do serviço de base.

O Quorum impede que dois servidores operem simultaneamente como ativos no cluster, o quorum implementa um algorítimo de voto para determinar se o cluster tem uma quantidade de nodos ativos para manter o serviço de cluster. Como o cluster tem um número finito de nodos e uma configuração de quorum, o serviço de cluster sabe quantos votos são necessários para manter o serviço. Se o número de votos ficar abaixo do mínimo o cluster não pode ser iniciado.

O DAG faz uso de um witness server e um compartilhamento de rede como o quorum. O servidor witness não faz parte como um membro do DAG e não participa na replicação das bases, o witness hospeda uma pasta compartilhada que é usada como quorum,. O quorum então é utilizado para determinar os membros da replicação e quais servidores possuem bases passivas.

Uma boa prática é configurar o servidor Client Access como o witness server. Este serviço consome poucos recursos e não afeta o funcionamento dos componentes do servidor web.

Como o cluster utiliza o sistema de voto, podemos encontrar duas situações quando configuramos um DAG. Quando a quantidade de servidores é par ou impar.

Se um Database Availability Group foi criado com um número impar de membros o a maioria simples de membros devem votar para que o cluster funcione. Por exemplo em um DAG de três servidores:

Dn747214.F142FEC72573C7783FAAE56AA4A1F274(pt-br,TechNet.10).png

Se um Database Availability Group foi criado com um número par de membros se cria uma situação onde pode ocorrer uma falha de metade dos membros e o serviço de cluster falhar. Para impedir esta situação o Witness server é tratado como um membro votante do DAG. Por exemplo em um cluster de dois Mailbox Server e um Witness server temos o seguinte sistema de voto

Dn747214.48D7398BD9E0580E43C8D1AF2765DFFF(pt-br,TechNet.10).png

Com um DAG configurado com quatro Mailbox Server e um Witness Server

Dn747214.CE74497098AE589F92C97F20A350BEFE(pt-br,TechNet.10).png

Continuous Replication

Cada membro do DAG participa do processo chamado de continuous replication, que mantem as copias passivas atualizadas e consistentes. O Exchange 2013 suporta dois tipos configurações:

  • File Mode
  • Block Mode

File Mode replication

O serviço do DAG utiliza envio de log assíncrono da base ativa para a base passiva. Cada arquivo de log do Exchange 2013 tem o tamanho fixo de 1 Mb, apos a gravação do arquivo o serviço de replicação copia para o servidor Mailbox que contem a copia da base. Cada Mailbox que recebe o arquivo de log então o aplica na base passiva mantendo a estrutura atualizada.

Quando o último arquivo de log for aplicado à base o serviço de replicação passa a funcionar com o Block Mode.

Block Mode replication

O Extensible Storage Engine (ESE) utiliza um conjunto de log buffers para armazenar informações na memória do servidor antes de escreve-los no transaction logs no disco. A replicação Block Mode replica o Extensible Storage Engine (ESE) log buffers da memória do servidor onde a base esta ativa para todos os membros do DAG que possuem uma copia passiva da base. Quando o log buffer enche o servidor escreve o conteúdo no arquivo de log do Exchange e esvazia o buffer, as alterações são aplicadas na base ativa e passiva simultaneamente.

O benefício da replicação em bloco é que diminui a diferença entre a base ativa e passiva diminuindo a possibilidade de perda de dados durante uma falha.

Rede

Quando um DAG é configurado dois tipos de tráfego são gerados pelos servidores:

  • MAPI, trafego de comunicação entre o servidor e cliente
  • Replicação, trafego de replicação entre servidores DAG

As redes configuradas nos servidores devem ser separadas logicamente para evitar falhas de comunicação.

O DAG suporta compressão entre os servidores baseada no algorítimo XPRESS implementado sobre algorítimo LZ77. As seguintes configurações são suportadas:

  • Disabled: tráfego de rede não é comprimido
  • Enable: tráfego de rede é comprimido
  • InterSubnetOnly: Este é a configuração padrão do DAG, compressão é utilizada quando a replicação em subredes diferentes
  • SeedOnly: compressão é utilizada no seed

Para configurar compressão o seguinte cmdlet

Set-DatabaseAvailabilityGroup <nome DAG> -NetworkCompression <Opção>

O DAG pode criptografar o tráfego de replicação, a criptografia pode tomar as seguintes configurações

  • Disabled: tráfego de rede não é encriptado
  • Enable: tráfego de rede é encriptado
  • InterSubnetOnly: Este é a configuração padrão do DAG, a encriptação é utilizada quando a replicação em subredes diferentes
  • SeedOnly: encriptação é utilizada no seed

Para configurar compressão o seguinte cmdlet

Set-DatabaseAvailabilityGroup <nome DAG> -NetworkEncrytion <Opção>

Instalação do Database Availability Group

Pré Requisitos

Para a instalação do DAG tenho um ambiente de quatro maquinas virtuais.

Dn747214.43C6FD494E272D2A4E1795297A6792A2(pt-br,TechNet.10).png

Um controlador de domínio e certificadora chamado Hm01.home.intranet, e três servidores executando o Exchange Server 2013 Service Pack 1. O servidor chamado Hm03CAS1.home.intranet foi configurado com o Client Access role e os servidores Hm03MBX1.home.intranet e o Hm03mbx2.home.intranet são foram configurados com o Mailbox Server. Todos os servidores estão executando Windows Server 2012 R2.

O servidor Hm03CAS1.home.intranet será configurado como Witness server para o DAG formado pelos Hm03MBX1 e Hm03MBX2. Os servidores Mailbox foram configurados com duas placas de rede, uma rede conectada com comunicação com os servidores e o Client Access e outra subnet utilizada para replicação e heartbeat do cluster.

FQDN

Endereço IP

Rede Replicação

Função do Servidor

Hm01.home.intranet

172.16.1.240/16

-

Controlador de domínio

Hm03CAS.home.intranet

172.16.1.241/16

-

Exchange Server Client Access

Hm03MBX1.home.intranet

172.16.1.242/16

192.168.0.1/30

Exchange Server Mailbox

Hm03MBX2.home.intranet

172.16.1.243/16

192.168.0.2/30

Exchange Server Mailbox

As placas de rede dos servidores Mailbox foram renomeadas para identificar suas funções.

Dn747214.DF83FE6927D481869B4AE4F353DEBCA7(pt-br,TechNet.10).png

As redes de replicação foram configuradas sem gaeway padrão, e removido as configurações de registro de DNS

Dn747214.A40782856020C0B7C74456EAD7773484(pt-br,TechNet.10).png

Permissões e Contas

Para o servidor que será configurado como Witness server é necessário adicionar o grupo Exchange Trusted Subsystem no grupo de administradores locais. Como o servidor que será utilizado é um Exchange Server Client Access a permissão deste grupo está configurada.

Dn747214.4720615625FCA64A8C2257BCE9776B28(pt-br,TechNet.10).png

Antes de iniciar a criação do Database Availability Group é necessário criar um Cluster Network Object no Active Directory. O CNO é uma conta de computador no Active Directory Domain Services desabilitada.

Dn747214.C5CCD971C381C760C03431C8B9113B74(pt-br,TechNet.10).png

Na segurança do objeto adicione o Mailbox Server que será usado para criar o DAG com full control.

Dn747214.EC65CB67A88798EA2C5D02ECEFD054CD(pt-br,TechNet.10).png

Storage

Cada servidor que será membro do DAG deve conter o mesmo número unidades e com a mesma nomenclatura. Neste exemplo cada servidor Mailbox contem duas unidades de disco.

A unidade E: armazena os arquivos de bancos de dados e a unidade F: armazena os arquivos de logs.

Dn747214.F90B7031CB43F92A8B655E09E25F6B63(pt-br,TechNet.10).png

Tenho criada duas bases de dados, DB1 e DB2.

Criação do Database Availability Group

Para criar o DAG acesse o Exchange console, na guia Server clique em

Dn747214.CA4A9026CBA433349CC88357F72FEA13(pt-br,TechNet.10).png

No assistente de criação adicione as configurações do DAG

  • Database avalability group name: configure o nome do DAG. Este nome deve ser igual ao Cluster Network Objectcriado no Active Directory
  • Witness server: adicione o nome do servidor que será usado como witness
  • Witness server directory: Configure o nome da pasta que será criada e compartilhada no servidor witness
  • Database avalability group IP Address: configure o endereço ip que o serviço de DAG responderá

Dn747214.AC30117DEA52839F5109859D05BBDC6E(pt-br,TechNet.10).png

As informações do Database Availability Group já é deve ser exibida no console. Agora é preciso adicionar os servidores no grupo, clique

Dn747214.E822FB97AD299D51FFE673B2339EF718(pt-br,TechNet.10).png

No assistente de configuração clique no sinal de adição

Dn747214.AE316765B3633D19DFC20859F2D84842(pt-br,TechNet.10).png

Selecione o servidor que foi configurado com Full Controll no Cluster Network Object e clique OK

Dn747214.9E1C30D9A09FBD66943DA841324CE76F(pt-br,TechNet.10).png

Clique em Save para gravar e iniciar as configurações do Mailbox

Dn747214.B971D02B13A0D889F0B78769D79E59D1(pt-br,TechNet.10).png

O processo pode demorar um pouco, com o processo concluído clique em Close

Dn747214.D6899D25FF38CF98EBCAE74D9B9264D1(pt-br,TechNet.10).png

Repita o mesmo processo para os outros servidores que serão membros do DAG. As informações dos membros devem ser exibidas

Dn747214.9070EDF5F8E411996E032149D7CE902C(pt-br,TechNet.10).png

Verifique se o diretório foi criado e compartilhado no witness server

Dn747214.9C3A6C7FDDFEE336E74C77CDF9931023(pt-br,TechNet.10).png

Configurando a Base para Replicação

Para adicionar uma base em alta disponibilidade, selecione a base e clique em Add database copy

Dn747214.1316E70E7CC2E62FBC6E3DBF393F374C(pt-br,TechNet.10).png

Selecione o Mailbox Server que receberá a base copia e clique em Save

Dn747214.8BEACB2C0EC60BF8BB6F16043B513BE3(pt-br,TechNet.10).png

O assistente deve configurar a cópia da base no servidor de destino

Dn747214.A0944E47AB2FF0AB09F97E3D602DFDE2(pt-br,TechNet.10).png

Nas propriedades da base são exibidas os servidores que hospedam uma cópia da base

Dn747214.7944EF685DFDD8920DFFD567C2345B51(pt-br,TechNet.10).png

Existe o cmdlet Get-MailboxDatabaseCopyStatus também mostra as copias de uma base e a saúde e qual servidor a base está montada

Get-MailboxDatabaseCopyStatus db1

Dn747214.E96FB58439C1DE5A95B60902740BCA64(pt-br,TechNet.10).png

No console do Exchange apresenta algumas opções de gerenciamento da copia

Dn747214.ABF5D940A8A955777F32FE1DA5CE614B(pt-br,TechNet.10).png

Verificando Replicação

O cmdlet Test-ReplicationHealth pode ser usado para verificar o status da replicação e replay dos logs nas bases passivas.

Test-ReplicationHealth

Dn747214.112EA0E130E36D1F9B7A3757B98F3D7E(pt-br,TechNet.10).png

Artigos Relacionados

Referência 

Você pode melhorar este artigo? Acesse e contribua no Microsoft Technet Wiki e contribua: https://social.technet.microsoft.com/wiki/pt-br/contents/articles/23841.exchange-server-2013-criando-database-availability-groups.aspx

Este artigo foi originalmente escrito por:
Fernando Lugão Veltem
blog: http://flugaoveltem.blogspot.com 
twitter: @flugaoveltem

| Home | Artigos Técnicos | Comunidade