Introdução

A globalização e os negócios online requerem servidores com o maior uptime de produção possível, você já pensou qual a porcentagem de tempo que seus servidores estão em Uptime e em Downtime?

Se sua resposta for não e você esta procurando criar um ambiente com alta disponibilidade e utilizar o Exchange Server 2010, este artigo foi feito para você!

Para entendermos melhor, este artigo além explicará o conceito de Uptime e Downtime de servidores Exchange e desmistificaremos todos os segredos que existem por trás da palavra HA (High Availability) ou Alta Disponibilidade, para o produto Exchange Server e suas Roles.

Então vamos lá...

Qual o Significado de Uptime e Downtime?

Estas duas palavras servem para medirmos o tempo ao qual o servidor esta em produção “Ativo” e o tempo ao qual o servidor está parado “Inativo”. Para isto usamos a palavra Uptime para “Ativo” e Downtime para “Inativo”.

Hoje você saberia informar quanto tempo seus servidores estão em Uptime e quanto tempo passaram em Downtime?

Claro que este controle pode ser feito por métricas e também com a utilização de metodologias de gerenciamento de infraestrutura, porém este não é o nosso foco, para falarmos melhor disto, pensemos em um caso onde eu queira oferecer os serviços de mensageria com 99,9% de Uptime por ano.

Para chegarmos neste valor precisaríamos fazer a conta abaixo:

365 dias no Ano e multiplicarmos por 24 Horas/dia (365*24=8760 horas)

8760*0.999% = 8751 horas “Aproximadamente”

8760 – 8751 = 9 horas

Logo para oferecermos um sistema de mensageria que esteja com um Uptime de 99,9%, precisaríamos ter este servidor ativo por 8751 horas durante o ano, ou se preferir parado “Inativo” por um total de 9 horas.

Quando paramos para projetar um sistema como o de mensageria, temos algumas variáveis como: Atualizações Software, Atualizações Hardware, Manutenções no Sistema, Manutenção no DataCenter e várias outras mais, porém para alcançarmos 99,9% de Uptime tudo isto teria que ser feito em 9 horas em um ano.

Achou o valor agressivo? Claro que todos nós também pensando nisto, este artigo foi desenvolvido para discutirmos todos os passos necessários para criarmos um ambiente de Exchange Server 2010 com Alta Disponibilidade e com o menor Downtime possível.

 

Qual tipo de Alta Disponibilidade posso utilizar no Exchange Server 2010?

No mercado hoje existem alguns métodos, aplicativos e hardwares especializados neste tipo de trabalho, antes de falarmos dos tipos de HA (High Availability), vamos conversar sobre os pontos importantes na compra, aquisição ou implementação deste componente/recurso.

  • Gerenciamento Facilitado – Esta solução é simples para gerenciar e configurar?
  • Detecção de Failover – Esta solução possui suporte para detecção de falha avançada (Service Awareness) ou apenas teste ping (Host Awareness)?
  • Afinidade – Esta solução disponibiliza distribuição the clientes?
  • Custo – Valide o custo real da implementação, lembre-se Aquisição +/ou Implementação + Treinamento, vale a pena?
  • Escalabilidade – Será necessário aumentar o número de servidores, o processo para escalabilidade é simples?
  • Features – Suporte a recursos como SSL Offloading, Redirect Protocol dentre outros estão disponíveis na solução?

Algumas destas perguntas fazem muita diferença entre comprar um produto e implantar uma solução para seu serviço de mensageria.

 

Software Load Balancing

O processo de Software Load Balancing, também conhecido como Windows NLB (NLB) ou qualquer outro software de terceiro, sugere o roteamento de solicitações através de software.

No Windows Server 2008 R2, o NLB suporta até 32 hosts dentro do mesmo NLB, porém vários documentos e a experiência do time de Microsoft Internal Deployment, limita esta utilização em no máximo de 8 hosts por NLB.


  • O NLB não pode ser utilizado junto com servidores Mailbox Server que estejam com o recurso de DAG habilitado, esta limitação acontece, pois não é possível trabalhar com NLB e Windows Failover Clustering  no mesmo host.
  • O NLB não detecta Service Awareness, funciona apenas como Host Awareness.
  • A Utilização do NLB pode resultar em Port Flooding, fazendo com que as redes fiquem sobrecarregadas, sugerimos quando utilizar o NLB, trabalhar com Vlan’s separadas para este recurso, isolando este problema.

Hardware Load Balancing

Caso precise de suporte para mais de 8 servidores em balanceamento, suporte a recursos de Service Awareness e melhor gestão de Port Flooding é indicado a utilização de Hardware Load Balancing (HLB).


  • Hardware Load Balancing, tem melhor performance e principalmente features para auxiliar em uma melhor administração do Exchange Server.
  • HLB suporta vários métodos de Node Health Checks, vários tipos de Afinidade para configuração dentre outras features, porém vale salientar que é uma solução que implica em investimento.

 

DNS Round Robin

Este recurso se utiliza do software de DNS, criando registros com o mesmo nome para IP’s diferentes, o próprio DNS estará encarregado de distribuir as cargas, conforme as solicitações forem sendo feitas.

Suponha que temos 2 servidores que estarão respondendo para o nome mail.shequinah.local, primeiro habilitamos o recurso de Round Robin no DNS e após isto criamos os registros idênticos ao exemplo abaixo:

Mail.shequinah.local                  A             192.168.0.1
Mail.shequinah.local                  A             192.168.0.2

O processo que irá acontecer nas solicitações esta representado na imagem demonstrada abaixo:


Desta forma as solicitações são distribuídas para ip’s diferentes, fazendo com que exista o Round Robin.

 

Application Firewall

Outro recurso interessante é utilizarmos um firewall como apliance de Load Balancing, alguns modelos no mercado já disponibilizam esta feature, é muito parecido com o Hardware Load Balancing, porém dentro de um próprio firewall.

Um ponto interessante é que estes produtos como Microsoft Threat Management Gateway (TMG) ou Forefront Unified Access Gateway (UAG), precisam ter profissionais muito bem treinados para que a solução funcione perfeitamente.


Sempre valide o custo da solução de Application Firewall junto com treinamento e tempo de aprendizado, caso contrário a solução pode não ser apropriada pelo tempo de implementação ou pelo custo.

 

As roles do Exchange Server 2010 tem recursos de Alta Disponibilidade?

Vamos revisar rapidamente as roles do Exchange Server 2010 Sp2 e verificar as possibilidades em cada uma destas roles:

  1. Mailbox Role – DAG Database Availability Group
  2. Hub Transport Role – NLB, HLB, Application Firewall e Round Robin
  3. Client Access  Role – NLB, HLB, Application Firewall e Round Robin
  4. Unified Messaging Role – Round Robin e Suporte no Gateway de VOIP para Tronco SIP
  5. Edge Transport Role – NLB, HLB, Application Firewall e Round Robin

Na tabela abaixo podemos visualizar os tipos de Alta Disponibilidade que podemos utilizar com cada uma das roles demonstradas acima:

Tipo

Custo

Afinidade

Benefícios

Inconvenientes

HLB

Alto

Todos Tipos

  • Failover Automáico
  • Pode usar com Failover Clusters
  • Verifica saúde do Serviço
  • SSL Bridging
  • Custo
  • Complexidade

 

NLB

Baixo

IP Origem

  • Facilidade de Configuração
  • Custo Baixo
  • Escalabilidade Limitada
  • Não usar com Failover Clusters
  • Não verifica saúde do serviço

Round
Robin

Baixo

Randômico

  • Facilidade de Configuração
  • Failover Manual
  • Tempo Alto para Failover
  • Tráfego Imprevisível

 

Application
Firewall

Medio

Origem Ip Cookie

  • SSL Bridging
  • Autenticação pelo AD
  • Segurança Reforçada
  • Verifica saúde do Serviço
  • Complexidade de Implementação

 

Nota: Os pontos identificados na tabela acima servem apenas como métricas de avaliação existem muitos produtos no mercado e sabemos que os prós e contras podem mudar.

A Microsoft disponibiliza uma página na internet onde faz referências aos HLB’s que são homologados, para visualizar clique no link abaixo:

http://technet.microsoft.com/en-us/office/ocs/cc843611.aspx

Espero que este artigo tenha ajudado em sua busca incansável para um serviço com High Availability, lembre-se nos dias de hoje com as decisões imediatistas, forma-se cada vez mais um cenário para que os projetos de mensageria gerem conflitos e prejudiquem os usuários finais. Minha dica é pesquise, analise, projete e teste antes de implementar!!!
Boa sorte em suas implementações.

Até mais,
Rover Marinho
Twitter: @rovermarinho
http://rovermarinho.wordpress.com