TCP/IP performance tuning for Azure VMs (Otimização do desempenho do TCP/IP para as VMs do Azure)
Este artigo discute técnicas comuns de ajuste de desempenho de TCP/IP e algumas coisas a considerar quando você as usa para máquinas virtuais em execução no Azure. Ele fornecerá uma visão geral básica das técnicas e explorará como elas podem ser ajustadas.
Técnicas comuns de ajuste de TCP/IP
MTU, fragmentação e grande descarregamento de envio
MTU
A unidade máxima de transmissão (MTU) é o quadro de maior tamanho (pacote mais cabeçalhos de acesso à rede), especificado em bytes, que pode ser enviado através de uma interface de rede. A MTU é uma definição configurável. A MTU predefinida utilizada em VMs do Azure e a predefinição na maioria dos dispositivos de rede globalmente é de 1.500 bytes.
Fragmentação
A fragmentação ocorre quando um pacote é enviado que excede a MTU de uma interface de rede. A pilha TCP/IP quebrará o pacote em partes menores (fragmentos) que estão em conformidade com a MTU da interface. A fragmentação ocorre na camada IP e é independente do protocolo subjacente (como TCP). Quando um pacote de 2.000 bytes é enviado através de uma interface de rede com uma MTU de 1.500, o pacote será dividido em um pacote de 1.500 bytes e um pacote de 500 bytes.
Os dispositivos de rede no caminho entre uma origem e um destino podem descartar pacotes que excedem a MTU ou fragmentar o pacote em partes menores.
O bit Don't Fragment em um pacote IP
O bit Don't Fragment (DF) é um sinalizador no cabeçalho do protocolo IP. O bit DF indica que os dispositivos de rede no caminho entre o emissor e o recetor não devem fragmentar o pacote. Este bit pode ser definido por muitas razões. (Consulte a seção "Descoberta de MTU de caminho" deste artigo para obter um exemplo.) Quando um dispositivo de rede recebe um pacote com o conjunto de bits Don't Fragment e esse pacote excede a MTU da interface do dispositivo, o comportamento padrão é que o dispositivo solte o pacote. O dispositivo envia uma mensagem ICMP Fragmentation Needed de volta para a fonte original do pacote.
Implicações da fragmentação no desempenho
A fragmentação pode ter implicações negativas no desempenho. Uma das principais razões para o efeito no desempenho é o impacto da CPU/memória da fragmentação e remontagem de pacotes. Quando um dispositivo de rede precisa de fragmentar um pacote, terá que alocar recursos de CPU/memória para executar a fragmentação.
A mesma coisa acontece quando o pacote é remontado. O dispositivo de rede deve armazenar todos os fragmentos até que eles sejam recebidos para que possa remontá-los no pacote original.
Azure e fragmentação
Os pacotes fragmentados no Azure não são processados pela Rede Acelerada. Quando uma VM recebe um pacote fragmentado, ele será processado por meio do caminho não acelerado. Isso significa que os pacotes fragmentados não obterão os benefícios da Rede Acelerada (menor latência, desvio reduzido e pacotes mais altos por segundo). Por esta razão, recomendamos evitar a fragmentação, se possível.
Por padrão, o Azure abandonará os fragmentos de ordem, ou seja, pacotes fragmentados que não chegam à VM na ordem em que foram transmitidos do ponto de extremidade de origem. Isso pode acontecer quando os pacotes são transmitidos pela Internet ou outras WANs grandes. A reordenação de fragmentos fora de ordem pode ser ativada em alguns casos. Se um aplicativo exigir isso, abra um caso de suporte.
Sintonize o MTU
Não recomendamos que os clientes aumentem a MTU em NICs de VM. Se a VM precisar se comunicar com destinos que não estão na Rede Virtual que têm um conjunto de MTU semelhante, provavelmente ocorrerá fragmentação, o que diminuirá o desempenho.
Grande descarga de envio
O LSO (Large Send Offload) pode melhorar o desempenho da rede descarregando a segmentação de pacotes para o adaptador Ethernet. Quando o LSO está habilitado, a pilha TCP/IP cria um pacote TCP grande e o envia para o adaptador Ethernet para segmentação antes de encaminhá-lo. O benefício do LSO é que pode libertar a CPU da segmentação de pacotes em tamanhos que estão em conformidade com a MTU e descarregar esse processamento para a interface Ethernet, onde é executado no hardware. Para saber mais sobre os benefícios do LSO, consulte Suporte a descarga de envio grande.
Quando o LSO está habilitado, os clientes do Azure podem ver grandes tamanhos de quadros quando executam capturas de pacotes. Esses tamanhos de quadros grandes podem levar alguns clientes a pensar que a fragmentação está ocorrendo ou que um MTU grande está sendo usado quando não está. Com LSO, o adaptador Ethernet pode anunciar um tamanho máximo de segmento (MSS) maior para a pilha TCP/IP para criar um pacote TCP maior. Todo esse quadro não segmentado é então encaminhado para o adaptador Ethernet e seria visível em uma captura de pacote realizada na VM. Mas o pacote será dividido em muitos quadros menores pelo adaptador Ethernet, de acordo com o MTU do adaptador Ethernet.
Dimensionamento de janelas TCP MSS e PMTUD
Tamanho máximo do segmento TCP
O tamanho máximo do segmento TCP (MSS) é uma definição que limita o tamanho dos segmentos TCP, o que evita a fragmentação dos pacotes TCP. Os sistemas operativos normalmente utilizarão esta fórmula para definir o MSS:
MSS = MTU - (IP header size + TCP header size)
O cabeçalho IP e o cabeçalho TCP têm 20 bytes cada, ou 40 bytes no total. Assim, uma interface com um MTU de 1.500 terá um MSS de 1.460. Mas o MSS é configurável.
Essa configuração é acordada no handshake de três vias TCP quando uma sessão TCP é configurada entre uma origem e um destino. Ambos os lados enviam um valor MSS e o menor dos dois é usado para a conexão TCP.
Tenha em mente que as MTUs da origem e do destino não são os únicos fatores que determinam o valor MSS. Dispositivos de rede intermediários, como gateways VPN, incluindo o Gateway de VPN do Azure, podem ajustar a MTU independentemente da origem e do destino para garantir o desempenho ideal da rede.
Descoberta de MTU de caminho
O MSS é negociado, mas pode não indicar o MSS real que pode ser usado. Isso ocorre porque outros dispositivos de rede no caminho entre a origem e o destino podem ter um valor de MTU menor do que a origem e o destino. Nesse caso, o dispositivo cuja MTU é menor do que o pacote soltará o pacote. O dispositivo enviará de volta uma mensagem ICMP Fragmentation Needed (Tipo 3, Código 4) que contém seu MTU. Esta mensagem ICMP permite que o host de origem reduza sua MTU de caminho adequadamente. O processo é chamado de Path MTU Discovery (PMTUD).
O processo PMTUD é ineficiente e afeta o desempenho da rede. Quando pacotes são enviados que excedem a MTU de um caminho de rede, os pacotes precisam ser retransmitidos com um MSS mais baixo. Se o remetente não receber a mensagem ICMP Fragmentation Needed, talvez devido a um firewall de rede no caminho (comumente referido como um buraco negro PMTUD), o remetente não sabe que precisa baixar o MSS e retransmitirá continuamente o pacote. É por isso que não recomendamos aumentar a MTU da VM do Azure.
VPN e MTU
Se você usar VMs que executam encapsulamento (como VPNs IPsec), há algumas considerações adicionais sobre o tamanho do pacote e MTU. As VPNs adicionam mais cabeçalhos aos pacotes, o que aumenta o tamanho do pacote e requer um MSS menor.
Para o Azure, recomendamos que você defina o TCP MSS clamping como 1.350 bytes e o MTU da interface de túnel como 1.400. Para obter mais informações, consulte a página de dispositivos VPN e parâmetros IPSec/IKE.
Latência, tempo de ida e volta e dimensionamento de janelas TCP
Latência e tempo de ida e volta
A latência da rede é regida pela velocidade da luz através de uma rede de fibra ótica. A taxa de transferência de rede do TCP também é efetivamente governada pelo tempo de ida e volta (RTT) entre dois dispositivos de rede.
| Rota | Distância | Tempo unidirecional | RTT |
|---|---|---|---|
| Nova Iorque para São Francisco | 4.148 quilômetros | 21 ms | 42 ms |
| Nova Iorque para Londres | 5.585 quilômetros | 28 ms | 56 ms |
| Nova Iorque para Sydney | 15.993 quilômetros | 80 ms | 160 ms |
Esta tabela mostra a distância em linha reta entre dois locais. Em redes, a distância é normalmente maior do que a distância em linha reta. Aqui está uma fórmula simples para calcular o RTT mínimo conforme regido pela velocidade da luz:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
Você pode usar 200 para a velocidade de propagação. Esta é a distância, em quilómetros, que a luz percorre em 1 milissegundo.
Tomemos como exemplo Nova Iorque e São Francisco. A distância em linha reta é de 4.148 km. Conectando esse valor à equação, obtemos o seguinte:
Minimum RTT = 2 * (4,148 / 200)
A saída da equação é em milissegundos.
Se você quiser obter o melhor desempenho de rede, a opção lógica é selecionar destinos com a menor distância entre eles. Você também deve projetar sua rede virtual para otimizar o caminho do tráfego e reduzir a latência. Para obter mais informações, consulte a seção "Considerações de design de rede" deste artigo.
Efeitos de latência e tempo de ida e volta no TCP
O tempo de ida e volta tem um efeito direto na taxa de transferência máxima de TCP. No protocolo TCP, o tamanho da janela é a quantidade máxima de tráfego que pode ser enviada através de uma conexão TCP antes que o remetente precise receber a confirmação do recetor. Se o TCP MSS estiver definido como 1.460 e o tamanho da janela TCP estiver definido como 65.535, o remetente poderá enviar 45 pacotes antes de ter de receber a confirmação do recetor. Se o remetente não receber a confirmação, ele retransmitirá os dados. A fórmula é esta:
TCP window size / TCP MSS = packets sent
Neste exemplo, 65.535 / 1.460 é arredondado para 45.
Esse estado de "aguardando reconhecimento", um mecanismo para garantir a entrega confiável de dados, é o que faz com que o RTT afete a taxa de transferência TCP. Quanto mais tempo o remetente espera pela confirmação, mais tempo precisa esperar antes de enviar mais dados.
Eis a fórmula para calcular a taxa de transferência máxima de uma única ligação TCP:
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
Esta tabela mostra a taxa de transferência máxima de megabytes/segundo de uma única conexão TCP. (Para facilitar a leitura, megabytes são usados para a unidade de medida.)
| Tamanho da janela TCP (bytes) | Latência RTT (ms) | Taxa de transferência máxima de megabyte/segundo | Taxa de transferência máxima de megabit/segundo |
|---|---|---|---|
| 65,535 | 1 | 65.54 | 524.29 |
| 65,535 | 30 | 2.18 | 17.48 |
| 65,535 | 60 | 1.09 | 8.74 |
| 65,535 | 90 | .73 | 5,83 |
| 65,535 | 120 | 55. | 4.37 |
Se os pacotes forem perdidos, a taxa de transferência máxima de uma conexão TCP será reduzida enquanto o remetente retransmite os dados já enviados.
Dimensionamento de janelas TCP
O dimensionamento de janelas TCP é uma técnica que aumenta dinamicamente o tamanho da janela TCP para permitir que mais dados sejam enviados antes que uma confirmação seja necessária. No exemplo anterior, 45 pacotes seriam enviados antes que uma confirmação fosse necessária. Se você aumentar o número de pacotes que podem ser enviados antes que uma confirmação seja necessária, estará reduzindo o número de vezes que um remetente está aguardando confirmação, o que aumenta a taxa de transferência máxima do TCP.
Esta tabela ilustra essas relações:
| Tamanho da janela TCP (bytes) | Latência RTT (ms) | Taxa de transferência máxima de megabyte/segundo | Taxa de transferência máxima de megabit/segundo |
|---|---|---|---|
| 65,535 | 30 | 2.18 | 17.48 |
| 131,070 | 30 | 4.37 | 34.95 |
| 262,140 | 30 | 8.74 | 69.91 |
| 524,280 | 30 | 17.48 | 139.81 |
Mas o valor do cabeçalho TCP para o tamanho da janela TCP é de apenas 2 bytes de comprimento, o que significa que o valor máximo para uma janela de receção é 65.535. Para aumentar o tamanho máximo da janela, foi introduzido um fator de escala de janela TCP.
O fator de escala também é uma configuração que você pode configurar em um sistema operacional. Eis a fórmula para calcular o tamanho da janela TCP utilizando fatores de escala:
TCP window size = TCP window size in bytes * (2^scale factor)
Aqui está o cálculo para um fator de escala de janela de 3 e um tamanho de janela de 65.535:
65,535 * (2^3) = 524,280 bytes
Um fator de escala de 14 resulta em um tamanho de janela TCP de 14 (o deslocamento máximo permitido). O tamanho da janela TCP será 1.073.725.440 bytes (8,5 gigabits).
Suporte para dimensionamento de janelas TCP
O Windows pode definir diferentes fatores de dimensionamento para diferentes tipos de conexão. (As classes de conexões incluem datacenter, internet e assim por diante.) Use o Get-NetTCPConnection comando PowerShell para exibir o tipo de conexão de dimensionamento de janela:
Get-NetTCPConnection
Você pode usar o Get-NetTCPSetting comando PowerShell para exibir os valores de cada classe:
Get-NetTCPSetting
Você pode definir o tamanho da janela TCP inicial e o fator de dimensionamento TCP no Windows usando o Set-NetTCPSetting comando PowerShell. Para obter mais informações, consulte Set-NetTCPSetting.
Set-NetTCPSetting
Estas são as configurações TCP efetivas para AutoTuningLevel:
| AutoTuningLevel | Fator de escala | Multiplicador de escala | Fórmula para calcular o tamanho máximo da janela |
|---|---|---|---|
| Desativado | Nenhuma | Nenhuma | Tamanho da janela |
| Restrito | 4 | 2^4 | Tamanho da janela * (2^4) |
| Altamente restrito | 2 | 2^2 | Tamanho da janela * (2^2) |
| Normal | 8 | 2^8 | Tamanho da janela * (2^8) |
| Experimental | 14 | 2^14 | Tamanho da janela * (2^14) |
Essas configurações são as mais prováveis de afetar o desempenho do TCP, mas lembre-se de que muitos outros fatores na Internet, fora do controle do Azure, também podem afetar o desempenho do TCP.
Rede acelerada e dimensionamento lateral de recebimento
Rede acelerada
Historicamente, as funções de rede da máquina virtual têm sido intensivas em CPU na VM convidada e no hipervisor/host. Cada pacote que transita pelo host é processado em software pela CPU do host, incluindo todo o encapsulamento e descapsulação de rede virtual. Assim, quanto mais tráfego passar pelo host, maior será a carga da CPU. E se a CPU do host estiver ocupada com outras operações, isso também afetará a taxa de transferência e a latência da rede. O Azure resolve este problema com a rede acelerada.
A rede acelerada fornece latência de rede ultrabaixa consistente por meio do hardware programável interno do Azure e de tecnologias como SR-IOV. A rede acelerada move grande parte da pilha de rede definida por software do Azure das CPUs para SmartNICs baseadas em FPGA. Esta alteração permite que as aplicações do utilizador final recuperem ciclos de computação, o que coloca menos carga na VM, diminuindo a interferência e a inconsistência na latência. Por outras palavras, o desempenho pode ser mais determinista.
A rede acelerada melhora o desempenho, permitindo que a VM convidada ignore o host e estabeleça um caminho de dados diretamente com o SmartNIC de um host. Aqui estão alguns benefícios da rede acelerada:
Menor latência / pacotes por segundo (pps) mais altos: remover o comutador virtual do caminho de dados elimina o tempo que os pacotes gastam no host para processamento de políticas e aumenta o número de pacotes que podem ser processados na VM.
Desvio reduzido: o processamento do comutador virtual depende da quantidade de política que precisa ser aplicada e da carga de trabalho da CPU que está fazendo o processamento. Descarregando a imposição de política para o hardware remove essa variabilidade entregando pacotes diretamente para a VM, eliminando a comunicação host-to-VM e todas as interrupções de software e comutadores de contexto.
Menor utilização da CPU: ignorar o comutador virtual no anfitrião leva a uma menor utilização da CPU para processar o tráfego da rede.
Para usar a rede acelerada, você precisa habilitá-la explicitamente em cada VM aplicável. Consulte Criar uma máquina virtual Linux com rede acelerada para obter instruções.
Receber dimensionamento lateral
O RSS (Receive side scaling) é uma tecnologia de driver de rede que distribui o recebimento de tráfego de rede de forma mais eficiente, distribuindo o processamento de recebimento entre várias CPUs em um sistema multiprocessador. Em termos simples, o RSS permite que um sistema processe mais tráfego recebido porque usa todas as CPUs disponíveis em vez de apenas uma. Para obter uma discussão mais técnica sobre RSS, consulte Introdução ao dimensionamento lateral de recebimento.
Para obter o melhor desempenho quando a rede acelerada está habilitada em uma VM, você precisa habilitar o RSS. O RSS também pode fornecer benefícios em VMs que não usam rede acelerada. Para obter uma visão geral de como determinar se o RSS está habilitado e como habilitá-lo, consulte Otimizar a taxa de transferência de rede para máquinas virtuais do Azure.
TIME_WAIT TCP e assassinato TIME_WAIT
O TCP TIME_WAIT é outra configuração comum que afeta o desempenho da rede e do aplicativo. Em VMs ocupadas que estão abrindo e fechando muitos soquetes, seja como clientes ou como servidores (IP de origem:Porta de origem + Porta de destino IP:Porta de destino), durante a operação normal do TCP, um determinado soquete pode acabar em um estado TIME_WAIT por um longo tempo. O estado TIME_WAIT destina-se a permitir que quaisquer dados adicionais sejam entregues em um soquete antes de fechá-lo. Assim, as pilhas TCP/IP geralmente impedem a reutilização de um soquete descartando silenciosamente o pacote TCP SYN do cliente.
A quantidade de tempo que um soquete está no TIME_WAIT é configurável. Pode variar de 30 segundos a 240 segundos. Os soquetes são um recurso finito, e o número de soquetes que podem ser usados a qualquer momento é configurável. (O número de soquetes disponíveis é normalmente de cerca de 30.000.) Se os soquetes disponíveis forem consumidos ou se os clientes e servidores tiverem configurações de TIME_WAIT incompatíveis e uma VM tentar reutilizar um soquete em um estado TIME_WAIT, novas conexões falharão quando os pacotes TCP SYN forem descartados silenciosamente.
O valor do intervalo de portas para soquetes de saída geralmente é configurável dentro da pilha TCP/IP de um sistema operacional. A mesma coisa é verdade para as configurações de TIME_WAIT TCP e reutilização de soquete. Alterar esses números pode potencialmente melhorar a escalabilidade. Mas, dependendo da situação, essas alterações podem causar problemas de interoperabilidade. Deve ter cuidado se alterar estes valores.
Você pode usar TIME_WAIT assassinato para resolver essa limitação de escala. TIME_WAIT assassinato permite que um soquete seja reutilizado em determinadas situações, como quando o número de sequência no pacote IP da nova conexão excede o número de sequência do último pacote da conexão anterior. Nesse caso, o sistema operacional permitirá que a nova conexão seja estabelecida (ele aceitará o novo SYN/ACK) e forçará o fechamento da conexão anterior que estava em um estado TIME_WAIT. Esse recurso é suportado em VMs do Windows no Azure. Para saber mais sobre o suporte em outras VMs, consulte o fornecedor do sistema operacional.
Para saber mais sobre como configurar as configurações de TIME_WAIT TCP e o intervalo de portas de origem, consulte Configurações que podem ser modificadas para melhorar o desempenho da rede.
Fatores de rede virtual que podem afetar o desempenho
Taxa de transferência máxima de saída da VM
O Azure fornece uma variedade de tamanhos e tipos de VM, cada um com uma combinação diferente de recursos de desempenho. Um desses recursos é a taxa de transferência de rede (ou largura de banda), que é medida em megabits por segundo (Mbps). Como as máquinas virtuais são hospedadas em hardware compartilhado, a capacidade da rede precisa ser compartilhada de forma justa entre as máquinas virtuais que usam o mesmo hardware. Máquinas virtuais maiores recebem mais largura de banda do que máquinas virtuais menores.
A largura de banda de rede alocada para cada máquina virtual é medida pelo tráfego de saída (saída) da máquina virtual. Todo o tráfego de rede que sai da máquina virtual é contado para o limite alocado, independentemente do destino. Por exemplo, se uma máquina virtual tiver um limite de 1.000 Mbps, esse limite se aplicará se o tráfego de saída for destinado a outra máquina virtual na mesma rede virtual ou fora do Azure.
A entrada não é medida ou limitada diretamente. Mas há outros fatores, como limites de CPU e armazenamento, que podem afetar a capacidade de uma máquina virtual de processar dados de entrada.
A rede acelerada foi projetada para melhorar o desempenho da rede, incluindo latência, taxa de transferência e utilização da CPU. A rede acelerada pode melhorar a taxa de transferência de uma máquina virtual, mas pode fazer isso apenas até a largura de banda alocada da máquina virtual.
As máquinas virtuais do Azure têm pelo menos uma interface de rede conectada a elas. Podem ter vários. A largura de banda alocada para uma máquina virtual é a soma de todo o tráfego de saída em todas as interfaces de rede conectadas à máquina. Em outras palavras, a largura de banda é alocada por máquina virtual, independentemente de quantas interfaces de rede estão conectadas à máquina.
A taxa de transferência de saída esperada e o número de interfaces de rede suportadas por cada tamanho de VM são detalhados em Tamanhos para máquinas virtuais do Windows no Azure. Para ver a taxa de transferência máxima, selecione um tipo, como Finalidade geral, e localize a seção sobre a série de tamanhos na página resultante (por exemplo, "Série Dv2"). Para cada série, há uma tabela que fornece especificações de rede na última coluna, intitulada "Max NICs / Expected network bandwidth (Mbps)".
O limite do débito aplica-se à máquina virtual. A taxa de transferência não é afetada por estes fatores:
Número de interfaces de rede: O limite de largura de banda aplica-se à soma de todo o tráfego de saída da máquina virtual.
Rede acelerada: embora esse recurso possa ser útil para atingir o limite publicado, ele não altera o limite.
Destino do tráfego: Todos os destinos contam para o limite de saída.
Protocolo: Todo o tráfego de saída em todos os protocolos conta para o limite.
Para obter mais informações, consulte Largura de banda de rede de máquina virtual.
Considerações sobre o desempenho da Internet
Conforme discutido ao longo deste artigo, fatores na Internet e fora do controle do Azure podem afetar o desempenho da rede. Aqui estão alguns desses fatores:
Latência: O tempo de ida e volta entre dois pontos finais pode ser afetado por problemas em redes intermediárias, pelo tráfego que não toma o caminho de distância "mais curto" e por caminhos de emparelhamento subótimos.
Perda de pacotes: A perda de pacotes pode ser causada por congestionamento de rede, problemas de caminho físico e dispositivos de rede com baixo desempenho.
Tamanho MTU/Fragmentação: A fragmentação ao longo do caminho pode levar a atrasos na chegada de dados ou em pacotes que chegam fora de ordem, o que pode afetar a entrega de pacotes.
O Traceroute é uma boa ferramenta para medir as características de desempenho da rede (como perda de pacotes e latência) ao longo de cada caminho de rede entre um dispositivo de origem e um dispositivo de destino.
Considerações sobre design de rede
Juntamente com as considerações discutidas anteriormente neste artigo, a topologia de uma rede virtual pode afetar o desempenho da rede. Por exemplo, um design hub-and-spoke que faz backhaul do tráfego globalmente para uma rede virtual de hub único introduzirá latência de rede, o que afetará o desempenho geral da rede.
O número de dispositivos de rede pelos quais o tráfego de rede passa também pode afetar a latência geral. Por exemplo, em um design hub-and-spoke, se o tráfego passar por um dispositivo virtual de rede spoke e um dispositivo virtual de hub antes de transitar para a Internet, os dispositivos virtuais de rede introduzirão alguma latência.
Regiões do Azure, redes virtuais e latência
As regiões do Azure são compostas por vários datacenters que existem dentro de uma área geográfica geral. Esses datacenters podem não estar fisicamente próximos uns dos outros. Em alguns casos, eles estão separados por até 10 quilômetros. A rede virtual é uma sobreposição lógica sobre a rede de datacenter físico do Azure. Uma rede virtual não implica nenhuma topologia de rede específica dentro do datacenter.
Por exemplo, duas VMs que estão na mesma rede virtual e sub-rede podem estar em racks, linhas ou até mesmo datacenters diferentes. Eles podem ser separados por pés de cabo de fibra ótica ou por quilômetros de cabo de fibra ótica. Essa variação pode introduzir latência variável (diferença de alguns milissegundos) entre VMs diferentes.
O posicionamento geográfico de VMs e a latência resultante potencial entre duas VMs podem ser influenciados pela configuração de conjuntos de disponibilidade, grupos de posicionamento de proximidade e zonas de disponibilidade. Mas a distância entre os datacenters em uma região é específica da região e influenciada principalmente pela topologia do datacenter na região.
Exaustão da porta NAT de origem
Uma implantação no Azure pode se comunicar com pontos de extremidade fora do Azure na Internet pública e/ou no espaço IP público. Quando uma instância inicia uma conexão de saída, o Azure mapeia dinamicamente o endereço IP privado para um endereço IP público. Depois que o Azure cria esse mapeamento, o tráfego de retorno para o fluxo originado de saída também pode chegar ao endereço IP privado onde o fluxo se originou.
Para cada conexão de saída, o Balanceador de Carga do Azure precisa manter esse mapeamento por algum período de tempo. Com a natureza multilocatária do Azure, manter esse mapeamento para cada fluxo de saída para cada VM pode exigir muitos recursos. Portanto, há limites que são definidos e baseados na configuração da Rede Virtual do Azure. Ou, para dizer que, mais precisamente, uma VM do Azure só pode fazer um determinado número de conexões de saída em um determinado momento. Quando esses limites forem atingidos, a VM não poderá fazer mais conexões de saída.
Mas esse comportamento é configurável. Para obter mais informações sobre o esgotamento da porta SNAT e SNAT, consulte este artigo.
Meça o desempenho da rede no Azure
Vários dos máximos de desempenho neste artigo estão relacionados à latência de rede / tempo de ida e volta (RTT) entre duas VMs. Esta seção fornece algumas sugestões sobre como testar a latência/RTT e como testar o desempenho do TCP e da rede VM. Você pode ajustar e testar o desempenho dos valores de TCP/IP e rede discutidos anteriormente usando as técnicas descritas nesta seção. Você pode conectar valores de latência, MTU, MSS e tamanho de janela aos cálculos fornecidos anteriormente e comparar máximos teóricos com valores reais observados durante o teste.
Meça o tempo de ida e volta e a perda de pacotes
O desempenho do TCP depende muito do RTT e da perda de pacotes. O utilitário PING disponível no Windows e Linux fornece a maneira mais fácil de medir RTT e perda de pacotes. A saída de PING mostrará a latência mínima/máxima/média entre uma origem e um destino. Ele também mostrará perda de pacote. O PING usa o protocolo ICMP por padrão. Você pode usar o PsPing para testar o TCP RTT. Para obter mais informações, consulte PsPing.
Nem os pings ICMP nem TCP medem o caminho de dados de rede acelerado. Para medir isso, leia sobre Latte e SockPerf neste artigo.
Medir a largura de banda real de uma máquina virtual
Para medir com precisão a largura de banda das VMs do Azure, siga estas orientações.
Para obter mais detalhes sobre como testar outros cenários, consulte estes artigos:
How to validate VPN throughput to a virtual network (Como validar o débito da VPN para uma rede virtual)
Detetar comportamentos TCP ineficientes
Nas capturas de pacotes, os clientes do Azure podem ver pacotes TCP com sinalizadores TCP (SACK, DUP ACK, RETRANSMISSION e FAST RETRANSMIT) que podem indicar problemas de desempenho de rede. Esses pacotes indicam especificamente ineficiências de rede resultantes da perda de pacotes. Mas a perda de pacotes não é necessariamente causada por problemas de desempenho do Azure. Os problemas de desempenho podem ser o resultado de aplicativos, sistemas operacionais ou outros problemas que podem não estar diretamente relacionados à plataforma Azure.
Além disso, tenha em mente que algumas ACKs de retransmissão e duplicadas são normais em uma rede. Os protocolos TCP foram construídos para serem confiáveis. A evidência desses pacotes TCP em uma captura de pacotes não indica necessariamente um problema de rede sistêmico, a menos que sejam excessivos.
Ainda assim, esses tipos de pacotes são indicações de que a taxa de transferência TCP não está atingindo seu desempenho máximo, por motivos discutidos em outras seções deste artigo.
Próximos passos
Agora que você aprendeu sobre o ajuste de desempenho de TCP/IP para VMs do Azure, convém ler sobre outras considerações para planejar redes virtuais ou saber mais sobre como conectar e configurar redes virtuais.