Resumo 70-341 – Parte 03: Alta Disponibilidade no Exchange Server 2013

Esse assunto será cobrado em peso nas provas de certificação do Microsoft Exchange Server 2013, se prepare para cenários com múltiplos sites e datacenters, nesse resumo tentarei trazer um pouco sobre a Alta Disponibilidade das funções, dicas para a prova e alguns cenários.

Leia nossa série de Posts para a prova 70-341:

Alta Disponibilidade da função de Client Access 

No Microsoft Exchange Server 2010, a alta disponibilidade era provida através de uma Client Access Array (utilizando um único nome para acesso a todos os servidores CAS) e alguma forma de balanceamento de carga entre os servidores, quase todos os protocolos de acesso que  forneciam acesso ao cliente necessitavam que o tráfego mantivesse uma afinidade de cliente com um servidor CAS, dessa forma podíamos utilizar um balanceamento de carga via Hardware de Camada 7 e Windows NLB com afinidade de IP de origem.


Devido as mudanças no Microsoft Exchange Server 2013, a função de Client Access passa a funcionar como servidores de Proxy, onde todo o processamento é feito nos servidores de Mailbox, com essa nova arquitetura não ficamos mais presos a uma Client Access Array ou afinidade com um servidor CAS, mais ainda utilizamos um único nome para acesso e algum mecanismo para balanceamento de carga.

O grande segredo da mudança de arquitetura está na alteração da afinidade de cliente. Como os servidores de Client Access funcionam como proxy o processamento de acesso é feito pela função de Mailbox onde a caixa postal do usuário é armazenada, portanto os clientes podem acessar vários servidores Client Access durante a mesma conexão, já que o acesso e afinidade sempre será mantido com o mesmo servidor Mailbox. Essa alteração também provê a possibilidade de manter um site com apenas um servidor de Mailbox, diferente das versões anteriores onde era necessário ter sempre um servidor de Client Access para um site.

A imagem abaixo mostra como o acesso é feito através de um cliente acessando o Outlook Web Access:

image001

Como essa alteração podemos utilizar as seguintes maneiras para o balanceamento de carga entre os servidores de Mailbox:

  • Balanceamento de Carga via Hardware de Camada 4;
  • Balanceamento de Carga via Hardware de Camada 7;
  • Balanceamento de Carga via Windows NLB;
  • Balanceamento de Carga via DNS Roud Robin.

Apesar de podermos utilizar os métodos acima para balanceamento de carga, a Microsoft recomenda que você utilize um Hardware para balanceamento de carga e ressalta algumas limitações para o uso de balanceamento de carga via Windows NLB e DNS Roud Robin:

  • O Windows NLB não pode ser utilizando no mesmo servidor que possui a função de Mailbox em alta disponibilidade, já que a DAG que é o mecanismo de alta disponibilidade utiliza a função de Failover Clustering do Windows (O Windows Server não possibilita a instalação da função de Windows NLB e Failover Clustering no mesmo servidor).
  • O Windows NLB não detecta interrupção no serviço, apenas no acesso ao IP, ou seja, em caso de um problema em serviços Web e o servidor estiver respondendo a solicitações via IP o tráfego será balanceado para esse servidor.
  • DNS Roub Robin não detecta nenhuma interrupção no serviço, mesmo com uma falha no servidor, ou seja, caso um servidor ou serviço fique indisponível o tráfego ainda continuará a ser enviado para o servidor.

Cabe a você decidir qual o melhor cenário para balanceamento de carga de servidores de Client Access em sua organização.

Dica: Como já realizei esse exame acabei me lembrando de um cenário onde o tráfego de acesso da internet usava NAT e era balanceado através de um Hardware Load Balance de camada 4, onde todo o tráfego era redirecionado apenas para um servidor, e você deveria configurar o Hardware load balance para balancear a carga entre todos os servidores. Esse cenário pode ser bem tipico em organizações, o que acontece é que  devemos configurar o HLB para enviar o IP de acesso original (Endereço IP dos clientes de fora da organização) e não o endereço IP do dispositivo que está realizando a tradução de endereço NAT.

Alta Disponibilidade da função de Mailbox

O Microsoft Exchange Server 2013 oferece um recurso nativo para alta disponibilidade e resiliência de sites para a função de Mailbox, chamado DAG (Grupo de Disponibilidade de Banco de Dados). Um DAG é um grupo de até 16 servidores de caixa de correio, que replicam um mesmo banco de dados, permitindo disponibilidade e recuperação automática a nível de banco de dados em caso de falha que afetem um servidor ou um banco de dados.

Para criar um DAG utilizamos o comando New-DatabaseAvailabilityGroup. Um DAGé criado inicialmente como um objeto vazio no ActiveDirectory. Esse objeto é usado para armazenar informações sobre o DAG. Quando o primeiro servidor Mailbox é adicionado um cluster de failover é criado automaticamente para o DAG.

Além de um cluster de failover ser criado, a infraestrutura que monitora os servidores em busca de falhas de rede ou servidor é iniciado. Em seguida, o mecanismo de pulsação do cluster de failover e o banco de dados do cluster são usados para acompanhar e gerenciar informações sobre o DAG que podem ser alteradas rapidamente, como o status de montagem do banco de dados, o status da replicação e o local da última montagem.

Quando criamos um DAG podemos atribuir um endereço IP estático ou usar o protocolo DHCP para o DAG, com o Exchange Server 2013 SP1 e o windows Server 2012 R2 podemos criar DAGs sem o ponto de acesso administrativo do cluster, ou seja sem um objeto no AD e um endereço IP.

Para entendermos algumas funcionalidades e como o DAG funciona precisamos olhar para outros fatores.

Exemplo 01:

Utilizamos o processo abaixo para a criação de um DAG chamado DAG1 com três servidores, espalhados em dois sites, nesse caso o DAG será criado com dois endereços IPs, uma para associado a cada site.

New-DatabaseAvailabilityGroup -Name DAG1 -WitnessServer EX4 -DatabaseAvailabilityGroupIPAddresses 10.0.0.5,192.168.0.5
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX1
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX2
Add-DatabaseAvailabilityGroupServer -Identity DAG1 -MailboxServer EX3


Passo 01: O DAG é criado utilizando o comando New-DatabaseAvailabilityGroup com um nome DAG1, utilizando um servidor testemunha EX4 e usando os endereços IP 10.0.0.5,192.168.0.5.

Passo 02: O cluster de DAG1 é criado quando EX1 é adicionado ao DAG. durante a criação de cluster, o cmdlet Add-DatabaseAvailabilityGroupServer recupera os endereços configurados para o DAG e ignora os que não correspondem a nenhuma das sub-redes encontradas no servidor EX1.

Passo 03: O cmdlet Add-DatabaseAvailabilityGroupServer recupera novamente os endereços IP configurados para o DAG. Não são feitas alterações nos endereços IP do cluster, pois EX2 está na mesma sub-rede de EX1.

Passo 04:  EX3 é adicionado, e o cmdlet Add-DatabaseAvailabilityGroupServer recupera novamente os endereços IP configurados para o DAG. Como uma sub-rede correspondente a 192.168.0.5 está presente em EX3, o endereço 192.168.0.5 é adicionado como um recurso de endereço IP no grupo do cluster. Além disso, uma dependência OR para o recurso de Nome de Rede de cada recurso de endereço IP é configurada automaticamente. O endereço 192.168.0.5 será usado pelo cluster quando o grupo de recursos principais do cluster for movido para EX3.

Exemplos de Ambientes com DAG:

IC742664

 

Na figura anterior, os bancos de dados verdes são cópias ativas de banco de dados de caixa de correio e os bancos de dados azuis são cópias passivas de banco de dados de caixa de correio. Neste exemplo, as cópias de banco de dados não são espelhadas em cada servidor, mas sim distribuídas em vários servidores. Isso garante que dois servidores do DAG não terão o mesmo conjunto de cópias de banco de dados, dando ao DAG uma maior resiliência a falhas, incluindo as que ocorrem enquanto outros componentes não estão disponíveis como resultado de manutenção regular.

Caso um Servidor falhe a cópia passiva é ativada em um outro servidor após 30 segundo, garantindo a alta disponibilidade da função de Mailbox.

Exemplos de Ambientes com DAG com vários sites:

IC742669

Neste exemplo, uma cópia passiva de cada banco de dados ativo no datacenter Redmond é configurada em EX6 no datacenter Dublin.

 

Modelos de quórum para DAG

Quando criamos um DAG e adicionamos o primeiro servidor, um cluster de failover é criado. Cluster de failover utiliza um conceito de quórum, ou seja, utiliza votos para garantir que um conjunto de membros esteja funcionando, garantindo a consistência dos dados. Se o cluster perder o quórum, todas as operações do DAG são encerradas e todos os bancos de dados são desmontados.

No Exchange Server 2013 utilizamos dois modelos de quórum:

Maioria dos Nós e Compartilhamento de Arquivo do cluster de failover: Utilizado para DAG com número par de membros, nesse modo cada membro conta como um voto e um servidor de testemunha é usado para votação ponderada (por exemplo, conta dois votos em vez de um). Desse modo se a maioria dos votantes não puder se comunicar com os outros, o cluster subjacente do DAG perde quorum e o DAG exigirá intervenção administrativa para tornar-se novamente operacional.
Considere um DAG com quatro membros, para manter uma maioria de votantes pelo menos 3 votantes devem ser capazes de se comunicar entre si. A qualquer momento, um máximo de dois votantes pode estar offline sem interromper o serviço e o acesso aos dados. se três ou mais votantes estiverem offline, o DAG perder quorum e o acesso aos dados é interrompido até o problema ser resolvido.

Maioria dos Nós do cluster de failover: Utilizado para DAG com número ímpar de membros. cada servidor tem um voto e o disco do sistema local de cada membro é usado para armazenar os dados de quorum do cluster. Se a configuração do DAG é alterada, a alteração é refletida nos discos dos membros, a alteração só é considerada confirmada depois que metade dos membros mais um realizar a alteração no seus discos locais. Considere um DAG com três membros, nesse caso apenas um servidor poderá ficar offline sem que o quórum seja perdido, caso dois servidores fiquem offline os bancos de dados serão desmontados.

 

Active Manager

O Active Manager é um componente do Microsoft Exchange Server 2013 responsável por gerenciar a plataforma de alta disponibilidade que inclui um DAG e as cópias de banco dados. Executado dentro do serviço de Replicação do Microsoft Exchange (MSExchangeRepl.exe) em todos os servidores Mailbox. Em servidores membros de DAG existem duas funções do Active Manager:

PAM – Active Manager Principal: decide quais cópias serão ativas e passivas, e obter notificações de alteração de topologia e reagir a falhas de servidor. O membro do DAG que possui o recurso de quorum do cluster hospedará a função de PAM.

SAM – Active Manager em Espera: fornece informações sobre qual servidor hospeda a cópia ativa de um banco de dados de caixa de correio para outros componentes do Exchange, também detecta falhas locais para seus bancos de dados. Quando uma falha de um banco de dados é detectada ele solicita ao PAM que inicie um failover.

 

DAC – Modo Coordenação de Ativação do Banco de Dados

Para entendermos oque é o DAC primeiro precisamos vamos analisar um cenário tipico de split brain.

Exemplo 01:

Temos dois sites, Datacenter MSCLOUD01 é nosso site principal e hospeda todos os Bancos de Dados Ativos, Datacenter MSCLOUD02 é nosso site secundário e é utilizado somente para site de Disastre Recovery.

Temos um DAG chamado DAG01 que contém 4 Servidores. MBX01 e MBX02 estão no site principal MSCLOUd01 e MBX03 e MBX04 estão no site secundário MSCLOUD02. O Servidor CAS01 é utilizado como servidor de testemunha para esse DAG.

Desenho1

Uma falta de energia afeta seu site principal, como vimos anteriormente, com a falha nos servidores CAS01, MBX01 e MBX02 o cluster perde o quórum e todos os bancos de dados são desmontados. Para estabilizar o acesso dos usuários, você executa uma intervenção administrativa e habilita todos os bancos de dados nos servidores MBX03 e MBX04.

A energia no datacenter MSCLOUD01 é normalizada, porém a conectividade entre os dois datacenters ainda continua indisponível, como os servidores do datacenter principal tinham quórum antes do desligamento dos bancos de dados os servidores são montados. Nesse caso uma condição de split brain (divisão de cérebro).

Para evitar esse problema no Exchange Server 2013, a Microsoft recomenda a utilização do modo DAC em todas as DAG com mais de dois membros.

 

Requisitos de Endereços IP e nome para DAG:

Considere os seguintes pontos para o planejamento de rede:

  • Cada membro do DAG deve ter pelo menos um adaptador de rede que seja capaz de se comunicar com todos os membros do DAG.
  • Recomenda-se utilizar um adaptador de rede exclusiva para replicação e uma rede para MAPI.
  • Cada membro do DAG de ter os mesmo números de interfaces de rede.
  • O endereço IP APIPA não é recomendado.

Exemplo:

IC694595

Neste exemplo, a rede MAPI em cada membro do DAG está em uma sub-rede separada. Dessa forma, o DAG exige dois endereços IP: um para cada sub-rede na rede MAPI.

As configurações e cada adaptador devem ser conforme especificação abaixo:

Rede de replicação:

Cliente para redes Microsoft:   Desabilitado
Agendador de pacotes QoS:    Opcional
Compartilhamento de Arquivos e Impressoras..:   Desabilitado
TCP versão 6:   Habilitado
TCP Versão 4:   Habilitado
Driver de E/S ..:  Habilitado
Respondente da descoberta de topologia..: Habilitado

Rede de replicação:

Cliente para redes Microsoft:   Habilitado
Agendador de pacotes QoS:    Opcional
Compartilhamento de Arquivos e Impressoras..:   Habilitado
TCP versão 6:   Habilitado
TCP Versão 4:   Habilitado
Driver de E/S ..:  Habilitado
Respondente da descoberta de topologia..: Habilitado

Cenário:

Veja um cenário completo envolvendo dois sites do Active Directory.

Alta Disponibilidade da função de Edge

Com o SP1 do Exchange Server 2013 podemos utilizar a função de Edge Server, função que é responsável pela comunicação SMTP entre a sua organização e a internet e alguns agentes de transporte que a função de Mailbox não é capaz de executar, também podemos utilizar um servidor Edge para implantações hibridas com o Microsoft Office 365.

Para a Alta Disponibilidade podemos ter dois ou mais servidores em uma rede DMZ e um mecanismo de balanceamento de carga (Hardware Load Balance, Software Load Balance e DNS Roud Robin).

 

 

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s