Modelos de Alta Disponibilidade no Exchange 2010

Fala Pessoal,

Abaixo segue um artigo bem bacana, que consegui no blog do amigo Jonathan Santos…

Abraços a Todos..

 

 

Algo que não é mais segredo para nenhum administrador de um ambiente Exchange Server é a vasta opção de HA disponível no Exchange 2010, combinando isso com o Windows Server 2008 R2 temos um sistema de mensageria com Redundância, Balanceamento de carga e Farm de servidores.
Os recursos de redundância do Exchange 2010 vão alem do Database Availability Group (DAG).
Tendo isso em vista, vou levantar neste post todos os possíveis cenários de Alta Disponibilidade das Roles do Exchange Server 2010.
Lembrando que a ideia não é ensinar a criar este ambiente, mas demonstrar os possíveis cenários que podem ser criado no Exchange 2010.

Como todos sabem, o Exchange possui 4 principais funções para um ambiente de mensageria o Mailbox Server, Client Access Server (CAS), Hub Transport e Edge Transport (Incluo o Edge pois falaremos sobre envio e recebimento também). Tendo todas essas funções em mente, podemos começar a detalhar as opções de Redundância para o Exchange:

Mailbox Server
No Exchange 2010 é a função mais conhecida quando falamos de redundância, o recurso utilizado pelo Exchange 2010 para redundância é o Database Availability Group ou simplesmente DAG.

O DAG é um recurso poderoso e ao mesmo tempo bem simples de se configurar. Ele prover redundância em caso de falha de um Database ativo em um servidor Mailbox Server que faça parte de um nó de Cluster DAG. Cada banco de dados pode ter até 16 copias distribuídas entre os servidores Mailbox. Caso ocorra alguma falha em um dos database do Cluster DAG, o Active Directory informa aos servidores CAS daquele site em qual servidor esta o novo banco de dados ativo, Provendo assim uma redundância maior com menos custos de gerenciamento ou até mesmo hardware comparado as versões anteriores do Exchange.
E quando ocorre um corrompimento Logico do Banco dados? é possível fazer redundância?
Eu respondo, SIM é possível, mas esse assunto vou deixar para detalhar em um outro post.

Client Access Server
O Client Access para quem não conhece, é o serviço responsável pelo acesso dos clientes de e-mail, ele disponibiliza acesso ao OWA, Active Sync, Autodiscover, POP3, IMAP4 e RPC é claro (Microsoft Outlook) apenas o acesso a Public Folder continua sendo feito diretamente no Mailbox Server.

Existe um recurso no Exchange Server Client Access chamado CAS Array que cria uma Matriz de servidores CAS em cada site do Active Directory onde estão alocados aqueles servidores CAS. Mas lembre-se, o CAS Array não fornece redundância em caso de falha sozinho, precisamos combina-lo com o Cluster NLB do Windows Server 2008 para que os recursos possam ser distribuídos e redundante a falhas. Ou seja você possui o serviço CAS Array que agrupa os servidores e o Windows NLB que balanceia a carga de trabalho.

Hub Transport
O Hub Transport é a função que esta e foi feita na Floresta do Active Directory, isso porque os emails quando são enviados por um usuário que esta na floresta onde esta alocado este servidor Hub Transport são roteados por ele mesmo. Quando você envia um email para outra Floresta, neste momento o Hub entra em contato com o Active Directory procurando procurando por relação de confiança entre essas florestas, assim que estabelecida a confidencialidade ele procura pelo Hub Transport responsável pela floresta de destino, entregando assim a responsabilidade da entrega do email para este servidor.
A partir deste ponto de vista, vamos ao cenário de HA com Hub.
O Exchange 2007 começou implementando um recurso chamado Transport Dumpster que mantem uma fila para um domínio de email que foi enviado recentemente, possibilitando assim reutilização da fila sem necessidade de criação de novas.

No Exchange 2010 esse recurso foi customizado e aprimorado com redundância de sombra enquanto a mensagem esta em transito. Como isso funciona?
A mensagem é enviada ao destinatário, sendo que ela não é excluída enquanto o numero de saltos definidos de um domínio para outro for concluído com sucesso. Assim, quando você adiciona mais de 1 servidor Hub Transport na sua infraestrutura ele torna-se redundante a falha pois a mensagem será entregue mesmo que o servidor que estava responsavel pela entrega desta mensagem falhe. Sendo assim podemos afirmar que ao adicionar no minimo 2 servidores Hub Transport na nossa infraestrutura temos um ambiente redundante.

Edge Transport
Nesta função temos 2 pontos a verificar, redundância na comunicação do Hub Transport da rede interna com o Edge e redundância no envio das mensagens. Então vamos lá!
Criar redundância de Edge Transport para seu Hub Transport é bem simples, quando precisamos que nosso Edge Transport tenha algumas informações dos usuários do Active Directory, usamos o Edge Subscription que cria uma comunicação entre o Hub Transport e o Edge. Feito isso, o Subscription torna-se um grupo que contem os servidores Edge Transport que podem ser utilizados para envio de uma mensagem. Assim sempre que adicionarmos um novo servidor Edge a um Subscription ele torna-se um caminho alternativo para entrega de mensagem caso o principal falhe.
Agora para recebimento de email externo temos a opção de criar MX’s alternativos:

Eu particularmente utilizo registro MX com custos diferente, isso porque existem diversos problemas que podem ocorrer ao utilizar prioridades iguais para endereços MX diferente.
Lembrando que. O endereço de IP do MX necessariamente precisa ser o mesmo endereço de IP de saida dos emails, por questões de Blacklist e spam.

Para um ambiente sem indisponibilidade

Como todos nós sabemos, essa é uma pergunta que depende de muitos fatores, isso por que dependemos de Hardware, locais físicos para alocação dos servidores e muito mais. Fora que precisamos avaliar a necessidade do negocio, digo isso pois trabalho com alguns clientes que tem uma SLA maior para um cenário de indisponibilidade de envio email externo, mas ao mesmo tempo não pode ficar sem conseguir enviar e receber email entre os usuários da empresa, por esse motivo precisamos desenhar bem a nossa necessidade para depois investir no nosso ambiente de mensageria para prover alta disponibilidade. Sendo assim para um ambiente muito critico eu indicaria o seguinte cenário:

– No minimo 2 servidores Mailbox para fornecer o DAG, mantendo assim a integridade dos dados.
– 2 servidores CAS para criar um Cluster NLB, mantendo assim o acesso dos usuários sejam moveis, Web ou local.
– 2 servidores Hub Transport para o roteamento das mensagens em uma organização. Lembrando que quando você faz redundância de servidores Hub Transport o envio de mensagens para organizações parceiras continua disponível mesmo que o Edge Transport (ou outra solução de transporte de mensagens) esteja indisponível.
– 2 Edge Transport para garantir o envio e recebimento de email externo.

Assim, finalizamos aqui mais um artigo.
Aguardo você em um próximo post.

Att,

Publicidade