Previsão da largura de banda do cliente Exchange – o problema de fuso horário…

Artigo original publicado na quarta-feira, 20 de junho de 2012

Atualização 22/6/12 - Este artigo e o download anexado foram atualizados.

A última versão da Calculadora de largura de banda de rede do cliente Exchange inclui várias atualizações, mas sem dúvida a mais significante é o suporte ao fuso horário. Eu tenho procurado sobre como lidar com o problema de fuso horário pelos últimos 12 meses e demorou um pouco para achar uma solução prática. No entanto, estou me antecipando, então vamos ver primeiro qual é o problema real com o fuso horário.

Qual é o problema com fuso horário?

Eu irei assumir que todos saibam o que é fuso horário e porque temos eles. No entanto, para aqueles que desejam saber mais, recomendo ler o artigo abaixo no Wikipédia;

https://en.wikipedia.org/wiki/Time_zone

O problema real com fuso horários de uma perspectiva de previsão de largura de banda de rede é que podemos estar tentando modelar cargas de trabalho de usuários em diferentes partes do mundo que compartilham a mesma conexão de rede ou o mesmo serviço final. Isto nos causa um problema porque os tempos de pico de uso da maioria dos usuários está relacionado ao seu fuso horário local;

Por exemplo, se vermos um dia comercial normal para uma organização média de 1.000 usuários, vemos dois picos típicos, um na manhã por volta das 10 horas que dura por 2 horas e um pela tarde por volta das 14 horas que dura por 4 horas. Quando imprimimos isso, se parecerá com;

Agora, vamos imaginar que estamos modelando os requisitos para 5 locais diferentes no mundo, cada um suportando 1.000 usuários acessando um recurso compartilhado em Nova Iorque. Neste ponto, vamos assumir que o recurso compartilhado é um balanceador de carga do Exchange 2010 local (eu acho que escolheria um exemplo local para variar)

• Londres (GMT) = 1.000 usuários
• Warsaw (GMT+1) = 1.000 usuários
• Jacarta (GMT+7) = 1.000 usuários
• Redmond (GMT-8) = 1.000 usuários
• Nova Iorque (GMT-5) = 1.000 usuários

Se modelarmos usando nossa técnica herdada de prever o pico de cada conjunto de usuários e agrupá-los, obtemos o seguinte;

O que este gráfico está mostrando é que cada local de 1.000 usuários exige cerca de 1,56Mbits/seg de largura de banda no pico cada dia e, portanto, quando adicionamos todos em uma conta para todos os usuários compartilhando o balanceador de carga em Nova Iorque, obtemos um requisito de pico de 7,81Mbits/seg. Isto é como lidamos com o planejamento de largura de banda para usuários distribuídos, prevendo seus requisitos de pico e permanecendo com eles em uma tabela e agrupando-os.

O problema aqui é que os usuários na Europa irão para casa quando os usuários em Redmond estão acordando e os usuários em Jacarta irão dormir!

Se levamos os fusos horários destes locais em consideração, o gráfico muda muito;

Este gráfico mostra como as cargas de trabalho realmente combinariam para formar um perfil de uso muito diferente do que teríamos planejado. O que é realmente interessante é que nossa carga de trabalho de pico é muito menor a apenas 3,78Mbits/seg (nossa previsão original era de 7,81Mbits/seg). O perfil de uso também é muito diferente da nossa previsão original.

Como podemos lidar com este problema?

Bem, como você pode ter adivinhado nos gráficos acima, aumentamos a calculadora de rede para permitir incluir detalhes de fuso horário!

O que realmente fizemos para obter isso foi abandonar a ideia de prever apenas a carga de trabalho de pico e prevemos agora o uso por hora do dia com base nos padrões de uso fornecidos quando é o horário de pico matinal, o horário de pico da tarde, etc. Isto permite que a calculadora saiba não apenas quando seu pico de uso será, mas também qual será o uso no resto do dia. Quando conhecemos esta curva, é possível agrupar dados em uma conta para fuso horários.

Alguém realmente faz uma única consolidação?

Bem, a resposta simples é sim – várias organizações estão consolidando cargas de trabalho o máximo possível. Isto exige que as equipes de criação planejem cargas de trabalho de serviço de usuários muito distribuídos; frequentemente com perfis diferentes em fuso horários diferentes. Isto é especialmente comum quando a carga de trabalho é movida para a nuvem desde que o Office 365 ofereça apenas locais de inquilino regional único e para uma organização global usando o Office 365 terá que planejar uma grande proporção de seus usuários acessando o serviço em uma região/país e fuso horário totalmente diferente, frequentemente por uma infraestrutura compartilhada.

Vários clientes com quem trabalho também estão consolidando vários pequenos centros de dados em menos centros de dados maiores – estes locais consolidados podem lidar com a carga de trabalho dos usuários distribuídos anteriormente, frequentemente estes usuários estarão em fuso horários diferentes e portanto, quando tentamos acomodar sua carga de trabalho, precisamos de uma forma de descobrir como eles irão se combinar com outras cargas de trabalho distribuídas.

Obviamente, se todos os seus usuários estão no mesmo fuso horário, você não precisa se preocupar com tudo isso e apenas use a calculadora normalmente.

Usando o novo recurso de fuso horário

Ok, você tem o cenário que exige suporte de fuso horário. Como eu uso ele?

Primeiro, precisamos configurar a tabela de configuração TimeZone na folha de entrada. Os parâmetros inseridos aqui controlam a forma que a curva de uso é usada para combinar as cargas de trabalho. Os valores precisam refletir os padrões de uso médios dentro da sua organização. Eu geralmente olho para os dados de desempenho executando em servidores do Exchange para criar isso, combinado com perguntar ao cliente como eles acham que seus usuários trabalham e quais são seus horários de pico.

Quando a folha de entrada estiver concluída, movemos para a folha Mix do Cliente – onde temos duas novas áreas para configurar os dados de fuso horário.

Primeiro é o Modelo de Fuso Horário, que apresenta o fuso horário do recurso que estamos planejando, isto é, o link de rede ou balanceador de carga. No exemplo anterior, é possível ver que eu definir a zona de fuso horário para GMT-5 para Nova Iorque, que é onde está nosso balanceador de carga.

A seguir, temos uma nova coluna chamada TimeZone – isto representa o fuso horário de cada local em relação ao GMT (observe que eu sou inglês e coloquei GMT, mas podemos usar UTC no futuro se houverem muitas reclamações).

A previsão resultante é exibida em um gráfico abaixo da tabela mix do cliente mostrada anteriormente. Os valores nesta tabela são Mbits/seg e representa a previsão de uso de rede em cada hora do dia.

Um bônus

Um outro bom recurso é que a calculadora oferecerá uma tabela que pode ser copiada na Calculadora de Função da Caixa de Correio para ajudar com a previsão de replicação da rede DAG.

Se você olhar à direita da tabela de previsão (Folha de Mix do Cliente) na Calculadora de Rede, verá uma tabela que contém uma % de alterações por hora do dia... se copiar isto para sua área de transferência...

Role para a parte inferior da folha de Entrada na Calculadora de Função do Servidor de Caixa de Correio, você encontrará uma tabela para a Configuração de Replicação de Log. Cole os números da Calculadora de Rede nesta tabela.

Pronto, a Calculadora de Função do Servidor de Caixa de Correio poderá prever os requisitos de largura de banda para replicação DAG levando em consideração os dados da sua organização e a configuração de fuso horário!

Conclusão

Esperamos que este novo recurso ajude vários de vocês a prever com precisão seus requisitos de largura de banda de rede; não é necessário para todas as implantações, mas para aqueles arquitetos de grandes empresas que estão tendo dificuldades com este problema. Espero que o recurso de fuso horário ajude.

Continue a fornecer seus valiosos comentários - positivos e negativos para o endereço netcalc@microsoft.com. Adoramos ler seus comentários!

Neil Johnson
Consultor Sênior, MCS RU

Esta é uma publicação localizada. Encontre o artigo original em Exchange Client Bandwidth Prediction – the time zone problem…