Solucionar problemas de desempenho de rede

Resumo

Azure fornece uma maneira estável e rápida de conectar sua rede local ao Azure. Clientes de todos os tamanhos usam métodos como VPN Site a Site e ExpressRoute para executar seus negócios em Azure. Mas o que acontece quando o desempenho não atende às suas expectativas ou à experiência anterior? Este artigo ajuda a padronizar a forma como você testa e estabelece uma linha de base para seu ambiente específico.

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 recebe conselhos sobre maneiras de examinar a rede Azure para ajudar a isolar pontos de problema. O script do PowerShell e as ferramentas discutidas 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 host pode ser Windows ou Linux.

Componentes de rede

Antes de investigar a solução de problemas, vamos discutir alguns termos e componentes comuns. Essa discussão garante que você esteja pensando em cada componente na cadeia de ponta a ponta que habilita a conectividade em Azure.

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

• A rede 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. Verifique se as rotas estáticas, as rotas padrão e as configurações do sistema operacional enviam e recebem o tráfego da maneira esperada. Além disso, cada SKU de VM tem uma restrição de largura de banda. Se você estiver usando uma SKU de VM menor, o tráfego será limitado pela largura de banda disponível para a NIC. Use um DS5v2 para teste para garantir a largura de banda adequada na VM.

• NIC – Verifique se você conhece o IP privado atribuído à NIC em questão.

• NIC NSG - Pode haver NSGs específicos aplicados no nível da NIC. Verifique se o conjunto de regras 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 passe.

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

• NSG de sub-rede – assim como a NIC, você também pode aplicar NSGs no nível da sub-rede. Verifique se o conjunto de regras NSG é apropriado 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 está saindo da VM, o NSG da NIC é aplicado primeiro e, em seguida, o NSG da sub-rede.

• UDR da sub-rede - rotas definidas pelo usuário podem direcionar o tráfego para um salto intermediário, como um firewall ou um balanceador de carga. Verifique se há uma UDR em vigor para seu tráfego. Nesse caso, entenda onde ele vai e o que o próximo salto faz com seu tráfego. Por exemplo, um firewall pode passar algum tráfego e negar outro tráfego entre os mesmos dois hosts.

• Sub-rede do gateway/NSG/UDR – assim como a sub-rede da VM, a sub-rede do gateway pode ter NSGs e UDRs. Certifique-se de saber se eles estão lá e quais efeitos eles têm no seu tráfego.

• Gateway de VNet (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 é roteado. Se você tiver um gateway de rede virtual conectado a vários circuitos do ExpressRoute ou túneis VPN, esteja 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 usa.

• 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 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 envolvidos nesses links, o que pode dificultar a solução de problemas. Primeiro, você precisa eliminar 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 alguns dispositivos de rede entre você e a WAN ou várias camadas de dispositivos em uma rede corporativa ou campus.

Dada a complexidade desses três diferentes ambientes de rede de alto nível, geralmente é ideal começar nas bordas e tentar mostrar onde o desempenho é bom e onde ele degrada. Essa abordagem pode ajudar a identificar qual dos três domínios de roteamento está causando problemas. Em seguida, você pode concentrar sua solução de problemas nesse ambiente específico.

Tools

Você pode analisar e isolar a maioria dos problemas de rede usando ferramentas básicas, como ping e rastreamento. É raro que você precise ir tão fundo quanto a análise de pacotes usando ferramentas como o Wireshark.

Para ajudar na solução de problemas, o Azure AzureCT (Connectivity Toolkit) 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. 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 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.

Você pode usar um módulo do PowerShell (AzureCT) que encapsula essas ferramentas e métodos.

AzureCT – o kit de ferramentas de conectividade do Azure

O módulo do AzureCT PowerShell inclui dois componentes: Availability Testing e Performance Testing. Este artigo foca em Teste de Desempenho, especificamente nos dois comandos Link Performance neste módulo do PowerShell.

Para usar este kit de ferramentas para Teste de Desempenho, siga estas três etapas básicas:

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
   

   Este comando do AzureCT instala o iPerf e o PSPing em um novo diretório C:\ACTTools e abre as portas do Firewall 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 na porta 3389 (RDP para Windows) ou na porta 22 (SSH para Linux) e permitindo tráfego na porta 5201 usada pelo 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 simultâneos de carga e latência para estimar a capacidade de largura de banda e a latência do link de rede.

4. Examinar 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 do AzureCT em C:\ACTTools.

Solucionar problemas de desempenho

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

1. Desafiar suas suposições

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

2. Comece na borda da rede

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

3. Criar um diagrama

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

4. Dividir e conquistar

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

5. Considere todas as camadas de OSI

   Embora seja comum se concentrar na rede e nas camadas 1 a 3 (camadas físicas, de dados e de 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 Azure pode ser desafiador se você não tiver certeza de onde está a borda da nuvem. Com o ExpressRoute, a borda é um componente de rede chamado MSEE (Microsoft Enterprise Edge). O MSEE é o primeiro ponto de contato na rede da Microsoft e o último salto ao deixá-la. Ao criar uma conexão entre o gateway de rede virtual e o circuito do ExpressRoute, você está se conectando ao MSEE. Reconhecer o MSEE como o primeiro ou o último salto é crucial para isolar um problema de rede Azure. Conhecer a direção do tráfego ajuda a determinar se o problema está em Azure ou mais downstream na WAN ou na rede corporativa.

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

Plano de teste

1. Execute o teste de 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 de Get-LinkPerformance entre VM1 e VM3. Esse teste realiza a conexão por meio da rede da Microsoft até o MSEE e retorna ao Azure. Se o teste produzir resultados aceitáveis de latência e largura de banda, você poderá marcar a rede Azure como boa.

3. Se Azure for descartado, 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 endereços de rede, como servidores e computadores cliente, que possam testar o caminho que está sendo testado.

O problema é isolado, e agora?

Quanto mais você isolar o problema, mais rápido você pode encontrar uma solução. À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 seu provedor de serviços dando saltos pela rede através da Europa quando espera que ele permaneça na Ásia. Neste ponto, envolva alguém para obter ajuda com base no domínio de roteamento para o qual você isolou o problema. Reduzi-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 na configuração do dispositivo ou no reparo de hardware.

Para problemas de WAN, compartilhe seus resultados de teste com seu provedor de serviços ou ISP para ajudá-los com seu trabalho e evitar tarefas redundantes. Talvez eles queiram verificar seus resultados com base no princípio da confiança, mas verifiquem.

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

Referências

Expectativas de latência e largura de banda

Por exemplo, você configurou um ExpressRoute em Seattle, Washington, EUA. A tabela a seguir mostra a latência e a largura de banda observadas ao testar várias localidades do Azure, bem como as distâncias estimadas.

Configuração de teste:

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

• Um circuito de ExpressRoute Premium de 10 Gbps com Peering Privado ativado.

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

• Uma VM DS5v2 em execução Windows Server 2016 na rede virtual, usando a imagem de Azure padrã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 para cada teste é do servidor local (cliente iPerf em Seattle) para a VM Azure (servidor iPerf na região de 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 um tamanho de janela de 1 MB.

Resultados de latência e largura de banda

* A latência para o Brasil é um exemplo em que a trajetória do cabo de fibra óptica difere significativamente da distância em linha reta. A latência esperada é de cerca de 160 ms, mas na verdade são 189 ms devido à rota de fibra mais longa.

Próximas etapas

• Baixe o Azure Connectivity Toolkit
• Siga as instruções para teste de desempenho de link