Office 365, latência e o GEO-DNS ou (A Inesperada Virtude do Conhecimento de Resiliência em Cloud)

By: Caio Ribeiro César e Robson Elias da Silva

Neste artigo, iremos focar em um problema comum em clientes do Brasil e América do Sul: latência.

A latência pode ocorrer em diversos cenários, como ações bulk no Exchange Admin Center, envio de e-mails Outlook, conexões OWA. Nem sempre o root cause é o que vamos discutir neste post, então inicie isolando o cenário (diferentes usuários, networks, computadores).

O vilão pode ser conhecido, e a solução muito simples. Antes de pular para a solução, vamos explicar o que clientes O365 e parceiros devem entender em questão de cloud, DNS, roundtrip e latência.

Primeiro vamos para a cloud. E-mails na nuvem, mas que nuvem?

O entendimento da localização da estrutura dos tenants é feito via cmdlet “Get-OrganizationConfig”:

Seguindo a tabela abaixo de localizações, temos o entendimento que:

1)      Tenant caiocbr15.onmicrosoft.com foi criado em uma estrutura de North America (NAMPR), o OriginatingServer localizando-se em “CY1”, Cheyenne, US;

2)      Tenant c4iocesar.onmicrosoft.com foi criado em uma estrutura de LATAM (LAMPR), o OriginatingServer localizando-se em “BLU”, Virginia, US;

Então vamos utilizar o segundo tenant (c4iocesar.onmicrosoft.com) como exemplo. Isto significa que todas as mailboxes estão localizadas em BLU? Não.

Como podemos ver no comando abaixo, as mailboxes estão localizadas em servidores diferentes:

get-mailbox | fl iden*,servername*

Identity   : aux.pg

ServerName : cp1pr80mb0453

Identity   : Barbosa BB. JJ

ServerName : blupr80mb1106

Identity   : caioc

ServerName : fr1pr80mb1730

Identity   : chuck

ServerName : grupr80mb172

Identity   : DiscoverySearchMailbox

ServerName : cp1pr80mb0391

Identity   : jude

ServerName : roxpr80mb1387

Identity   : stevbios

ServerName : grupr80mb0396

Identity   : diretor

ServerName : grupr80mb345

Identity   : testefrederico

ServerName : grupr80mb0747

Identity   : usercloud

ServerName : grupr80mb201

A Microsoft trata reliability e disponibilidade para clientes O365. Isto significa que existem cópias e localizações diferentes na cloud para cada tenant.

https://o365datacentermap.azurewebsites.net/

Aliás, quando falamos de cloud (depois de ter explicado o que é a cloud), as empresas que entregam soluções cloud fazem resiliência. Algumas GEO-resiliency, o que em high availability significa segurança (ou um aumento de availability level) .

A Microsoft possui estrutura de Exchange em dois datacenters LATAM (Brasil e Chile):

Isto não significa que mailboxes serão alocadas somente nos dois datacenters. Para tanto, temos reliability e high availability (consequentemente réplicas em outros datacenters).

Com o entendimento da estrutura, vamos a uma suposição comum de administradores: “minha estrutura ou mailbox está fora do BR [meu país], logo terei latência”.

Se o seu DNS apontar para o Brasil [ou o seu país de origem da conexão], não terá latência. O motivo é que a comunicação é feita via closest datacenter e, neste caso (Brasil), seria GRU. Se o DNS estiver apontando para outro país, como Estados Unidos, o roundtrip é maior e causa latência.

Se o meu computador apontar o DNS para US, significa que a comunicação é feita via web para os US. Se o DNS apontar para o BR, vai para o datacenter de GRU e consequentemente via fibra para US (caso a mailbox esteja localizada em US).

Vamos utilizar algo muito simples para explicar isso: nslookup e ping.

Utilizando um DNS localizado nos Estados Unidos e tendo a mailbox em BLU ou San Antonio (SN), o entendimento é que a conexão é feita com “outlook-namnorthwest2” e consequentemente tenho latência, por estar no Brasil:

Veja a diferença da latência para um request para o mesmo FQDN (outlook.office365.com). Inicialmente, com o DNS apontando para os EUA, temos um tempo de 171ms vs. o DNS apontando para o Brasil, com um tempo de 15ms. Note também a diferença da resolução de nome para o FQDN:

A latência ocorre, pois o roundtrip é maior. Consequentemente, os produtos (OWA/Outlook/Skype/Sharepoint) terão latência.

A mailbox abaixo está localizada em “cp1”. O computador possui um DNS apontando localmente para o BR:

Ao anexar um arquivo de 25MB, o POST demora cerca de 27 segundos:

Quando utilizamos um DNS localizado nos Estados Unidos, o POST demora cerca de 36 segundos:

Aproveitando esse cenário de latência em simples “POST”, vamos adicionar um pouco mais de complexidade - uma comparação, por exemplo, um arquivo de aproximadamente 20MB sendo anexado via OWA costuma levar cerca de 5 segundos, considerando que você esteja utilizando um DNS baseado em sua região (em nosso caso, Brasil).

Se fizermos upload deste mesmo arquivo via Outlook, e estivermos utilizando um DNS baseado em US, o tempo total de upload aumentará exponencialmente, e gastaremos aproximadamente 5 minutos.

Isso ocorre primeiramente porque o Outlook não utilizará a mesma largura de banda que o processo de upload via OWA, uma vez que o Outlook utiliza RPC/HTTP ou MAPI/HTTP - sendo assim, o Outlook está encapsulando o request dentro do protocolo HTTP e não o utilizando diretamente.

Este encapsulamento faz com que a requisição seja dividida em pacotes menores de 32kb cada, então um anexo de 20MB será dividido em aproximadamente 640 pacotes. Esse número grande de pequenos pacotes junto com uma latência alta irá aumentar o tempo de envio e, consequentemente, quanto maior for a latência entre o cliente Outlook e o servidor Exchange, maior será o tempo para o envio de e-mail.

Portanto, utilizar um DNS baseado em sua região irá resultar em um roundtrip menor, melhorando exponencialmente a performance na utilização do produto.

Cenários de mailbox migration, OneDrive upload (GB’s), Outlook efetuando download do .ost: a diferença de tempo é perceptível para o usuário final/administrador.

“O meu DNS já aponta para um DNS do Brasil [Argentina,Chile,Uruguai, etc], porém minha conexão está com o mesmo delay e a resposta vem de US”. Alguns provedores DNS utilizam forwarders para os Estados Unidos. Exclusões de forwarder para o FQDN de office365 podem ser solicitadas diretamente com o seu provedor (ou utilize um DNS diferente).

Imagine então um segundo cenário. A mailbox em GRU (Brasil), e o DNS apontando para os EUA. O roundtrip seria algo explicado neste vídeo.

Para clientes com acesso ao channel9, recomendamos a sessão abaixo, que detalha os cenários discutidos:

https://channel9.msdn.com/Events/Ignite/2015/BRK4121

If you want this blog post to be translated to your language, please comment below. Thank you.