Ajuste de desempenho de TCP/IP em VMs do Azure
Este artigo discute técnicas comuns de ajuste de desempenho de TCP/IP e algumas coisas a serem consideradas ao usá-las para máquinas virtuais em execução no Azure. Ele fornecerá uma visão geral básica das técnicas, explorando como elas podem ser ajustadas.
Técnicas comuns de ajuste de TCP/IP
MTU, fragmentação e descarregamento de envio grande
MTU
A MTU (unidade máxima de transmissão) é o maior quadro de tamanho (pacote mais cabeçalhos de acesso à rede), especificado em bytes, que pode ser enviado por um adaptador de rede. A MTU é um ajuste configurável. A MTU padrão usada nas VMs do Azure e a configuração padrão usada na maioria dos dispositivos de rede globalmente é de 1.500 bytes.
Fragmentação
A fragmentação ocorre quando um pacote enviado excede a MTU de um adaptador de rede. A pilha de TCP/IP dividirá o pacote em pedaços menores (fragmentos) que estão em conformidade com a MTU da interface. A fragmentação ocorre na camada de IP e é independente do protocolo subjacente (como TCP). Quando um pacote de 2.000 bytes é enviado por um adaptador de rede com 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 os pacotes que excedem a MTU ou fragmentar em pacotes menores.
O bit Não fragmentar em um pacote IP
O bit DF (Don’t Fragment) é um sinalizador no cabeçalho do protocolo IP. O bit DF indica que os dispositivos de rede no caminho entre o remetente e o destinatário não devem fragmentar o pacote. Esse bit poderia ser definido por vários motivos. (Consulte a seção "descoberta de MTU de caminho" deste artigo para ver um exemplo.) Quando um dispositivo de rede recebe um pacote com o conjunto de bits DF e esse pacote excede a MTU da interface do dispositivo, o comportamento padrão é que o dispositivo descarte o pacote. O dispositivo envia uma mensagem de Fragmentação de ICMP necessária de volta para a fonte original do pacote.
Implicações de desempenho da fragmentação
A fragmentação pode ter implicações negativas de desempenho. Uma das principais razões para o efeito no desempenho é o impacto da CPU/memória da fragmentação e da remontagem dos pacotes. Quando um dispositivo de rede precisar fragmentar um pacote, ele precisará 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 ele possa remontá-los no pacote original.
O Azure e a fragmentação
Os pacotes fragmentados no Azure não são processados pela Rede Acelerada. Quando uma VM recebe um pacote fragmentado, ela será processada por meio do caminho não acelerado. Isso significa que os pacotes fragmentados não obterão os benefícios da Rede Acelerada (latência mais baixa, tremulação reduzida e pacotes mais altos por segundo). Por esse motivo, recomendamos evitar a fragmentação, se possível.
Por padrão, o Azure removerá os fragmentos de pedido, 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 outros WANs grandes. A reordenação de fragmento fora de ordem pode ser habilitada em alguns casos. Se um aplicativo exigir isso, abra um caso de suporte.
Ajustar a 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á uma fragmentação que diminuirá o desempenho.
Descarregamento de envio grande
O LSO (descarregamento de envio grande) pode melhorar o desempenho da rede, descarregando a segmentação de pacotes para o adaptador Ethernet. Quando o LSO é habilitado, a pilha TCP/IP cria um pacote TCP grande e, antes de encaminhá-lo, o envia ao adaptador Ethernet para segmentação. O benefício do LSO é que ele pode evitar que a CPU segmente pacotes em tamanhos de acordo com a MTU e descarregue o processamento para a interface Ethernet, onde ele é executado no hardware. Para saber mais sobre os benefícios do LSO, consulte Suporte ao descarregamento de envio grande.
Quando o LSO está habilitado, os clientes do Azure podem ver tamanhos de quadros grandes ao capturar pacote. Esses quadros grandes podem levar alguns clientes a acreditar que a fragmentação está ocorrendo, ou que uma MTU grande está sendo usada quando não está. Com o LSO, o adaptador Ethernet pode anunciar um MSS (tamanho máximo de segmento) maior para a pilha TCP/IP, criando um pacote TCP maior. Em seguida, todo esse quadro não segmentado é encaminhado para o adaptador Ethernet e fica visível em uma captura de pacote executada na VM. Mas o pacote será dividido em muitos quadros menores pelo adaptador Ethernet, de acordo com a MTU do adaptador Ethernet.
PMTUD e escala da janela de MSS do TCP
Tamanho máximo de segmento do TCP
O MSS (tamanho máximo de segmento) do TCP é uma configuração que limita o tamanho dos segmentos do TCP, evitando a fragmentação dos pacotes. Os sistemas operacionais geralmente usam essa 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 ao todo. Portanto, uma interface com uma MTU de 1.500 terá um MSS de 1.460. Mas o MSS é configurável.
Essa configuração é definida no handshake de três vias do TCP, quando sua sessão é configurada entre uma origem e um destino. Ambos os lados enviam um valor de MSS, e o menor dos dois é usado para a conexão do TCP.
As MTUs da origem e do destino não são os únicos fatores que determinam o valor do MSS. Os dispositivos de rede intermediários, como Gateways de VPN, incluindo o Gateway de VPN do Azure, podem ajustar a MTU independentemente da origem e do destino, garantindo o desempenho ideal da rede.
PMTUD (Descoberta de MTU do caminho)
O MSS é negociado, mas pode não indicar o MSS real a 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 removerá o pacote. O dispositivo enviará de volta uma mensagem de Fragmentação ICMP necessária (tipo 3, código 4), com sua MTU. Essa mensagem ICMP permite que o host de origem reduza corretamente a MTU do seu caminho. O processo é chamado de PMTUD (Descoberta de MTU do caminho).
O processo de PMTUD é ineficaz e afeta o desempenho da rede. Quando são enviados pacotes que excedem a MTU de um caminho de rede, os pacotes precisam ser retransmitidos com um MSS inferior. Se o remetente não receber a mensagem de Fragmentação ICMP necessária, talvez devido a um firewall de rede no caminho (comumente chamado de Blackhole da PMTUD), o remetente não saberá que precisa reduzir o MSS, e continuará retransmitindo o pacote. Por isso, não recomendamos aumentar a MTU de VM do Azure.
VPN e MTU
Há algumas considerações adicionais sobre o tamanho do pacote e a MTU ao usar VMs que executam encapsulamento (como VPNs IPsec). As VPNs adicionam mais cabeçalhos aos pacotes, aumentando o tamanho do pacote e exigindo um MSS menor.
Para o Azure, recomendamos definir o MSS do TCP em 1.350 bytes e a MTU da interface de túnel em 1.400. Para obter mais informações, consulte a página Dispositivos VPN e parâmetros de IPSec/IKE.
Latência, tempo de ida e volta e escala da janela do TCP
Latência e tempo de ida e volta
A latência de rede é definida pela velocidade da luz em uma rede de fibra óptica. A taxa de transferência de rede do TCP também é definida pelo RTT (tempo de ida e volta) entre dois dispositivos de rede.
| Rota | Distância | Tempo unidirecional | RTT |
|---|---|---|---|
| Nova York a São Francisco | 4\.148 km | 21 ms | 42 ms |
| Nova York para Londres | 5\.585 km | 28 ms | 56 ms |
| Nova York para Sydney | 15.993 km | 80 ms | 160 ms |
Esta tabela mostra a distância em linha reta entre dois locais. Normalmente, a distância em redes é maior do que a distância de linha reta. Esta é uma fórmula simples para calcular o mínimo de RTT conforme definido pela velocidade da luz:
minimum RTT = 2 * (Distance in kilometers / Speed of propagation)
É possível usar 200 para a velocidade de propagação. Esta é a distância, em quilômetros, que a luz viaja em 1 milissegundo.
Vejamos o exemplo de Nova York a San Francisco. A distância em linha reta é de 4.148 km. Ao conectar esse valor à equação, obtemos o seguinte:
Minimum RTT = 2 * (4,148 / 200)
A saída da equação está em milissegundos.
Se quiser obter o melhor desempenho de rede, a opção lógica é selecionar os destinos com a distância mais curta. Crie também 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 criação de rede" deste artigo.
Latência e efeitos do tempo de ida e volta no TCP
O tempo de ida e volta tem um efeito direto na taxa de transferência máxima do TCP. No protocolo TCP, tamanho da janela é a quantidade máxima de tráfego que pode ser enviada por uma conexão TCP antes que o remetente precise receber a confirmação do destinatário. Se o MSS do TCP estiver definido como 1.460 e o tamanho da janela do TCP for 65.535, o remetente poderá enviar 45 pacotes antes de receber a confirmação do destinatário. Se o remetente não receber a confirmação, ele retransmitirá os dados. Aqui está a fórmula:
TCP window size / TCP MSS = packets sent
Neste exemplo, 65.535/1.460 é arredondado para 45.
O estado "aguardando confirmação" é um mecanismo para garantir a entrega confiável dos dados, e faz com que o RTT afete a taxa de transferência do TCP. Quanto mais tempo o remetente aguardar pela confirmação, mais tempo ele precisará aguardar antes de enviar mais dados.
Veja a fórmula para calcular a taxa de transferência máxima de uma única conexão do TCP:
Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second
Esta tabela mostra a taxa de transferência máxima em megabytes/segundo de uma única conexão do TCP. (Para facilitar a leitura, a unidade de medida usada é megabytes.)
| Tamanho da janela do TCP (bytes) | Latência do RTT (ms) | Taxa de transferência máxima de megabytes/segundo | Taxa de transferência máxima de megabits/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 | 0\.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.
Escala da janela do TCP
A escala da janela do TCP é uma técnica que aumenta dinamicamente o tamanho da janela do TCP para permitir que mais dados sejam enviados antes que seja necessária uma confirmação. No exemplo anterior, 45 pacotes seriam enviados antes que uma confirmação fosse necessária. Ao aumentar o número de pacotes que podem ser enviados antes que a confirmação seja necessária, você reduz o número de vezes que um remetente aguarda pela confirmação, o que aumenta a taxa de transferência máxima do TCP.
Esta tabela ilustra essas relações:
| Tamanho da janela do TCP (bytes) | Latência do RTT (ms) | Taxa de transferência máxima de megabytes/segundo | Taxa de transferência máxima de megabits/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 para o tamanho da janela do TCP é de apenas 2 bytes, o que significa que o valor máximo para uma janela de recepção é de 65.535. Para aumentar o tamanho máximo da janela, foi definido um fator de escala de janela do TCP.
O fator de escala também é uma configuração que pode ser feita em um sistema operacional. Aqui está a fórmula para calcular o tamanho da janela do TCP usando fatores de escala:
TCP window size = TCP window size in bytes * (2^scale factor)
Este é o cálculo de um fator de escala de 3 para a janela 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 do TCP de 14 (o deslocamento máximo permitido). O tamanho da janela do TCP será de 1.073.725.440 bytes (8,5 gigabits).
Suporte para escala de janela do TCP
O Windows pode definir fatores de escala diferentes para tipos de conexão diferentes. (As classes de conexões incluem datacenter, Internet e assim por diante.) Use o Get-NetTCPConnection comando do PowerShell para exibir o tipo de conexão de escala da janela:
Get-NetTCPConnection
É possível usar o comandoGet-NetTCPSetting do PowerShell para exibir os valores de cada classe:
Get-NetTCPSetting
Defina o tamanho inicial da janela do TCP e o fator de escala do TCP no Windows usando o Set-NetTCPSetting comando do PowerShell. Para obter mais informações, consulte Set-NetTCPSetting.
Set-NetTCPSetting
Essas são as configurações efetivas do TCP para AutoTuningLevel:
| AutoTuningLevel | Fator de escala | Multiplicador de escala | Fórmula para calcular o tamanho máximo da janela |
|---|---|---|---|
| Desabilitado | Nenhum | Nenhum | Tamanho da janela |
| Restritos | 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) |
| Habilitação | 14 | 2^14 | Tamanho da janela * (2^14) |
É mais provável que essas configurações afetem o desempenho do TCP, mas muitos outros fatores na Internet, fora do controle do Azure, também podem afetar o desempenho do TCP.
Rede acelerada e recebimento de escala lateral
Redes aceleradas
As funções de rede da máquina virtual costumam ter uso intenso da CPU na VM convidada e no hipervisor/host. Cada pacote que está em trânsito no host é processado no software pela CPU do host, incluindo todos os encapsulamentos de rede virtual e desencapsulamento. Portanto, 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 esse problema com a rede acelerada.
A rede acelerada fornece latência de rede ultralow 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 pelo software do Azure para fora das CPUs e para o SmartNICs baseado em FPGA. Essa alteração permite que os aplicativos do usuário final recuperem ciclos de computação, o que coloca menos carga na VM, diminuindo a tremulação e inconsistência na latência. Em outras palavras, o desempenho pode ser mais determinístico.
A rede acelerada melhora o desempenho, permitindo que a VM convidada ignore o host e estabeleça um DataPath diretamente com o SmartNIC de um host. Aqui estão alguns benefícios da rede acelerada:
Latência menor/mais pps (pacotes por segundo): remover o comutador virtual do caminho de dados elimina o tempo que os pacotes gastam no host para processamento da política e aumenta o número de pacotes que podem ser processados na VM.
Tremulação reduzida: processamento de comutador virtual depende da quantidade de política que precisa ser aplicada e da carga de trabalho da CPU que está fazendo o processamento. O descarregamento da imposição de política para o hardware remove essa variabilidade ao entregar pacotes diretamente à VM, removendo a comunicação do host para a VM e todas as interrupções e mudanças de contexto de software.
Menor utilização da CPU: ignorar o comutador virtual no host resulta em menor utilização da CPU para processar o tráfego de rede.
Para usar a rede acelerada, você precisa habilitá-la explicitamente em cada VM aplicável. Veja instruções em Criar uma máquina virtual Linux com a rede acelerada.
Recebimento de escala lateral
O RSS (recebimento de escala lateral) é uma tecnologia de driver de rede que distribui o recebimento de tráfego de rede com mais eficiência, distribuindo o processamento de recebimento entre várias CPUs em um sistema multiprocessador. Em resumo, o RSS permite que um sistema processe mais tráfego recebido porque usa todas as CPUs disponíveis em vez de apenas uma. Para uma discussão mais técnica sobre o RSS, consulte Introdução ao recebimento da escala lateral.
Para obter o melhor desempenho quando as rede acelerada estão habilitada em uma VM, habilite o RSS. O RSS também pode fornecer benefícios para VMs que não usam rede acelerada. Para ter uma visão geral sobre como determinar se o RSS está habilitado e como habilitá-lo, consulte Otimizar a taxa de transferência da rede para máquinas virtuais do Azure.
TIME_WAIT do TCP e TIME_WAIT Assassination
O TIME_WAIT do TCP é outra configuração comum que afeta o desempenho da rede e do aplicativo. Em VMs ocupadas que estiverem abrindo e fechando muitos soquetes, seja como clientes ou como servidores (IP de origem: porta de origem + IP de destino: porta de destino), durante a operação normal do TCP, um determinado soquete pode terminar em um estado de TIME_WAIT por muito tempo. O estado de TIME_WAIT permite que os dados adicionais sejam entregues em um soquete antes de fechá-lo. Portanto, as pilhas de TCP/IP geralmente impedem a reutilização de um soquete, removendo silenciosamente o pacote SYN do TCP do cliente.
A quantidade de tempo em que um soquete está em TIME_WAIT é configurável, podendo variar de 30 a 240 segundos. Os soquetes são um recurso finito, e é possível configurar o número de soquetes que podem ser usados em um determinado momento. (O número de soquetes disponíveis normalmente é cerca de 30.000.) Se os soquetes disponíveis forem consumidos, ou se os clientes e servidores tiverem configurações incompatíveis de TIME_WAIT e uma VM tentar reutilizar um soquete em estado de TIME_WAIT, novas conexões falharão, pois os pacotes SYN do TCP serão silenciosamente descartados.
Geralmente, o valor do intervalo de portas para soquetes de saída pode ser configurado na pilha do TCP/IP de um sistema operacional. O mesmo ocorre para configurações de TIME_WAIT do TCP e reutilização de soquete. Alterar esses números pode melhorar a escalabilidade. Mas, dependendo da situação, essas alterações podem causar problemas de interoperabilidade. Tenha cuidado ao alterar esses valores.
Use TIME_WAIT Assassination para resolver essa limitação de escala. TIME_WAIT Assassination 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 de TIME_WAIT. Esse recurso é compatível com as VMs do Windows no Azure. Para saber mais sobre a compatibilidade com outras VMs, verifique com o fornecedor do sistema operacional.
Para saber mais sobre como configurar o estado de TIME_WAIT do 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 oferece uma variedade de tamanhos e tipos de VM, cada um com uma combinação diferente de funcionalidades de desempenho. Uma dessas funcionalidades de desempenho está a taxa de transferência de rede (ou largura de banda), medida em megabits por segundo (Mbps). Como as máquinas virtuais são hospedadas em um hardware compartilhado, a capacidade de rede deve ser compartilhada adequadamente entre as máquinas virtuais que usam o mesmo hardware. Máquinas virtuais maiores recebem mais largura de banda que máquinas virtuais menores.
A largura de banda de rede alocada a cada máquina virtual é limitada no tráfego de saída (saída) da máquina virtual. Todo o tráfego de rede que deixa a máquina virtual é contado para o limite alocado, independentemente do destino. Por exemplo, se uma máquina virtual tem um limite de 1.000 Mbps, esse limite se aplica se o tráfego de saída é destinado a outra máquina virtual na mesma rede virtual ou fora do Azure.
A entrada não é 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 criada para melhorar o desempenho de rede, incluindo latência, taxa de transferência e utilização da CPU. A rede acelerada possa melhorar a taxa de transferência de uma máquina virtual, mas ela poderá fazer isso somente até a largura de banda alocada da máquina virtual.
As máquinas virtuais do Azure têm pelo menos um adaptador de rede anexado. Elas podem ter vários. A largura de banda alocada a uma máquina virtual é a soma de todo o tráfego de saída em todos os adaptadores de rede anexados à máquina. Em outras palavras, a largura de banda é alocada por máquina virtual, independentemente de quantos adaptadores de rede estão anexados à máquina.
A taxa de transferência de saída esperada e o número de interfaces de rede com suporte em cada tamanho de VM são detalhados em Tamanhos das máquinas virtuais do Windows no Azure. Para ver a taxa de transferência máxima, selecione um tipo, como uso 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 "Máximo de NICs/largura de banda de rede esperada (Mbps)".
O limite de taxa de transferência se aplica à máquina virtual. A taxa de transferência não é afetada por esses fatores:
Número de adaptadores de rede: o limite de largura de banda se aplica à soma de todo o tráfego de saída da máquina virtual.
Rede acelerada: embora o recurso possa ser útil para alcançar 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 contam para o limite.
Para obter mais informações, consulte a Largura de banda da rede de máquina virtual.
Considerações sobre o desempenho da Internet
Conforme discutido no 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 de extremidade pode ser afetado por problemas em redes intermediárias, pelo tráfego que não faz o caminho de distância "mais curto" e por caminhos de emparelhamento abaixo do ideal.
Perda de pacotes: a perda de pacotes pode ser causada por congestionamento de rede, problemas de caminho físico e por dispositivos de rede com execução insatisfatória.
Tamanho/fragmentação de MTU: 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 dos pacotes.
O Rastreamento de rotas é uma boa ferramenta para medir as características de desempenho da rede (como latência e perda de pacotes) ao longo de cada caminho de rede entre um dispositivo de origem e um dispositivo de destino.
Considerações sobre a criação da rede virtual
Junto com as considerações discutidas anteriormente neste artigo, a topologia de uma rede virtual pode afetar o desempenho da rede. Por exemplo, um design de Hub e Spoke que redireciona o tráfego globalmente para uma rede virtual de hub único apresentará latência de rede, afetando o desempenho geral da rede.
O número de dispositivos de rede que o tráfego de rede atravessa também pode afetar a latência geral. Por exemplo, em um design hub-and-spoke, se o tráfego passar por uma solução de virtualização de rede spoke e uma solução de virtualização de hub antes de transitar para a internet, os dispositivos virtuais de rede apresentarão alguma latência.
Regiões do Azure, redes virtuais e latência
As regiões do Azure são formadas por vários datacenters dentro de uma área geográfica geral. Esses datacenters podem não estar fisicamente próximos um do outro. Em alguns casos, eles estão a até 10 quilômetros de distância. A rede virtual é uma sobreposição lógica na rede do datacenter físico do Azure. Uma rede virtual não resulta em nenhuma topologia de rede específica no datacenter.
Por exemplo, duas VMs que estão na mesma rede e sub-rede virtual podem estar em diferentes racks, linhas ou até mesmo datacenters. Elas podem ser separadas por pés ou quilômetros de cabo de fibra ótica. Essa variação pode apresentar latência variável (diferença de alguns milissegundos) entre VMs diferentes.
A colocação geográfica das VMs e a possível latência resultante entre as duas VMs podem ser influenciadas 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.
Esgotamento de porta NAT de origem
Uma implantação no Azure pode se comunicar com pontos de extremidade fora do Azure, na internet pública ou no espaço de endereços 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 de saída originado também pode alcançar o endereço IP privado onde o fluxo foi originado.
Para cada conexão de saída, o Azure Load Balancer precisa manter o mapeamento por um período de tempo. Com a natureza de multilocatário do Azure, manter esse mapeamento para cada fluxo de saída de todas as VMs pode consumir muitos recursos. Portanto, há limites definidos e baseados na configuração da rede virtual do Azure. Ou, para ser mais preciso, uma VM do Azure só pode fazer um determinado número de conexões de saída em um determinado momento. Quando o limite for atingido, a VM não poderá fazer mais conexões de saída.
Mas esse comportamento pode ser configurado. Para obter mais informações sobre SNAT e esgotamento de porta SNAT, consulte este artigo.
Medir o desempenho de rede no Azure
Vários dos números 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 o desempenho da rede de VM. Ajuste e teste o desempenho dos valores do TCP/IP e de rede discutidos anteriormente usando as técnicas descritas nesta seção. Adicione os valores de latência, MTU, MSS e tamanho da janela nos cálculos fornecidos anteriormente e compare os máximos hipotéticos aos valores reais observados durante o teste.
Medir 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 no Linux fornece a maneira mais fácil de medir a perda de RTT e de pacotes. A saída do PING mostrará a latência mínima/máxima/média entre uma origem e um destino. Ela também mostrará a perda de pacotes. O PING usa o protocolo ICMP por padrão. Use PsPing para testar o RTT do TCP. Para saber mais, consulte PsPing.
Nem os pings ICMP nem TCP medem o datapath de rede acelerada. 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 diretrizes.
Para obter mais detalhes sobre como testar outros cenários, consulte estes artigos:
Detectar comportamentos ineficientes do TCP
Em capturas de pacotes, os clientes do Azure podem ver pacotes do TCP com sinalizadores (SACK, confirmação de DUP, retransmissão e retransmissão rápida) que podem indicar problemas de desempenho da rede. Esses pacotes indicam especificamente as ineficiências de rede que resultam da perda de pacotes. Mas a perda de pacotes não é necessariamente causada por problemas de desempenho do Azure. Problemas de desempenho podem ser resultado de problemas de aplicativo, sistema operacional ou outros que podem não estar diretamente relacionados à plataforma do Azure.
Além disso, é normal ter algumas confirmações duplicadas e de retransmissão em uma rede. Os protocolos do TCP foram criados para serem confiáveis. A evidência desses pacotes do TCP em uma captura de pacotes não indica necessariamente problemas na rede do sistema, a menos que eles sejam excessivos.
Ainda assim, esses tipos de pacotes indicam que a taxa de transferência do TCP não está atingindo seu desempenho máximo, por motivos discutidos em outras seções deste artigo.
Próximas etapas
Agora que você aprendeu sobre o ajuste de desempenho do TCP/IP para VMs do Azure, talvez queira ler sobre outras considerações para planejar redes virtuais ou saber mais sobre como conectar e configurar redes virtuais.