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 grandes e pequenos clientes para executar seus negócios no Azure. Mas o que acontece quando o desempenho não satisfaz suas expectativas ou a experiência anterior? 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 de forma fácil e consistente a latência de rede e a largura de banda entre dois hosts. Você também receberá alguns conselhos sobre maneiras de 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; 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)

Ao examinar o diagrama da direita para esquerda, vamos falar resumidamente sobre 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.

• NIC NSG – pode haver NSGs específicos aplicados no nível da NIC, certifique-se de que o conjunto de regras do NSG seja apropriado 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 de VNet – a NIC é atribuída a uma sub-rede específica. Certifique-se de que você saiba qual e quais as regras associadas a essa sub-rede.

• NSG de Sub-rede – assim como a NIC, os NSGs também podem ser aplicados na 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 para a NIC, a sub-rede NSG aplica-se primeiro e, em seguida, a NIC NSG. Quando o tráfego sai da VM, a NIC NSG aplica-se primeiro e, em seguida, a sub-rede NSG é aplicada.

• 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 diferentes ambientes de rede de alto nível. Muitas vezes, é ideal começar pelas bordas e tentar mostrar onde o desempenho é bom e onde ele 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 normalmente usada para testes básicos de desempenho e é razoavelmente 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" de maneira simples, através da cópia dos arquivos em 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 AzureCT tem dois componentes: Teste de disponibilidade e Teste de desempenho. Este documento aborda somente o teste de desempenho, assim, vamos nos concentrar nos dois comandos de Desempenho de links deste módulo do PowerShell.

Há três etapas básicas para usar este kit de ferramentas para teste de desempenho.

1. Instalação do módulo do PowerShell.

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

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

2. Instalar os aplicativos de suporte.

   Install-LinkPerformance
   

   Este comando do AzureCT instala o iPerf e o PSPing em um novo diretório C:\ACTTools; ele também 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, você deve instalar e executar o iPerf no modo de servidor. Verifique também se o host remoto está escutando na 3389 (RDP para Windows) ou na 22 (SSH para Linux), e permitindo tráfego na porta 5201 para o iPerf. Se o host remoto for Windows, instale o AzureCT e execute o comando Install-LinkPerformance. O comando configura o iPerf e as regras de firewall necessárias para iniciar o iPerf no modo de servidor com êxito.

   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
   

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

4. Examinar o resultado dos testes.

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

   

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

Solução de problemas

Se o teste de desempenho não fornecer os resultados esperados, conhecer as razões deverá ser um processo passo a passo progressivo. Considerando o número de componentes no caminho, uma abordagem sistemática fornece um caminho mais rápido para a resolução. Ao solucionar o problema sistematicamente, você pode impedir múltiplos testes desnecessários.

Observação

Essa é uma situação de um problema de desempenho e não de um problema de conectividade. Para isolar o problema de conectividade com a rede do Azure, siga o artigo Verificando a conectividade do ExpressRotue.

Primeiro, desafie suas suposições. A sua expectativa é razoável? Por exemplo, se você tiver um circuito de ExpressRoute de 1 Gbps e 100 ms de latência. Não é razoável esperar o total de 1 Gbps de tráfego, considerando as características de desempenho do TCP em links de alta latência. Consulte a seção Referências para saber mais sobre premissas de desempenho.

Em seguida, é recomendado começar pelas bordas entre domínios de roteamento e tentar isolar o problema a um único domínio de roteamento principal. Você pode começar na Rede Corporativa, na WAN ou na Rede do Azure. As pessoas geralmente culpam a "caixa preta" no caminho. Embora culpar a caixa preta seja fácil, isso pode atrasar significativamente a resolução. Especialmente se o problema estiver em uma área em que você pode fazer alterações para corrigir o problema. Faça tudo o que for possível antes de passar para seu provedor de serviços ou ISP.

Depois de identificar o domínio de roteamento principal que parece conter o problema, você deve criar um diagrama da área em questão. Ao desenhar um diagrama, você pode trabalhar metodicamente e isolar o problema. Você pode planejar pontos de teste e atualizar o mapa ao descartar as áreas ou obter detalhes conforme o progresso do teste.

Agora que você tem um diagrama, comece a dividir a rede em segmentos e restringir o problema. Descubra em que locais ela funciona e onde não funciona. Continue movendo seus pontos de teste para isolar até o componente com problema.

Além disso, não se esqueça de examinar outras camadas do modelo OSI. É fácil se concentrar na rede e nas camadas de 1 a 3 (camadas física, de dados e de rede), mas os problemas também podem estar até na camada 7, na camada de aplicativo. Mantenha uma mente aberta e verifique as suposições.

Solução de problemas avançada do ExpressRoute

Se você não tem certeza de onde realmente está borda da nuvem, isolar os componentes do Azure pode se tornar um desafio. Quando o ExpressRoute é usado, a borda é um componente de rede chamado MSEE (Microsoft Enterprise Edge). Ao usar o ExpressRoute, o MSEE é o primeiro ponto de contato com a rede da Microsoft e o último salto ao sair dela. Ao criar um objeto de conexão entre o gateway de rede virtual e o circuito do ExpressRoute, você está realmente fazendo uma conexão com o MSEE. Reconhecendo o MSEE como o primeiro ou último salto, dependendo da direção do tráfego, é crucial para isolar um problema de rede do Azure. Saber qual é a direção prova se o problema está no Azure ou mais adiante na WAN ou na rede corporativa.

Observação

Observe que o MSEE não está na nuvem do Azure. Na verdade, o ExpressRoute está na borda da rede da Microsoft e não no Azure. Ao conectar o ExpressRoute a um MSEE, você está conectado à rede da Microsoft; daí você pode acessar qualquer um dos serviços de nuvem, como o Microsoft 365 (com o Emparelhamento da Microsoft) ou o Azure (com Emparelhamento privado e/ou da Microsoft).

Se duas VNets forem conectadas ao mesmo circuito do ExpressRoute, você pode fazer uma série de 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 ou não. Se este 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 esse teste produzir resultados de latência e de largura de banda aceitáveis, você poderá marcar a rede do Azure como boa.

3. Se o Azure for excluído, você poderá fazer uma sequência de testes semelhante em sua rede corporativa. Se esses testes também produzirem bons resultados, será hora de trabalhar com seu provedor de serviços ou ISP para diagnosticar a conexão da WAN. Exemplo: execute este teste entre duas filiais, ou entre sua mesa e um servidor de data center. Dependendo do que você está testando, localize pontos de extremidade, como servidores e computadores de clientes, que podem exercer esse caminho.

Importante

É fundamental que, para cada teste, você marque a hora do dia em que executou o teste e registre os resultados em um local comum. Cada execução de teste deve ter saída idêntica para que você possa comparar os dados resultantes entre execuções de teste e não ter "lacunas" nos dados. A consistência entre vários testes é a principal razão pela qual usamos o AzureCT para solução de problemas. A mágica não está nos cenários de carga exatos que executamos, mas a mágica está no fato de obtermos uma saída consistente de teste e dados de cada teste. Registrar a hora e sempre ter dados consistentes será especialmente útil se você descobrir mais tarde que o problema é esporádico. Antecipe-se no cuidado com a coleta de dados e você evitará perda de tempo refazendo testes com os mesmos cenários.

O problema está isolado, e agora?

Quanto mais você isolar o problema, mais rapidamente a solução poderá ser encontrada. Em algum momento, você chega a um ponto em que não é possível continuar com a solução de problemas. Por exemplo, você vê o link entre o provedor de serviços realizando saltos na Europa, mas esperava que o caminho ficasse na Ásia. Neste ponto, você deve envolver alguém para obter ajuda. A ajuda depende do domínio de roteamento ao qual você isola o problema. Se você puder limitá-lo a um componente específico, será 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.

Uma boa prática para solucionar problemas da WAN é compartilhar os seus resultados de teste com o seu Provedor de Serviços ou ISP, pois isso pode ajudá-los com o seu trabalho. Os resultados do teste também podem evitar realizar novamente as mesmas tarefas que você já realizou. No entanto, talvez eles queiram verificar seus próprios resultados. Isso se baseia no princípio de confiar, mas verificar.

Com o Azure, quando você isola o problema com todos os detalhes possíveis, é hora de examinar a Documentação da Rede do Azure e, em seguida, caso ainda seja necessário, abrir um tíquete de suporte.

Referências

Expectativas de largura de banda/latência

Dica

A latência geográfica (em milhas ou quilômetros) entre os pontos de extremidade que você está testando é, sem dúvida, o maior componente de latência. Embora haja latência de equipamento (componentes físicos e virtuais, número de saltos, etc.) envolvida, a geografia é, comprovadamente, o maior componente de latência geral ao lidar com conexões WAN. Também é importante observar que a distância é a distância que a fibra percorre e não a distância em linha reta ou a distância do mapa. É incrivelmente difícil obter essa distância com algum nível de precisão. Assim, geralmente usamos uma calculadora de distância de cidade na internet e sabemos que esse método resulta em uma medida bastante imprecisa, mas é o suficiente para definir uma expectativa geral.

Por exemplo, temos uma instalação do ExpressRoute em Seattle, Washington, nos EUA. A tabela a seguir mostra a latência e a largura de banda que obtivemos ao testar com vários locais do Azure. Estimamos a distância geográfica entre cada extremidade do teste.

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 Premium do ExpressRoute de 10 Gbps no local identificado, com o 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. A VM não foi ingressada no domínio, criada a partir da imagem padrão do Azure (sem otimização ou personalização) com o AzureCT instalado.

• Todos os testes usam 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 de cada teste tinha a carga fluindo do servidor físico local (cliente iPerf em Seattle) até a VM do Azure (servidor iPerf na região do Azure listada).

• Os dados da coluna "Latência" são do teste Sem carga (um teste de latência de TCP sem execução do iPerf).

• Os dados da coluna "Largura de banda máx." são dos 16 testes de carga de fluxo de TCP com um tamanho de 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 no Azure ou na rede dos provedores de serviços podem enviar o tráfego por diferentes caminhos a qualquer momento, afetando, assim, a latência e a largura de banda. Geralmente, os efeitos dessas alterações não resultam em diferenças significativas.

ExpressRoute Local	Azure Região	Estimada (km) Distância	Latency	Sessão 1 Largura de banda	Máximo Largura de banda
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 até o Brasil é um bom exemplo em que a distância em linha reta difere significativamente da distância que a fibra percorre. A latência esperada seria de cerca de 160 ms, mas é de 189 ms na realidade. A diferença na latência pareceria indicar um problema de rede em algum lugar. Mas a realidade é que a linha de fibra não vai para o Brasil em uma linha reta. Portanto, você deve esperar até que mil quilômetros extras, mais ou menos, viajem de Seattle para chegar ao Brasil.

Observação

Embora esses números devam ser levados em consideração, eles foram testados usando o AzureCT, que é baseado no IPERF no Windows por meio do PowerShell. Nesse cenário, o IPERF não respeita as opções padrão do TCP do Windows para o Fator de Escala e usa uma Contagem de Deslocamentos muito menor para o tamanho da janela TCP. Os números representados aqui foram realizados usando os valores padrão do IPERF e servem apenas como referência geral. Ao ajustar os comandos IPERF com o comutador -w e um tamanho grande de janela TCP, é possível obter uma melhor taxa de transferência em longas distâncias, mostrando números de taxa de transferência significativamente melhores. Além disso, para garantir que um ExpressRoute esteja usando toda a largura de banda, é ideal executar o IPERF na opção multi-threaded de vários computadores simultaneamente para garantir que a capacidade de computação possa atingir o desempenho máximo do link e não seja limitada pela capacidade de processamento de uma única VM. Para obter os melhores resultados do Iperf no Windows, use "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Verifique suas políticas organizacionais antes de fazer alterações.

Próximas etapas

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