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 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ê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ê aprenderá como testar de forma fácil e consistente a latência e a largura de banda da rede entre dois hosts. Também receberá 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, e 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.

• NSG da NIC - Pode haver NSGs específicos aplicados no nível da NIC. Verifique se o conjunto de regras do NSG é 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 no nível da 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 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 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 copiando os arquivos para 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 inclui dois componentes: Teste de Disponibilidade e Teste de Desempenho. Este documento se concentra em Testes de Desempenho, especificamente os dois comandos de Desempenho de Link neste módulo do PowerShell.

Aqui estão as três etapas básicas para usar este kit de ferramentas para testes de desempenho:

1. Instalar o módulo PowerShell

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

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

2. Instale os aplicativos de suporte

   Install-LinkPerformance
   

   Este 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 a 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 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 para configurar o iPerf e as regras de firewall necessárias.

   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 estimar a largura de banda, a capacidade e a latência do seu link de rede.

4. Revise a saída do teste

   O formato de 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 AzureCT em C:\ACTTools.

Resoluçã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.

Nota

O cenário aqui é um problema de desempenho, não um problema de conectividade. Para isolar problemas de conectividade à rede do Azure, siga o artigo Verificando a conectividade da Rota Expressa.

1. Desafie as suas suposições

   Certifique-se de que as suas expectativas são razoáveis. Por exemplo, com um circuito de Rota Expressa de 1 Gbps e 100 ms de latência, esperar o total de 1 Gbps de tráfego é irrealista devido às 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.

2. Comece 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 limpa áreas ou se aprofunda.

4. Dividir para conquistar

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

5. Considere todas as camadas OSI

   Embora o foco na rede e nas camadas 1 a 3 (camadas física, de dados e de rede) seja comum, lembre-se de que 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 de Rota Expressa

Isolar componentes do Azure pode ser um desafio se você não tiver certeza de onde está a borda da nuvem. Com a Rota Expressa, 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. Ao criar uma conexão entre seu gateway de rede virtual e o circuito de Rota Expressa, você está se conectando ao MSEE. Reconhecer o MSEE como o primeiro ou o último salto é crucial 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 a jusante na WAN ou na rede corporativa.

Nota

O MSEE não está na nuvem do Azure. O ExpressRoute está na borda da rede da Microsoft, não no Azure. Uma vez conectado 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 Microsoft Peering) ou o Azure (com Private e/ou Microsoft Peering).

Se duas redes virtuais estiverem conectadas ao mesmo circuito de Rota Expressa, você poderá executar 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. 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 VM1 e VM3. Este teste exerce a conexão através da rede Microsoft até o MSEE e de volta ao 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 excluído, execute testes semelhantes em sua rede corporativa. Se esses testes também forem bons, trabalhe com seu provedor de serviços ou ISP para diagnosticar sua conexão WAN. Por exemplo, execute testes entre duas filiais ou entre sua mesa e um servidor de data center. Encontre pontos de extremidade, como servidores e PCs cliente, que possam exercer 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 saída idêntica para uma comparação de dados consistente. A consistência em vários testes é o principal motivo para usar o AzureCT para solução de problemas. A chave é obter testes consistentes e saída de dados sempre. Registrar o tempo e ter dados consistentes é especialmente útil se o problema for esporádico. Seja diligente com a coleta de dados antecipadamente para 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 a solução de problemas. Por exemplo, você pode ver o link em todo o seu provedor de serviços levando lúpulo pela Europa quando espera que ele permaneça na Ásia. Neste ponto, contrate alguém para obter ajuda com base no domínio de roteamento no qual você isolou o problema. Restringi-lo a um componente específico é 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.

Para problemas de WAN, compartilhe os resultados dos testes com seu provedor de serviços ou ISP para ajudá-los com seu trabalho e evitar tarefas redundantes. Eles podem querer verificar seus resultados com base no princípio da confiança, mas verifique.

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

Referências

Expectativas de latência/largura de banda

Gorjeta

A distância geográfica entre os pontos finais é 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 um papel, a distância da corrida da fibra, não a distância em linha reta, é o principal contribuinte. Esta distância é difícil de medir com precisão, por isso muitas vezes usamos uma calculadora de distância da cidade para uma estimativa aproximada.

Por exemplo, criamos uma Rota Expressa 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 uma placa de rede de 10 Gbps, conectado a um circuito de Rota Expressa.

• Um circuito de Rota Expressa Premium de 10 Gbps com 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, usando a imagem padrão do Azure com o AzureCT instalado.

• Todos os testes usaram 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 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 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 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 da Rota Expressa	Região do Azure	Distância estimada (km)	Latência	1 Largura de banda de sessão	Largura de Banda Máxima
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 exemplo onde a distância de execução da fibra difere significativamente da distância em linha reta. A latência esperada seria de cerca de 160 ms, mas na verdade é de 189 ms devido à rota de fibra mais longa.

Nota

Esses números foram testados usando AzureCT com base no iPerf no Windows via PowerShell. O iPerf não respeita as opções padrão de TCP do Windows para o Fator de Dimensionamento e usa uma Contagem de Deslocamento menor para o tamanho da Janela TCP. Ao ajustar os comandos iPerf com o -w switch e um tamanho maior de janela TCP, uma melhor taxa de transferência pode ser alcançada. Executar o iPerf no modo multi-threaded a partir de várias máquinas também pode ajudar a alcançar o desempenho máximo do link. Para obter os melhores resultados do iPerf no Windows, use "Set-NetTCPSetting -AutoTuningLevelLocal Experimental". Verifique suas políticas organizacionais antes de fazer qualquer alteração.

Próximos passos

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