Na postagem anterior, Parte 4, realizamos a implementação do Exchange Server 2019, agora vamos falar um pouco da arquitetura do Exchange Server 2019 de forma descomplicada!

  1. Consolidação dos Serviços

O Exchange Server 2016 e o Exchange Server 2019 consolidam todas as funções no servidor de Caixa de Correio, exceto a função de servidor Transporte de Borda

O servidor de caixa de correio hospeda os serviços front-end e back-end
No Exchange Server 2016, todas as solicitações de clientes, exceto as de Unificação de Mensagens, são enviadas por proxy para os serviços de back-end no servidor de Caixa de Correio

A função de Unificação de Mensagens foi removida do Exchange Server 2019

A consolidação de funções oferece vários benefícios em custo, gerenciamento e escalabilidade
  1. Arquitetura Preferida (PA)
Arquittura
Com o lançamento do Exchange 2013 foi iniciado pela Microsoft a atualização de arquitetura preferida pela fabricante, o Exchange Permite que você desenha sua arquitetura da forma como melhor puder te atender, no entanto, o time de engenheiros da Microsoft tem uma recomendação de uma PA, recomendo que seja analisado sempre as boas praticas recomendado pelo fabricante, se for alterar alguma coisa que esteja ciente do que esta fazendo e documente tudo.

Os requisitos que foram usadas para criação da PA tiverem como foco o negocio em si dos clientes que usam o Exchange Server 2019, visando os seguintes pontos:

  • Incluir alta disponibilidade no datacenter e resiliência de site entre data centers
  • Dar suporte a várias cópias de cada banco de dados, permitindo a ativação rápida
  • Reduzir o custo da infraestrutura de mensagens
  • Aumentar a disponibilidade otimizando os domínios de falha e reduzindo a complexidade

Mesmo existindo ambientes diferentes é recomendado que seja seguido o máximo possível a PA recomendada pela microsoft, caso seja necessário desviar o foco, que seja feito apenas no ponto necessário, o restante pode ser seguido a risca.

O PA cobre as quatro áreas de foco a seguir:

  1. Design de namespace
  2. Design de par de data center resistente ao site
  3. Design de servidor
  4. Design de grupo de disponibilidade de banco de dados
* Clicando nos links você e direcionado as paginas correspondentes no site da Microsoft.

Design de namespace

Recomendo a leitura dos artigos sobre planejamento de namespace e balanceamento de carga para o Exchange Server 2016, Ross Smith IV descreveu as várias opções de configuração que estavam disponíveis com o Exchange 2016 e esses conceitos continuam a ser aplicados ao Exchange Server 2019, então uma boa forma de começar a entender o design de Namespace e entendo como é aplicado no Exchange 2016, uma vez que as mudanças não foram muito extensas. 

Para o Namespace é recomendado que os serviços sejam associados ao Data Center especifico, caso os usuários acessem apenas este data center ou que não sejam associados, desta forma os usuários acessam qualquer data center disponivel.

se sua organização possui apenas um data center é obvio que você vai acessar apenas ele, ok?

A Arquitetura Recomendada e de modelo não associado, desta forma a implementação de um único namespace do Exchange por protocolo, assim os usuários acessam qualquer data center que esteja disponível (onde cada datacenter é considerado para representar seu próprio site do Active Directory-Veja mais detalhes sobre isso abaixo ).

Por exemplo:

  • Para o serviço de descoberta automática: autodiscover.chesley.com.br
  • Para clientes HTTP: mail.chesley.com.br
  • Para clientes IMAP: imap.chesley.com.br
  • Para clientes SMTP: smtp.chesley.com.br

Utilizando a Camada 7 do modelo OSI é recomendado a adoção do DNS ROUN ROBIN caso você não possua uma solução mais robusta, lembrando sempre que o DNS ROUND ROBIN divide o trafego em 50% entre os pares e não faz balanceamento de carga, essa solução é mais simples e menos complexa de se implementar.

Manter um TTL baixo para os registros de DNS associados a arquitetura Exchange é uma boa pratica, se caso precise alterar algum registro ou mudar algum datacenter com o TTL baixo você passa a ter capacidade de realizar essas mudanças de forma mais célere.

Se você possui registro com mais de 24 horas, eu já gente com registro configurado de mais de 48 horas, pode levar mais de um dia para que os caches DNS Downstream sejam atualizados corretamente, isso significa que você pode ficar off line para alguns clientes.

 

Recursos que foram Descontinuados
Recursos descontinuados do Exchange Server 2016:
Unificação de Mensagens

 

Recursos descontinuados do Exchange Server 2013:

  • Servidor de Acesso para Cliente
  • Biblioteca MAPI sobre Collaboration Data Objects (MAPI / CDO)

Recursos não enfatizados do Exchange Server 2019:

  • RPC sobre HTTP
  • Suporte ao grupo de disponibilidade do banco de dados para pontos de acesso
  • administrativo do cluster de failover
  • APIs de replicação que não são da Microsoft
Na próxima postagem estaremos falando sobre os outros pontos relevantes da Arquitetura do Exchange Server, desta maneira podemos entender um pouco mais sobre o por que devemos configurar o servidor Exchange seguindo as melhores praticas.