Como encontrar o gargalo da largura de banda da rede da máquina local para a VM do Azure e melhorá-lo?

Como encontrar o gargalo da largura de banda da rede da máquina local para a VM do Azure e melhorá-lo?

Eu crio uma VM do Azure com SKU Standard_D1_v21no formato Southeast Asia. De acordo comeste documento, a largura de banda esperada é de 750 Mbps.

Porém, eu testo a largura de banda da conexão da minha máquina local para a VM, o resultado é em torno de 3Mbps. A ferramenta de teste éiPerf3, com a VM como servidor iPerf3 e minha máquina local como iPerf3 clent. Nenhuma outra carga de trabalho de rede pesada na VM durante o teste. fiz outro teste atravésNTTTCPacompanhou esse resultado.

Entendo que a largura de banda real será menor do que o esperado por vários motivos, como:

  • A conexão é cruzada entre regiões com muitos saltos.
  • VMs em infraestrutura compartilhada compartilham uma limitação total (link).
  • A VM é implantada na região de menor latência (Teste de velocidade do Azure).

Mas a largura de banda real (3Mbps) é muito menor do que o esperado (750Mbps). Então, como fazer:

  1. solucionar as causas raiz? Uma configuração incorreta na VM; ou para muitos saltos em conexões entre regiões; ou um acelerador em algum lugar da infraestrutura?
  2. como melhorar a largura de banda entre a máquina local e a VM remota?

Responder1

Que tal você fazer alguns testes totalmente óbvios - coisas que me fazem pensar se você deveria preferir perguntar no superusuário do que em um site para profissionais.

  • Teste a largura de banda em ambos os endpoints e entre eles. Use um teste obtido na Internet - muitos deles são executados no navegador. Speedtest.net permite que você selecione o contraponto, para que você possa começar com um servidor local e depois usar o outro lado (pelo menos próximo) e depois percorrer todo o caminho.

Essencialmente: a menos que você ou o outro lado tenham um problema local - o que é improvável em níveis de velocidade cômicos como você os acerta - este é um problema de roteamento e não há NADA que você possa fazer - exceto duas coisas:

  • Fale com o suporte do seu ISP
  • Mude seu provedor de internet.

O roteamento é o domínio deles. Eles podem ter atrapalhado uma rota específica - mas se não, bem, nada que você possa fazer a não ser procurar outro provedor de Internet.

Seu teste (como está) é totalmente inútil - porque testa apenas de A a B - e não se há um problema local em algum lado. Com a minha abordagem você pode variar o contraponto e ver se sua máquina local tem problemas em destinos específicos. Pode ser que você tenha uma boa largura de banda local, mas os links internacionais estejam sobrecarregados.

Se isso funcionar, é hora de verificar o sistema operacional usado. O RSS existe por uma razão - ele aumenta o número de pacotes "em trânsito" que podem ser necessários para pings longos.

Além disso, não há realmente nada que você possa fazer.

Responder2

Bem-vindo ao fórum.

O problema aqui é que você não controla os pontos intermediários. Encontrar essa granularidade é em parte ciência, em parte arte, já que não existe uma resposta realmente boa, mas sim um relatório sobre as descobertas de muitos fatores.

Localizar um gargalo corretamente significaria ser capaz de testar todos os pontos entre e de cada lado, você nunca terá acesso a todos eles, mas pode inferir algumas coisas e visualizar vários ângulos para obter uma imagem melhor.

As coisas que você pode eliminar são: "Você tem rendimento adequado do seu lado?" Isso pode ser obtido se você tiver um site conhecido com largura de banda dedicada para testar e uma boa rota conhecida capaz de sustentar sua taxa de transferência. Os testes de velocidade online podem enganar, porque você pode ter uma conexão adequada e ELES podem ter a largura de banda adequada para realizar testes de maneira confiável. Mas nenhum de vocês controla o que acontece entre você e eles. SE você estiver realizando consistentemente bons testes de velocidade em vários locais de teste, poderá descartar com relativa segurança que o problema está do seu lado, na medida em que você o controla. O outro lado, é claro, se essa falha para todos ainda não for você, pode ser o ISP do seu ISP, alguém em uma rede principal em algum lugar, alguma rota congestionando outra para permanecer ativa, etc. para se envolver, mas em uma linha de consumo eles vão lançar o "Speeds up to" para você, em uma linha de negócios dedicada você tem um argumento, mas ainda assim o ônus da prova.

Embora não seja impossível, o ponto de estrangulamento provavelmente não está no lado azul, a menos que você tenha um BW limitado contratualmente.

Você pode fazer coisas como usar MTRhttps://en.wikipedia.org/wiki/MTR_(software)para obter uma breve visão geral, mas tenha em mente que a queda do ICMP pode ser resultado da operação natural dos sistemas, já que a maioria dos equipamentos de rede descartará o ICMP sob estresse e alguns estão configurados apenas para não responder por padrão. Portanto, embora isso possa lhe dar mais informações, não é uma arma fumegante; você precisa entender como lê-la e interpretá-la.

Você pode procurar lugares como aquihttps://www.thousandeyes.com/outages/onde grandes interrupções são registradas através de redes de sensores em todo o mundo. Às vezes, isso pode lhe dar uma pista, especialmente na rede AS (os nós principais da Internet em termos simples), se houver problemas que afetem diretamente sua rota. Mil Olhos

Para interpretar isso e determinar qual é a "sua" rota, você pode começar com as ferramentas BGP da HE aquihttps://bgp.he.net/você verá efetivamenteondena internet você está no sentido de roteamento. SE você clicar no IP que você usa para acessar a internet (comumente conhecido como seu IP público), lá você verá algo assim...ELE BGP

Isto é quem você é para a internet (visitando de), de qual rede você vem (anunciado como) e como isso entra na "internet" (seu ISP)

Isso pode ser rastreado de ASN para ASN (número do sistema autônomo) para ver a rota real que você segue (nesse momento, pois está sujeita a alterações sem aviso prévio para manter as rotas abertas) ou até mesmo visualizá-la graficamente.

Gráfico ASN

Em seguida, você pode comparar com o gráfico de mil olhos ou com uma infinidade de outras ferramentas de relatórios BGP on-line para ver se essas rotas têm congestionamento conhecido ou estão oscilando (subindo e descendo), etc.

Isso geralmente fornecerá informações suficientes para notificar quem pode ser responsável por qual sistema (esteja ciente de que a maioria não se importará com o seu ISP) e, embora isso possa não levá-lo aonde deseja, explica por que você não está onde você querer ser.

Resumindo, você tem que pensar assim: a velocidade não é consistente em toda a Internet, algumas seções são conectadas por meio de links rápidos incompreensíveis, outras nem tanto. E quando um desses grandes afunda, muitos menores sofrem muito.

Então, o que você pode fazer sobre isso? Às vezesvocê pode contornar isso se estiver fazendo conexões ponto a ponto, mas isso não garantirá que todos os seus clientes que viajam nas mesmas rotas tenham a mesma experiência. Por exemplo, você pode ter um servidor da Web lá e conseguir uma conexão sólida e de boa taxa de transferência com algo como um provedor de VPN que sai mais perto do seu terminal remoto e forçá-lo a seguir uma rota melhor. Os usuários que acessam o seu servidor e não fazem a mesma coisa não terão a mesma experiência. Existem alguns serviços que podem fazer isso mediante o pagamento de uma taxa por tudo, fazendo com que seu servidor apareça em outro lugar diferente de onde realmente está e seguindo uma rota premium. Possivelmente o cloudflare tem serviços como este, eu nunca os usei, então teria que deixar um especialista em cloudflair falar sobre isso.

Esperamos que isso lhe dê o suficiente para entender como isso pode ser complicado e também entender que sua experiência e a de alguém em um estado de distância podem ser totalmente diferentes.

informação relacionada