Ligações de saída (Clássico)

O Azure fornece conectividade de saída para implementações de clientes através de vários mecanismos diferentes. Este artigo descreve quais são os cenários, quando se aplicam, como funcionam e como geri-los.

Nota

Este artigo abrange apenas implementações clássicas. Veja Ligações de saída para todos os cenários de implementação Resource Manager no Azure.

Uma implementação no Azure pode comunicar com pontos finais fora do Azure no espaço de endereços IP público. Quando uma instância inicia um fluxo de saída para um destino no espaço de endereços IP públicos, o Azure mapeia dinamicamente o endereço IP privado para um endereço IP público. Após a criação deste mapeamento, o tráfego devolvido para este fluxo com origem de saída também pode chegar ao endereço IP privado de origem do fluxo.

O Azure utiliza a tradução de endereços de rede de origem (SNAT) para executar esta função. Quando vários endereços IP privados estão disfarçados atrás de um único endereço IP público, o Azure utiliza a tradução de endereços de porta (PAT) para mascarar endereços IP privados. As portas efémeras são utilizadas para PAT e são pré-instaladas com base no tamanho do conjunto.

Existem vários cenários de saída. Pode combinar estes cenários conforme necessário. Reveja-as cuidadosamente para compreender as capacidades, restrições e padrões à medida que se aplicam ao seu modelo de implementação e cenário de aplicação. Veja as orientações para gerir estes cenários.

Scenario overview (Descrição geral do cenário)

O Azure fornece três métodos diferentes para alcançar a conectividade de saída Implementações clássicas. Nem todas as implementações clássicas têm os três cenários disponíveis:

Scenario	Método	Protocolos IP	Description	Função de Trabalho Web	IaaS
1. VM com um endereço IP Público ao Nível da Instância	SNAT, masquerading de porta não utilizado	TCP, UDP, ICMP, ESP	O Azure utiliza o IP público atribuído à Máquina Virtual. A instância tem todas as portas efémeras disponíveis.	No	Yes
2. Ponto final com balanceamento de carga público	SNAT com disquerading de porta (PAT) para o ponto final público	TCP, UDP	O Azure partilha o ponto final público do endereço IP público com vários pontos finais privados. O Azure utiliza portas efémeras do ponto final público para PAT.	Yes	Yes
3. VM autónoma	SNAT com disquerading de porta (PAT)	TCP, UDP	O Azure designa automaticamente um endereço IP público para SNAT, partilha este endereço IP público com toda a implementação e utiliza portas efémeras do endereço IP do ponto final público para PAT. Este é um cenário de contingência para os cenários anteriores. Não o recomendamos se precisar de visibilidade e controlo.	Yes	Yes

Este é um subconjunto de funcionalidades de ligação de saída disponíveis para implementações Resource Manager no Azure.

As diferentes implementações no Clássico têm diferentes funcionalidades:

Implementação clássica	Funcionalidade disponível
Máquina Virtual	cenário 1, 2 ou 3
Função de Trabalho Web	único cenário 2, 3

As estratégias de mitigação também têm as mesmas diferenças.

O algoritmo utilizado para pré-instalar portas efémeras para PAT para implementações clássicas é o mesmo que para implementações de recursos Resource Manager do Azure.

Cenário 1: VM com um endereço IP Público ao Nível da Instância

Neste cenário, a VM tem um IP Público ao Nível da Instância (ILPIP) atribuído ao mesmo. No que diz respeito às ligações de saída, não importa se a VM tem ou não um ponto final com balanceamento de carga. Este cenário tem precedência sobre os outros. Quando é utilizado um ILPIP, a VM utiliza o ILPIP para todos os fluxos de saída.

Um IP público atribuído a uma VM é uma relação 1:1 (em vez de 1:muitos) e implementado como um NAT sem estado 1:1. A disquerading de porta (PAT) não é utilizada e a VM tem todas as portas efémeras disponíveis para utilização.

Se a sua aplicação iniciar muitos fluxos de saída e ocorrer esgotamento da porta SNAT, considere atribuir um ILPIP para mitigar as restrições de SNAT. Reveja Gerir o esgotamento do SNAT na sua totalidade.

Cenário 2: Ponto final com balanceamento de carga público

Neste cenário, a VM ou a Função de Trabalho Web está associada a um endereço IP público através do ponto final com balanceamento de carga. A VM não tem um endereço IP público atribuído.

Quando a VM com balanceamento de carga cria um fluxo de saída, o Azure traduz o endereço IP de origem privada do fluxo de saída para o endereço IP público do ponto final com balanceamento de carga público. O Azure utiliza o SNAT para executar esta função. O Azure também utiliza o PAT para mascarar vários endereços IP privados por trás de um endereço IP público.

As portas efémeras do front-end do endereço IP público do balanceador de carga são utilizadas para distinguir fluxos individuais originados pela VM. O SNAT utiliza dinamicamente portas efémeras pré-instaladas quando são criados fluxos de saída. Neste contexto, as portas efémeras utilizadas para SNAT são denominadas portas SNAT.

As portas SNAT são pré-instaladas conforme descrito na secção Understanding SNAT and PAT (Compreender o SNAT e o PAT ). São um recurso finito que pode ser esgotado. É importante compreender como são consumidos. Para compreender como conceber este consumo e mitigar conforme necessário, veja Gerir o esgotamento do SNAT.

Quando existem vários pontos finais com balanceamento de carga público , qualquer um destes endereços IP públicos é candidato a fluxos de saída e um é selecionado aleatoriamente.

Cenário 3: Não existe nenhum endereço IP público associado

Neste cenário, a VM ou o ROle de Trabalho Web não fazem parte de um ponto final com balanceamento de carga público. No caso da VM, não tem um endereço ILPIP atribuído. Quando a VM cria um fluxo de saída, o Azure traduz o endereço IP de origem privada do fluxo de saída para um endereço IP de origem pública. O endereço IP público utilizado para este fluxo de saída não é configurável e não conta com o limite de recursos ip públicos da subscrição. O Azure atribui automaticamente este endereço.

O Azure utiliza o SNAT com a disquerading de porta (PAT) para efetuar esta função. Este cenário é semelhante ao cenário 2, exceto que não existe controlo sobre o endereço IP utilizado. Este é um cenário de contingência para quando os cenários 1 e 2 não existem. Não recomendamos este cenário se quiser controlar o endereço de saída. Se as ligações de saída forem uma parte crítica da sua aplicação, deve escolher outro cenário.

As portas SNAT são pré-instaladas conforme descrito na secção Understanding SNAT and PAT (Compreender o SNAT e o PAT ). O número de VMs ou Funções de Trabalho Web que partilham o endereço IP público determina o número de portas efémeras pré-instaladas. É importante compreender como são consumidos. Para compreender como conceber este consumo e mitigar conforme necessário, veja Gerir o esgotamento do SNAT.

Compreender o SNAT e o PAT

Port masquerading SNAT (PAT)

Quando uma implementação faz uma ligação de saída, cada origem de ligação de saída é reescrita. A origem é reescrita do espaço de endereços IP privado para o IP público associado à implementação (com base nos cenários descritos acima). No espaço de endereços IP públicos, a cadeia de 5 cadeias de identificação do fluxo (endereço IP de origem, porta de origem, protocolo de transporte IP, endereço IP de destino, porta de destino) tem de ser exclusiva.

As portas efémeras (portas SNAT) são utilizadas para o conseguir depois de reescrever o endereço IP de origem privada, porque vários fluxos têm origem num único endereço IP público.

Uma porta SNAT é consumida por fluxo para um único endereço IP de destino, porta e protocolo. Para vários fluxos para o mesmo endereço IP de destino, porta e protocolo, cada fluxo consome uma única porta SNAT. Isto garante que os fluxos são exclusivos quando têm origem no mesmo endereço IP público e acedem ao mesmo endereço IP de destino, porta e protocolo.

Vários fluxos, cada um para um endereço IP de destino diferente, porta e protocolo, partilham uma única porta SNAT. O endereço IP de destino, a porta e o protocolo tornam os fluxos exclusivos sem a necessidade de portas de origem adicionais para distinguir fluxos no espaço de endereços IP públicos.

Quando os recursos da porta SNAT estão esgotados, os fluxos de saída falham até que os fluxos existentes libertem portas SNAT. Balanceador de Carga recupera as portas SNAT quando o fluxo fecha e utiliza um tempo limite de inatividade de 4 minutos para recuperar portas SNAT de fluxos inativos.

Para obter padrões para mitigar condições que normalmente levam ao esgotamento da porta SNAT, veja a secção Gerir SNAT .

Pré-instalação da porta efémera para sNAT de masqueding de porta (PAT)

O Azure utiliza um algoritmo para determinar o número de portas SNAT pré-instaladas disponíveis com base no tamanho do conjunto de back-end ao utilizar o SNAT de configuração de porta (PAT). As portas SNAT são portas efémeras disponíveis para um determinado endereço de origem de IP público.

O Azure pré-instala portas SNAT quando uma instância é implementada com base no número de instâncias de Função de Trabalho Web ou VM que partilham um determinado endereço IP público. Quando os fluxos de saída são criados, o PAT consome dinamicamente (até ao limite pré-alocado) e liberta estas portas quando o fluxo fecha ou ocorrem tempos limite inativos.

A tabela seguinte mostra as pré-instalações da porta SNAT para camadas de tamanhos de conjuntos de back-end:

de Instâncias	Portas SNAT pré-instaladas por instância
1-50	1,024
51-100	512
101-200	256
201-400	128

Lembre-se de que o número de portas SNAT disponíveis não se traduz diretamente no número de fluxos. Uma única porta SNAT pode ser reutilizada para vários destinos exclusivos. As portas só são consumidas se for necessário tornar os fluxos exclusivos. Para obter orientações de conceção e mitigação, veja a secção sobre como gerir este recurso exaustivo e a secção que descreve o PAT.

Alterar o tamanho da implementação pode afetar alguns dos fluxos estabelecidos. Se o tamanho do conjunto de back-end aumentar e transitar para o escalão seguinte, metade das portas SNAT pré-alocadas serão recuperadas durante a transição para o escalão de conjunto de back-end maior seguinte. Os fluxos associados a uma porta SNAT recuperada excederão o limite de tempo e têm de ser restabelecidos. Se for tentado um novo fluxo, o fluxo terá êxito imediatamente, desde que as portas pré-instaladas estejam disponíveis.

Se o tamanho da implementação diminuir e transitar para um escalão inferior, o número de portas SNAT disponíveis aumenta. Neste caso, as portas SNAT alocadas existentes e os respetivos fluxos não são afetados.

Se um serviço cloud for reimplementado ou alterado, a infraestrutura poderá comunicar temporariamente que o conjunto de back-end tem até o dobro do tamanho real e o Azure, por sua vez, pré-instalará menos portas SNAT por instância do que o esperado. Isto pode aumentar temporariamente a probabilidade de esgotamento da porta SNAT. Eventualmente, o tamanho do conjunto irá transitar para o tamanho real e o Azure aumentará automaticamente as portas SNAT pré-instaladas para o número esperado de acordo com a tabela acima. Este comportamento é por predefinição e não é configurável.

As alocações de portas SNAT são específicas do protocolo de transporte IP (TCP e UDP são mantidas separadamente) e são lançadas nas seguintes condições:

Versão da porta SNAT TCP

• Se o servidor/cliente enviar FIN/ACK, a porta SNAT será lançada após 240 segundos.
• Se for visto um RST, a porta SNAT será libertada após 15 segundos.
• tempo limite de inatividade foi atingido

Versão da porta UDP SNAT

• tempo limite de inatividade foi atingido

Resolução de problemas

Esta secção destina-se a ajudar a mitigar o esgotamento do SNAT e outros cenários que podem ocorrer com ligações de saída no Azure.

Gerir o esgotamento da porta SNAT (PAT)

As portas efémeras utilizadas para PAT são um recurso exaustivo, conforme descrito em nenhum IP público associado e ponto final com balanceamento de carga público.

Se souber que está a iniciar muitas ligações TCP ou UDP de saída para o mesmo endereço IP de destino e porta, e observar a falha das ligações de saída ou for avisado pelo suporte de que está a esgotar as portas SNAT ( portas efémeras pré-alocadas utilizadas pelo PAT), tem várias opções gerais de mitigação. Reveja estas opções e decida o que está disponível e o melhor para o seu cenário. É possível que um ou mais possam ajudar a gerir este cenário.

Se estiver a ter problemas para compreender o comportamento da ligação de saída, pode utilizar as estatísticas da pilha de IP (netstat). Em alternativa, pode ser útil observar comportamentos de ligação com capturas de pacotes.

Modificar a aplicação para reutilizar ligações

Pode reduzir a procura de portas efémeras utilizadas para o SNAT ao reutilizar ligações na sua aplicação. Isto aplica-se especialmente a protocolos como HTTP/1.1, em que a reutilização da ligação é a predefinição. E outros protocolos que utilizam HTTP como transporte (por exemplo, REST) podem beneficiar por sua vez.

A reutilização é sempre melhor do que as ligações TCP atómicas individuais para cada pedido. Reutilizar resulta em transações TCP mais eficazes e eficazes.

Modificar a aplicação para utilizar os agrupamentos de ligações

Pode utilizar um esquema de agrupamento de ligações na sua aplicação, onde os pedidos são distribuídos internamente por um conjunto fixo de ligações (cada um reutilizando sempre que possível). Este esquema restringe o número de portas efémeras em utilização e cria um ambiente mais previsível. Este esquema também pode aumentar o débito dos pedidos ao permitir várias operações simultâneas quando uma única ligação está a bloquear na resposta de uma operação.

O agrupamento de ligações pode já existir na arquitetura que está a utilizar para desenvolver a sua aplicação ou as definições de configuração da sua aplicação. Pode combinar o conjunto de ligações com a reutilização da ligação. Em seguida, os seus múltiplos pedidos consomem um número fixo e previsível de portas para o mesmo endereço IP de destino e porta. Os pedidos também beneficiam da utilização eficiente de transações TCP, reduzindo a latência e a utilização de recursos. As transações UDP também podem beneficiar, uma vez que a gestão do número de fluxos UDP pode, por sua vez, evitar condições de escape e gerir a utilização da porta SNAT.

Modificar a aplicação para utilizar uma lógica de repetição menos agressiva

Quando as portas efémeras pré-instaladas utilizadas para PAT estão esgotadas ou ocorrem falhas na aplicação, as repetições de força agressiva ou bruta sem lógica de decadência e backoff fazem com que o esgotamento ocorra ou persista. Pode reduzir a procura de portas efémeras com uma lógica de repetição menos agressiva.

As portas efémeras têm um tempo limite de inatividade de 4 minutos (não ajustável). Se as tentativas forem demasiado agressivas, o esgotamento não tem oportunidade de limpar por si só. Por conseguinte, considerar como e com que frequência as transações de repetição da aplicação são uma parte crítica da estrutura.

Atribuir um IP Público ao Nível da Instância a cada VM

Atribuir um ILPIP altera o seu cenário para IP Público ao Nível da Instância para uma VM. Todas as portas efémeras do IP público que são utilizadas para cada VM estão disponíveis para a VM. (Ao contrário dos cenários em que as portas efémeras de um IP público são partilhadas com todas as VMs associadas à respetiva implementação.) Existem contrapartidas a considerar, como o impacto potencial da lista de permissões de um grande número de endereços IP individuais.

Nota

Esta opção não está disponível para funções de trabalho Web.

Utilizar as métricas keep alive para repor o tempo limite de inatividade de saída

As ligações de saída têm um tempo limite de 4 minutos de inatividade. Este tempo limite não é ajustável. No entanto, pode utilizar o transporte (por exemplo, keepalives TCP) ou keepalives de camada de aplicação para atualizar um fluxo inativo e repor este tempo limite inativo, se necessário. Contacte o fornecedor de qualquer software empacotado sobre se é suportado ou como ativá-lo. Geralmente, apenas um lado precisa de gerar keepalives para repor o tempo limite de inatividade.

Descobrir o IP público que uma VM utiliza

Existem muitas formas de determinar o endereço IP de origem pública de uma ligação de saída. O OpenDNS fornece um serviço que lhe pode mostrar o endereço IP público da sua VM.

Ao utilizar o comando nslookup, pode enviar uma consulta DNS para o nome myip.opendns.com para a resolução OpenDNS. O serviço devolve o endereço IP de origem que foi utilizado para enviar a consulta. Quando executa a seguinte consulta a partir da VM, a resposta é o IP público utilizado para essa VM:

nslookup myip.opendns.com resolver1.opendns.com

Passos seguintes

• Saiba mais sobre Balanceador de Carga utilizados em implementações de Resource Manager.
• Modo de aprendizagem sobre cenários de ligação de saída disponíveis em implementações Resource Manager.