Exchange Server – Qual o limite máximo de recursos de hardware em um servidor Exchange?

 

image

Olá galera,

Esse artigo de hoje é para explicar um tema bem interessante, e muitas vezes pouco discutido pelos administradores de TI que fazem a gestão de seu ambiente, seja ele de Exchange Server ou de qualquer outra tecnologia. Até de tecnologias não-Microsoft, por exemplo. Sempre que há um sizing (definição dos recursos a serem utilizados pela arquitetura), a preocupação é sempre com o mínimo de recursos a serem quantificados para elaboração deste projeto. Mínimo de memória RAM, mínimo de CPU, mínimo de capacidade do disco, velocidade de IOPS da Storage. Tudo isso é realmente importante e necessário.

Mas e a quantificação de recursos máximos para um servidor? Já parou pra pensar que seu sistema pode ter limitações quanto ao máximo de recursos adicionados ao seu ambiente, para funcionamento dos seus serviços? Essa é a nossa discussão de hoje, frente a um cenário muitas vezes despercebido pela galera de infraestrutura. Nem sempre o jargão “quanto mais, melhor” serve para nossos dias atuais. E qual o motivo disso? Vamos explicar agora.

O ambiente de Exchange Server possui algumas especificidades quanto a sua capacidade de utilização e gestão de recursos de hardware, principalmente no que diz respeito a memória RAM. Essas suas especificidades se dão por conta de algumas configurações que foram inseridas no produto, afim de fazer com que seu funcionamento pudesse ser adequado a realidade dos dias em que o produto fora lançado, e pudesse ser um produto que atendesse as necessidades estratégicas do mercado, mas sem se tornar um monstro insaciável de recursos. Uma destas incríveis características que foram inseridas no Exchange Server para otimizar seu funcionamento se chama Mailbox Database Cache. Esse recurso basicamente utiliza-se da memória RAM disponível no servidor alocando informações das databases, para evitar com que o disco seja consultado a todo momento para uma leitura, e assim gere uma quantidade de I/O (Input/Output) maior do que o suportado. Isso, na época em que foi lançado, revolucionou a gestão de recursos, uma vez que a velocidade dos discos era extremamente lenta.  Com isso, o aumento do consumo de RAM aumentou consideravelmente, principalmente nos servidores que abrigavam as databases do ambiente de Exchange Server.

Até então, os servidores de Exchange Server 2010 não tinham uma quantidade máxima de recursos recomendada. Era apenas um guideline, quase que uma recomendação baseada no quanto você pode pagar e no quanto seu servidor e Sistema Operacional suportam. Podemos observar em uma das documentações do TechNet sobre o Exchange 2010, a seguinte afirmação:

image

Ok, até então tudo certo. Mas e como fica então a evolução disso, e da utilização e definição de sizing do ambiente frente à crescente queda dos preços de hardware e consequente aquisição de servidores com monstruosas configurações? Até onde o Sistema Operacional e as aplicações saberão lidar com tanta capacidade de recursos assim? Pensando nisso, o time de Produto de Exchange começou a trabalhar em cima de uma recomendação para este tipo de cenário, podendo ser considerado um limite do Oversizing suportado pelo Exchange Server.

Com isso, a partir do Exchange Server 2013, foram inseridas recomendações e limites de suportabilidade para que o Exchange pudesse realizar melhor o gerenciamento destes recursos. Por exemplo, no Exchange há uma função de garbage collector embutida pelo .NET, que tem a função de auxiliar no controle da contínua e dinâmica alteração de requests dos recursos, seja de memória, throughput de rede, e outros. Por conta dessa função, o garbage collector é instanciado de acordo com a quantidade de cores de processamento existentes. Uma vez que essa quantidade está acima do aceitável, pode comprometer o funcionamento do recurso, impactando no framework do Exchange Server e podendo causar indisponibilidades.

Há muitos questionamentos e perguntas de “como um oversizing pode causar problemas”e quais seriam estes, para que eu possa decidir se quero correr o risco ou não. Mas a explicação do Jeff Mealife, Program Manager de Office 365, foi a melhor: “Esta é uma pergunta muito difícil de responder, quase impossível. Há inúmeras coisas que podem dar errado em uma larga escala de sizing do ambiente. Desde problemas de High CPU, como o descrito no artigo do Marc Nivens (citado nas referências como Troubleshooting High CPU), como deslocar os recursos da arquitetura de Exchange para trabalhar com outras demandas de alocação de recursos, quando poderia estar dedicados a resolver e processar suas cargas de trabalho e funcionamento. O Exchange foi projetado para um tipo de servidor de médio-porte, e nenhum refinamento foi feito para ele suportar além disso”.

Acho que depois desta explicação, não precisamos gastar muito mais falando sobre. Winking smile

Mas gostaria de deixar aqui as duas últimas recomendações de escalabilidade mais atuais, tanto para ambientes com Exchange Server 2013 e Exchange Server 2016. Sendo assim, este artigo também servirá para aqueles que precisarem consultar quais as recomendações e definições para implantação do seu ambiente de mensageria, e também para não terem equívocos na hora de adquirir hardware e definir sua arquitetura corporativa.

 

image

 

O mais interessante é saber que estes valores mensurados não foram definidos aleatoriamente, mas sim com base no estudo das capacidades de cada versão do Exchange Server e sua consequente utilização em larga escala no Office 365 através do Exchange Online, que hoje já é o serviço de mensageria mais utilizado no mundo, com mais de 100 mi de usuários ativos no mundo. Então, a Microsoft sabe como definir uma boa arquitetura dos seus produtos, uma vez que a Nuvem também tem servido como ambiente de amadurecimento das aplicações antes de serem lançadas na sua versão On-Premises. Todas essas recomendações, arquiteturas preferenciais e análises foram feitas baseadas na usabilidade do serviço nos maiores datacenters do mundo, no que com certeza é o maior cenário de implantação de Exchange Server de todos os tempos.

Espero que este artigo lhes auxilie nas dúvidas.

 

Referências:

Understanding the Mailbox Database Cache

Understanding Memory Configurations and Exchange Performance

Ask the Perf Guy: How big is too BIG?

Troubleshooting High CPU utilization issues in Exchange 2013

The .NET Framework 4.5 includes new garbage collector enhancements for client and server apps

Ask the Perf Guy: Update to scalability guidance for Exchange 2016

 

TechNet Wiki: https://social.technet.microsoft.com/wiki/pt-br/contents/articles/41818.exchange-server-qual-o-limite-maximo-de-recursos-de-hardware-em-um-servidor-exchange.aspx

 

Bruno Lopes – MVP Office Servers and Services

Anúncios

Sobre MVP Bruno Lopes

Profissional MBA em Redes de Computadores e Telecomunicações, MVP Microsoft e atualmente Technical Trainer e Engenheiro de Suporte na Microsoft/Wipro, especialista em Exchange/Office 365; sou mais um voluntário desta grande pátria de blogueiros a me dedicar em prol das informações compartilhadas à todos...Se já me salvou um dia, creio que ajudará a muitos mais...

Publicado em 28/09/2017, em Exchange Server, Servidores Windows e marcado como , , , , , , . Adicione o link aos favoritos. Deixe um comentário.

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

%d blogueiros gostam disto: