Resolver problemas de desempenho da rede

Descrição geral

O Azure fornece uma maneira estável e rápida de conectar sua rede local ao Azure. Métodos como VPN Site a Site e ExpressRoute são utilizados com êxito por clientes grandes e pequenos para a gestão dos seus negócios no Azure. Mas o que acontece quando o desempenho não atende às suas expectativas ou experiência anterior? Este artigo pode ajudar a padronizar a maneira como você testa e faz a linha de base do seu ambiente específico.

Você aprende a testar de forma fácil e consistente a latência e a largura de banda da rede entre dois hosts. Também lhe serão fornecidos alguns conselhos sobre formas de analisar a rede do Azure para ajudar a isolar os pontos problemáticos. O script e as ferramentas do PowerShell discutidos exigem dois hosts na rede (em cada extremidade 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 discutir alguns termos e componentes comuns. Esta discussão garante que estamos pensando em cada componente na cadeia de ponta a ponta que permite a conectividade no Azure.

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

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

Olhando para 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 que todas as rotas estáticas, rotas padrão e configurações do sistema operacional estão enviando e recebendo tráfego do jeito que você acha que é. Além disso, cada SKU de VM tem uma restrição de largura de banda. Se você estiver usando uma SKU de VM menor, seu tráfego será limitado pela largura de banda disponível para a NIC. Recomendamos o uso de um DS5v2 para testes para garantir a largura de banda adequada na VM.

• NIC - Certifique-se de conhecer o IP privado 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, verifique se as portas 5201 para iPerf, 3389 para RDP ou 22 para SSH estão abertas para permitir que o tráfego de teste seja aprovado.

• Sub-rede VNet - A NIC é atribuída a uma sub-rede específica, certifique-se de saber qual e as regras associadas a essa sub-rede.

• Sub-rede NSG - Assim como a NIC, os NSGs também podem ser aplicados na sub-rede. Verifique se o conjunto de regras do NSG é apropriado 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 está saindo da VM, o NSG da NIC se aplica primeiro e, em seguida, o NSG da sub-rede é aplicado.

• UDR de sub-rede - 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 saber se há um UDR em vigor para o seu tráfego. Se sim, entenda para onde ele vai e o que esse próximo salto fará com o seu tráfego. Por exemplo, um firewall pode passar algum tráfego e negar outro tráfego entre os mesmos dois hosts.

• Sub-rede de gateway / NSG / UDR - Assim como a sub-rede de VM, a sub-rede de gateway pode ter NSGs e UDRs. Certifique-se de que sabe se existem e que efeitos têm no seu tráfego.

• VNet Gateway (ExpressRoute) - Depois que o emparelhamento (ExpressRoute) ou VPN estiver habilitado, não há muitas configurações que possam afetar como ou se o tráfego rota. Se você tiver um Gateway de rede virtual conectado a vários circuitos de Rota Expressa ou túneis VPN, você deve 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 seu tráfego toma.

• Filtro de Rota (Não mostrado) - Um filtro de rota é necessário ao usar o Microsoft Peering através da Rota Expressa. Se você não estiver recebendo nenhuma rota, 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 seu provedor de serviços, sua WAN corporativa ou a Internet. Há muitos saltos, dispositivos e empresas envolvidas com esses links, o que pode dificultar a solução de problemas. Você precisa primeiro excluir o Azure e suas redes corporativas antes de poder investigar os saltos intermediários.

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

Dada a complexidade destes 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 se degrada. Essa abordagem pode ajudar a identificar o domínio de roteamento de problemas dos três. Em seguida, você pode concentrar sua solução de problemas nesse ambiente específico.

Ferramentas

A maioria dos problemas de rede pode ser analisada e isolada usando ferramentas básicas como ping e traceroute. É raro você precisar ir tão fundo quanto uma análise de pacotes usando ferramentas como o Wireshark.

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

Essas ferramentas e métodos são encapsulados em um módulo do PowerShell (AzureCT) que você pode instalar e usar.

AzureCT - o Kit de Ferramentas de Conectividade do Azure

O módulo AzureCT PowerShell tem dois componentes: Teste de Disponibilidade e Teste de Desempenho. Este documento se preocupa apenas com testes de desempenho, portanto, vamos nos concentrar nos dois comandos Link Performance neste módulo do PowerShell.

Há três etapas básicas para usar esse kit de ferramentas para testes de desempenho.

1. Instalando o módulo PowerShell.

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

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

2. Instale os aplicativos de suporte.

   Install-LinkPerformance
   

   Este comando AzureCT instala iPerf e 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 porta 5201 (iPerf).

3. Execute 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 no 3389 (RDP para Windows) ou 22 (SSH para Linux) e permitindo o tráfego na porta 5201 para iPerf. Se o host remoto for o 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 a máquina remota estiver pronta, abra o PowerShell na máquina 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 largura de banda, a capacidade e a latência do seu link de rede.

4. Analise a saída dos testes.

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

   

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

Resolução de Problemas

Se o teste de desempenho não está dando os resultados esperados, descobrir por que deve ser um processo passo a passo progressivo. Dado o número de componentes no caminho, uma abordagem sistemática fornece um caminho mais rápido para a resolução do que saltar. Ao solucionar problemas sistematicamente, você pode evitar fazer testes desnecessários várias vezes.

Nota

O cenário aqui é um problema de desempenho, não 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 ExpressRoute de 1 Gbps e 100 ms de latência. Não é razoável esperar o total de 1 Gbps de tráfego, dadas as características de desempenho do TCP em links de alta latência. Consulte a seção Referências para obter mais informações sobre pressupostos de desempenho.

Em seguida, recomendamos começar pelas bordas entre domínios de roteamento e tentar isolar o problema em um único domínio de roteamento principal. Você pode começar na Rede Corporativa, na WAN ou na Rede do Azure. As pessoas costumam culpar a "caixa preta" no caminho. Embora culpar a caixa preta seja fácil de fazer, pode atrasar significativamente a resolução. Especialmente se o problema estiver em uma área que você pode fazer alterações para corrigir o problema. Certifique-se de fazer a devida diligência antes de entregar ao 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 à medida que limpa áreas ou se aprofunda à medida que o teste progride.

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

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

Solução de problemas avançada de Rota Expressa

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

Nota

Observe que o MSEE não está na nuvem do Azure. O ExpressRoute está, na verdade, na borda da rede da Microsoft, não no Azure. Depois de estar conectado com o ExpressRoute a um MSEE, você está conectado à rede da Microsoft, de lá você pode ir para qualquer um dos serviços de nuvem, como o Microsoft 365 (com Microsoft Peering) ou Azure (com Private e/ou Microsoft Peering).

Se duas VNets estiverem conectadas ao mesmo circuito de Rota Expressa, você poderá fazer uma série de testes para isolar o problema no Azure.

Plano de teste

1. Execute o teste Get-LinkPerformance entre VM1 e VM2. Este teste fornece informações sobre se o problema é local ou não. Se esse 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 VM1 e VM3. Este teste exerce a conexão através da rede Microsoft até o MSEE e de volta ao Azure. Se esse 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 excluído, você poderá fazer uma sequência semelhante de testes em sua rede corporativa. Se isso também testar bem, é hora de trabalhar com seu provedor de serviços ou ISP para diagnosticar sua conexão WAN. Exemplo: execute este teste entre duas filiais ou entre sua mesa e um servidor de data center. Dependendo do que você estiver testando, encontre pontos de extremidade, como servidores e PCs clientes, que possam exercer esse caminho.

Importante

É fundamental que, para cada teste, marque a hora do dia em que executa 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 as execuções de teste e não ter "buracos" nos dados. A consistência em vários testes é a principal razão pela qual usamos o AzureCT para solução de problemas. A magia não está nos cenários de carga exatos que executamos, mas sim no fato de que obtemos um teste consistente e uma saída de dados de cada teste. Registrar o tempo e ter dados consistentes todas as vezes é especialmente útil se você descobrir mais tarde que o problema é esporádico. Seja diligente com sua coleta de dados antecipadamente e você evitará horas de novos testes nos mesmos cenários.

O problema é isolado, e agora?

Quanto mais você isolar o problema, mais rápido a solução pode ser encontrada. Às vezes você chega a um ponto em que não pode ir mais longe com sua solução de problemas. Por exemplo, você vê o link em todo o seu provedor de serviços levando lúpulo pela Europa, mas espera que o caminho permaneça todo na Ásia. Neste ponto, você deve contratar alguém para obter ajuda. Quem você pergunta depende do domínio de roteamento para o qual você isola o problema. Se você puder reduzi-lo a um componente específico, isso seria ainda melhor.

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

Uma boa prática para solucionar problemas da WAN é compartilhar os resultados dos testes com seu provedor de serviços ou ISP, pois isso pode ajudá-los com seu trabalho. Os resultados do teste também podem evitar fazer as mesmas tarefas que você já fez. No entanto, eles podem querer verificar seus próprios resultados. Isto baseia-se no princípio da confiança, mas verifique.

Com o Azure, depois de isolar o problema com o máximo de detalhes possível, é hora de revisar a Documentação de Rede do Azure e, se ainda necessário, abrir um tíquete de suporte.

Referências

Expectativas de latência/largura de banda

Gorjeta

A latência geográfica (milhas ou quilômetros) entre os pontos finais que você está testando é, de longe, o maior componente de latência. Embora haja latência de equipamentos (componentes físicos e virtuais, número de saltos, etc.) envolvidos, a geografia provou ser o maior componente da latência geral ao lidar com conexões WAN. Também é importante notar que a distância é a distância da corrida da fibra, não a distância em linha reta ou mapa de estrada. Esta distância é incrivelmente difícil de obter com qualquer precisão. Como resultado, geralmente usamos uma calculadora de distância da cidade na internet e sabemos que este método é uma medida grosseiramente imprecisa, mas é suficiente para definir uma expectativa geral.

Por exemplo, temos uma configuração de Rota Expressa em Seattle, Washington, nos EUA. A tabela a seguir mostra a latência e a largura de banda que vimos testando em vários locais do Azure. Estimou-se a distância geográfica entre cada extremidade do teste.

Configuração do teste:

• Um servidor físico executando o Windows Server 2016 com uma placa de rede de 10 Gbps, conectado a um circuito de Rota Expressa.

• Um circuito Premium ExpressRoute de 10 Gbps no local identificado com o Emparelhamento Privado ativado.

• 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 associada ao 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 AzureCT Get-LinkPerformance 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 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 No Load (um teste de latência TCP sem iPerf em execução).

• Os dados da coluna "Max Bandwidth" são do teste de carga de fluxo TCP 16 com um tamanho de janela de 1 Mb.

Resultados de latência/largura de banda

Importante

Estes números são apenas para 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 de Provedores de Serviços podem enviar tráfego por caminhos diferentes a qualquer momento, portanto, a latência e a largura de banda podem ser afetadas. Geralmente, os efeitos dessas alterações não resultam em diferenças significativas.

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

* A latência para o Brasil é um bom exemplo onde a distância em linha reta difere significativamente da distância de execução da fibra. A latência esperada seria na vizinhança de 160 ms, mas na verdade é de 189 ms. A diferença na latência parece indicar um problema de rede em algum lugar. Mas a realidade é que a linha de fibra não vai para o Brasil em linha reta. Então você deve esperar mais 1.000 km ou mais de viagem para chegar ao Brasil a partir de Seattle.

Nota

Embora esses números devam ser levados em consideração, eles foram testados usando o AzureCT, que é baseado em IPERF no Windows via PowerShell. Nesse cenário, o IPERF não honra as opções padrão de TCP do Windows para o fator de dimensionamento e usa uma contagem de turnos muito menor para o tamanho da janela TCP. Os números aqui representados foram realizados utilizando valores IPERF predefinidos e são apenas para referência geral. Ao ajustar os comandos IPERF com -w switch e um grande tamanho de janela TCP, uma melhor taxa de transferência pode ser obtida em longas distâncias, mostrando números de taxa de transferência significativamente melhores. Além disso, para garantir que uma Rota Expressa esteja usando toda a largura de banda, é ideal executar o IPERF na opção multi-threaded de várias máquinas simultaneamente para garantir que a capacidade de computação seja capaz de 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 as políticas organizacionais antes de fazer alterações.

Próximos passos

• Baixe o Kit de Ferramentas de Conectividade do Azure
• Siga as instruções para testar o desempenho do link