Solução de problemas de desempenho de rede

Visão geral

O Azure oferece uma maneira estável e rápida de se conectar sua rede local ao Azure. Métodos como VPN Site a Site e ExpressRoute são usados com êxito por clientes de todos os tamanhos para executar seus negócios no Azure. Mas o que acontece quando o desempenho não atende às suas expectativas ou experiências anteriores? Este artigo pode ajudar a padronizar a maneira de testar e fazer uma linha de base específica de seu ambiente.

Você aprenderá a testar a latência e a largura de banda da rede entre dois hosts com facilidade e consistência. Você também receberá conselhos sobre como examinar a rede do Azure para ajudar a isolar pontos problemáticos. O script do PowerShell e as ferramentas abordadas exigem dois hosts na rede (em ambas as extremidades do link que está sendo testado). Um host deve ser um Windows Server ou Desktop, e o outro pode ser Windows ou Linux.

Componentes de rede

Antes de nos aprofundarmos na solução de problemas, vamos falar sobre alguns termos e componentes comuns. Esta discussão garante que nos lembremos de cada componente na cadeia de ponta a ponta que permite a conectividade no Azure.

No nível mais alto, existem três principais domínios de roteamento de rede:

• A rede do Azure (nuvem azul)
• Internet ou WAN (nuvem verde)
• A Rede Corporativa (nuvem laranja)

Examinando o diagrama da direita para a esquerda, vamos discutir brevemente cada componente:

• Máquina virtual – o servidor pode ter várias NICs. Certifique-se de as rotas estáticas, as rotas padrão e as configurações do sistema operacional estejam enviando e recebendo tráfego da forma você pensa que estão. Além disso, cada SKU de VM tem uma restrição de largura de banda. Se você estiver usando um SKU de VM menor, o tráfego será limitado pela largura de banda disponível para a NIC. É recomendável usar um DS5v2 para teste para garantir a largura de banda adequada na VM.

• NIC – certifique-se de saber qual IP privado está atribuído à NIC em questão.

• NSG da NIC - Pode haver NSGs específicos aplicados no nível da NIC. Certifique-se de que o conjunto de regras de NSG é adequado para o tráfego que você está tentando passar. Por exemplo, certifique-se de que as portas 5201 para iPerf, 3389 para RDP ou 22 para SSH estejam abertas para permitir a passagem do tráfego de teste.

• Sub-rede da VNet - A NIC é atribuída a uma sub-rede específica. Verifique se você sabe qual é e as regras associadas a essa sub-rede.

• NSG da Sub-rede - Assim como a NIC, os NSGs também podem ser aplicados no nível da sub-rede. Certifique-se de que o conjunto de regras de NSG é adequado para o tráfego que você está tentando passar. Para o tráfego de entrada na NIC, o NSG da sub-rede é aplicado primeiro e, em seguida, o NSG da NIC. Quando o tráfego sai da VM, o NSG da NIC é aplicado primeiro e, em seguida, o NSG da Sub-rede.

• UDR de sub-rede: as rotas definidas pelo usuário podem direcionar o tráfego para um salto intermediário (como um firewall ou balanceador de carga). Certifique-se de que você sabe se há um UDR em vigor para o tráfego. Nesse caso, entenda onde vai e o que o próximo salto fará em seu tráfego. Por exemplo, um firewall pode passar algum tráfego e negar outro entre os mesmos dois hosts.

• NSG/UDR de sub-rede de gateway – assim como a sub-rede de VM, a sub-rede de gateway pode ter NSGs e UDRs. Verifique se eles existem e que efeitos têm sobre seu tráfego.

• Gateway de Rede Virtual (ExpressRoute) – uma vez que o emparelhamento (ExpressRoute) ou VPN estiver habilitado, não haverá muitas configurações que podem afetar como ou se o tráfego é roteado. Se você tiver um Gateway de rede virtual conectado a vários circuitos do ExpressRoute ou túneis VPN, deverá estar ciente das configurações de peso da conexão. O peso da conexão afeta a preferência de conexão e determina o caminho que o tráfego leva.

• Filtro de rota (não mostrado): um filtro de rota é necessário ao usar o emparelhamento da Microsoft por meio do ExpressRoute. Se você não estiver recebendo rotas, verifique se o filtro de rota está configurado e aplicado corretamente ao circuito.

Neste ponto, você está na parte WAN do link. Esse domínio de roteamento pode ser o seu provedor de serviços, sua WAN corporativa ou a Internet. Há muitos saltos, dispositivos e empresas envolvidos nesses links, o que pode dificultar a solução de problemas. Você precisa primeiro fazer a regra para o Azure e suas redes corporativas antes de poder investigar os saltos entre eles.

No diagrama anterior, na extrema esquerda, está sua rede corporativa. Dependendo do tamanho da sua empresa, esse domínio de roteamento pode ser de alguns dispositivos de rede entre você e a WAN ou várias camadas de dispositivos em uma rede de um campus ou uma empresa.

Dada a complexidade desses três ambientes de rede de alto nível diferentes, geralmente é ideal começar pelas bordas e tentar mostrar onde o desempenho é bom e onde ele se degrada. Essa abordagem pode ajudar a identificar o domínio do problema de roteamento entre os três. Em seguida, você pode concentrar sua solução de problemas nesse ambiente específico.

Ferramentas

A maioria dos problemas de rede podem ser analisados e isolados usando ferramentas básicas, como o ping e o rastreamento de rotas. É raro você ter que avançar até uma análise de pacotes usando ferramentas como Wireshark.

Para ajudar na solução de problemas, o AzureCT (Kit de ferramentas de conectividade do Azure) foi desenvolvido para colocar algumas dessas ferramentas em um pacote simples. Para testes de desempenho, ferramentas como iPerf e PSPing podem fornecer informações sobre a sua rede. O iPerf é uma ferramenta comumente usada para testes básicos de desempenho e é bastante fácil de usar. O PSPing é uma ferramenta de ping desenvolvida pelo SysInternals. O PSPing pode fazer pings de ICMP e TCP para alcançar um host remoto. Ambas as ferramentas são leves e são "instaladas" simplesmente copiando os arquivos para um diretório no host.

Essas ferramentas e métodos estão encapsuladas em um módulo do PowerShell (AzureCT) para que você possa instalar e usar.

AzureCT – o Kit de ferramentas de conectividade do Azure

O módulo do PowerShell do AzureCT inclui dois componentes: Teste de Disponibilidade e Teste de Desempenho. Esse documento se concentra no Teste de Desempenho, especificamente nos dois comandos de Desempenho de Link nesse módulo do PowerShell.

Aqui estão as três etapas básicas para usar esse kit de ferramentas para o Teste de Desempenho:

1. Instalar o Módulo do PowerShell

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   

   Esse comando baixa e instala o módulo do PowerShell localmente.

2. Instalar os Aplicativos de Suporte

   Install-LinkPerformance
   

   Esse comando AzureCT instala o iPerf e o PSPing em um novo diretório C:\ACTTools e abre as portas do Firewall do Windows para permitir o tráfego ICMP e da porta 5201 (iPerf).

3. Executar o Teste de Desempenho

   Primeiro, no host remoto, instale e execute o iPerf no modo de servidor. Verifique se o host remoto está escutando na 3389 (RDP para Windows) ou na 22 (SSH para Linux) e permitindo o tráfego na porta 5201 para o iPerf. Se o host remoto for Windows, instale o AzureCT e execute o comando Install-LinkPerformance para configurar o iPerf e as regras de firewall necessárias.

   Quando o computador remoto estiver pronto, abra o PowerShell no computador local e inicie o teste:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Esse comando executa uma série de testes de carga e latência simultâneos para estimar a capacidade de largura de banda e a latência do link de rede.

4. Revisar a Saída do Teste

   O formato da saída do PowerShell é semelhante a:

   

   Os resultados detalhados de todos os testes iPerf e PSPing são salvos em arquivos de texto individuais no diretório de ferramentas do AzureCT em C:\ACTTools.

Solução de problemas

Se os resultados do teste de desempenho não forem os esperados, siga uma abordagem sistemática para identificar o problema. Dado o número de componentes no caminho, um processo passo a passo é mais eficaz do que testes aleatórios.

Observação

Essa é uma situação de um problema de desempenho e não de um problema de conectividade. Para isolar problemas de conectividade na rede do Azure, siga o artigo Verificar a conectividade do ExpressRoute.

1. Desafiar suas suposições

   Verifique se suas expectativas são razoáveis. Por exemplo, com um circuito do ExpressRoute de 1 Gbps e 100 ms de latência, esperar o tráfego total de 1 Gbps é irreal devido às características de desempenho do TCP em links de alta latência. Consulte a Seção de Referências para obter mais informações sobre suposições de desempenho.

2. Iniciar na borda da rede

   Comece nas bordas entre domínios de roteamento e tente isolar o problema em um único domínio de roteamento principal. Evite culpar a "caixa preta" no caminho sem uma investigação completa, pois isso pode atrasar a resolução.

3. Criar um diagrama

   Desenhe um diagrama da área em questão para trabalhar metodicamente e isolar o problema. Planeje pontos de teste e atualize o mapa à medida que você limpa áreas ou obtém mais detalhes.

4. Dividir e conquistar

   Segmente a rede e reduza o problema. Identifique onde funciona e onde não funciona e continue movendo seus pontos de teste para isolar o componente ofensivo.

5. Considerar todas as camadas OSI

   Embora seja comum focar na rede e nas camadas 1 a 3 (camadas Física, Dados e Rede), lembre-se de que os problemas também podem ocorrer na Camada 7 (camada de Aplicativo). Mantenha a mente aberta e verifique todas as suposições.

Solução de problemas avançada do ExpressRoute

Isolar componentes do Azure pode ser um desafio se você não souber onde está a borda da nuvem. Com o ExpressRoute, a borda é um componente de rede chamado Microsoft Enterprise Edge (MSEE). O MSEE é o primeiro ponto de contato na rede da Microsoft e o último salto ao sair dela. Quando você cria uma conexão entre o gateway de rede virtual e o circuito do ExpressRoute, está se conectando ao MSEE. Reconhecer o MSEE como o primeiro ou último salto é essencial para isolar um problema de rede do Azure. Saber a direção do tráfego ajuda a determinar se o problema está no Azure ou mais downstream na rede WAN ou corporativa.

Observação

O MSEE não está na nuvem do Azure. O ExpressRoute está na borda da rede da Microsoft, não no Azure. Depois de se conectar com o ExpressRoute a um MSEE, você estará conectado à rede da Microsoft, permitindo o acesso a serviços de nuvem como o Microsoft 365 (com Emparelhamento da Microsoft) ou o Azure (com Emparelhamento Privado e/ou da Microsoft).

Se duas VNets estiverem conectadas ao mesmo circuito do ExpressRoute, você poderá realizar testes para isolar o problema no Azure.

Plano de teste

1. Execute o teste Get-LinkPerformance entre a VM1 e a VM2. Esse teste fornece informações sobre se o problema é local. Se o teste produzir resultados aceitáveis de latência e largura de banda, você poderá marcar a rede virtual local como boa.

2. Supondo que o tráfego de rede virtual local seja bom, execute o teste Get-LinkPerformance entre a VM1 e VM3. Esse teste exerce a conexão pela rede da Microsoft até a MSEE, retornando para o Azure. Se o teste produzir resultados aceitáveis de latência e largura de banda, você poderá marcar a rede do Azure como boa.

3. Se o Azure for descartado, execute testes semelhantes na rede corporativa. Se esses testes também forem aprovados, trabalhe com seu provedor de serviços ou ISP para diagnosticar a conexão WAN. Por exemplo, execute testes entre duas filiais ou entre seu desk e um servidor de data center. Encontre pontos de extremidade, como servidores e PCs cliente, que possam usar o caminho que você está testando.

Importante

Para cada teste, marque a hora do dia e registre os resultados em um local comum. Cada execução de teste deve ter a mesma saída para comparação de dados consistentes. A consistência em vários testes é o principal motivo para usar o AzureCT para solução de problemas. A chave é obter saída de teste e dados consistentes todas as vezes. Registrar a hora e ter dados consistentes é especialmente útil se o problema for esporádico. Seja diligente com a coleta de dados antecipadamente para evitar horas de repetição dos mesmos cenários.

O problema está isolado, e agora?

Quanto mais você isolar o problema, mais rápido a solução poderá ser encontrada. Às vezes, você chega a um ponto em que não pode prosseguir com a solução de problemas. Por exemplo, você pode ver o link do seu provedor de serviços dando saltos pela Europa quando espera que ele permaneça na Ásia. Nesse ponto, peça ajuda com base no domínio de roteamento em que você isolou o problema. Restringir a um componente específico é ainda melhor.

Para problemas de rede corporativa, seu departamento interno de TI ou provedor de serviço pode ajudar com configuração de dispositivo ou reparo de hardware.

Para problemas de WAN, compartilhe seus resultados de teste com seu Provedor de Serviços ou ISP para ajudá-los no trabalho e evitar tarefas redundantes. Eles podem querer verificar seus resultados com base no princípio de confiança, mas verificação.

Para problemas do Azure, depois de isolar o problema com o máximo de detalhes possível, revise a Documentação da Rede do Azure e, se necessário, abra um tíquete de suporte.

Referências

Expectativas de largura de banda/latência

Dica

A distância geográfica entre os pontos de extremidade é o maior fator de latência. Embora a latência do equipamento (componentes físicos e virtuais, número de saltos etc.) também desempenhe uma função, a distância da execução da fibra, e não a distância em linha reta, é o principal colaborador. Essa distância é difícil de medir com precisão, por isso usamos frequentemente uma calculadora de distância da cidade para uma estimativa aproximada.

Por exemplo, configuramos um ExpressRoute em Seattle, Washington, EUA. A tabela abaixo mostra a latência e a largura de banda observadas ao testar em vários locais do Azure, juntamente com as distâncias estimadas.

Configuração do teste:

• Um servidor físico executando o Windows Server 2016 com NIC de 10 Gbps, conectado a um circuito do ExpressRoute.

• Um circuito do ExpressRoute Premium de 10 Gbps com Emparelhamento Privado habilitado.

• Uma rede virtual do Azure com um gateway UltraPerformance na região especificada.

• Uma VM DS5v2 executando o Windows Server 2016 na rede virtual, usando a imagem padrão do Azure com o AzureCT instalado.

• Todos os testes usaram o comando Get-LinkPerformance do AzureCT com um teste de carga de 5 minutos para cada uma das seis execuções de teste. Por exemplo:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• O fluxo de dados para cada teste foi do servidor local (cliente iPerf em Seattle) para a VM do Azure (servidor iPerf na região do Azure listada).

• A coluna "Latência" mostra dados do teste Sem Carga (um teste de latência TCP sem iPerf em execução).

• A coluna "Largura de Banda Máxima" mostra dados do teste de carga de 16 fluxos TCP com uma janela de 1 Mb.

Resultados de latência/largura de banda

Importante

Esses números servem apenas como referência geral. Muitos fatores afetam a latência e, embora esses valores sejam geralmente consistentes ao longo do tempo, as condições dentro do Azure ou da rede do Provedor de Serviços podem mudar, afetando a latência e a largura de banda. Geralmente, essas alterações não resultam em diferenças significativas.

Localização do ExpressRoute	Região do Azure	Distância Estimada (km)	Latência	1 Sessão de Largura de Banda	Largura de Banda Máxima
Seattle	Oeste dos EUA 2	191 km	5 ms	262,0 Mbits/s	3,74 Gbits/s
Seattle	Oeste dos EUA	1.094 km	18 ms	82,3 Mbits/s	3,70 Gbits/s
Seattle	Centro dos EUA	2.357 km	40 ms	38,8 Mbits/s	2,55 Gbits/s
Seattle	Centro-Sul dos Estados Unidos	2.877 km	51 ms	30,6 Mbits/s	2,49 Gbits/s
Seattle	Centro-Norte dos EUA	2.792 km	55 ms	27,7 Mbits/s	2,19 Gbits/s
Seattle	Leste dos EUA 2	3.769 km	73 ms	21,3 Mbits/s	1,79 Gbits/s
Seattle	Leste dos EUA	3.699 km	74 ms	21,1 Mbits/s	1,78 Gbits/s
Seattle	Leste do Japão	7.705 km	106 ms	14,6 Mbits/s	1,22 Gbits/s
Seattle	Sul do Reino Unido	7.708 km	146 ms	10,6 Mbits/s	896 Mbits/s
Seattle	Europa Ocidental	7.834 km	153 ms	10,2 Mbits/s	761 Mbits/s
Seattle	Leste da Austrália	12.484 km	165 ms	9,4 Mbits/s	794 Mbits/s
Seattle	Sudeste Asiático	12.989 km	170 ms	9,2 Mbits/s	756 Mbits/s
Seattle	Sul do Brasil *	10.930 km	189 ms	8,2 Mbits/s	699 Mbits/s
Seattle	Sul da Índia	12.918 km	202 ms	7,7 Mbits/s	634 Mbits/s

* A latência para o Brasil é um exemplo em que a distância do percurso da fibra difere significativamente da distância em linha reta. A latência esperada seria de cerca de 160 ms, mas é de 189 ms devido à rota de fibra mais longa.

Observação

Esses números foram testados usando o AzureCT com base no iPerf no Windows via PowerShell. O iPerf não respeita as opções TCP padrão do Windows para Fator de Escala e usa uma Contagem de Deslocamento inferior para o tamanho da Janela TCP. Ajustando os comandos iPerf com o parâmetro -w e um tamanho maior da Janela TCP, é possível obter uma melhor taxa de transferência. Executar o iPerf no modo multithread em vários computadores também pode ajudar a atingir o desempenho máximo do link. Para obter os melhores resultados do iPerf no Windows, use "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Verifique as políticas da sua organização antes de fazer qualquer alteração.

Próximas etapas

• Baixe o Kit de ferramentas de conectividade do Azure
• Siga as instruções para teste de desempenho de link