Exchange Server 2013 Criando Database Availability Groups

Exchange Server 2013 Criando Database Availability Groups



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 copia 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. 


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


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: 


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


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


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

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.


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.


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



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 esta configurada.


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. 


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


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.


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 


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 Object criado 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á


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


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


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


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


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


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


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


Configurando a Base para Replicação

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


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

O assistente deve configurar a copia da base no servidor de destino


Nas propriedades da base são exibidas os servidores que hospedam uma copia da base


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


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


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

Tra

Artigos Relacionados

Referência

Classificar por: Data da Publicação | Mais Recente | Mais Úteis
Comentários
Página 1 de 1 (1 itens)